Re: [PATCH] avoid undefined behavior in libiberty/cplus-dem.c
On Sun, Jan 06, 2013 at 11:25:44PM -0500, Nickolai Zeldovich wrote:
@@ -494,20 +505,15 @@
while (ISDIGIT ((unsigned char)**type))
{
- count *= 10;
-
- /* Check for overflow.
- We assume that count is represented using two's-complement;
- no power of two is divisible by ten, so if an overflow occurs
- when multiplying by ten, the result will not be a multiple of
- ten. */
- if ((count % 10) != 0)
+ /* Check whether we can add another digit without overflow. */
+ if (count (INT_MAX - 9) / 10)
{
while (ISDIGIT ((unsigned char) **type))
(*type)++;
return -1;
}
+ count *= 10;
count += **type - '0';
(*type)++;
Won't the above preclude parsing 2147483640 up to 2147483647 ?
Because then in the last iteration count 214748364 (INT_MAX - 9) / 10.
Jakub
Re: [committed] 2011 and 2012 Copyright year updates
On Sun, 6 Jan 2013, Jakub Jelinek wrote: On Sun, Jan 06, 2013 at 12:13:32PM +, Richard Sandiford wrote: I never remember to update the copyright years, so I thought I'd have a go. And you were right of course. It ended up being a huge time sink. Anyway, here's my attempt a script to convert to ranges and, if enabled, to include the current year. The script only updates FSF copyright notices and leaves others alone. I've tried my best to make sure that licences and imported FSF sources aren't touched, but I could have missed some cases. Looks reasonable to me, though I'd like to hear richi's and Joseph's opinion too. Certainly fine with me. Richard. I've noticed a minor nit: --- gcc.orig/gcc/testsuite/gcc.misc-tests/linkage.exp +++ gcc/gcc/testsuite/gcc.misc-tests/linkage.exp @@ -1,5 +1,4 @@ -# Copyright (C) 1988, 90-96, 1997, 2000, 2001, 2002, 2007, 2008, 2010, -# 2011, -# 2012 Free Software Foundation, Inc. +# Copyright (C) 90-2012 Free Software Foundation, Inc. That should have been presumably 1988-2012, haven't looked at other similar cases. As for updating to -2013, I think it isn't appropriate for all files, e.g. I'd leave ChangeLog* and various README* files to keep their finish date as is, say ChangeLog.2003 can be just Copyright (c) 2003, doesn't need to be 2003-2013. Perhaps just automatically add -2013 to gcc (except gcc/testsuite) *.[ch], *.md, *.def, *.opt files or so, plus gcc/testsuite *.exp files? E.g. testsuite *.c/*.C files that are Copyright 2004 don't need to be -2013? Also, just a remainder, any Copyright line change in libstdc++-v3/include might potentially require adjustments to libstdc++-v3/testsuite/, because various tests have header line numbers hardcoded in them. Jakub -- Richard Biener rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend
[Patch, Fortran] PR55852 fix ubound /size ICE and cleanup class.c's finalizer
Dear all, the following patch is based on Thomas' comment 5 in PR55852. He independently created a patch for the PR; his version is in comment 6: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852#c6 The problem with the current trunk's version of gfc_build_intrinsic_call is that it assumes that gfc_find_symtree will return the intrinsic function (size in this case); if the user has a different symbol named size or hasn't used size, the code doesn't work. My version is attached. In my version, the gfc_build_intrinsic_call takes gfc_isym_id as identifier for the intrinsic - the passed string is mangled via GFC_PREFIX to avoid issues with symbol declarations of the user. I do set rather bluntly n.sym... = , assuming that under mangled name one always finds this intrinsic function. Besides fixing the ICE, I used the opportunity to cleanup class.c, where I now use gfc_build_intrinsic_call, which is a nice cleanup: 4 files changed, 65 insertions(+), 143 deletions(-) Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias 2013-01-07 Tobias Burnus bur...@net-b.de Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55852 * expr.c (gfc_build_intrinsic_call): Avoid clashes with user's procedures. * gfortran.h (gfc_build_intrinsic_call): Update prototype. * simplify.c (gfc_simplify_size): Update call. * class.c (finalization_scalarizer, finalization_get_offset, finalizer_insert_packed_call, generate_finalization_wrapper): Clean up by using gfc_build_intrinsic_call. 2013-01-07 Tobias Burnus bur...@net-b.de PR fortran/55852 * gfortran.dg/intrinsic_size_3.f90: New. diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 0d34e78..5fdf0a3 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -969,31 +969,6 @@ finalization_scalarizer (gfc_symbol *array, gfc_symbol *ptr, /* The addr part: TRANSFER (C_LOC (array), c_intptr_t). */ - /* TRANSFER. */ - expr2 = gfc_get_expr (); - expr2-expr_type = EXPR_FUNCTION; - expr2-value.function.name = __transfer0; - expr2-value.function.isym - = gfc_intrinsic_function_by_id (GFC_ISYM_TRANSFER); - /* Set symtree for -fdump-parse-tree. */ - gfc_get_sym_tree (transfer, sub_ns, expr2-symtree, false); - expr2-symtree-n.sym-intmod_sym_id = GFC_ISYM_TRANSFER; - expr2-symtree-n.sym-attr.flavor = FL_PROCEDURE; - expr2-symtree-n.sym-attr.intrinsic = 1; - gfc_commit_symbol (expr2-symtree-n.sym); - expr2-value.function.actual = gfc_get_actual_arglist (); - expr2-value.function.actual-expr - = gfc_lval_expr_from_sym (array); - expr2-ts.type = BT_INTEGER; - expr2-ts.kind = gfc_index_integer_kind; - - /* TRANSFER's second argument: 0_c_intptr_t. */ - expr2-value.function.actual = gfc_get_actual_arglist (); - expr2-value.function.actual-next = gfc_get_actual_arglist (); - expr2-value.function.actual-next-expr - = gfc_get_int_expr (gfc_index_integer_kind, NULL, 0); - expr2-value.function.actual-next-next = gfc_get_actual_arglist (); - /* TRANSFER's first argument: C_LOC (array). */ expr = gfc_get_expr (); expr-expr_type = EXPR_FUNCTION; @@ -1010,7 +985,14 @@ finalization_scalarizer (gfc_symbol *array, gfc_symbol *ptr, gfc_commit_symbol (expr-symtree-n.sym); expr-ts.type = BT_INTEGER; expr-ts.kind = gfc_index_integer_kind; - expr2-value.function.actual-expr = expr; + + /* TRANSFER. */ + expr2 = gfc_build_intrinsic_call (sub_ns, GFC_ISYM_TRANSFER, transfer, +gfc_current_locus, 2, expr, +gfc_get_int_expr (gfc_index_integer_kind, + NULL, 0)); + expr2-ts.type = BT_INTEGER; + expr2-ts.kind = gfc_index_integer_kind; /* array addr + offset. */ block-ext.actual-expr = gfc_get_expr (); @@ -1072,27 +1054,18 @@ finalization_get_offset (gfc_symbol *idx, gfc_symbol *idx2, gfc_symbol *offset, * strides(idx2). */ /* mod (idx, sizes(idx2)). */ - expr = gfc_get_expr (); - expr-expr_type = EXPR_FUNCTION; - expr-value.function.isym = gfc_intrinsic_function_by_id (GFC_ISYM_MOD); - gfc_get_sym_tree (mod, sub_ns, expr-symtree, false); - expr-symtree-n.sym-intmod_sym_id = GFC_ISYM_MOD; - expr-symtree-n.sym-attr.flavor = FL_PROCEDURE; - expr-symtree-n.sym-attr.intrinsic = 1; - gfc_commit_symbol (expr-symtree-n.sym); - expr-value.function.actual = gfc_get_actual_arglist (); - expr-value.function.actual-expr = gfc_lval_expr_from_sym (idx); - expr-value.function.actual-next = gfc_get_actual_arglist (); - expr-value.function.actual-next-expr = gfc_lval_expr_from_sym (sizes); - expr-value.function.actual-next-expr-ref = gfc_get_ref (); - expr-value.function.actual-next-expr-ref-type = REF_ARRAY; - expr-value.function.actual-next-expr-ref-u.ar.as = sizes-as; - expr-value.function.actual-next-expr-ref-u.ar.type = AR_ELEMENT; - expr-value.function.actual-next-expr-ref-u.ar.dimen = 1; - expr-value.function.actual-next-expr-ref-u.ar.dimen_type[0] - = DIMEN_ELEMENT; - expr-value.function.actual-next-expr-ref-u.ar.start[0] - =
Re: [PR libmudflap/53359] don't register symbols not emitted
On Sun, Jan 6, 2013 at 8:47 PM, Alexandre Oliva aol...@redhat.com wrote: On Jan 2, 2013, Richard Biener richard.guent...@gmail.com wrote: On Sun, Dec 30, 2012 at 1:22 AM, Alexandre Oliva aol...@redhat.com wrote: On Dec 21, 2012, Richard Biener richard.guent...@gmail.com wrote: On Fri, Dec 21, 2012 at 6:33 AM, Alexandre Oliva aol...@redhat.com wrote: libmudflap emits a global initializer that registers memory ranges for global data symbols. However, even if IPA decides not to emit a symbol because it's unused, we'd still emit registration sequences for them in some cases, which, in the PR testcase, would result in TOC references to the undefined symbols. Hmm, I think that at this point of the compilation you are looking for TREE_ASM_WRITTEN instead. That doesn't work, several mudflap regressions show up because accesses to global library symbols that are accessed by template methods compiled with mudflap (say cout) are then verified but not registered. We have to register symbols that are not emitted but that referenced. Ehm, how can something be not emitted but still referenced? You mean if it's external? Yeah. if (!TREE_ASM_WRITTEN (obj) || DECL_EXTERNAL (obj)) instead? Then we're back to the original bug. How does the test above tell whether we're actually referencing the object? Only when we are do we want to register it with mudflap. If it's referenced and we don't register it, we get mudflap runtime errors. If it's not referenced but we register it, we get link-time errors if the symbol is one we'd have emitted if it was referenced. Then the bug is that we register something but do not actually tell the middle-end that this is a reference. Hmm. I suppose instead of asking for TREE_ASM_WRITTEN you may want to look at DECL_RTL (which should be set for all referenced decls, whether external or not). Richard. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
[PATCH] Fix PR864, apply program_transform_name to ada tools
This makes us unconditionally apply program_transform_name when installing $(ADA_TOOLS). It's a patch distros have been applying for ages (now I've updated it for 4.8 which meant re-writing it completely so I am eligible to submit it). Bootstrapped on x86_64-unknown-linux-gnu with --program-suffix=-4.8, installed (and installation inspected) and tested (which uses the unsuffixed names - names get changed at install time only). Ok for trunk? Thanks, Richard. 2013-01-04 Richard Biener rguent...@suse.de PR ada/864 * gcc-interface/Make-lang.in (ada.install-common): Always apply program_transform_name. Index: gcc/ada/gcc-interface/Make-lang.in === --- gcc/ada/gcc-interface/Make-lang.in (revision 194900) +++ gcc/ada/gcc-interface/Make-lang.in (working copy) @@ -736,14 +736,13 @@ ada.install-common: -if [ -f gnat1$(exeext) ] ; \ then \ for tool in $(ADA_TOOLS) ; do \ + install_name=`echo $$tool|sed '$(program_transform_name)'`$(exeext); \ + $(RM) $(DESTDIR)$(bindir)/$$install_name; \ if [ -f $$tool-cross$(exeext) ] ; \ then \ - install_name=`echo $$tool|sed '$(program_transform_name)'`$(exeext); \ - $(RM) $(DESTDIR)$(bindir)/$$install_name; \ $(INSTALL_PROGRAM) $$tool-cross$(exeext) $(DESTDIR)$(bindir)/$$install_name; \ else \ - $(RM) $(DESTDIR)$(bindir)/$$tool$(exeext); \ - $(INSTALL_PROGRAM) $$tool$(exeext) $(DESTDIR)$(bindir)/$$tool$(exeext); \ + $(INSTALL_PROGRAM) $$tool$(exeext) $(DESTDIR)$(bindir)/$$install_name; \ fi ; \ done; \ $(RM) $(DESTDIR)$(bindir)/gnatdll$(exeext); \
Re: [PATCH] Fix PR864, apply program_transform_name to ada tools
This makes us unconditionally apply program_transform_name when installing $(ADA_TOOLS). It's a patch distros have been applying for ages (now I've updated it for 4.8 which meant re-writing it completely so I am eligible to submit it). Bootstrapped on x86_64-unknown-linux-gnu with --program-suffix=-4.8, installed (and installation inspected) and tested (which uses the unsuffixed names - names get changed at install time only). Ok for trunk? OK, thanks. 2013-01-04 Richard Biener rguent...@suse.de PR ada/864 * gcc-interface/Make-lang.in (ada.install-common): Always apply program_transform_name.
[PATCH] Fix PR55876 - Make generation of paradoxical subreg in widen_operand more robust
[with CC to gcc-patches]
Original Message
Subject: [PATCH] Fix PR55876 - Make generation of paradoxical subreg in
widen_operand more robust
Date: Mon, 07 Jan 2013 11:13:49 +0100
From: Tom de Vries tom_devr...@mentor.com
To: Richard Henderson r...@redhat.com
CC: Steve Ellcey sell...@mips.com, Andrew Pinski pins...@gmail.com
Richard,
Consider test-case test.c:
...
static inline unsigned char
bar (const char *b)
{
unsigned char used = 0;
int i;
for (i = 0; i 4; ++i)
if (b[i] != 'F')
used = 1;
return used;
}
static char buffer[8];
unsigned char
foo (void)
{
return bar (buffer) ? 0 : 1;
}
...
When compiling test.c with a mips compiler, this ICE triggers:
...
$ ./install/bin/mips-linux-gnu-gcc -O3 test.c -S -mabi=64 -march=mips64
test.c: In function 'foo':
test.c:19:3: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:776
return bar (buffer) ? 0 : 1;
...
The ICE is introduced by revision r193539 discussed at
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01148.html .
The representation of foo just before expand is this:
...
foo ()
{
unsigned charD.13 usedD.1407;
charD.2 _7;
unsigned charD.13 _13;
charD.2 _19;
charD.2 _28;
charD.2 _37;
;; basic block 2, loop depth 0
;;pred: ENTRY
# VUSE .MEM_1(D)
_19 = MEM[(const charD.2 *)bufferD.1387];
used_20 = _19 != 70 ? 1 : 0;
# VUSE .MEM_1(D)
_28 = MEM[(const charD.2 *)bufferD.1387 + 1B];
used_29 = _28 == 70 ? used_20 : 1;
# VUSE .MEM_1(D)
_37 = MEM[(const charD.2 *)bufferD.1387 + 2B];
used_38 = _37 == 70 ? used_29 : 1;
# VUSE .MEM_1(D)
_7 = MEM[(const charD.2 *)bufferD.1387 + 3B];
used_10 = _7 == 70 ? used_38 : 1;
_13 = used_10 ^ 1;
# VUSE .MEM_1(D)
return _13;
;;succ: EXIT
}
...
The used_10 operand is in a DImode reg because r193539 allows it to be promoted
while expanding
used_10 = _7 == 70 ? used_38 : 1
in expand_cond_expr_using_cmove.
The ICE happens during expansion of
_13 = used_10 ^ 1
when trying to widen the DIMode reg for use_10 from QImode to SImode:
...
#6 0x085d7da5 in widen_operand (op=0xf7cd2ec0, mode=SImode, oldmode=QImode,
unsignedp=1, no_extend=1) at
/home/vries/local/mips/upstream/src/gcc-mainline/gcc/optabs.c:333
333 return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
(gdb) call debug_rtx (op)
(reg:DI 222 [ used+-7 ])
...
And although the comment in widen_operand states that we're generating a
paradoxical subreg:
...
/* If MODE is no wider than a single word, we return a paradoxical
SUBREG. */
if (GET_MODE_SIZE (mode) = UNITS_PER_WORD)
return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
...
it's not because mode == SImode and GET_MODE (op) == DImode.
Then validate_subreg triggers the ICE in gen_rtx_SUBREG by returning false here:
...
/* For pseudo registers, we want most of the same checks. Namely:
If the register no larger than a word, the subreg must be lowpart.
If the register is larger than a word, the subreg must be the lowpart
of a subword. A subreg does *not* perform arbitrary bit extraction.
Given that we've already checked mode/offset alignment, we only have
to check subword subregs here. */
if (osize UNITS_PER_WORD
! (lra_in_progress (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode
{
enum machine_mode wmode = isize UNITS_PER_WORD ? word_mode : imode;
unsigned int low_off = subreg_lowpart_offset (omode, wmode);
if (offset % UNITS_PER_WORD != low_off)
return false;
}
...
For a valid pseudo subreg with outer mode SImode and inner mode DImode we need
the offset corresponding to the lowpart, which is 4 for -EB. But since we were
trying to generate a paradoxical subreg, the offset is 0. This explains why the
assert doesn't trigger with -EL.
Attached patch (build and tested for target mips-linux-gnu) prevents the ICE by
checking in widen_operand whether the result of the gen_rtx_SUBREG call would
indeed be a paradoxical subreg. As a consequence, it handles this case now here:
...
/* Otherwise, get an object of MODE, clobber it, and set the low-order
part to OP. */
result = gen_reg_rtx (mode);
emit_clobber (result);
emit_move_insn (gen_lowpart (GET_MODE (op), result), op);
return result;
...
So the generated code is this:
...
(insn 34 33 35 2 (clobber (reg:SI 228)) -1
(nil))
(insn 35 34 36 2 (set (subreg:DI (reg:SI 228) 0)
(reg:DI 222 [ usedD.1407+-7 ])) -1
(nil))
(insn 36 35 37 2 (set (reg:SI 229)
(xor:SI (reg:SI 228)
(const_int 1 [0x1]))) -1
...
which is correct.
I've just realized that this is probably a too conservative fix. Using this
patch:
...
Index: gcc/optabs.c
===
--- gcc/optabs.c (revision 194898)
+++ gcc/optabs.c (working copy)
@@ -327,10 +327,15 @@ widen_operand (rtx op, enum machine_mode
SUBREG_PROMOTED_UNSIGNED_P (op) == unsignedp))
return
RE: [PATCH][ARM][1/3] Add vectorization support for rounding functions
Ping. http://gcc.gnu.org/ml/gcc-patches/2012-12/msg0.html Thanks, Kyrill -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 18 December 2012 13:33 To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw Subject: [PATCH][ARM][1/3] Add vectorization support for rounding functions Hi all, This patch does some refactoring by moving the definitions of the NEON builtins to a separate file (arm_neon_builtins.def) and includes that when initialising the neon_builtin_data array and also during the definition of enum arm_builtins (with appropriate redefinitions of the VAR* macros). This allows us to have symbolic names for the neon builtins that allows us to look up their declaration in arm_builtin_decls. This is needed for vectorisation support in the next patch. The ARM_BUILTIN_NEON_BASE constant which was defined as part of the arm_builtins enum is now defined as a macro, since various functions that deal with the initialisation and expansion of builtins use it. No regressions on arm-none-eabi with model. Ok for trunk? Thanks, Kyrill gcc/ChangeLog 2012-12-18 Kyrylo Tkachov kyrylo.tkachov at arm.com * config/arm/arm_neon_builtins.def: New file. * config/arm/arm.c (neon_builtin_data): Move contents to arm_neon_builtins.def. (enum arm_builtins): Include neon builtin definitions. (ARM_BUILTIN_NEON_BASE): Move from enum to macro.
RE: [PATCH][ARM][2/3] Add vectorization support for rounding functions
Ping. http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01113.html Thanks, Kyrill -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches- ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov Sent: 18 December 2012 13:34 To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw Subject: [PATCH][ARM][2/3] Add vectorization support for rounding functions Hi all, This patch adds support for the vectorisation of the rounding functions: floorf, ceilf, truncf, roundf. These can be implemented using the ARMv8 NEON instructions: vrintm, vrintp, vrintz, vrinta. This is done by defining the TARGET_VECTORIZE_BUILTINS and TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION macros and the function arm_builtin_vectorized_function that returns the decl of the vector form of a builtin function, or NULL_TREE if no vector variant exists. No regressions on arm-none-eabi with AEM. Ok for trunk? gcc/ChangeLog 2012-12-18 Kyrylo Tkachov kyrylo.tkachov at arm.com * config/arm/arm-protos.h (arm_builtin_vectorized_function): New function prototype. * config/arm/arm.c (TARGET_VECTORIZE_BUILTINS): Define. (TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION): Likewise. (arm_builtin_vectorized_function): New function.
[AARCH64] Add support for vector and scalar floating-point immediate loads.
Hi,
Currently, the AArch64 port loads all floating-point values via a
constant pool. For some cases, we can do a better job.
This patch adds support for loading immediates which are either +0.0
or a value which can be represented in a quarter-precision format.
That is to say, an 8-bit floating-point value with 4-bit mantissa,
3-bit exponent and 1-bit sign.
We add the support for both scalar and vector loads of these constants.
I've tested the patch on aarch64-none-elf with no regressions.
Is this OK to commit?
Thanks,
James Greenhalgh
---
gcc/
2013-01-07 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-protos.h
(aarch64_const_double_zero_rtx_p): Rename to...
(aarch64_float_const_zero_rtx_p): ...this.
(aarch64_float_const_representable_p): New.
(aarch64_output_simd_mov_immediate): Likewise.
* config/aarch64/aarch64-simd.md (*aarch64_simd_movmode): Refactor
move immediate case.
* config/aarch64/aarch64.c
(aarch64_const_double_zero_rtx_p): Rename to...
(aarch64_float_const_zero_rtx_p): ...this.
(aarch64_print_operand): Allow printing of new constants.
(aarch64_valid_floating_const): New.
(aarch64_legitimate_constant_p): Check for valid floating-point
constants.
(aarch64_simd_valid_immediate): Likewise.
(aarch64_vect_float_const_representable_p): New.
(aarch64_float_const_representable_p): Likewise.
(aarch64_simd_imm_zero_p): Also allow for floating-point 0.0.
(aarch64_output_simd_mov_immediate): New.
* config/aarch64/aarch64.md (*movsf_aarch64): Add new alternative.
(*movdf_aarch64): Likewise.
* config/aarch64/constraints.md (Ufc): New.
(Y): call aarch64_float_const_zero_rtx.
* config/aarch64/predicates.md (aarch64_fp_compare_operand): New.
gcc/testsuite/
2013-01-07 James Greenhalgh james.greenha...@arm.com
* gcc.target/aarch64/fmovd.c: New.
* gcc.target/aarch64/fmovf.c: Likewise.
* gcc.target/aarch64/fmovd-zero.c: Likewise.
* gcc.target/aarch64/fmovf-zero.c: Likewise.
* gcc.target/aarch64/vect-fmovd.c: Likewise.
* gcc.target/aarch64/vect-fmovf.c: Likewise.
* gcc.target/aarch64/vect-fmovd-zero.c: Likewise.
* gcc.target/aarch64/vect-fmovf-zero.c: Likewise.
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index bcd3bb1..5c9404d 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -136,7 +136,7 @@ struct tune_params
HOST_WIDE_INT aarch64_initial_elimination_offset (unsigned, unsigned);
bool aarch64_bitmask_imm (HOST_WIDE_INT val, enum machine_mode);
-bool aarch64_const_double_zero_rtx_p (rtx);
+bool aarch64_float_const_zero_rtx_p (rtx);
bool aarch64_constant_address_p (rtx);
bool aarch64_function_arg_regno_p (unsigned);
bool aarch64_gen_movmemqi (rtx *);
@@ -215,6 +215,9 @@ void aarch64_split_128bit_move (rtx, rtx);
bool aarch64_split_128bit_move_p (rtx, rtx);
+/* Check for a legitimate floating point constant for FMOV. */
+bool aarch64_float_const_representable_p (rtx);
+
#if defined (RTX_CODE)
bool aarch64_legitimate_address_p (enum machine_mode, rtx, RTX_CODE, bool);
@@ -246,4 +249,5 @@ extern void aarch64_expand_vec_perm (rtx target, rtx op0, rtx op1, rtx sel);
extern bool
aarch64_expand_vec_perm_const (rtx target, rtx op0, rtx op1, rtx sel);
+char* aarch64_output_simd_mov_immediate (rtx *, enum machine_mode, unsigned);
#endif /* GCC_AARCH64_PROTOS_H */
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index febf71d..d4b52c3 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -394,34 +394,8 @@
case 4: return ins\t%0.d[0], %1;
case 5: return mov\t%0, %1;
case 6:
- {
- int is_valid;
- unsigned char widthc;
- int width;
- static char templ[40];
- int shift = 0, mvn = 0;
- const char *mnemonic;
- int length = 0;
-
- is_valid =
- aarch64_simd_immediate_valid_for_move (operands[1], MODEmode,
- operands[1], width, widthc,
- mvn, shift);
- gcc_assert (is_valid != 0);
-
- mnemonic = mvn ? mvni : movi;
- if (widthc != 'd')
- length += snprintf (templ, sizeof (templ),
- %s\t%%0.%d%c, %%1,
- mnemonic, 64 / width, widthc);
- else
- length += snprintf (templ, sizeof (templ), %s\t%%d0, %%1, mnemonic);
-
- if (shift != 0)
- length += snprintf (templ + length, sizeof (templ) - length,
- , lsl %d, shift);
- return templ;
- }
+ return aarch64_output_simd_mov_immediate (operands[1],
+ MODEmode, 64);
default: gcc_unreachable ();
}
}
@@ -438,39 +412,19 @@
(register_operand (operands[0], MODEmode)
|| register_operand (operands[1], MODEmode))
{
- switch (which_alternative)
- {
- case 0: return ld1\t{%0.Vtype}, %1;
- case 1: return st1\t{%1.Vtype}, %0;
-
Re: [Ada] Remove dead code in elaborate_entity
Pasto: applied on mainline only.
Similar patch that removes a useless test (always true) and adjust a comment.
Tested on x86_64-suse-linux, applied on mainline.
2013-01-07 Eric Botcazou ebotca...@adacore.com
* gcc-interface/decl.c (gnat_to_gnu_entity) E_Record_Type: Adjust
comment about type extension with discriminants.
E_Record_Subtype: Remove useless test and reorder conditions.
(elaborate_entity) E_Record_Subtype: Likewise.
--
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 194964)
+++ gcc-interface/decl.c (working copy)
@@ -3006,9 +3006,9 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
tree gnu_parent;
/* A major complexity here is that the parent subtype will
- reference our discriminants in its Discriminant_Constraint
- list. But those must reference the parent component of this
- record which is of the parent subtype we have not built yet!
+ reference our discriminants in its Stored_Constraint list.
+ But those must reference the parent component of this record
+ which is precisely of the parent subtype we have not built yet!
To break the circle we first build a dummy COMPONENT_REF which
represents the get to the parent operation and initialize
each of those discriminants to a COMPONENT_REF of the above
@@ -3287,9 +3287,8 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
if (IN (Ekind (gnat_base_type), Record_Kind)
!Is_Unchecked_Union (gnat_base_type)
!Is_For_Access_Subtype (gnat_entity)
- Is_Constrained (gnat_entity)
Has_Discriminants (gnat_entity)
- Present (Discriminant_Constraint (gnat_entity))
+ Is_Constrained (gnat_entity)
Stored_Constraint (gnat_entity) != No_Elist)
{
vecsubst_pair gnu_subst_list
@@ -5948,9 +5947,7 @@ elaborate_entity (Entity_Id gnat_entity)
case E_Private_Subtype:
case E_Limited_Private_Subtype:
case E_Record_Subtype_With_Private:
- if (Is_Constrained (gnat_entity)
- Has_Discriminants (gnat_entity)
- Present (Discriminant_Constraint (gnat_entity)))
+ if (Has_Discriminants (gnat_entity) Is_Constrained (gnat_entity))
{
Node_Id gnat_discriminant_expr;
Entity_Id gnat_field;
[AArch64] Make argument of ld1 intrinsics const.
Hi,
This patch fixes the definitions of the vld1* intrinsics
to take a const-qualified argument.
I've tested this on aarch64-none-elf with no regressions.
Is this OK to commit?
Thanks,
James Greenhalgh
---
2013-01-07 James Greenhalgh james.greenha...@arm.com
* config/aarch64/arm_neon.h (vld1_dup_*): Make argument const.
(vld1q_dup_*): Likewise.
(vld1_*): Likewise.
(vld1q_*): Likewise.
(vld1_lane_*): Likewise.
(vld1q_lane_*): Likewise.
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index e8fafa6..21fa428 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -8387,7 +8387,7 @@ vhsubq_u32 (uint32x4_t a, uint32x4_t b)
}
__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
-vld1_dup_f32 (float32_t * a)
+vld1_dup_f32 (const float32_t * a)
{
float32x2_t result;
__asm__ (ld1r {%0.2s},[%1]
@@ -8398,7 +8398,7 @@ vld1_dup_f32 (float32_t * a)
}
__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
-vld1_dup_f64 (float64_t * a)
+vld1_dup_f64 (const float64_t * a)
{
float64x1_t result;
__asm__ (ld1 {%0.1d},[%1]
@@ -8409,7 +8409,7 @@ vld1_dup_f64 (float64_t * a)
}
__extension__ static __inline poly8x8_t __attribute__ ((__always_inline__))
-vld1_dup_p8 (poly8_t * a)
+vld1_dup_p8 (const poly8_t * a)
{
poly8x8_t result;
__asm__ (ld1r {%0.8b},[%1]
@@ -8420,7 +8420,7 @@ vld1_dup_p8 (poly8_t * a)
}
__extension__ static __inline poly16x4_t __attribute__ ((__always_inline__))
-vld1_dup_p16 (poly16_t * a)
+vld1_dup_p16 (const poly16_t * a)
{
poly16x4_t result;
__asm__ (ld1r {%0.4h},[%1]
@@ -8431,7 +8431,7 @@ vld1_dup_p16 (poly16_t * a)
}
__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
-vld1_dup_s8 (int8_t * a)
+vld1_dup_s8 (const int8_t * a)
{
int8x8_t result;
__asm__ (ld1r {%0.8b},[%1]
@@ -8442,7 +8442,7 @@ vld1_dup_s8 (int8_t * a)
}
__extension__ static __inline int16x4_t __attribute__ ((__always_inline__))
-vld1_dup_s16 (int16_t * a)
+vld1_dup_s16 (const int16_t * a)
{
int16x4_t result;
__asm__ (ld1r {%0.4h},[%1]
@@ -8453,7 +8453,7 @@ vld1_dup_s16 (int16_t * a)
}
__extension__ static __inline int32x2_t __attribute__ ((__always_inline__))
-vld1_dup_s32 (int32_t * a)
+vld1_dup_s32 (const int32_t * a)
{
int32x2_t result;
__asm__ (ld1r {%0.2s},[%1]
@@ -8464,7 +8464,7 @@ vld1_dup_s32 (int32_t * a)
}
__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
-vld1_dup_s64 (int64_t * a)
+vld1_dup_s64 (const int64_t * a)
{
int64x1_t result;
__asm__ (ld1 {%0.1d},[%1]
@@ -8475,7 +8475,7 @@ vld1_dup_s64 (int64_t * a)
}
__extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
-vld1_dup_u8 (uint8_t * a)
+vld1_dup_u8 (const uint8_t * a)
{
uint8x8_t result;
__asm__ (ld1r {%0.8b},[%1]
@@ -8486,7 +8486,7 @@ vld1_dup_u8 (uint8_t * a)
}
__extension__ static __inline uint16x4_t __attribute__ ((__always_inline__))
-vld1_dup_u16 (uint16_t * a)
+vld1_dup_u16 (const uint16_t * a)
{
uint16x4_t result;
__asm__ (ld1r {%0.4h},[%1]
@@ -8497,7 +8497,7 @@ vld1_dup_u16 (uint16_t * a)
}
__extension__ static __inline uint32x2_t __attribute__ ((__always_inline__))
-vld1_dup_u32 (uint32_t * a)
+vld1_dup_u32 (const uint32_t * a)
{
uint32x2_t result;
__asm__ (ld1r {%0.2s},[%1]
@@ -8508,7 +8508,7 @@ vld1_dup_u32 (uint32_t * a)
}
__extension__ static __inline uint64x1_t __attribute__ ((__always_inline__))
-vld1_dup_u64 (uint64_t * a)
+vld1_dup_u64 (const uint64_t * a)
{
uint64x1_t result;
__asm__ (ld1 {%0.1d},[%1]
@@ -8519,7 +8519,7 @@ vld1_dup_u64 (uint64_t * a)
}
__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
-vld1_f32 (float32_t * a)
+vld1_f32 (const float32_t * a)
{
float32x2_t result;
__asm__ (ld1 {%0.2s},[%1]
@@ -8530,7 +8530,7 @@ vld1_f32 (float32_t * a)
}
__extension__ static __inline float64x1_t __attribute__ ((__always_inline__))
-vld1_f64 (float64_t * a)
+vld1_f64 (const float64_t * a)
{
float64x1_t result;
__asm__ (ld1 {%0.1d},[%1]
@@ -8544,7 +8544,7 @@ vld1_f64 (float64_t * a)
__extension__ \
({ \
float32x2_t b_ = (b);\
- float32_t * a_ = (a);\
+ const float32_t * a_ = (a); \
float32x2_t result; \
__asm__ (ld1 {%0.s}[%3],[%1] \
: =w(result) \
@@ -8557,7 +8557,7 @@ vld1_f64 (float64_t * a)
__extension__ \
({
Re: [Patch, Fortran] PR55852 fix ubound /size ICE and cleanup class.c's finalizer
Dear Tobias, It looks good to me. OK for trunk Thanks for the patch - we'll have regressions down below 20 by tonight. I am rather certain that I have the correct fix for PR55618. Let's see if we can get to single figures, once more, by the end of the month! Paul On 7 January 2013 10:13, Tobias Burnus bur...@net-b.de wrote: Dear all, the following patch is based on Thomas' comment 5 in PR55852. He independently created a patch for the PR; his version is in comment 6: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852#c6 The problem with the current trunk's version of gfc_build_intrinsic_call is that it assumes that gfc_find_symtree will return the intrinsic function (size in this case); if the user has a different symbol named size or hasn't used size, the code doesn't work. My version is attached. In my version, the gfc_build_intrinsic_call takes gfc_isym_id as identifier for the intrinsic - the passed string is mangled via GFC_PREFIX to avoid issues with symbol declarations of the user. I do set rather bluntly n.sym... = , assuming that under mangled name one always finds this intrinsic function. Besides fixing the ICE, I used the opportunity to cleanup class.c, where I now use gfc_build_intrinsic_call, which is a nice cleanup: 4 files changed, 65 insertions(+), 143 deletions(-) Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[PATCH, i386]: Remove definition of DEFAULT_PCC_STRUCT_RETURN from i386.c
Hello! The same definition now lives in defaults.h, included through tm.h. 2013-01-07 Uros Bizjak ubiz...@gmail.com * config/i386/i386.c (DEFAULT_PCC_STRUCT_RETURN): Remove. Tested on x86_64-pc-linux-gnu, committed to mainline SVN. Uros. Index: config/i386/i386.c === --- config/i386/i386.c (revision 194959) +++ config/i386/i386.c (working copy) @@ -2397,12 +2397,6 @@ #define SUBTARGET32_DEFAULT_CPU i386 #endif -/* The svr4 ABI for the i386 says that records and unions are returned - in memory. */ -#ifndef DEFAULT_PCC_STRUCT_RETURN -#define DEFAULT_PCC_STRUCT_RETURN 1 -#endif - /* Whether -mtune= or -march= were specified */ static int ix86_tune_defaulted; static int ix86_arch_specified;
[Patch,avr] PR55243: Mistimed use of STAMP in Ada build
This patch is a rewrite of t-avr so that STAMP is not needed. Ada triggers a mistimed re-build of targets using STAMP which causes PR55243 because the respective places in gnattools ada/gcc-interface don't set STAMP. With this patch, files that were formerly auto-generated must be generated by hand after avr-mcus.def is changed. Ok to apply? Johann PR55243 * config/avr/t-avr: Don't automatically rebuild $(srcdir)/config/avr/t-multilib $(srcdir)/config/avr/avr-tables.opt $(srcdir)/doc/avr-mmcu.texi (avr-mcus): New phony target to build them on request. (s-avr-mlib, s-avr-mmcu-texi): Remove. * avr/avr-mcus.def: Adjust comments. Index: config/avr/t-avr === --- config/avr/t-avr (revision 194964) +++ config/avr/t-avr (working copy) @@ -40,48 +40,36 @@ avr.o avr-c.o: $(srcdir)/config/avr/buil AVR_MCUS = $(srcdir)/config/avr/avr-mcus.def +# Run `avr-mcus' after you changed or added devices in avr-mcus.def + +.PHONY: avr-mcus + +avr-mcus: $(srcdir)/config/avr/t-multilib \ + $(srcdir)/config/avr/avr-tables.opt \ + $(srcdir)/doc/avr-mmcu.texi ; @true + +# Make sure that -mmcu= is supported for devices from avr-mcus.def and +# is displaed all -mmcu= values are displayed on the help screen $(srcdir)/config/avr/avr-tables.opt: $(srcdir)/config/avr/genopt.sh $(AVR_MCUS) $(SHELL) $ $(AVR_MCUS) $@ +# Make sure that -mmcu= support is in sync with -mmcu= documentation. gen-avr-mmcu-texi$(build_exeext): $(srcdir)/config/avr/gen-avr-mmcu-texi.c \ $(AVR_MCUS) $(srcdir)/config/avr/avr-devices.c \ $(srcdir)/config/avr/avr-arch.h $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $ -o $@ -# Make sure that the -mmcu= documentation is in sync with the compiler. -$(srcdir)/doc/avr-mmcu.texi: s-avr-mmcu-texi; @true - -# invoke.texi @includes avr-mmcu.texi. Put this dependency here instead -# of in the global Makefile so that developers of other backends are not -# bothered with AVR stuff. -$(srcdir)/doc/invoke.texi: $(srcdir)/doc/avr-mmcu.texi - -# Ensure that device support is in sync with -mmcu= documentation. -s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext) - $(RUN_GEN) ./$ tmp-avr-mmcu.texi - $(SHELL) $(srcdir)/../move-if-change tmp-avr-mmcu.texi avr-mmcu.texi - @if cmp -s $(srcdir)/doc/avr-mmcu.texi avr-mmcu.texi; then \ - $(STAMP) $@; \ - else \ - echo 2 ; \ - echo *** 2 ; \ - echo *** Verify that you have permission to grant a 2 ; \ - echo *** GFDL license for all new text in 2 ; \ - echo *** avr-mmcu.texi, then copy it to $(srcdir)/doc/avr-mmcu.texi 2 ; \ - echo *** 2 ; \ - false; \ - fi +$(srcdir)/doc/avr-mmcu.texi: gen-avr-mmcu-texi$(build_exeext) + $(RUN_GEN) ./$ $@ +# Map -mmcu= to the right multilib variant # MULTILIB_OPTIONS # MULTILIB_DIRNAMES # MULTILIB_EXCEPTIONS # MULTILIB_MATCHES -$(srcdir)/config/avr/t-multilib: s-avr-mlib; @true s-mlib: $(srcdir)/config/avr/t-multilib -s-avr-mlib: $(srcdir)/config/avr/genmultilib.awk $(AVR_MCUS) - $(AWK) -f $ -v FORMAT=Makefile $ $(AVR_MCUS) tmp-avr-mlib - $(SHELL) $(srcdir)/../move-if-change \ - tmp-avr-mlib $(srcdir)/config/avr/t-multilib - $(STAMP) $@ +$(srcdir)/config/avr/t-multilib: $(srcdir)/config/avr/genmultilib.awk \ + $(AVR_MCUS) + $(AWK) -f $ -v FORMAT=Makefile $ $(AVR_MCUS) $@ Index: config/avr/avr-mcus.def === --- config/avr/avr-mcus.def (revision 194964) +++ config/avr/avr-mcus.def (working copy) @@ -18,19 +18,50 @@ along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/. */ -/* List of all known AVR MCU types - if updated, it has to be kept - in sync in several places (FIXME: is there a better way?): -- here; -- gas/config/tc-avr.c; -- avr-libc. +/* List of all known AVR MCU types. If updated, cd to $(builddir)/gcc and run + + $ make avr-mcus + + This will regenerate / update the following source files: + + - $(srcdir)/config/avr/t-multilib + - $(srcdir)/config/avr/avr-tables.opt + - $(srcdir)/doc/avr-mmcu.texi + + After that, rebuild everything and check-in the new sources to the repo. + The device list below has to be kept in sync with the following places: + + - here + - gas/config/tc-avr.c + - avr-libc Before including this file, define a macro: - AVR_MCU (NAME, ARCH, MACRO, SHORT_SP, ERRATA_SKIP, DATA_SEC, N_FLASH, LIBRARY_NAME) + AVR_MCU (NAME, ARCH, MACRO, SHORT_SP, ERRATA_SKIP, DATA_SEC, N_FLASH, +LIBRARY_NAME) + + where the arguments are the fields of struct mcu_type_s: + + NAME Accept -mmcu=NAME + + ARCH Specifies the multilib variant together with SHORT_SP + + MACROIf NULL, this is a core and not a device. If non-NULL, +supply respective built-in macro. + + SHORT_SP The device / multilib has an 8-bit stack pointer (no
Re: [Patch,avr] PR55243: Mistimed use of STAMP in Ada build
2013/1/7 Georg-Johann Lay a...@gjlay.de: This patch is a rewrite of t-avr so that STAMP is not needed. Ada triggers a mistimed re-build of targets using STAMP which causes PR55243 because the respective places in gnattools ada/gcc-interface don't set STAMP. With this patch, files that were formerly auto-generated must be generated by hand after avr-mcus.def is changed. Ok to apply? Johann PR55243 * config/avr/t-avr: Don't automatically rebuild $(srcdir)/config/avr/t-multilib $(srcdir)/config/avr/avr-tables.opt $(srcdir)/doc/avr-mmcu.texi (avr-mcus): New phony target to build them on request. (s-avr-mlib, s-avr-mmcu-texi): Remove. * avr/avr-mcus.def: Adjust comments. Please, apply. Denis.
[Patch, AArch64-4.7] Implement vec_init.
Hi,
The attached patch implements vec_init for AArch64. This has been tested on
aarch64-none-elf with no regressions. OK for aarch64-4.7-branch?
Thanks,
Tejas Belagod
ARM.
2013-01-07 Tejas Belagod tejas.bela...@arm.com
gcc/
* config/aarch64/aarch64-simd.md (vec_initmode): New.
* config/aarch64/aarch64-protos.h (aarch64_expand_vector_init): Declare.
* config/aarch64/aarch64.c (aarch64_simd_dup_constant,
aarch64_simd_make_constant, aarch64_expand_vector_init): New.diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index c09330a..4ecbf5f 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -138,6 +138,7 @@ HOST_WIDE_INT aarch64_initial_elimination_offset (unsigned,
unsigned);
bool aarch64_bitmask_imm (HOST_WIDE_INT val, enum machine_mode);
bool aarch64_const_double_zero_rtx_p (rtx);
bool aarch64_constant_address_p (rtx);
+void aarch64_expand_vector_init (rtx, rtx);
bool aarch64_function_arg_regno_p (unsigned);
bool aarch64_gen_movmemqi (rtx *);
bool aarch64_is_extend_from_extract (enum machine_mode, rtx, rtx);
diff --git a/gcc/config/aarch64/aarch64-simd.md
b/gcc/config/aarch64/aarch64-simd.md
index febf71d..c630808 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -3527,3 +3527,14 @@
DONE;
})
+;; Standard pattern name vec_initmode.
+
+(define_expand vec_initmode
+ [(match_operand:VALL 0 register_operand )
+ (match_operand 1 )]
+ TARGET_SIMD
+{
+ aarch64_expand_vector_init (operands[0], operands[1]);
+ DONE;
+})
+
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 9b7bed1..f38df32 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6423,6 +6423,166 @@ aarch64_simd_vector_alignment_reachable (const_tree
type, bool is_packed)
return true;
}
+/* If VALS is a vector constant that can be loaded into a register
+ using DUP, generate instructions to do so and return an RTX to
+ assign to the register. Otherwise return NULL_RTX. */
+static rtx
+aarch64_simd_dup_constant (rtx vals)
+{
+ enum machine_mode mode = GET_MODE (vals);
+ enum machine_mode inner_mode = GET_MODE_INNER (mode);
+ int n_elts = GET_MODE_NUNITS (mode);
+ bool all_same = true;
+ rtx x;
+ int i;
+
+ if (GET_CODE (vals) != CONST_VECTOR)
+return NULL_RTX;
+
+ for (i = 1; i n_elts; ++i)
+{
+ x = CONST_VECTOR_ELT (vals, i);
+ if (!rtx_equal_p (x, CONST_VECTOR_ELT (vals, 0)))
+ all_same = false;
+}
+
+ if (!all_same)
+return NULL_RTX;
+
+ /* We can load this constant by using DUP and a constant in a
+ single ARM register. This will be cheaper than a vector
+ load. */
+ x = copy_to_mode_reg (inner_mode, CONST_VECTOR_ELT (vals, 0));
+ return gen_rtx_VEC_DUPLICATE (mode, x);
+}
+
+
+/* Generate code to load VALS, which is a PARALLEL containing only
+ constants (for vec_init) or CONST_VECTOR, efficiently into a
+ register. Returns an RTX to copy into the register, or NULL_RTX
+ for a PARALLEL that can not be converted into a CONST_VECTOR. */
+rtx
+aarch64_simd_make_constant (rtx vals)
+{
+ enum machine_mode mode = GET_MODE (vals);
+ rtx const_dup;
+ rtx const_vec = NULL_RTX;
+ int n_elts = GET_MODE_NUNITS (mode);
+ int n_const = 0;
+ int i;
+
+ if (GET_CODE (vals) == CONST_VECTOR)
+const_vec = vals;
+ else if (GET_CODE (vals) == PARALLEL)
+{
+ /* A CONST_VECTOR must contain only CONST_INTs and
+CONST_DOUBLEs, but CONSTANT_P allows more (e.g. SYMBOL_REF).
+Only store valid constants in a CONST_VECTOR. */
+ for (i = 0; i n_elts; ++i)
+ {
+ rtx x = XVECEXP (vals, 0, i);
+ if (CONST_INT_P (x) || CONST_DOUBLE_P (x))
+ n_const++;
+ }
+ if (n_const == n_elts)
+ const_vec = gen_rtx_CONST_VECTOR (mode, XVEC (vals, 0));
+}
+ else
+gcc_unreachable ();
+
+ if (const_vec != NULL_RTX
+ aarch64_simd_immediate_valid_for_move (const_vec, mode, NULL, NULL,
+ NULL, NULL, NULL))
+/* Load using MOVI/MVNI. */
+return const_vec;
+ else if ((const_dup = aarch64_simd_dup_constant (vals)) != NULL_RTX)
+/* Loaded using DUP. */
+return const_dup;
+ else if (const_vec != NULL_RTX)
+/* Load from constant pool. We can not take advantage of single-cycle
+ LD1 because we need a PC-relative addressing mode. */
+return const_vec;
+ else
+/* A PARALLEL containing something not valid inside CONST_VECTOR.
+ We can not construct an initializer. */
+return NULL_RTX;
+}
+
+void
+aarch64_expand_vector_init (rtx target, rtx vals)
+{
+ enum machine_mode mode = GET_MODE (target);
+ enum machine_mode inner_mode = GET_MODE_INNER (mode);
+ int n_elts = GET_MODE_NUNITS (mode);
+ int n_var = 0, one_var = -1;
+ bool all_same = true;
+ rtx x, mem;
+ int i;
+
+ x = XVECEXP (vals, 0, 0);
+
[Patch, AArch64] Implement vec_init.
Hi,
The attached patch implements vec_init for AArch64. This has been tested on
aarch64-none-elf with no regressions. OK for trunk?
Thanks,
Tejas Belagod
ARM.
2013-01-07 Tejas Belagod tejas.bela...@arm.com
gcc/
* config/aarch64/aarch64-simd.md (vec_initmode): New.
* config/aarch64/aarch64-protos.h (aarch64_expand_vector_init): Declare.
* config/aarch64/aarch64.c (aarch64_simd_dup_constant,
aarch64_simd_make_constant, aarch64_expand_vector_init): New.diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index bcd3bb1..e8859a0 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -138,6 +138,7 @@ HOST_WIDE_INT aarch64_initial_elimination_offset (unsigned,
unsigned);
bool aarch64_bitmask_imm (HOST_WIDE_INT val, enum machine_mode);
bool aarch64_const_double_zero_rtx_p (rtx);
bool aarch64_constant_address_p (rtx);
+void aarch64_expand_vector_init (rtx, rtx);
bool aarch64_function_arg_regno_p (unsigned);
bool aarch64_gen_movmemqi (rtx *);
bool aarch64_is_extend_from_extract (enum machine_mode, rtx, rtx);
diff --git a/gcc/config/aarch64/aarch64-simd.md
b/gcc/config/aarch64/aarch64-simd.md
index febf71d..c630808 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -3527,3 +3527,14 @@
DONE;
})
+;; Standard pattern name vec_initmode.
+
+(define_expand vec_initmode
+ [(match_operand:VALL 0 register_operand )
+ (match_operand 1 )]
+ TARGET_SIMD
+{
+ aarch64_expand_vector_init (operands[0], operands[1]);
+ DONE;
+})
+
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 7bc2f6b..29b8e64 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -6423,6 +6423,166 @@ aarch64_simd_vector_alignment_reachable (const_tree
type, bool is_packed)
return true;
}
+/* If VALS is a vector constant that can be loaded into a register
+ using DUP, generate instructions to do so and return an RTX to
+ assign to the register. Otherwise return NULL_RTX. */
+static rtx
+aarch64_simd_dup_constant (rtx vals)
+{
+ enum machine_mode mode = GET_MODE (vals);
+ enum machine_mode inner_mode = GET_MODE_INNER (mode);
+ int n_elts = GET_MODE_NUNITS (mode);
+ bool all_same = true;
+ rtx x;
+ int i;
+
+ if (GET_CODE (vals) != CONST_VECTOR)
+return NULL_RTX;
+
+ for (i = 1; i n_elts; ++i)
+{
+ x = CONST_VECTOR_ELT (vals, i);
+ if (!rtx_equal_p (x, CONST_VECTOR_ELT (vals, 0)))
+ all_same = false;
+}
+
+ if (!all_same)
+return NULL_RTX;
+
+ /* We can load this constant by using DUP and a constant in a
+ single ARM register. This will be cheaper than a vector
+ load. */
+ x = copy_to_mode_reg (inner_mode, CONST_VECTOR_ELT (vals, 0));
+ return gen_rtx_VEC_DUPLICATE (mode, x);
+}
+
+
+/* Generate code to load VALS, which is a PARALLEL containing only
+ constants (for vec_init) or CONST_VECTOR, efficiently into a
+ register. Returns an RTX to copy into the register, or NULL_RTX
+ for a PARALLEL that can not be converted into a CONST_VECTOR. */
+rtx
+aarch64_simd_make_constant (rtx vals)
+{
+ enum machine_mode mode = GET_MODE (vals);
+ rtx const_dup;
+ rtx const_vec = NULL_RTX;
+ int n_elts = GET_MODE_NUNITS (mode);
+ int n_const = 0;
+ int i;
+
+ if (GET_CODE (vals) == CONST_VECTOR)
+const_vec = vals;
+ else if (GET_CODE (vals) == PARALLEL)
+{
+ /* A CONST_VECTOR must contain only CONST_INTs and
+CONST_DOUBLEs, but CONSTANT_P allows more (e.g. SYMBOL_REF).
+Only store valid constants in a CONST_VECTOR. */
+ for (i = 0; i n_elts; ++i)
+ {
+ rtx x = XVECEXP (vals, 0, i);
+ if (CONST_INT_P (x) || CONST_DOUBLE_P (x))
+ n_const++;
+ }
+ if (n_const == n_elts)
+ const_vec = gen_rtx_CONST_VECTOR (mode, XVEC (vals, 0));
+}
+ else
+gcc_unreachable ();
+
+ if (const_vec != NULL_RTX
+ aarch64_simd_immediate_valid_for_move (const_vec, mode, NULL, NULL,
+ NULL, NULL, NULL))
+/* Load using MOVI/MVNI. */
+return const_vec;
+ else if ((const_dup = aarch64_simd_dup_constant (vals)) != NULL_RTX)
+/* Loaded using DUP. */
+return const_dup;
+ else if (const_vec != NULL_RTX)
+/* Load from constant pool. We can not take advantage of single-cycle
+ LD1 because we need a PC-relative addressing mode. */
+return const_vec;
+ else
+/* A PARALLEL containing something not valid inside CONST_VECTOR.
+ We can not construct an initializer. */
+return NULL_RTX;
+}
+
+void
+aarch64_expand_vector_init (rtx target, rtx vals)
+{
+ enum machine_mode mode = GET_MODE (target);
+ enum machine_mode inner_mode = GET_MODE_INNER (mode);
+ int n_elts = GET_MODE_NUNITS (mode);
+ int n_var = 0, one_var = -1;
+ bool all_same = true;
+ rtx x, mem;
+ int i;
+
+ x = XVECEXP (vals, 0, 0);
+ if
[PATCH] Fix PR55888, fix PR55862 differently
The following fixes a fallout of fixing PR55862 - the fix for it
merely papered over the issue that we inconsistently prune
expressions in clean (). Fixing that allows us to revert the
original PR55862 fix and thus fix PR55888.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-01-07 Richard Biener rguent...@suse.de
PR tree-optimization/55888
PR tree-optimization/55862
* tree-ssa-pre.c (phi_translate_1): Revert previous change.
(valid_in_sets): Check if a NAME has a leader in AVAIL_OUT,
not if it is contained therein.
* gcc.dg/torture/pr55888.c: New testcase.
Index: gcc/tree-ssa-pre.c
===
*** gcc/tree-ssa-pre.c (revision 194964)
--- gcc/tree-ssa-pre.c (working copy)
*** phi_translate_1 (pre_expr expr, bitmap_s
*** 1729,1738
edge e = find_edge (pred, gimple_bb (def_stmt));
tree def = PHI_ARG_DEF (def_stmt, e-dest_idx);
- /* Valueize it. */
- if (TREE_CODE (def) == SSA_NAME)
- def = VN_INFO (def)-valnum;
-
/* Handle constant. */
if (is_gimple_min_invariant (def))
return get_or_alloc_expr_for_constant (def);
--- 1729,1734
*** valid_in_sets (bitmap_set_t set1, bitmap
*** 1978,1984
switch (expr-kind)
{
case NAME:
! return bitmap_set_contains_expr (AVAIL_OUT (block), expr);
case NARY:
{
unsigned int i;
--- 1974,1981
switch (expr-kind)
{
case NAME:
! return bitmap_find_leader (AVAIL_OUT (block),
!get_expr_value_id (expr)) != NULL;
case NARY:
{
unsigned int i;
Index: gcc/testsuite/gcc.dg/torture/pr55888.c
===
*** gcc/testsuite/gcc.dg/torture/pr55888.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr55888.c (working copy)
***
*** 0
--- 1,116
+ /* { dg-do compile } */
+
+ typedef unsigned _GCC_ATTR_ALIGN_u32t;
+ typedef _GCC_ATTR_ALIGN_u32t _Uint32t __attribute__ ((__aligned__ (4)));
+ typedef unsigned int _GCC_ATTR_ALIGN_u8t __attribute__ ((__mode__ (__QI__)));
+ typedef _GCC_ATTR_ALIGN_u8t _Uint8t __attribute__ ((__aligned__ (1)));
+ typedef unsigned _Sizet;
+ typedef _Sizet size_t;
+ typedef _Uint8t uint8_t;
+ typedef _Uint32t uint32_t;
+ typedef enum
+ {
+ PROTOBUF_C_LABEL_REQUIRED, PROTOBUF_C_LABEL_OPTIONAL,
+ PROTOBUF_C_LABEL_REPEATED
+ }
+ ProtobufCLabel;
+ typedef enum
+ {
+ PROTOBUF_C_TYPE_INT32, PROTOBUF_C_TYPE_SINT32, PROTOBUF_C_TYPE_SFIXED32,
+ PROTOBUF_C_TYPE_INT64, PROTOBUF_C_TYPE_SINT64, PROTOBUF_C_TYPE_SFIXED64,
+ PROTOBUF_C_TYPE_UINT32, PROTOBUF_C_TYPE_FIXED32, PROTOBUF_C_TYPE_UINT64,
+ PROTOBUF_C_TYPE_FIXED64, PROTOBUF_C_TYPE_FLOAT, PROTOBUF_C_TYPE_DOUBLE,
+ PROTOBUF_C_TYPE_BOOL, PROTOBUF_C_TYPE_ENUM, PROTOBUF_C_TYPE_STRING,
+ PROTOBUF_C_TYPE_BYTES, PROTOBUF_C_TYPE_MESSAGE,
+ }
+ ProtobufCType;
+ typedef struct _ProtobufCBinaryData ProtobufCBinaryData;
+ struct _ProtobufCBinaryData
+ {
+ size_t len;
+ };
+ typedef struct _ProtobufCMessageDescriptor ProtobufCMessageDescriptor;
+ typedef struct _ProtobufCFieldDescriptor ProtobufCFieldDescriptor;
+ typedef struct _ProtobufCMessage ProtobufCMessage;
+ struct _ProtobufCFieldDescriptor
+ {
+ uint32_t id;
+ ProtobufCLabel label;
+ ProtobufCType type;
+ unsigned offset;
+ };
+ struct _ProtobufCMessageDescriptor
+ {
+ unsigned n_fields;
+ const ProtobufCFieldDescriptor *fields;
+ };
+ struct _ProtobufCMessage
+ {
+ const ProtobufCMessageDescriptor *descriptor;
+ };
+ typedef enum
+ {
+ PROTOBUF_C_WIRE_TYPE_VARINT, PROTOBUF_C_WIRE_TYPE_64BIT,
+ PROTOBUF_C_WIRE_TYPE_LENGTH_PREFIXED, PROTOBUF_C_WIRE_TYPE_START_GROUP,
+ PROTOBUF_C_WIRE_TYPE_END_GROUP, PROTOBUF_C_WIRE_TYPE_32BIT
+ }
+ ProtobufCWireType;
+ static inline size_t
+ uint32_pack (uint32_t value, uint8_t * out)
+ {
+ unsigned rv = 0;
+ if (value = 0x80)
+ {
+ if (value = 0x80)
+ {
+ value = 7;
+ }
+ }
+ out[rv++] = value;
+ }
+
+ static inline size_t
+ binary_data_pack (const ProtobufCBinaryData * bd, uint8_t * out)
+ {
+ size_t len = bd-len;
+ size_t rv = uint32_pack (len, out);
+ return rv + len;
+ }
+
+ static size_t
+ required_field_pack (const ProtobufCFieldDescriptor * field,
+const void *member, uint8_t * out)
+ {
+ size_t rv = tag_pack (field-id, out);
+ switch (field-type)
+ {
+ case PROTOBUF_C_TYPE_BYTES:
+ {
+ const ProtobufCBinaryData *bd =
+ ((const ProtobufCBinaryData *) member);
+ out[0] |= PROTOBUF_C_WIRE_TYPE_LENGTH_PREFIXED;
+ return rv + binary_data_pack (bd, out + rv);
+ }
+ case PROTOBUF_C_TYPE_MESSAGE:
+ {
+ out[0] |= PROTOBUF_C_WIRE_TYPE_LENGTH_PREFIXED;
+ return rv +
+
[PATCH][RFC] Fix PR55890
Since we freely propagate function addresses we can end up with
call statements with mismatched number and type of arguments
than what the function decl referenced says. This is a problem
for builtin decls and all code that tries to examine their
arguments (which may not be there or be of bogus type). The
following provides an easy means to not even consider such bogus
calls as calls to builtins.
Only PTA fixed up, other cases should add some more testcases
(IIRC Jakub had one for strlen-opt).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-01-07 Richard Biener rguent...@suse.de
PR middle-end/55890
* gimple.h (gimple_call_builtin_p): New overload.
* gimple.c (validate_call): New function.
(gimple_call_builtin_p): Likewise.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Use gimple_call_builtin_p.
(find_func_clobbers): Likewise.
* gcc.dg/torture/pr55890-1.c: New testcase.
* gcc.dg/torture/pr55890-2.c: Likewise.
Index: gcc/gimple.c
===
*** gcc/gimple.c(revision 194964)
--- gcc/gimple.c(working copy)
*** is_gimple_builtin_call (gimple stmt)
*** 4137,4152
return false;
}
! /* Return true when STMT is builtins call to CODE. */
bool
gimple_call_builtin_p (gimple stmt, enum built_in_function code)
{
tree fndecl;
! return (is_gimple_call (stmt)
! (fndecl = gimple_call_fndecl (stmt)) != NULL
! DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
! DECL_FUNCTION_CODE (fndecl) == code);
}
/* Return true if STMT clobbers memory. STMT is required to be a
--- 4137,4196
return false;
}
! /* Return true when STMTs arguments match those of FNDECL. */
!
! static bool
! validate_call (gimple stmt, tree fndecl)
! {
! tree targs = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
! unsigned nargs = gimple_call_num_args (stmt);
! for (unsigned i = 0; i nargs; ++i)
! {
! /* Variadic args follow. */
! if (!targs)
! return true;
! tree arg = gimple_call_arg (stmt, i);
! if (INTEGRAL_TYPE_P (TREE_TYPE (arg))
! INTEGRAL_TYPE_P (TREE_VALUE (targs)))
! ;
! else if (POINTER_TYPE_P (TREE_TYPE (arg))
! POINTER_TYPE_P (TREE_VALUE (targs)))
! ;
! else if (TREE_CODE (TREE_TYPE (arg))
! != TREE_CODE (TREE_VALUE (targs)))
! return false;
! targs = TREE_CHAIN (targs);
! }
! if (targs !VOID_TYPE_P (TREE_VALUE (targs)))
! return false;
! return true;
! }
!
! /* Return true when STMT is builtins call to CLASS. */
!
! bool
! gimple_call_builtin_p (gimple stmt, enum built_in_class klass)
! {
! tree fndecl;
! if (is_gimple_call (stmt)
!(fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
!DECL_BUILT_IN_CLASS (fndecl) == klass)
! return validate_call (stmt, fndecl);
! return false;
! }
!
! /* Return true when STMT is builtins call to CODE of CLASS. */
bool
gimple_call_builtin_p (gimple stmt, enum built_in_function code)
{
tree fndecl;
! if (is_gimple_call (stmt)
!(fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
!DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
!DECL_FUNCTION_CODE (fndecl) == code)
! return validate_call (stmt, fndecl);
! return false;
}
/* Return true if STMT clobbers memory. STMT is required to be a
Index: gcc/gimple.h
===
*** gcc/gimple.h(revision 194964)
--- gcc/gimple.h(working copy)
*** extern bool walk_stmt_load_store_ops (gi
*** 893,898
--- 893,899
bool (*)(gimple, tree, void *),
bool (*)(gimple, tree, void *));
extern bool gimple_ior_addresses_taken (bitmap, gimple);
+ extern bool gimple_call_builtin_p (gimple, enum built_in_class);
extern bool gimple_call_builtin_p (gimple, enum built_in_function);
extern bool gimple_asm_clobbers_memory_p (const_gimple);
Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c (revision 194964)
--- gcc/tree-ssa-structalias.c (working copy)
*** find_func_aliases_for_builtin_call (gimp
*** 4014,4021
vecce_s rhsc = vNULL;
varinfo_t fi;
! if (fndecl != NULL_TREE
!DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
/* ??? All builtins that are handled here need to be handled
in the alias-oracle query functions explicitly! */
switch (DECL_FUNCTION_CODE (fndecl))
--- 4014,4020
vecce_s rhsc = vNULL;
varinfo_t fi;
! if (gimple_call_builtin_p (t, BUILT_IN_NORMAL))
/* ??? All builtins that are handled here need to be handled
in the alias-oracle query functions
Re: [PATCH][RFC] Fix PR55890
On Mon, Jan 07, 2013 at 02:55:48PM +0100, Richard Biener wrote:
*** gcc/testsuite/gcc.dg/torture/pr55890-1.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr55890-1.c (working copy)
***
*** 0
--- 1,6
+ /* { dg-do compile } */
+
+ extern void *memmove(void *, void *, long unsigned int);
Please use __SIZE_TYPE__ as the last argument here.
Jakub
Re: [PATCH][RFC] Fix PR55890
On Mon, 7 Jan 2013, Jakub Jelinek wrote:
On Mon, Jan 07, 2013 at 02:55:48PM +0100, Richard Biener wrote:
*** gcc/testsuite/gcc.dg/torture/pr55890-1.c(revision 0)
--- gcc/testsuite/gcc.dg/torture/pr55890-1.c(working copy)
***
*** 0
--- 1,6
+ /* { dg-do compile } */
+
+ extern void *memmove(void *, void *, long unsigned int);
Please use __SIZE_TYPE__ as the last argument here.
Done. Also fixed up tree-ssa-strlen.c now as pr55890-2.c also
ICEs therein.
Re-bootstrapping/testing now.
Richard.
2013-01-07 Richard Biener rguent...@suse.de
PR middle-end/55890
* gimple.h (gimple_call_builtin_p): New overload.
* gimple.c (validate_call): New function.
(gimple_call_builtin_p): Likewise.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Use gimple_call_builtin_p.
(find_func_clobbers): Likewise.
* tree-ssa-strlen.c (adjust_last_stmt): Likewise.
(strlen_optimize_stmt): Likewise.
* gcc.dg/torture/pr55890-1.c: New testcase.
* gcc.dg/torture/pr55890-2.c: Likewise.
Index: gcc/gimple.c
===
*** gcc/gimple.c(revision 194970)
--- gcc/gimple.c(working copy)
*** is_gimple_builtin_call (gimple stmt)
*** 4137,4152
return false;
}
! /* Return true when STMT is builtins call to CODE. */
bool
gimple_call_builtin_p (gimple stmt, enum built_in_function code)
{
tree fndecl;
! return (is_gimple_call (stmt)
! (fndecl = gimple_call_fndecl (stmt)) != NULL
! DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
! DECL_FUNCTION_CODE (fndecl) == code);
}
/* Return true if STMT clobbers memory. STMT is required to be a
--- 4137,4196
return false;
}
! /* Return true when STMTs arguments match those of FNDECL. */
!
! static bool
! validate_call (gimple stmt, tree fndecl)
! {
! tree targs = TYPE_ARG_TYPES (TREE_TYPE (fndecl));
! unsigned nargs = gimple_call_num_args (stmt);
! for (unsigned i = 0; i nargs; ++i)
! {
! /* Variadic args follow. */
! if (!targs)
! return true;
! tree arg = gimple_call_arg (stmt, i);
! if (INTEGRAL_TYPE_P (TREE_TYPE (arg))
! INTEGRAL_TYPE_P (TREE_VALUE (targs)))
! ;
! else if (POINTER_TYPE_P (TREE_TYPE (arg))
! POINTER_TYPE_P (TREE_VALUE (targs)))
! ;
! else if (TREE_CODE (TREE_TYPE (arg))
! != TREE_CODE (TREE_VALUE (targs)))
! return false;
! targs = TREE_CHAIN (targs);
! }
! if (targs !VOID_TYPE_P (TREE_VALUE (targs)))
! return false;
! return true;
! }
!
! /* Return true when STMT is builtins call to CLASS. */
!
! bool
! gimple_call_builtin_p (gimple stmt, enum built_in_class klass)
! {
! tree fndecl;
! if (is_gimple_call (stmt)
!(fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
!DECL_BUILT_IN_CLASS (fndecl) == klass)
! return validate_call (stmt, fndecl);
! return false;
! }
!
! /* Return true when STMT is builtins call to CODE of CLASS. */
bool
gimple_call_builtin_p (gimple stmt, enum built_in_function code)
{
tree fndecl;
! if (is_gimple_call (stmt)
!(fndecl = gimple_call_fndecl (stmt)) != NULL_TREE
!DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
!DECL_FUNCTION_CODE (fndecl) == code)
! return validate_call (stmt, fndecl);
! return false;
}
/* Return true if STMT clobbers memory. STMT is required to be a
Index: gcc/gimple.h
===
*** gcc/gimple.h(revision 194970)
--- gcc/gimple.h(working copy)
*** extern bool walk_stmt_load_store_ops (gi
*** 893,898
--- 893,899
bool (*)(gimple, tree, void *),
bool (*)(gimple, tree, void *));
extern bool gimple_ior_addresses_taken (bitmap, gimple);
+ extern bool gimple_call_builtin_p (gimple, enum built_in_class);
extern bool gimple_call_builtin_p (gimple, enum built_in_function);
extern bool gimple_asm_clobbers_memory_p (const_gimple);
Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c (revision 194970)
--- gcc/tree-ssa-structalias.c (working copy)
*** find_func_aliases_for_builtin_call (gimp
*** 4014,4021
vecce_s rhsc = vNULL;
varinfo_t fi;
! if (fndecl != NULL_TREE
!DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
/* ??? All builtins that are handled here need to be handled
in the alias-oracle query functions explicitly! */
switch (DECL_FUNCTION_CODE (fndecl))
--- 4014,4020
vecce_s rhsc = vNULL;
varinfo_t fi;
! if (gimple_call_builtin_p (t, BUILT_IN_NORMAL))
/* ??? All builtins that are
Re: [PATCH][RFC] Fix PR55890
On Mon, Jan 07, 2013 at 03:06:50PM +0100, Richard Biener wrote:
*** gcc/tree-ssa-strlen.c (revision 194970)
--- gcc/tree-ssa-strlen.c (working copy)
*** adjust_last_stmt (strinfo si, gimple stm
*** 809,818
if (!is_gimple_call (last.stmt))
return;
! callee = gimple_call_fndecl (last.stmt);
! if (callee == NULL_TREE || DECL_BUILT_IN_CLASS (callee) !=
BUILT_IN_NORMAL)
return;
switch (DECL_FUNCTION_CODE (callee))
{
case BUILT_IN_MEMCPY:
--- 809,818
if (!is_gimple_call (last.stmt))
return;
The above call could be dropped too, gimple_call_builtin_p checks that as
well.
Jakub
Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file
Early * ping * the patch below, i.e. http://gcc.gnu.org/ml/fortran/2013-01/msg00033.html Other pending patches by me: http://gcc.gnu.org/ml/fortran/2013-01/msg00049.html http://gcc.gnu.org/ml/fortran/2013-01/msg00025.html Other pending patches by … Thomas: http://gcc.gnu.org/ml/fortran/2013-01/msg0.html Janne: http://gcc.gnu.org/ml/fortran/2013-01/msg00037.html Tobias Burnus wrote: This patch removes -fno-whole-file. (Actually, it turns it into Ignore.) Reasoning: * -fwhole-file/-fno-whole-file was added in 4.5 to make the transition easier; -fwhole-file is the default since 4.6. * There are many wrong-code issues and probably also some ICEs with -fno-whole file. * The generated code of -fwhole-file is faster as it allows for inlining. * -fno-whole-file has been deprecated since 4.6 and announced for removal. * Code cleanup is always nice (diff -w): 17 insertions(+), 80 deletions(-) Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias PS: Dominique pointed out that PR 45128 is a -fwhole-file regression. However, it mainly shows that gfortran needs the new array descriptor to fix such subpointer issues (and other PRs).
Re: [PATCH][RFC] Fix PR55890
On Mon, 7 Jan 2013, Jakub Jelinek wrote:
On Mon, Jan 07, 2013 at 03:06:50PM +0100, Richard Biener wrote:
*** gcc/tree-ssa-strlen.c (revision 194970)
--- gcc/tree-ssa-strlen.c (working copy)
*** adjust_last_stmt (strinfo si, gimple stm
*** 809,818
if (!is_gimple_call (last.stmt))
return;
! callee = gimple_call_fndecl (last.stmt);
! if (callee == NULL_TREE || DECL_BUILT_IN_CLASS (callee) !=
BUILT_IN_NORMAL)
return;
switch (DECL_FUNCTION_CODE (callee))
{
case BUILT_IN_MEMCPY:
--- 809,818
if (!is_gimple_call (last.stmt))
return;
The above call could be dropped too, gimple_call_builtin_p checks that as
well.
Right. Fixed.
Richard.
Re: [PATCH] avoid undefined behavior in libiberty/cplus-dem.c
On Mon, 7 Jan 2013, Jakub Jelinek wrote:
Won't the above preclude parsing 2147483640 up to 2147483647 ?
Because then in the last iteration count 214748364 (INT_MAX - 9) / 10.
You're right -- thanks for catching that! Below is a patch with a more
precise check.
Nickolai.
--- libiberty/cplus-dem.c (revision 194959)
+++ libiberty/cplus-dem.c (working copy)
@@ -48,7 +48,18 @@
#include sys/types.h
#include string.h
#include stdio.h
+#ifdef HAVE_LIMITS_H
+#include limits.h
+#endif
+#ifndef UINT_MAX
+#define UINT_MAX ((unsigned int)(~0U)) /* 0x */
+#endif
+
+#ifndef INT_MAX
+#define INT_MAX((int)(UINT_MAX 1))/* 0x7FFF
*/
+#endif
+
#ifdef HAVE_STDLIB_H
#include stdlib.h
#else
@@ -494,28 +505,25 @@
while (ISDIGIT ((unsigned char)**type))
{
+ /* Check whether we can add another digit without overflow. */
+ if (count INT_MAX / 10)
+ goto overflow;
+
count *= 10;
- /* Check for overflow.
-We assume that count is represented using two's-complement;
-no power of two is divisible by ten, so if an overflow occurs
-when multiplying by ten, the result will not be a multiple of
-ten. */
- if ((count % 10) != 0)
- {
- while (ISDIGIT ((unsigned char) **type))
- (*type)++;
- return -1;
- }
+ if (count INT_MAX - (**type - '0'))
+ goto overflow;
count += **type - '0';
(*type)++;
}
- if (count 0)
-count = -1;
+ return count;
- return (count);
+ overflow:
+ while (ISDIGIT ((unsigned char) **type))
+(*type)++;
+ return -1;
}
[Patch,avr] PR55897: Allocate __memx to .progmemx.data
Currently, data in address space __memx is allocated to .progmem.data, i.e. the
same section as for __flash resp. progmem. However, there os no need that
__memx goes onto the same section and wastes precious memory in the first 64 Ki.
The patch puts __memx data into .progmemx.data so that a linker script can
allocate it after .text and it can be distinguished from data in __flash or
progmem.
The current default linker script contains .progmem* so that the patch does not
change anything here. A new default script is still to come (binutils PR14406).
Moreover, there is some code clean-up like avoid magic 6 and use
ADDR_SPACE_COUNT instead.
Ok to apply?
Johann
PR target/55897
* config/avr/avr.h (ADDR_SPACE_COUNT): New enum.
(avr_addrspace_t): Add .section_name field.
* config/avr/avr.c (progmem_section): Use ADDR_SPACE_COUNT as
array size.
(avr_addrspace): Same. Initialize .section_name. Remove last
NULL entry. Put __memx into .progmemx.data.
(progmem_section_prefix): Remove.
(avr_asm_init_sections): No need to initialize progmem_section.
(avr_asm_named_section): Use avr_addrspace[].section_name to get
section name prefix.
(avr_asm_select_section): Ditto. And use get_unnamed_section to
retrieve the progmem section.
* avr-c.c (avr_cpu_cpp_builtins): Use ADDR_SPACE_COUNT as loop
boundary to run over avr_addrspace[].
(avr_register_target_pragmas): Ditto.
Index: avr-c.c
===
--- avr-c.c (revision 194964)
+++ avr-c.c (working copy)
@@ -43,7 +43,7 @@ avr_register_target_pragmas (void)
/* Register address spaces. The order must be the same as in the respective
enum from avr.h (or designated initialized must be used in avr.c). */
- for (i = 0; avr_addrspace[i].name; i++)
+ for (i = 0; i ADDR_SPACE_COUNT; i++)
{
gcc_assert (i == avr_addrspace[i].id);
@@ -160,7 +160,7 @@ avr_cpu_cpp_builtins (struct cpp_reader
if (!strcmp (lang_hooks.name, GNU C))
{
- for (i = 0; avr_addrspace[i].name; i++)
+ for (i = 0; i ADDR_SPACE_COUNT; i++)
if (!ADDR_SPACE_GENERIC_P (i)
/* Only supply __FLASHn macro if the address space is reasonable
for this target. The address space qualifier itself is still
Index: avr.c
===
--- avr.c (revision 194964)
+++ avr.c (working copy)
@@ -80,29 +80,18 @@
/* Known address spaces. The order must be the same as in the respective
enum from avr.h (or designated initialized must be used). */
-const avr_addrspace_t avr_addrspace[] =
+const avr_addrspace_t avr_addrspace[ADDR_SPACE_COUNT] =
{
-{ ADDR_SPACE_RAM, 0, 2, , 0 },
-{ ADDR_SPACE_FLASH, 1, 2, __flash, 0 },
-{ ADDR_SPACE_FLASH1, 1, 2, __flash1, 1 },
-{ ADDR_SPACE_FLASH2, 1, 2, __flash2, 2 },
-{ ADDR_SPACE_FLASH3, 1, 2, __flash3, 3 },
-{ ADDR_SPACE_FLASH4, 1, 2, __flash4, 4 },
-{ ADDR_SPACE_FLASH5, 1, 2, __flash5, 5 },
-{ ADDR_SPACE_MEMX, 1, 3, __memx, 0 },
-{ 0 , 0, 0, NULL, 0 }
+ { ADDR_SPACE_RAM, 0, 2, , 0, NULL },
+ { ADDR_SPACE_FLASH, 1, 2, __flash, 0, .progmem.data },
+ { ADDR_SPACE_FLASH1, 1, 2, __flash1, 1, .progmem1.data },
+ { ADDR_SPACE_FLASH2, 1, 2, __flash2, 2, .progmem2.data },
+ { ADDR_SPACE_FLASH3, 1, 2, __flash3, 3, .progmem3.data },
+ { ADDR_SPACE_FLASH4, 1, 2, __flash4, 4, .progmem4.data },
+ { ADDR_SPACE_FLASH5, 1, 2, __flash5, 5, .progmem5.data },
+ { ADDR_SPACE_MEMX, 1, 3, __memx, 0, .progmemx.data },
};
-/* Map 64-k Flash segment to section prefix. */
-static const char* const progmem_section_prefix[6] =
- {
-.progmem.data,
-.progmem1.data,
-.progmem2.data,
-.progmem3.data,
-.progmem4.data,
-.progmem5.data
- };
/* Holding RAM addresses of some SFRs used by the compiler and that
are unique over all devices in an architecture like 'avr4'. */
@@ -205,8 +194,9 @@ const struct mcu_type_s *avr_current_dev
static GTY(()) section *progmem_swtable_section;
/* Unnamed sections associated to __attribute__((progmem)) aka. PROGMEM
- or to address space __flash*. */
-static GTY(()) section *progmem_section[6];
+ or to address space __flash* or __memx. Only used as singletons inside
+ avr_asm_select_section, but it must not be local there because of GTY. */
+static GTY(()) section *progmem_section[ADDR_SPACE_COUNT];
/* Condition for insns/expanders from avr-dimode.md. */
bool avr_have_dimode = true;
@@ -8107,8 +8097,6 @@ avr_output_progmem_section_asm_op (const
static void
avr_asm_init_sections (void)
{
- unsigned int n;
-
/* Set up a section for jump tables. Alignment is handled by
ASM_OUTPUT_BEFORE_CASE_LABEL. */
@@ -8127,13 +8115,6 @@ avr_asm_init_sections (void)
,\ax\,@progbits);
}
Re: [Patch, AArch64] Implement vec_init.
On 07/01/13 13:11, Tejas Belagod wrote: Hi, The attached patch implements vec_init for AArch64. This has been tested on aarch64-none-elf with no regressions. OK for trunk? Thanks, Tejas Belagod ARM. 2013-01-07 Tejas Belagod tejas.bela...@arm.com gcc/ * config/aarch64/aarch64-simd.md (vec_initmode): New. * config/aarch64/aarch64-protos.h (aarch64_expand_vector_init): Declare. * config/aarch64/aarch64.c (aarch64_simd_dup_constant, aarch64_simd_make_constant, aarch64_expand_vector_init): New. OK
Re: [Patch, AArch64-4.7] Implement vec_init.
On 07/01/13 13:11, Tejas Belagod wrote: Hi, The attached patch implements vec_init for AArch64. This has been tested on aarch64-none-elf with no regressions. OK for aarch64-4.7-branch? Thanks, Tejas Belagod ARM. 2013-01-07 Tejas Belagod tejas.bela...@arm.com gcc/ * config/aarch64/aarch64-simd.md (vec_initmode): New. * config/aarch64/aarch64-protos.h (aarch64_expand_vector_init): Declare. * config/aarch64/aarch64.c (aarch64_simd_dup_constant, aarch64_simd_make_constant, aarch64_expand_vector_init): New. OK
Re: [AArch64] Make argument of ld1 intrinsics const.
On 07/01/13 10:54, James Greenhalgh wrote: Hi, This patch fixes the definitions of the vld1* intrinsics to take a const-qualified argument. I've tested this on aarch64-none-elf with no regressions. Is this OK to commit? Thanks, James Greenhalgh --- 2013-01-07 James Greenhalgh james.greenha...@arm.com * config/aarch64/arm_neon.h (vld1_dup_*): Make argument const. (vld1q_dup_*): Likewise. (vld1_*): Likewise. (vld1q_*): Likewise. (vld1_lane_*): Likewise. (vld1q_lane_*): Likewise. OK
Re: [AARCH64] Add support for vector and scalar floating-point immediate loads.
On 07/01/13 10:36, James Greenhalgh wrote: bool aarch64_bitmask_imm (HOST_WIDE_INT val, enum machine_mode); -bool aarch64_const_double_zero_rtx_p (rtx); +bool aarch64_float_const_zero_rtx_p (rtx); bool aarch64_constant_address_p (rtx); Can we keep these in alphabetical order please? Otherwise OK /Marcus
[patch,doc,avr] ad PR54461: Document --with-avrlibc
This addendum adds --with-avrlibc to the (web) documentation.
It inserts the explanation after --with-newlib which seems to be a reasonable
place.
Ok to apply?
Johann
PR target/PR54461
* doc/install.texi (Cross-Compiler-Specific Options): Document
--with-avrlibc.
Index: doc/install.texi
===
--- doc/install.texi (revision 194964)
+++ doc/install.texi (working copy)
@@ -1813,6 +1813,16 @@ being used as the target C library. Thi
omitted from @file{libgcc.a} on the assumption that it will be provided by
@samp{newlib}.
+@item --with-avrlibc
+Specifies that @samp{AVR-Libc} is
+being used as the target C library. This causes float support
+functions like @code{__addsf3} to be omitted from @file{libgcc.a} on
+the assumption that it will be provided by @file{libm.a}. For more
+technical details, cf. @uref{http://gcc.gnu.org/PR54461,,PR54461}.
+This option is only supported for the AVR target and only for
+non-RTEMS configurations. The options is supported since version
+4.7.2 and is the default in 4.8.0 and newer.
+
@item --with-build-time-tools=@var{dir}
Specifies where to find the set of target tools (assembler, linker, etc.)
that will be used while building GCC itself. This option can be useful
RE: [patch,doc,avr] ad PR54461: Document --with-avrlibc
-Original Message- From: Georg-Johann Lay Sent: Monday, January 07, 2013 8:02 AM To: gcc-patches@gcc.gnu.org Cc: Denis Chertykov; Weddington, Eric; Gerald Pfeifer Subject: [patch,doc,avr] ad PR54461: Document --with-avrlibc This addendum adds --with-avrlibc to the (web) documentation. It inserts the explanation after --with-newlib which seems to be a reasonable place. Ok to apply? Change: +This option is only supported for the AVR target and only for +non-RTEMS configurations. The options is supported since version To: +This option is only supported for the AVR target and only for +non-RTEMS configurations, which currently use newlib. The option is supported since version Note misspelling of option on second line. (You have the plural form when it should be singular. Because avr-libc is used more frequently than newlib, and especially since it is default (for a version and above), what about placing this option text *before* --with-newlib in the manual? Eric
[PATCH] Bump LTO bytecode version
This bumps the minor version, LTO bytecode from 4.7 is not compatible with one from 4.8. Committed as obvious. Thanks, Richard. 2013-01-07 Richard Biener rguent...@suse.de * lto-streamer.h (LTO_minor_version): Bump to 2. Index: gcc/lto-streamer.h === *** gcc/lto-streamer.h (revision 194970) --- gcc/lto-streamer.h (working copy) *** along with GCC; see the file COPYING3. *** 141,147 #define LTO_SECTION_NAME_PREFIX .gnu.lto_ #define LTO_major_version 2 ! #define LTO_minor_version 1 typedef unsigned char lto_decl_flags_t; --- 141,147 #define LTO_SECTION_NAME_PREFIX .gnu.lto_ #define LTO_major_version 2 ! #define LTO_minor_version 2 typedef unsigned char lto_decl_flags_t;
Re: [patch,doc,avr] ad PR54461: Document --with-avrlibc
Weddington, Eric wrote: Georg-Johann Lay Sent Document --with-avrlibc This addendum adds --with-avrlibc to the (web) documentation. It inserts the explanation after --with-newlib which seems to be a reasonable place. Ok to apply? Change: +This option is only supported for the AVR target and only for +non-RTEMS configurations. The options is supported since version To: +This option is only supported for the AVR target and only for +non-RTEMS configurations, which currently use newlib. The option is supported since version Note misspelling of option on second line. (You have the plural form when it should be singular. Thanks. Because avr-libc is used more frequently than newlib, and especially since it is default (for a version and above), what about placing this option text *before* --with-newlib in the manual? I put it after newlib because I think newlib is far more common (to the general reader of the GCC install docs). Johann
RE: [patch,doc,avr] ad PR54461: Document --with-avrlibc
-Original Message- From: Georg-Johann Lay Sent: Monday, January 07, 2013 8:28 AM To: Weddington, Eric Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Gerald Pfeifer Subject: Re: [patch,doc,avr] ad PR54461: Document --with-avrlibc +This option is only supported for the AVR target and only for +non- RTEMS configurations, which currently use newlib. The option is supported since version I forgot to mention that it looks like there might be some work to get avr rtems target working with avr-libc. But that is unknown timing at this point. Ok to commit with the changes you made. Thanks! Eric
[patch] Let tree-ssa-sink also sink pure calls
Hello,
As-is, tree-ssa-sink.c can only sink GIMPLE_ASSIGN statements. This
patch lets tree-ssa-sink.c sink pure calls also.
This allows the pass to sink the call to use in the following test
case (new test case, ssa-sink-10.c to be):
-- 8
/* { dg-do compile } */
/* { dg-options -O -fdump-tree-sink } */
__attribute__((__noinline__,__noclone__,__pure__,__const__))
int use (int b)
{
return b * 2 + 4;
}
int foo (int b, int c, int d)
{
int res, r = 0;
res = use (b);
if (c)
r = res;
return r;
}
/* use(b) should be sunk below the if(c). */
/* { dg-final { scan-tree-dump-times Sinking.*use 1 sink } } */
/* { dg-final { cleanup-tree-dump sink } } */
-- 8
so that the optimized code (.092t.sink dump) looks like this:
;; Function foo (foo, funcdef_no=1, decl_uid=2008, cgraph_uid=1)
...
Sinking r_3 = use (b_2(D));
from bb 2 to bb 3
foo (int b, int c, int d)
{
int r;
bb 2:
if (c_4(D) != 0)
goto bb 3;
else
goto bb 5;
bb 5:
goto bb 4;
bb 3:
r_3 = use (b_2(D));
bb 4:
# r_1 = PHI 0(5), r_3(3)
return r_1;
}
The patch allows the sinking of a number of functions in GCC itself
(mostly simple predicates e.g. from gimple.h) to be sunk in an LTO
bootstrap.
The patch is a bit larger than necessary because I cleaned up the
comments a bit. The only real changes are these three bits:
/* We only can sink assignments. */
- if (!is_gimple_assign (stmt))
+ stmt_lhs = gimple_get_lhs (stmt);
+ if (stmt_lhs == NULL_TREE)
return false;
and
- TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode))
+ TYPE_MODE (TREE_TYPE (stmt_lhs)) == BLKmode))
and
- operand_equal_p (gimple_assign_lhs (stmt),
- gimple_assign_lhs (use_stmt), 0))
+ operand_equal_p (stmt_lhs, gimple_assign_lhs (use_stmt), 0))
continue;
Bootstrappedtested on powerpc64-unknown-linux-gnu.
OK for GCC 4.9 stage1?
Ciao!
Steven
gcc/
* tree-ssa-sink.c (statement_sink_location): Handle pure calls.
testsuite/
* gcc.dg/tree-ssa/ssa-sink-10.c: New test.
Index: tree-ssa-sink.c
===
--- tree-ssa-sink.c (revision 194924)
+++ tree-ssa-sink.c (working copy)
@@ -264,56 +264,48 @@ statement_sink_location (gimple stmt, basic_block
def_operand_p def_p;
ssa_op_iter iter;
imm_use_iterator imm_iter;
+ tree stmt_lhs;
/* We only can sink assignments. */
- if (!is_gimple_assign (stmt))
+ stmt_lhs = gimple_get_lhs (stmt);
+ if (stmt_lhs == NULL_TREE)
return false;
- /* We only can sink stmts with a single definition. */
+ /* We only can sink stmts with a single definition.
+ We don't want to sink dead code, so anything with 0 immediate uses
+ is not sunk. */
def_p = single_ssa_def_operand (stmt, SSA_OP_ALL_DEFS);
- if (def_p == NULL_DEF_OPERAND_P)
+ if (def_p == NULL_DEF_OPERAND_P
+ || has_zero_uses (DEF_FROM_PTR (def_p)))
return false;
- /* Return if there are no immediate uses of this stmt. */
- if (has_zero_uses (DEF_FROM_PTR (def_p)))
-return false;
-
/* There are a few classes of things we can't or don't move, some because we
don't have code to handle it, some because it's not profitable and some
- because it's not legal.
+ because it's not legal. */
- We can't sink things that may be global stores, at least not without
- calculating a lot more information, because we may cause it to no longer
- be seen by an external routine that needs it depending on where it gets
- moved to.
-
- We don't want to sink loads from memory.
-
- We can't sink statements that end basic blocks without splitting the
- incoming edge for the sink location to place it there.
-
- We can't sink statements that have volatile operands.
-
- We don't want to sink dead code, so anything with 0 immediate uses is not
- sunk.
-
- Don't sink BLKmode assignments if current function has any local explicit
- register variables, as BLKmode assignments may involve memcpy or memset
- calls or, on some targets, inline expansion thereof that sometimes need
- to use specific hard registers.
-
- */
- if (stmt_ends_bb_p (stmt)
+ if (/* We can't sink statements that end basic blocks without splitting
+the incoming edge for the sink location to place it there. */
+ stmt_ends_bb_p (stmt)
+ /* We can't sink statements with side effects, e.g. statements that
+have volatile operands, or non-pure calls. */
|| gimple_has_side_effects (stmt)
- || gimple_has_volatile_ops (stmt)
+ /* We don't want to sink loads from memory.
+We can't sink things that may be global stores, at least not
+without calculating a lot more information, because we may cause
+it to no longer be seen by an external routine that needs it
+depending
Re: [committed] 2011 and 2012 Copyright year updates
On Sun, 6 Jan 2013, Richard Sandiford wrote: Anyway, here's my attempt a script to convert to ranges and, if enabled, to include the current year. The script only updates FSF copyright notices and leaves others alone. I've tried my best to make sure that licences and imported FSF sources aren't touched, but I could have missed some cases. I don't see anything to exclude the soft-fp files imported from glibc (where the current glibc versions should be copied instead ... but note that some soft-fp files, e.g. for TImode, are GCC-specific and not in glibc). It may make sense to leave out libiberty (and other directories shared with the src repository) initially. To convert them, binutils will need an appropriate README notice explaining the meaning of ranges (like the one I added to GCC's toplevel README a while back), as per GNU policy, and someone may need to work out whether any missing years being inserted in the ranges need to be copyrightable years for all of GCC, binutils and GDB (and what the copyrightable year ranges are in each case - the years in which either there was a release of the relevant package, including beta releases etc., or it had public version control). I think a patch for each directory will need posting separately for review of such things as whether any imported / generated files are mistakenly changed. I've also attached a bzip2 patch of the gcc/ and fixincludes/ part. This patch converts to ranges but doesn't add 2013. I can add 2013 at the same time, separately or not at all; let me know. I think 2013 should be added (so the notices should say year-2013, for any value of year 1986 or later, all years 1987 and later being copyrightable years for GCC). But --version notices should just say 2013 (including e.g. that in fixincludes/mkheaders.in). -- Joseph S. Myers jos...@codesourcery.com
Re: PING^2: [PATCH] Support -fuse-ld=bfd and -fuse-ld=gold
On Wed, 19 Dec 2012, H.J. Lu wrote:
+#ifdef CROSS_DIRECTORY_STRUCTURE
+ = concat(target_machine, -, ld_suffixes[i], NULL);
Missing space before '('.
The patch is OK with that fixed.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [patch] Let tree-ssa-sink also sink pure calls
On Mon, 7 Jan 2013, Steven Bosscher wrote:
Hello,
As-is, tree-ssa-sink.c can only sink GIMPLE_ASSIGN statements. This
patch lets tree-ssa-sink.c sink pure calls also.
This allows the pass to sink the call to use in the following test
case (new test case, ssa-sink-10.c to be):
-- 8
/* { dg-do compile } */
/* { dg-options -O -fdump-tree-sink } */
__attribute__((__noinline__,__noclone__,__pure__,__const__))
int use (int b)
{
return b * 2 + 4;
}
int foo (int b, int c, int d)
{
int res, r = 0;
res = use (b);
if (c)
r = res;
return r;
}
/* use(b) should be sunk below the if(c). */
/* { dg-final { scan-tree-dump-times Sinking.*use 1 sink } } */
/* { dg-final { cleanup-tree-dump sink } } */
-- 8
so that the optimized code (.092t.sink dump) looks like this:
;; Function foo (foo, funcdef_no=1, decl_uid=2008, cgraph_uid=1)
...
Sinking r_3 = use (b_2(D));
from bb 2 to bb 3
foo (int b, int c, int d)
{
int r;
bb 2:
if (c_4(D) != 0)
goto bb 3;
else
goto bb 5;
bb 5:
goto bb 4;
bb 3:
r_3 = use (b_2(D));
bb 4:
# r_1 = PHI 0(5), r_3(3)
return r_1;
}
The patch allows the sinking of a number of functions in GCC itself
(mostly simple predicates e.g. from gimple.h) to be sunk in an LTO
bootstrap.
The patch is a bit larger than necessary because I cleaned up the
comments a bit. The only real changes are these three bits:
/* We only can sink assignments. */
- if (!is_gimple_assign (stmt))
+ stmt_lhs = gimple_get_lhs (stmt);
+ if (stmt_lhs == NULL_TREE)
return false;
and
- TYPE_MODE (TREE_TYPE (gimple_assign_lhs (stmt))) == BLKmode))
+ TYPE_MODE (TREE_TYPE (stmt_lhs)) == BLKmode))
and
- operand_equal_p (gimple_assign_lhs (stmt),
- gimple_assign_lhs (use_stmt), 0))
+ operand_equal_p (stmt_lhs, gimple_assign_lhs (use_stmt), 0))
continue;
Bootstrappedtested on powerpc64-unknown-linux-gnu.
OK for GCC 4.9 stage1?
Comments below
Ciao!
Steven
gcc/
* tree-ssa-sink.c (statement_sink_location): Handle pure calls.
testsuite/
* gcc.dg/tree-ssa/ssa-sink-10.c: New test.
Index: tree-ssa-sink.c
===
--- tree-ssa-sink.c (revision 194924)
+++ tree-ssa-sink.c (working copy)
@@ -264,56 +264,48 @@ statement_sink_location (gimple stmt, basic_block
def_operand_p def_p;
ssa_op_iter iter;
imm_use_iterator imm_iter;
+ tree stmt_lhs;
/* We only can sink assignments. */
- if (!is_gimple_assign (stmt))
+ stmt_lhs = gimple_get_lhs (stmt);
+ if (stmt_lhs == NULL_TREE)
return false;
Instead of this ...
- /* We only can sink stmts with a single definition. */
+ /* We only can sink stmts with a single definition.
+ We don't want to sink dead code, so anything with 0 immediate uses
+ is not sunk. */
def_p = single_ssa_def_operand (stmt, SSA_OP_ALL_DEFS);
- if (def_p == NULL_DEF_OPERAND_P)
+ if (def_p == NULL_DEF_OPERAND_P
+ || has_zero_uses (DEF_FROM_PTR (def_p)))
return false;
... do
stmt_lhs = DEF_FROM_PTR (def_p);
which then also handles sinking single-def GIMPLE_ASMs ;)
- /* Return if there are no immediate uses of this stmt. */
- if (has_zero_uses (DEF_FROM_PTR (def_p)))
-return false;
-
/* There are a few classes of things we can't or don't move, some because
we
don't have code to handle it, some because it's not profitable and some
- because it's not legal.
+ because it's not legal. */
- We can't sink things that may be global stores, at least not without
- calculating a lot more information, because we may cause it to no longer
- be seen by an external routine that needs it depending on where it gets
- moved to.
-
- We don't want to sink loads from memory.
-
- We can't sink statements that end basic blocks without splitting the
- incoming edge for the sink location to place it there.
-
- We can't sink statements that have volatile operands.
-
- We don't want to sink dead code, so anything with 0 immediate uses is
not
- sunk.
-
- Don't sink BLKmode assignments if current function has any local
explicit
- register variables, as BLKmode assignments may involve memcpy or memset
- calls or, on some targets, inline expansion thereof that sometimes need
- to use specific hard registers.
-
- */
- if (stmt_ends_bb_p (stmt)
+ if (/* We can't sink statements that end basic blocks without splitting
+the incoming edge for the sink location to place it there. */
+ stmt_ends_bb_p (stmt)
+ /* We can't sink statements with side effects, e.g. statements that
+have volatile operands, or non-pure calls. */
||
[testsuite] Fix 32-bit gcc.dg/lto/pr55525 with Sun ld
gcc.dg/lto/pr55525 currently FAILs on Solaris with Sun ld for the 32-bit
multilib:
FAIL: gcc.dg/lto/pr55525 c_lto_pr55525_0.o-c_lto_pr55525_1.o link, -flto -w
UNRESOLVED: gcc.dg/lto/pr55525 c_lto_pr55525_0.o-c_lto_pr55525_1.o execute
-flto -w
ld: fatal: symbol 's' has differing sizes:
(file c_lto_pr55525_0.o value=0x8; file c_lto_pr55525_1.o value=0x4);
tentative symbol cannot override defined symbol of smaller size
The following patch (from Richi) fixes this.
Tested with the appropriate runtest invocation on i386-pc-solaris2.10
and x86_64-unknown-linux-gnu (both multilibs each), installed on
mainline as approved in the PR.
Rainer
2013-01-07 Richard Biener rguent...@suse.de
* gcc.dg/lto/pr55525_0.c (s): Size like char *.
# HG changeset patch
# Parent 698c7b5e4929ecd54651ad11b9f49dc7e8c3f395
Fix 32-bit gcc.dg/lto/pr55525 with Sun ld
diff --git a/gcc/testsuite/gcc.dg/lto/pr55525_0.c b/gcc/testsuite/gcc.dg/lto/pr55525_0.c
--- a/gcc/testsuite/gcc.dg/lto/pr55525_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr55525_0.c
@@ -1,7 +1,7 @@
/* { dg-lto-do link } */
/* { dg-lto-options { { -flto -w } } } */
-char s[8];
+char s[sizeof (char *)];
int main(void)
{
return strcmp(s[1], foo);
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
RE: [RFC] New feature to reuse one multilib among different targets
On Fri, 7 Dec 2012, Terry Guo wrote: 2012-12-07 Terry Guo terry@arm.com * gcc/Makefile.in (s-mlib): New argument MULTILIB_REUSE. * gcc/doc/fragments.texi: Document MULTILIB_REUSE. * gcc/gcc.c (multilib_reuse): New internal spec. (set_multilib_dir): Also search multilib from multilib_reuse. * gcc/genmultilib (tmpmultilib3): Refactor code. (tmpmultilib4): Ditto. (multilib_reuse): New multilib argument. This patch is OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch,doc,avr] ad PR54461: Document --with-avrlibc
Weddington, Eric wrote: Georg-Johann Lay Sent Document --with-avrlibc This option is only supported for the AVR target and only for non-RTEMS configurations, which currently use newlib. The option is supported since version I forgot to mention that it looks like there might be some work to get avr rtems target working with avr-libc. But that is unknown timing at this point. If --with-avrlibc is extended to work with RTEMS, the docs should reflect that, of course. But this is independent from the state of AVR-Libc. Ok to commit with the changes you made. I used a different formulation because I found the for non-RTEMS configurations, which currently use newlib confusing: This option is only supported for the AVR target. It is not supported for RTEMS configurations, which currently use newlib. http://gcc.gnu.org/viewcvs?view=revisionrevision=194978 Johann
Re: [PATCH] Enable non-complex math builtins from C99 for Bionic
On Fri, 21 Dec 2012, Alexander Ivchenko wrote: Hi, Thank you very much for your input! Please, take a look at the updated version: I fixed coding style, moved documentation for TARGET_LIBC_HAS_FUNCTION to target.def. Removed TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS and all their influence and moved the implementation of linux_libc_has_function to host-linux.c. I changed the defaults: now it is assumed that we have C99 runtime, but no sincos. I updated all needed gcc/config/*.h. But 'm not sure in this part, cause I don't have the opportunity to test it properly... This patch seems mostly plausible, though there are various places that call targetm.libc_has_function with and empty string as second argument, that should be naming the specific function instead. I haven't reviewed the details, and at this development stage I think it will need to wait until after 4.8 branches. -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file
Sorry for the late and lengthy answer. To make the story short, I think the decision to remove -fno-whole-file should be based on the answer to the following questions: (1) Is there any hint of -fno-whole-file misbehavior (as suggested by the second point of the Reasoning)? As said in my comment below, if the answer is yes, then IMO this should be investigated and fixed before removal. (2) Is the -fwhole-file status ZKB (zero known bug)? I am not 100% confident that this the case (see at least PR 45128). (3) What is the confidence that there is no rampant bug in -fwhole-file? While I cannot remember any recent PR in this area (thanks Paul), at the same time I did not see recent reports (in buzilla or in comp.lang.fortran) about the common errors which have plagued the f77 to f90 transition. (4) Is there an easy replacement for -fno-whole-file? Here the answer is clearly yes: put the different TUs in different files. So to summarize, I think the key point is the answer to the first question. I think the answer is no, but this was not what I understood from the original post. This patch removes -fno-whole-file. (Actually, it turns it into Ignore.) Reasoning: * -fwhole-file/-fno-whole-file was added in 4.5 to make the transition easier; -fwhole-file is the default since 4.6. My understanding of -fno-whole-file as well as -fno-realloc-lhs, -fno-frontend-optimize, or any of the -fno-* options is two fold: (i) to provide a workaround to user hit by a bug in the corresponding area, (ii) to help the maintainers to locate the bug or to change the default in case of a too severe bug. So the decision to remove an option should be based on the answer to the questions (2) and (3) above. * There are many wrong-code issues and probably also some ICEs with -fno-whole file. I think the wording is misleading. I have checked bugzilla for open PR containing -fno-whole-file and I have found only 2 (48939 and 52621). None of them are related to wrong-code issue due to -fno-whole-file. My understanding of the -fno-whole-file option is that it is (should be) strictly equivalent to put all the TUs in separate files. If it exists an example for which this is not true, I think it would be a bug, a PR should be filled for it, and indeed, the removal of -fno-whole-file should be delayed after it the bug(s) is (are) fixed. If the meaning of the quoted sentence is that -fwhole-file gives errors for invalid code (missing interface, argument mismatches, ...), hence prevents wrong-code issues, this is true. However such errors can only be catched if all the involved TUs are in the same file, e.g. I won't get any error if I mess up the arguments of a subroutine in the lapack library unless I add it (and its dependencies) to my source. * The generated code of -fwhole-file is faster as it allows for inlining. This has nothing to do with the removal of -fno-whole-file. AFAICT most of the speeddup is achieved with -fwhole-program. In addition the code has to be in a single file. On platforms with the right linker and the right plugin (i.e. not Darwin) the speedup for split files can be obtained by compiling the different files with -flto. * -fno-whole-file has been deprecated since 4.6 and announced for removal. OK, but no time table has been released so far. * Code cleanup is always nice (diff -w): 17 insertions(+), 80 deletions(-) OK Build and regtested on x86-64-gnu-linux. OK for the trunk? PS: Dominique pointed out that PR 45128 is a -fwhole-file regression. However, it mainly shows that gfortran needs the new array descriptor to fix such subpointer issues (and other PRs). Compiling PR 45128 with -fwhole-file gives an ICE: Segmentation fault, while with -fno-whole-file it gives a linking error Undefined symbols: _span.0, referenced from: ... as it does if the two TUs are put is different files. Dominique
RE: [patch,doc,avr] ad PR54461: Document --with-avrlibc
-Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Monday, January 07, 2013 9:17 AM To: Weddington, Eric Cc: gcc-patches@gcc.gnu.org; Denis Chertykov; Gerald Pfeifer Subject: Re: [patch,doc,avr] ad PR54461: Document --with-avrlibc I used a different formulation because I found the for non-RTEMS configurations, which currently use newlib confusing: This option is only supported for the AVR target. It is not supported for RTEMS configurations, which currently use newlib. Looks great! Thanks for understanding my intent. :-) Eric
[v3, build] Restrict -Wa,-nH use to Solaris (PR libstdc++/55594)
As reported in the PR, the AIX assembler also accepts the -nH option,
but with completely different semantics. To avoid this, the current
patch restricts checking the option to Solaris targets.
Bootstrapped without regressions on i386-pc-solaris2.10 with Sun as
(-Wa,-nH is added), x86_64-unknown-linux-gnu (test no longer performed),
tested on AIX by David.
Ok for mainline?
Rainer
2013-01-06 Rainer Orth r...@cebitec.uni-bielefeld.de
PR libstdc++/55594
* acinclude.m4 (GLIBCXX_CHECK_ASSEMBLER_HWCAP): Restrict test to
Solaris targets.
* configure: Regenerate.
# HG changeset patch
# Parent 432f2ce7493ce21ac73d8d1a10d32695da22d58a
Restrict -Wa,-nH use to Solaris (PR libstdc++/55594)
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -178,17 +178,23 @@ dnl
AC_DEFUN([GLIBCXX_CHECK_ASSEMBLER_HWCAP], [
test -z $HWCAP_FLAGS HWCAP_FLAGS=''
- ac_save_CFLAGS=$CFLAGS
- CFLAGS=$CFLAGS -Wa,-nH
-
- AC_MSG_CHECKING([for as that supports -Wa,-nH])
- AC_TRY_COMPILE([], [return 0;], [ac_hwcap_flags=yes],[ac_hwcap_flags=no])
- if test $ac_hwcap_flags = yes; then
-HWCAP_FLAGS=-Wa,-nH $HWCAP_FLAGS
- fi
- AC_MSG_RESULT($ac_hwcap_flags)
-
- CFLAGS=$ac_save_CFLAGS
+ # Restrict the test to Solaris, other assemblers (e.g. AIX as) have -nH
+ # with a different meaning.
+ case ${target_os} in
+solaris2*)
+ ac_save_CFLAGS=$CFLAGS
+ CFLAGS=$CFLAGS -Wa,-nH
+
+ AC_MSG_CHECKING([for as that supports -Wa,-nH])
+ AC_TRY_COMPILE([], [return 0;], [ac_hwcap_flags=yes],[ac_hwcap_flags=no])
+ if test $ac_hwcap_flags = yes; then
+ HWCAP_FLAGS=-Wa,-nH $HWCAP_FLAGS
+ fi
+ AC_MSG_RESULT($ac_hwcap_flags)
+
+ CFLAGS=$ac_save_CFLAGS
+ ;;
+ esac
AC_SUBST(HWCAP_FLAGS)
])
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, dataflow]: Fix PR55845, 454.calculix miscompares on x86 AVX due to movement of vzeroupper
On Sun, Jan 6, 2013 at 5:22 PM, Jakub Jelinek ja...@redhat.com wrote:
--- df-problems.c (revision 194945)
+++ df-problems.c (working copy)
@@ -3916,6 +3916,10 @@ can_move_insns_across (rtx from, rtx to, rtx acros
break;
if (NONDEBUG_INSN_P (insn))
{
+ /* Do not move unspec_volatile insns. */
+ if (GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE)
+ break;
+
Shouldn't UNSPEC_VOLATILE be handled similarly in the across_from ..
across_to loop? Both UNSPEC_VOLATILE and volatile asm are handled there
just with
trapping_insns_in_across |= may_trap_p (PATTERN (insn));
but your new change doesn't prevent moving just trapping insns across
UNSPEC_VOLATILE, but any insns whatsoever. So supposedly for UNSPEC_VOLATILE
the first loop should just return false; (or fail = 1; ?).
For asm volatile I guess the code is fine as is, it must always describe
what exactly it modifies, so supposedly non-trapping insns can be moved
across asm volatile.
if (may_trap_or_fault_p (PATTERN (insn))
(trapping_insns_in_across || other_branch_live != NULL))
break;
You could do the check only for may_trap_or_fault_p, all UNSPEC_VOLATILE
may trap.
BTW, can't UNSPEC_VOLATILE be embedded deeply in the pattern?
So volatile_insn_p (insn) asm_noperands (PATTERN (insn)) == -1?
But perhaps you want to treat that way only UNSPEC_VOLATILE directly in the
pattern and all other UNSPEC_VOLATILE insns must describe in detail what
exactly they are changing? This really needs to be better documented.
TBH, I'm not that familiar with the RTL infrastructure enough to
answer these questions. While I can spend some time on this problem,
and probably waste quite some reviewer's time, the problem is not that
trivial as I hoped to be, so I would kindly ask someone with better
understanding of this part of the compiler for the proper solution.
Uros.
Re: C++ PATCH for c++/55753 (ICE with constexpr)
And another bug: we were building an AGGR_INIT_EXPR in non-dependent
code, and then failing to handle it properly in fold_non_dependent_expr.
Fixed by not creating AGGR_INIT_EXPR in templates. As a result, we
end up with a CALL_EXPR to the address of a constructor, and we need to
avoid an error when instantiating that by stripping the address and
letting the call code put it back.
Tested x86_64-pc-linux-gnu, applying to trunk. This is only an ICE with
checking enabled, so I'm not going to apply it to 4.7.
commit 843d522093cdc00181ea4590bf69d5f10162998a
Author: Jason Merrill ja...@redhat.com
Date: Mon Jan 7 09:31:13 2013 -0500
PR c++/55753
* tree.c (build_aggr_init_expr): Do nothing in a template.
* pt.c (tsubst_copy_and_build) [CALL_EXPR]: Strip an ADDR_EXPR off
a FUNCTION_DECL before tsubsting.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 30bafa0..c55dabef 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13743,6 +13743,11 @@ tsubst_copy_and_build (tree t,
else
qualified_p = false;
+ if (TREE_CODE (function) == ADDR_EXPR
+ TREE_CODE (TREE_OPERAND (function, 0)) == FUNCTION_DECL)
+ /* Avoid error about taking the address of a constructor. */
+ function = TREE_OPERAND (function, 0);
+
function = tsubst_copy_and_build (function, args, complain,
in_decl,
!qualified_p,
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index fcab1a4..0824214 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -412,6 +412,10 @@ build_aggr_init_expr (tree type, tree init)
tree rval;
int is_ctor;
+ /* Don't build AGGR_INIT_EXPR in a template. */
+ if (processing_template_decl)
+return init;
+
if (TREE_CODE (init) == CALL_EXPR)
fn = CALL_EXPR_FN (init);
else if (TREE_CODE (init) == AGGR_INIT_EXPR)
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor13.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor13.C
new file mode 100644
index 000..ed01a31
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor13.C
@@ -0,0 +1,15 @@
+// PR c++/55753
+// { dg-options -std=c++11 }
+
+struct A
+{
+ double r,i;
+ constexpr A(double r = 0.0, double i = 0.0): r(r), i(i) {}
+};
+
+template typename Tp
+struct B {
+ B() {
+A((true ? 1.0 : A()));
+ }
+};
Re: [asan] Fix asan -fsection-anchors handling
Jakub Jelinek ja...@redhat.com writes: 2012-12-21 Jakub Jelinek ja...@redhat.com * varasm.c (output_constant_def_contents): For asan_protect_global protected strings, adjust DECL_ALIGN if needed, before testing for anchored symbols. (place_block_symbol): Adjust size for asan protected STRING_CSTs if TREE_CONSTANT_POOL_ADDRESS_P. Increase alignment for asan protected normal decls. (output_object_block): For asan protected decls, emit asan padding after their contents. (asan_protect_global): Don't check TREE_ASM_WRITTEN here. (asan_finish_file): Test it here instead. This looks OK to me. Thank you. -- Dodji
Re: Support for MIPS r5900
On 01/06/2013 03:56 PM, Jürgen Urban wrote: Hello, I created a patch from scratch to support MIPS r5900 used in the Playstation 2, but I have some problems with it. The attached patch only works with the latest binutils from CVS. The binutils forces the compiler to use r5900 compatible instructions which is good to find errors in the GCC. Later I will try to submit a patch here, but first I need some help. The MIPS r5900 supports 32 bit, 64 bit and 128 bit data accesses on a 32 Bit address bus. It supports instructions from MIPS ISA I, II, III, IV and has additional instructions, but none of them are complete. On each ISA level there are instructions missing. It can run MIPS ABI o32, n32 and o64 code, as long as unsupported instructions are not used or emulated by the operating system and the addresses keep in the first 32 bit. My patch adds support for r5900 and tries to disable the following unsupported instructions: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Does someone know how to enable TImode in MIPS ABI o32 (this doesn't need to use the 128 bit instructions at the moment)? There is some old code for the Playstation 2 which needs this. I know that TImode is supported in ABI n32, but some code uses also the 32 bit FPU and FPU registers are not available with -msoft-float in inline assembler. What is the best way to change the alignment to 128 bit for all structures and stack in any MIPS ABI? Much old code for the Playstation 2 expects this. Hmm, I did a R5900 port back in the late 90s... Did that port never get contributed (yes, my memory is that bad these days) As far as getting TI mode working, IIRC I did a configury hack of some sort to force using a 64bit host wide integer, that in turn made it possible to support TImode as a pair of 64bit HWIs. As far as aligning structures and the stack, GCC has a standard set of macros to define structure stack alignment. Jeff
Re: [Patch, Fortran] PR55763 - improve init-data checks for pointers
Hello,
Le 04/01/2013 13:51, Tobias Burnus a écrit :
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 2610784..146154e 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3291,22 +3291,21 @@ gfc_check_assign (gfc_expr *lvalue, gfc_expr *rvalue,
int conform)
gfc_try
gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
{
- symbol_attribute attr;
+ symbol_attribute attr, lhs_attr;
gfc_ref *ref;
bool is_pure, is_implicit_pure, rank_remap;
int proc_pointer;
- if (lvalue-symtree-n.sym-ts.type == BT_UNKNOWN
- !lvalue-symtree-n.sym-attr.proc_pointer)
+ lhs_attr = gfc_expr_attr (lvalue);
+ if (lvalue-ts.type == BT_UNKNOWN !lhs_attr.proc_pointer)
{
gfc_error (Pointer assignment target is not a POINTER at %L,
lvalue-where);
return FAILURE;
}
- if (lvalue-symtree-n.sym-attr.flavor == FL_PROCEDURE
- lvalue-symtree-n.sym-attr.use_assoc
- !lvalue-symtree-n.sym-attr.proc_pointer)
+ if (lhs_attr.flavor == FL_PROCEDURE lvalue-symtree-n.sym-attr.use_assoc
Should it be lhs_attr.use_assoc (for consistency)?
The patch has a downside: One gets some messages twice or trice: Once
for resolving the type declaration (type t) and then for resolving the
default initialization via
gfc_traverse_ns (ns, resolve_values);
That's a bit annoying, but better have diagnostics twice than not at all.
Currently, that's unavoidable as one cannot trivially distinguish
between a user-supplied sym-value and the default constructor. If you
think that this is a problem, one can change it, e.g. by setting a
sym-attr.value_is_default_init.
Or we can keep sym-value cleared until translation stage where the
(default) initialization is picked directly from the type.
Anyway
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK (even in its current state).
Mikael
[PATCH] Ensure gimplify_one_sizepos doesn't change something with INTEGER_TYPE into something with e.g. ENUMERAL_TYPE (PR middle-end/55851, take 2)
On Fri, Jan 04, 2013 at 02:21:43PM +0100, Richard Biener wrote:
The other way would be
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 194900)
+++ gcc/fold-const.c(working copy)
@@ -900,9 +900,9 @@ associate_trees (location_t loc, tree t1
static bool
int_binop_types_match_p (enum tree_code code, const_tree type1,
const_tree type2)
{
- if (TREE_CODE (type1) != INTEGER_TYPE !POINTER_TYPE_P (type1))
+ if (!INTEGRAL_TYPE_P (type1) !POINTER_TYPE_P (type1))
return false;
- if (TREE_CODE (type2) != INTEGER_TYPE !POINTER_TYPE_P (type2))
+ if (!INTEGRAL_TYPE_P (type2) !POINTER_TYPE_P (type2))
return false;
switch (code)
Ok, as discussed on IRC, here is your version, ok for trunk?
Bootstrapped/regtested on x86_64-linux and i686-linux.
2013-01-06 Jakub Jelinek ja...@redhat.com
Richard Biener rguent...@suse.de
PR middle-end/55851
* fold-const.c (int_binop_types_match_p): Allow all INTEGRAL_TYPE_P
types instead of just INTEGER_TYPE types.
* gcc.c-torture/compile/pr55851.c: New test.
--- gcc/fold-const.c(revision 194900)
+++ gcc/fold-const.c(working copy)
@@ -900,9 +900,9 @@ associate_trees (location_t loc, tree t1
static bool
int_binop_types_match_p (enum tree_code code, const_tree type1, const_tree
type2)
{
- if (TREE_CODE (type1) != INTEGER_TYPE !POINTER_TYPE_P (type1))
+ if (!INTEGRAL_TYPE_P (type1) !POINTER_TYPE_P (type1))
return false;
- if (TREE_CODE (type2) != INTEGER_TYPE !POINTER_TYPE_P (type2))
+ if (!INTEGRAL_TYPE_P (type2) !POINTER_TYPE_P (type2))
return false;
switch (code)
--- gcc/testsuite/gcc.c-torture/compile/pr55851.c.jj2013-01-03
16:20:19.085284806 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr55851.c 2013-01-03
16:19:27.698571718 +0100
@@ -0,0 +1,12 @@
+/* PR middle-end/55851 */
+
+enum { A = 1UL, B = -1UL } var = A;
+void foo (char *);
+
+void
+test (void)
+{
+ char vla[1][var];
+ vla[0][0] = 1;
+ foo (vla[0][0]);
+}
Jakub
Re: [PATCH] Fix PR55876 - Make generation of paradoxical subreg in widen_operand more robust
On 01/07/2013 02:16 AM, Tom de Vries wrote:
- /* If MODE is no wider than a single word, we return a paradoxical
- SUBREG. */
+ /* If MODE is no wider than a single word, we return a
+ lowpart or paradoxical SUBREG. */
if (GET_MODE_SIZE (mode) = UNITS_PER_WORD)
-return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
+{
+ if (GET_MODE_SIZE (mode) GET_MODE_SIZE (GET_MODE (op)))
+ return gen_lowpart_SUBREG (mode, op);
+ else
+ return gen_rtx_SUBREG (mode, force_reg (GET_MODE (op), op), 0);
+}
Is there any good reason we're using gen_rtx_SUBREG directly here?
Seems like this sort of logic would be present in plain gen_lowpart,
generating the paradoxical subreg that we want.
r~
Re: Use libstdc++-raw-cxx.m4 in libjava
On Fri, Jan 4, 2013 at 6:56 AM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:06 AM, Andreas Schwab sch...@linux-m68k.org wrote: H.J. Lu hjl.to...@gmail.com writes: On Thu, Jan 3, 2013 at 10:09 AM, Andreas Schwab sch...@linux-m68k.org wrote: H.J. Lu hjl.to...@gmail.com writes: diff --git a/libjava/Makefile.am b/libjava/Makefile.am index c6c84e4..dd08a4f 100644 --- a/libjava/Makefile.am +++ b/libjava/Makefile.am @@ -594,7 +594,7 @@ lib_gnu_awt_xlib_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ $(LIBSTDCXX_RAW_CXX_CXXFLAGS) ## The mysterious backslash in the grep pattern is consumed by make. -lib_gnu_awt_xlib_la_LDFLAGS = $(LIBSTDCXX_RAW_CXX_LDLAGS) \ +lib_gnu_awt_xlib_la_LDFLAGS = $(LIBSTDCXX_RAW_CXX_LIBADD) \ @X_PRE_LIBS@ @X_LIBS@ -lX11 @X_EXTRA_LIBS@ \ -rpath $(toolexeclibdir) $(LIBJAVA_LDFLAGS_NOUNDEF) \ -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LIBGCJ_LD_SYMBOLIC) It is still wrong to use LDFLAGS for libraries to be linked in. All of $(LIBSTDCXX_RAW_CXX_LIBADD) @X_PRE_LIBS@ @X_LIBS@ -lX11 @X_EXTRA_LIBS@ should be on lib_gnu_awt_xlib_la_LDADD. This was how it was done before my change. If we want to make a change, I can submit a separate patch. Libraries should never occur before the objects which reference them. This is in GCC 4.7: lib_gnu_awt_xlib_la_LDFLAGS = ../libstdc++-v3/src/libstdc++.la \ @X_PRE_LIBS@ @X_LIBS@ -lX11 @X_EXTRA_LIBS@ \ -rpath $(toolexeclibdir) $(LIBJAVA_LDFLAGS_NOUNDEF) \ -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LIBGCJ_LD_SYMBOLIC) lib_gnu_awt_xlib_la_LINK = $(LIBLINK) $(lib_gnu_awt_xlib_la_LDFLAGS) \ $(lib_gnu_awt_xlib_la_version_arg) It does put libraries first. If it is a real bug, it should be fixed separately. -- H.J. I am checking in this patch to fix the typo. We can leave LIBADD change to 4.9. -- H.J. --- config/ 2013-01-07 H.J. Lu hongjiu...@intel.com * libstdc++-raw-cxx.m4 (GCC_LIBSTDCXX_RAW_CXX_FLAGS): Remove -I from LIBSTDCXX_RAW_CXX_LDFLAGS. libjava/ 2013-01-07 H.J. Lu hongjiu...@intel.com * Makefile.am (lib_gnu_awt_xlib_la_LDFLAGS): Replace LIBSTDCXX_RAW_CXX_LDLAGS with LIBSTDCXX_RAW_CXX_LDFLAGS. * Makefile.in: Regenerated. libsanitizer/ 2013-01-07 H.J. Lu hongjiu...@intel.com * asan/Makefile.am (libasan_la_LIBADD): Replace LIBSTDCXX_RAW_CXX_LDLAGS with LIBSTDCXX_RAW_CXX_LDFLAGS. * tsan/Makefile.am (libtsan_la_LIBADD): Likewise. * Makefile.in: Regenerated. * configure: Likewise. * asan/Makefile.in: Likewise. * interception/Makefile.in: Likewise. * sanitizer_common/Makefile.in: Likewise. * tsan/Makefile.in: Likewise. diff --git a/config/libstdc++-raw-cxx.m4 b/config/libstdc++-raw-cxx.m4 index 8052c2f..aafa509 100644 --- a/config/libstdc++-raw-cxx.m4 +++ b/config/libstdc++-raw-cxx.m4 @@ -24,7 +24,7 @@ AC_DEFUN([GCC_LIBSTDCXX_RAW_CXX_FLAGS], [ -I\$(top_builddir)/../libstdc++-v3/include/\$(target_noncanonical) \ -I\$(top_srcdir)/../libstdc++-v3/libsupc++ LIBSTDCXX_RAW_CXX_LDFLAGS=\ --I\$(top_builddir)/../libstdc++-v3/src/libstdc++.la +\$(top_builddir)/../libstdc++-v3/src/libstdc++.la AC_SUBST(LIBSTDCXX_RAW_CXX_CXXFLAGS) AC_SUBST(LIBSTDCXX_RAW_CXX_LDFLAGS) ]) diff --git a/libjava/Makefile.am b/libjava/Makefile.am index c6c84e4..a4941a9 100644 --- a/libjava/Makefile.am +++ b/libjava/Makefile.am @@ -594,7 +594,7 @@ lib_gnu_awt_xlib_la_CPPFLAGS = \ $(AM_CPPFLAGS) \ $(LIBSTDCXX_RAW_CXX_CXXFLAGS) ## The mysterious backslash in the grep pattern is consumed by make. -lib_gnu_awt_xlib_la_LDFLAGS = $(LIBSTDCXX_RAW_CXX_LDLAGS) \ +lib_gnu_awt_xlib_la_LDFLAGS = $(LIBSTDCXX_RAW_CXX_LDFLAGS) \ @X_PRE_LIBS@ @X_LIBS@ -lX11 @X_EXTRA_LIBS@ \ -rpath $(toolexeclibdir) $(LIBJAVA_LDFLAGS_NOUNDEF) \ -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(LIBGCJ_LD_SYMBOLIC) diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am index 76cdcfd..04a621f 100644 --- a/libsanitizer/asan/Makefile.am +++ b/libsanitizer/asan/Makefile.am @@ -40,7 +40,7 @@ libasan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la else libasan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la $(top_builddir)/interception/libinterception.la endif -libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDLAGS) +libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDFLAGS) libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl diff --git a/libsanitizer/tsan/Makefile.am b/libsanitizer/tsan/Makefile.am index 435fe71..26d1af2 100644 --- a/libsanitizer/tsan/Makefile.am +++ b/libsanitizer/tsan/Makefile.am @@ -34,7 +34,7 @@ tsan_files = \ tsan_symbolize_addr2line_linux.cc libtsan_la_SOURCES = $(tsan_files) -libtsan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la
Re: [Patch,avr] PR55897: Allocate __memx to .progmemx.data
2013/1/7 Georg-Johann Lay a...@gjlay.de Currently, data in address space __memx is allocated to .progmem.data, i.e. the same section as for __flash resp. progmem. However, there os no need that __memx goes onto the same section and wastes precious memory in the first 64 Ki. The patch puts __memx data into .progmemx.data so that a linker script can allocate it after .text and it can be distinguished from data in __flash or progmem. The current default linker script contains .progmem* so that the patch does not change anything here. A new default script is still to come (binutils PR14406). Moreover, there is some code clean-up like avoid magic 6 and use ADDR_SPACE_COUNT instead. Ok to apply? Johann PR target/55897 * config/avr/avr.h (ADDR_SPACE_COUNT): New enum. (avr_addrspace_t): Add .section_name field. * config/avr/avr.c (progmem_section): Use ADDR_SPACE_COUNT as array size. (avr_addrspace): Same. Initialize .section_name. Remove last NULL entry. Put __memx into .progmemx.data. (progmem_section_prefix): Remove. (avr_asm_init_sections): No need to initialize progmem_section. (avr_asm_named_section): Use avr_addrspace[].section_name to get section name prefix. (avr_asm_select_section): Ditto. And use get_unnamed_section to retrieve the progmem section. * avr-c.c (avr_cpu_cpp_builtins): Use ADDR_SPACE_COUNT as loop boundary to run over avr_addrspace[]. (avr_register_target_pragmas): Ditto. Approved. Denis.
Re: [Patch, Fortran] Remove the Fortran-only flag -fno-whole-file
Dominique Dhumieres wrote: (1) Is there any hint of -fno-whole-file misbehavior (as suggested by the second point of the Reasoning)? The middle end is simply not prepared for having multiple declaration for a single file (translation unit), which leads to wrong optimizations and thus to wrong code. I think the bug which triggeded my decision to fix all remaining known -fno-whole-file issues and then to enable it by default was PR 44945. See also http://gcc.gnu.org/ml/fortran/2010-07/msg00321.html But there are surely more. Using multiple declarations was simply a design bug in the original implementation of gfortran, which was only realized rather late - and then deferred. Paul was that brave to fix this by implementing -fwhole-file. As said in my comment below, if the answer is yes, then IMO this should be investigated and fixed before removal. We did the investigation when switching to -fwhole-file by default. And no, I do not want to investigate why the middle end misbehaves with multiple declarations in a single translation unit - nor do I want to fix it. I am content if everything works with -fwhole-file. There is really not any advantage of having multiple declarations in a single TU. (2) Is the -fwhole-file status ZKB (zero known bug)? I am not 100% confident that this the case (see at least PR 45128). I am not aware of any bug since 4.6. I am rather certain that we fixed all known bugs in this area. Neither having remaining mult-decls nor issues which wouldn't occur with -fno-whole-file. By now it simply makes more sense to fix a bug, ignoring whether it worked by chance with -fno-whole-file or not. All recent regressions seem to be unrelated. Thus, for users it makes more sense to use an older version or wait for the patch than to try -fno-while-file. Given the potential to generate wrong-code bugs, I wouldn't trust -fno-whole-file for any code which goes beyond a hello-world example. PR45128 requires the new array descriptor; we have a kludge which allows sub-type pointer in some cases. Seemingly, that kludge works in one case with -fno-whole-file where it fails with -fwhole-file. But I will actively ignore all subpointer PRs until the new array descriptor is ready, which will be the right fix. (3) What is the confidence that there is no rampant bug in -fwhole-file? Well, even if there is a bug which doesn't affect -fno-whole-file, using -fno-whole-file is no solution, given that -fno-whole-file has many known bugs. And while I am willing to fix -fwhole-file bugs, I will ignore any -fno-whole-file ones. (4) Is there an easy replacement for -fno-whole-file? Yes: -fwhole-file :-) Really, you shouldn't think of -fno-whole-file anymore. Here the answer is clearly yes: put the different TUs in different files. Or doing that ;-) My understanding of -fno-whole-file as well as -fno-realloc-lhs, -fno-frontend-optimize, or any of the -fno-* options is two fold: (i) to provide a workaround to user hit by a bug in the corresponding area, (ii) to help the maintainers to locate the bug or to change the default in case of a too severe bug. Well, the main point of -fno-realloc-lhs is to disable the performance penalty of RHS. That is also helped to find some bugs was a side effect. For -fno-frontend-optimize I agree that its purpose was indeed to toggle the optimization separately from only using -O0 vs -O1. But there is a difference between -frealloc-lhs, -ffrontend-optimize and -fwhole-file: The former two enable a specific feature or optimization and valid programs can (should) be produced with either version. By contrast, in terms of middle-end assumptions -fno-whole-file is always wrong. I think (ii) does not really apply. We never changed the defaults when a serious bug popped up, we always fixed it. [Though we might have suggested a command-line option as workaround, cf. (i).] For -fno-whole-file, it also didn't help much with localizing the bug. For -f(no-)frontend-optimize I agree that it helped several times to isolate the bug. * There are many wrong-code issues and probably also some ICEs with -fno-whole file. I think the wording is misleading. I have checked bugzilla for open PR containing -fno-whole-file and I have found only 2 (48939 and 52621). None of them are related to wrong-code issue due to -fno-whole-file. You have to search for mult-decl issues. -fwhole-file was the cure of that problem; as it had a couple of issues before July 2010 and wasn't enabled by default, almost no one used it. Hence, you don't find it in the log. And after -fwhole-file became the default, no one cared anymore about issues which occurred only with -fno-whole-file. My understanding of the -fno-whole-file option is that it is (should be) strictly equivalent to put all the TUs in separate files. If it exists an example for which this is not true, I think it would be a bug But that's not how the middle end works. It
FW: AVX generic mode tuning discussion.
We would like to propose changing AVX generic mode tuning to generate 128-bit AVX instead of 256-bit AVX. You indicate a 3% reduction on bulldozer with avx256. How does avx128 compare to -mno-avx -msse4.2? Will the next AMD generation have a useable avx256? I'm not keen on the idea of generic mode being tune for a single processor revision that maybe shouldn't actually be using avx at all. Btw, it looks like the data is massively skewed by 436.cactusADM. What are the overall numbers if you disregard cactus? It's also for sure the case that the vectorizer cost model has not been touched for avx256 vs. avx128 vs. sse, so a more sensible approach would be to look at differentiating things there to improve the cactus numbers. Harsha, did you investigate why avx256 is such a loss for cactus or why it is so much of a win for SB? I know this thread did not get closed from our end for a while now, but we (AMD) would really like to re-open this discussion. So here goes. We did investigate why cactus is slower in avx-256 mode than avx-128 mode on AMD processors. Using -Ofast flag (with appropriate flags to generate avx-128 code or avx-256 code) and running with the reference data set, we observe the following runtimes on Bulldozer. Runtime %Diff AVX-256 versus AVX-128 AVX128616s 38% AVX256 with store splitting 853s Scheduling and predictive commoning are turned off in the compiler for both cases, so that the code generated by the compiler for the avx-128 and avx-256 cases are mostly equivalent i.e only avx-128 instructions on one side are being replaced by avx-256 instructions on the other side. Looking at the cactus source and oprofile reports, the hottest loop nest is a triple nested loop. The innermost loop of this nest has ~400 lines of Fortran code and takes up 99% of the run time of the benchmark. Gcc vectorizes the innermost loop for both the 128 and 256 bit cases. In order to vectorize the innermost loop, gcc generates a SIMD scalar prologue loop to align the relevant vectors, followed by a SIMD packed avx loop, followed by a SIMD scalar epilogue loop to handle what's left after a whole multiple of vector factor is taken care of. Here are the oprofile samples seen in the AVX-128 and AVX-256 case for the innermost Fortran loop's 3 components. Oprofile Samples AVX 128 AVX-256-ss Gap in samples Gap as % of total runtime Total 153408 214448 61040 38% SIMD Vector loop135653 183074 4742130% SIMD Scalar Prolog loop3817 104346617 4% SIMD Scalar Epilog loop 3471 100726601 4% The avx-256 code is spending 30% more time in the SIMD vector loop than the avx-128 code. The code gen appears to be equivalent for this vector loop in the 128b and 256b cases- i.e only avx-128 instructions on one side are being replaced by avx-256 instructions on the other side. The instruction mix and scheduling are same, except for the spilling and loading of one variable. We know this gap is because there are fewer physical registers available for renaming to the avx-256 code, since our processor loses the upper halves of the FP registers for renaming. Our entire SIMD pipeline in the processor is 128-bit and we don't have native true 256-bit, even for foreseeable future generations, unlike Sandybridge/Ivybridge. The avx-256 code is spending 8% more time in the SIMD scalar prologue and epilogue than the avx-128 code. The code gen is exactly the same for these scalar loops in the 128b and 256b case - i.e exact same instruction mix and scheduling. The reason for the gap is actually the number of iterations that gcc executes in these loops for the 2 cases. This is because gcc is following Sandy bridge's recommendation and aligning avx-256 vectors to a 32-byte boundary instead of a 16-byte boundary, even on Bulldozer. The Sandybridge Software Optimization Guide mentions that the optimal memory alignment of an AVX 256-bit vector, stored in memory, is 32 bytes. The Bulldozer Software Optimization Guide says Align all packed floating-point data on 16-byte boundaries. In case of cactus, the relevant double vector has 118 elements that are stepped through in unit stride and the first element handled in the Fortran loop is aligned at a boundary akin to 0x8.
[patch, mips, stabs] Do any MIPS targets use stabs?
While testing all the variations of my mips-mti-elf target I found that a number of debug tests like gcc.dg/debug/trivial.c fail when compiled using a stabs debug flag (-gstabs3 for example) and -mips16. While running the GNU simulator I get: mips-core: 1 byte read to unmapped address 0xe820 at 0x80020278 program stopped with signal 10 (User defined signal 1). FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test Since I don't actually care about STABS I was looking at undefining DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes the failures a moot point for me since I would no longer run the tests with any -stabs flags. But I was wondering, are there any MIPS targets that do use stabs? If not maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h instead of undefing it just for my targets. Opinions? I saw the discussion about removing STABS completely from GCC, etc. but it looks like there is still some users who want it on some targets. Here is my default patch which just undef's it for the mti targets. Steve Ellcey sell...@mips.com 2013-01-07 Steve Ellcey sell...@mips.com * config/mips/mips-mti-elf.h: undef DBX_DEBUGGING_INFO. * config/mips/mips-mti-linux.h: Ditto. diff --git a/gcc/config/mips/mti-elf.h b/gcc/config/mips/mti-elf.h index f6b38a5..f90b060 100644 --- a/gcc/config/mips/mti-elf.h +++ b/gcc/config/mips/mti-elf.h @@ -41,3 +41,6 @@ along with GCC; see the file COPYING3. If not see \ /* Configuration-independent MIPS rules. */ \ BASE_DRIVER_SELF_SPECS + + +#undef DBX_DEBUGGING_INFO diff --git a/gcc/config/mips/mti-linux.h b/gcc/config/mips/mti-linux.h index cda9bdc..c12138f 100644 --- a/gcc/config/mips/mti-linux.h +++ b/gcc/config/mips/mti-linux.h @@ -45,3 +45,5 @@ along with GCC; see the file COPYING3. If not see \ /* Use the standard linux specs for everything else. */ \ LINUX64_DRIVER_SELF_SPECS + +#undef DBX_DEBUGGING_INFO
[patch, mips] Change -mad to -mmad to match documentation
The MIPS documentation describes a -mmad (-mno-mad) flag, but it is incorrectly implemented as -mad (-mno-ad) instead. This patch changes the implementation to match the documentation. This means that users who are currently using the -mad or -mno-ad flags would have to change. If we want we could leave -mad and -mno-ad as aliases for -mmad and -mno-ad but I don't think that is necessary. If someone does think we should do allow -mad, please let me know. OK to checkin? Steve Ellcey sell...@mips.com 2013-01-07 Steve Ellcey sell...@mips.com PR target/42661 * config/mips/mips.opt: Change mad to mmad to match documentation. diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt index dec028d..201d46f 100644 --- a/gcc/config/mips/mips.opt +++ b/gcc/config/mips/mips.opt @@ -55,7 +55,7 @@ mabicalls Target Report Mask(ABICALLS) Generate code that can be used in SVR4-style dynamic objects -mad +mmad Target Report Var(TARGET_MAD) Use PMC-style 'mad' instructions
Re: Control dependence vs. builtin_unreachable
On 01/05/2013 01:10 PM, Steven Bosscher wrote:
Presumably BB7 was created in response to the builtin_unreachable?
Yes. The block only contains the BB_UNREACHABLE call. It is cleaned up
at the end of the GIMPLE passes pipeline, in the fold-all-builtins
pass (most __builtin_unreachable calls are, but not all).
I think if you eliminate the block and the cleanup the CFG
appropriately, the right thing will just happen.
The problem with this, is that __builtin_unreachable actually exposes
optimization opportunities: more const/copy props of implicit sets
in the predicate guarding the __builtin_unreachable call, more
optimistic value numbering, etc. It also helps improve maybe-unused
warnings accuracy. So simply removing these dead ends in the CFG is
probably not a good idea.
?!? By removing the empty unreachable block that's precisely what you
enable. The block itself goes away and the branch leading to the block
is simplified appropriately. That in turn will create larger basic
blocks, enabling the const/copy propagations and similar optimizations.
Finally removing unreachable paths was insired by the desire to
eliminate false positives from maybe-{unused,uninitialized} and similar
warnings.
I'd be very curious to see the conditions under which removing the empty
unreachable and appropriate cleanup of the CFG (including the
underlying control statement) results in less optimizations and less
precision in our may-warnings.
I think there is one important difference: In the thread you referred
to, you're removing paths in the CFG that are implicitly not
executable (for some languages anyway), whereas a
__builtin_unreachable call is an explicit marker for this can never
happen. I think this difference is important:
I don't see this as an important distinction. The difference is in the
implicit can't happen case, eliminating the can't happen path may
eliminate a user visible side effect (for example a segfault).
* The explicit marker may have been put there on purpose (e.g. to get
rid of a false-positive warning). The compiler should respect that. An
implicit unreachable path can be optimized away without regard for the
user's intent.
Right, but if done right, eliminating the unreachable path correctly
should eliminate false positive warnings.
* The explicit marker should not inhibit optimizations. For an
implicit unreachable path the compiler should be conservative. But for
a __builtin_unreachable call that is the only statement in a basic
block, the compiler should be allowed to work as if the block really
is never reached.
Right.
The attached patch implements these ideas. During a tree-CFG cleanup,
basic blocks containing only a __builtin_unreachable call are marked
with a new flag BB_NEVER_REACHED. The flag is used in post-dominance:
A marked block is not considered in the computations of the immediate
post-dominator of the predecessor blocks. The result is a more
optimistic post-dominance tree: Without the patch all predecessors of
these BB_NEVER_REACHED blocks have the EXIT block as their
post-dominator, but with the patch this non-executable path in the CFG
is ignored and the post-dominators are those that would result if the
BB_NEVER_REACHED blocks are not there at all (the BB_NEVER_REACHED
blocks themselves are only post-dominated by the EXIT block).
I've also added a control dependence calculation function. It's not
currently used, but it shows how the BB_NEVER_REACHED flag is used in
this case to avoid the false control dependences that I showed in
the graphs in http://gcc.gnu.org/ml/gcc/2013-01/msg00021.html.
Bootstrappedtested on powerpc64-unknown-linux-gnu.
What do you think of this approach?
Before diving into the patch I think we should figure out why we see
such different effects of eliminating these paths from the CFG. Your
assertion is eliminating them will result in more false positives and
less optimization while my assertion is the opposite.
Jeff
Re: [committed] 2011 and 2012 Copyright year updates
Joseph S. Myers jos...@codesourcery.com writes: On Sun, 6 Jan 2013, Richard Sandiford wrote: Anyway, here's my attempt a script to convert to ranges and, if enabled, to include the current year. The script only updates FSF copyright notices and leaves others alone. I've tried my best to make sure that licences and imported FSF sources aren't touched, but I could have missed some cases. I don't see anything to exclude the soft-fp files imported from glibc (where the current glibc versions should be copied instead ... but note that some soft-fp files, e.g. for TImode, are GCC-specific and not in glibc). Hmm, OK. Is there a plan to move those to glibc? Every file seems to say This file is part of the GNU C Library., but it wasn't obvious whether that was an aspiration or just cut--paste. Maybe it'd be easier for the script to treat them all as imported and soft-fp altogether. Would that be OK? It may make sense to leave out libiberty (and other directories shared with the src repository) initially. To convert them, binutils will need an appropriate README notice explaining the meaning of ranges (like the one I added to GCC's toplevel README a while back), as per GNU policy, and someone may need to work out whether any missing years being inserted in the ranges need to be copyrightable years for all of GCC, binutils and GDB (and what the copyrightable year ranges are in each case - the years in which either there was a release of the relevant package, including beta releases etc., or it had public version control). OK, hadn't expected it to be that complicated, but there again, I wasn't sure if we'd ever use the --shared flag anyway. It was there as much to differentiate the shared with src cases from the imported from upstream cases. I think a patch for each directory will need posting separately for review of such things as whether any imported / generated files are mistakenly changed. So fixincludes/ separate from gcc/, and every library separate? OK. I've also attached a bzip2 patch of the gcc/ and fixincludes/ part. This patch converts to ranges but doesn't add 2013. I can add 2013 at the same time, separately or not at all; let me know. I think 2013 should be added (so the notices should say year-2013, for any value of year 1986 or later, all years 1987 and later being copyrightable years for GCC). But --version notices should just say 2013 (including e.g. that in fixincludes/mkheaders.in). OK, thanks. Richard
Re: RFA: RL78: Always select register bank 0 at the start of an ISR
I think that's right, since the ISR return restores the flag register, which has the bank select bits in it.
[Patch,avr] Add predicate symbols for the linker script to bump sections containing addr-space data
This is a tentative patch that adds symbols that can be used as predicates in
the linker script.
Background is binutils PR14406: Data in address space __flash1 must be located
in such a way that the high byte (hh8) of the address is 0x1. This is needed
because avr-gcc sets RAMPZ to 0x1 before reading data from __flash1.
The input section for __flash1 is .progmem1.data
Similar for other __flashN, n = 2..5
The problems to be solved are:
1) .progmemN.data must be located in [0xN, 0xN].
2) If there is too much data in .progmemN.data the linker should
complain.
3) Moving the location counter to 0xN is only needed if
.progmemN is non-empty.
4) We must be careful not to move to pointer backwards.
5) User-level build-scripts and Makefiles should be the same if
the user does not use the new features like __flashN.
Even if __flashN is used, it's appreciated if everything
works out of the box and without changing calls of objcopy,
for example.
6) If .text extends to, say, 0x20010, it's still fine if .progmem2.data
starts at 0x20011. There is no need to throw an error because text
overlaps 0x2...0x2.
The very problem is that the linker script language is too limited. Neither
does it support memory holes, nor can a section float around others, and not
even detecting if a section does not contain any data works as promised by
binutils, cf. [1].
The patch addresses the latter problem: It defines symbols that can be used
like predicates by the linker script like so, cf. [2]:
.text :
{
...
. = MAX (DEFINED(__need_.progmem1.data) ? 1 16 : 0, ABSOLUTE(.)) ;
__progmem1_start = . ;
*(.progmem1)
*(.progmem1.*)
__progmem1_end = . ;
...
} text
There was some discussion in [3] about how PR14406 could be approached and
there were basically two proposals:
- One from Erik that does not solve 3), 6) or 5) i.e. requires a change in
the user Makefiles like -j .hightext instead of -j .text etc.
.text is after .progmemN
- One from me with the predicate-like-symbols kludge that needs a
GCC change and has less informative error messages than Erik's
approach in the case anything overflows.
.text is before .progmemN
Maybe everything can be solved much easier and I am lacking the respective
binutils knowledge...
Thoughts?
Johann
[1] http://sourceware.org/ml/binutils/2012-12/msg00151.html
[2] http://lists.gnu.org/archive/html/avr-gcc-list/2012-12/msg00046.html
[3] http://lists.gnu.org/archive/html/avr-gcc-list/2012-12/msg00029.html
gcc/
* config/avr/avr.c (avr_need_addrspace_p): New static variable.
(avr_asm_named_section): Record avr_need_addrspace_p.
(avr_asm_select_section): Ditto.
(avr_asm_function_rodata_section): Ditto.
(avr_file_end): Reference __need_.progmemN.data according to
avr_need_addrspace_p[N].
libgcc/
* config/avr/t-avr (LIB1ASMFUNCS): Add: _progmem1, _progmem2,
_progmem3, _progmem4, _progmem5.
* config/avr/lib1funcs.S (__need_.progmem1.data)
(__need_.progmem2.data, __need_.progmem3.data)
(__need_.progmem4.data, __need_.progmem5.data): Define symbols.
Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c (revision 194991)
+++ gcc/config/avr/avr.c (working copy)
@@ -205,6 +205,10 @@ bool avr_have_dimode = true;
bool avr_need_clear_bss_p = false;
bool avr_need_copy_data_p = false;
+/* Track need for the non-generic address spaces, similar to
+ avr_need_copy_data_p. */
+static bool avr_need_addrspace_p[ADDR_SPACE_COUNT];
+
/* Custom function to count number of set bits. */
@@ -8148,6 +8152,9 @@ avr_asm_function_rodata_section (tree de
flags = frodata-common.flags;
}
+ /* Just for the record... */
+ avr_need_addrspace_p[ADDR_SPACE_FLASH] = true;
+
if (frodata != readonly_data_section
flags SECTION_NAMED)
{
@@ -8195,6 +8202,8 @@ avr_asm_named_section (const char *name,
const char *old_prefix = .rodata;
const char *new_prefix = avr_addrspace[as].section_name;
+ avr_need_addrspace_p[as] = true;
+
if (STR_PREFIX_P (name, old_prefix))
{
const char *sname = ACONCAT ((new_prefix,
@@ -8313,6 +8322,8 @@ avr_asm_select_section (tree decl, int r
if (ADDR_SPACE_GENERIC_P (as))
as = ADDR_SPACE_FLASH;
+ avr_need_addrspace_p[as] = true;
+
if (sect-common.flags SECTION_NAMED)
{
const char * name = sect-named.name;
@@ -8393,6 +8404,27 @@ avr_file_end (void)
if (avr_need_clear_bss_p)
fputs (.global __do_clear_bss\n, asm_out_file);
+
+ for (size_t n = 0; n ADDR_SPACE_COUNT; n++)
+{
+ addr_space_t as = (addr_space_t) n;
+
+ if (avr_need_addrspace_p[as]
+ /* We only need the __need_ symbols in the linker script for
+ the paged sections that move the location counter forward.
+
Re: [committed] 2011 and 2012 Copyright year updates
On Mon, Jan 7, 2013 at 11:49 AM, Richard Sandiford rdsandif...@googlemail.com wrote: I think a patch for each directory will need posting separately for review of such things as whether any imported / generated files are mistakenly changed. So fixincludes/ separate from gcc/, and every library separate? OK. Separate? Seems pretty inextricably intertwined to me. Maybe I'm coming in too late in this conversation. I'll just update the copyrights in the next few days. It (fixincludes) has _certainly_ been updated every year of its existence. (Probably ought not count the original shell script, though I did lift all of its expressions) Cheers - Bruce
Re: [patch, mips, stabs] Do any MIPS targets use stabs?
Steve Ellcey sell...@mips.com writes: While testing all the variations of my mips-mti-elf target I found that a number of debug tests like gcc.dg/debug/trivial.c fail when compiled using a stabs debug flag (-gstabs3 for example) and -mips16. While running the GNU simulator I get: mips-core: 1 byte read to unmapped address 0xe820 at 0x80020278 program stopped with signal 10 (User defined signal 1). FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test Since I don't actually care about STABS I was looking at undefining DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes the failures a moot point for me since I would no longer run the tests with any -stabs flags. But I was wondering, are there any MIPS targets that do use stabs? If not maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h instead of undefing it just for my targets. Opinions? Do you know why selecting stabs causes an execution failure? That shouldn't happen regardless of whether the debug info itself is good. I don't mind removing stabs from all MIPS targets, but I'd like to understand why we get the execution failure first. Richard
Re: [committed] 2011 and 2012 Copyright year updates
On Mon, 7 Jan 2013, Richard Sandiford wrote: Joseph S. Myers jos...@codesourcery.com writes: On Sun, 6 Jan 2013, Richard Sandiford wrote: Anyway, here's my attempt a script to convert to ranges and, if enabled, to include the current year. The script only updates FSF copyright notices and leaves others alone. I've tried my best to make sure that licences and imported FSF sources aren't touched, but I could have missed some cases. I don't see anything to exclude the soft-fp files imported from glibc (where the current glibc versions should be copied instead ... but note that some soft-fp files, e.g. for TImode, are GCC-specific and not in glibc). Hmm, OK. Is there a plan to move those to glibc? Every file seems to say This file is part of the GNU C Library., but it wasn't obvious whether that was an aspiration or just cut--paste. They'd only move to glibc if some architecture has a use for them (most likely if some architecture wishes to support rounding modes and exceptions for soft-float, like powerpc, but also has TImode support; in that case the best results would come from that architecture using these functions only in glibc and not in libgcc at all). Maybe it'd be easier for the script to treat them all as imported and soft-fp altogether. Would that be OK? Sure. The point should be to get something in that covers a useful set of files, and then its coverage can be expanded incrementally later. OK, hadn't expected it to be that complicated, but there again, I wasn't sure if we'd ever use the --shared flag anyway. It was there as much to differentiate the shared with src cases from the imported from upstream cases. I didn't look at what options might cause the script to touch what directories, just for cases that appeared like they might be covered but that have complications. I think a patch for each directory will need posting separately for review of such things as whether any imported / generated files are mistakenly changed. So fixincludes/ separate from gcc/, and every library separate? OK. Yes, I think that will produce sensibly-sized chunks for people familiar with the relevant directories to review to see whether any imported files are being inappropriately changed, generated files changed without corresponding changes to their sources, or sources for generated files changed without corresponding changes to the generated files. -- Joseph S. Myers jos...@codesourcery.com
Re: atomic update of profile counters (issue7000044)
On 01/03/2013 04:42 PM, Rong Xu wrote: It links libatomic when -fprofile-gen-atomic is specified for FDO instrumentation build. Here I assume libatomic is always installed. Andrew: do you think if this is reasonable? It also disables the functionality if target does not support weak (ie. TARGET_SUPPORTS_WEAK == 0). Since you're linking libatomic, you don't need weak references. I think its ok to assume libatomic is installed, given that the user has had to explicitly use the command-line option. r~
Re: [patch, mips, stabs] Do any MIPS targets use stabs?
Richard Sandiford rdsandif...@googlemail.com writes:
Steve Ellcey sell...@mips.com writes:
While testing all the variations of my mips-mti-elf target I found that
a number of debug tests like gcc.dg/debug/trivial.c fail when compiled
using a stabs debug flag (-gstabs3 for example) and -mips16. While running
the GNU simulator I get:
mips-core: 1 byte read to unmapped address 0xe820 at 0x80020278
program stopped with signal 10 (User defined signal 1).
FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test
Since I don't actually care about STABS I was looking at undefining
DBX_DEBUGGING_INFO in mips-mti-elf.h and mips-mti-linux.h which makes
the failures a moot point for me since I would no longer run the tests
with any -stabs flags.
But I was wondering, are there any MIPS targets that do use stabs? If not
maybe we should just remove the define of DBX_DEBUGGING_INFO from mips.h
instead of undefing it just for my targets. Opinions?
Do you know why selecting stabs causes an execution failure?
That shouldn't happen regardless of whether the debug info itself is good.
Ah, sorry, this reminded me of a patch I'd written a year ago and never
got around to sanity-checking. Does it fix the problem for you?
Richard
Index: gas/config/tc-mips.c
===
--- gas/config/tc-mips.c2012-01-28 14:47:10.0 +
+++ gas/config/tc-mips.c2012-01-28 14:48:14.0 +
@@ -1476,7 +1476,9 @@ static const pseudo_typeS mips_pseudo_ta
{section, s_change_section, 0},
{short, s_cons, 1},
{single, s_float_cons, 'f'},
+ {stabd, s_mips_stab, 'd'},
{stabn, s_mips_stab, 'n'},
+ {stabs, s_mips_stab, 's'},
{text, s_change_sec, 't'},
{word, s_cons, 2},
@@ -16817,9 +16819,7 @@ s_insn (int ignore ATTRIBUTE_UNUSED)
static void
s_mips_stab (int type)
{
- if (type == 'n')
-mips_mark_labels ();
-
+ mips_mark_labels ();
s_stab (type);
}
Re: [patch, mips, stabs] Do any MIPS targets use stabs?
On Mon, 2013-01-07 at 20:30 +, Richard Sandiford wrote: Steve Ellcey sell...@mips.com writes: While testing all the variations of my mips-mti-elf target I found that a number of debug tests like gcc.dg/debug/trivial.c fail when compiled using a stabs debug flag (-gstabs3 for example) and -mips16. While running the GNU simulator I get: mips-core: 1 byte read to unmapped address 0xe820 at 0x80020278 program stopped with signal 10 (User defined signal 1). FAIL: gcc.dg/debug/trivial.c -gstabs3 -O execution test Do you know why selecting stabs causes an execution failure? That shouldn't happen regardless of whether the debug info itself is good. I don't mind removing stabs from all MIPS targets, but I'd like to understand why we get the execution failure first. Richard No, I don't know why I get the execution failure. I dug around a bit but could not figure out what or where the problem was coming from. I assume the executable is accessing a bad address or an uninitialized bit of memory somewhere but I could not figure out where. The actual executable code is the same with or without the debug information. I don't even know if this is a bug in GCC or in the GNU simulator. My inability to figure out where the problem was occurring is the main reason I started wondering why I even cared about stabs. Steve Ellcey sell...@mips.com
Re: Control dependence vs. builtin_unreachable
On Mon, Jan 7, 2013 at 8:45 PM, Jeff Law l...@redhat.com wrote:
Before diving into the patch I think we should figure out why we see such
different effects of eliminating these paths from the CFG. Your assertion
is eliminating them will result in more false positives and less
optimization while my assertion is the opposite.
Warnings:
$ cat q.c
#if 0
#define UNREACHABLE() __builtin_unreachable()
#else
#define UNREACHABLE() break
#endif
typedef enum fruits { banana = 0, apple = 1, pear = 2, orange = 3 } fruit;
extern void price_fruit_of_the_day (int);
void
discount_of_the_day (fruit f)
{
int p, c = (int) f;
switch (f)
{
case banana:
UNREACHABLE ();
case apple:
p = 3 * c + 4;
break;
case pear:
case orange:
p = 7;
break;
}
price_fruit_of_the_day (p);
}
$ # Compiled with UNREACHABLE defined as break:
$ ./cc1 -quiet -W -Wall -Wextra q.c -fdump-tree-all -O1
q.c: In function 'discount_of_the_day':
q.c:28:26: warning: 'p' may be used uninitialized in this function
[-Wmaybe-uninitialized]
price_fruit_of_the_day (p);
^
$ # Compiled with UNREACHABLE defined as builtin_unreachable:
$ ./cc1 -quiet -W -Wall -Wextra q.c -fdump-tree-all -O1
$
For optimizations it's a bit more difficult. The situations I'm
looking at, are all sinking related, and I suspect that most missed
optimizations will be of this form:
int foo (int b, int c, int d)
{
int res, r = 0;
res = 5 * d + b;
if (d)
__builtin_unreachable ();
if (c)
r = res;
return r;
}
The res = statement can be sunk into the conditional arm of if(c)
and tree-ssa-sink.c is able to do so. But secondary effects are missed
(and test cases for this are hard to reduce to mailing list acceptable
size ;-) because tree-ssa-sink walks the post-dominator tree and, with
the right amount of bad luck, it visits the res= statement _before_
the part of the (forward-)dominator tree below if(d) because the
basic block containing res= has EXIT as its immediate
post-dominator, because that's where __builtin_unreachable() leads to.
The optimistic post-dominator of res= is the if(c) block, of
course, because the builtin_unreachable is a kind-of assert, not
something that can really ever happen.
I already showed how the control dependence graph looks Wrong with
__builtin_unreachable calls in place. Any transformation using the CDG
will also be less effective because of this.
Ciao!
Steven
Re: Support for MIPS r5900
Jeff Law l...@redhat.com writes: On 01/06/2013 03:56 PM, Jürgen Urban wrote: Hello, I created a patch from scratch to support MIPS r5900 used in the Playstation 2, but I have some problems with it. The attached patch only works with the latest binutils from CVS. The binutils forces the compiler to use r5900 compatible instructions which is good to find errors in the GCC. Later I will try to submit a patch here, but first I need some help. The MIPS r5900 supports 32 bit, 64 bit and 128 bit data accesses on a 32 Bit address bus. It supports instructions from MIPS ISA I, II, III, IV and has additional instructions, but none of them are complete. On each ISA level there are instructions missing. It can run MIPS ABI o32, n32 and o64 code, as long as unsupported instructions are not used or emulated by the operating system and the addresses keep in the first 32 bit. My patch adds support for r5900 and tries to disable the following unsupported instructions: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Does someone know how to enable TImode in MIPS ABI o32 (this doesn't need to use the 128 bit instructions at the moment)? There is some old code for the Playstation 2 which needs this. I know that TImode is supported in ABI n32, but some code uses also the 32 bit FPU and FPU registers are not available with -msoft-float in inline assembler. What is the best way to change the alignment to 128 bit for all structures and stack in any MIPS ABI? Much old code for the Playstation 2 expects this. Hmm, I did a R5900 port back in the late 90s... Did that port never get contributed (yes, my memory is that bad these days) I remember there was talk in the early 2000s of contributing it, but we never had time. I think the MIPS copro support was from the r5900 port -- so it's effectively dead at the moment -- and the MODE_HAS_* stuff was from a refresh of it. Both of those made their way in, but I think that was about it. Richard
Re: RFA: RL78: Correct values of the MDBL and MDBH registers
I did notice that the hardware didn't work the same way as the documentation... this would explain it. Yes, please apply it :-)
Re: [patch, mips, stabs] Do any MIPS targets use stabs?
On Mon, 2013-01-07 at 20:38 +, Richard Sandiford wrote: Ah, sorry, this reminded me of a patch I'd written a year ago and never got around to sanity-checking. Does it fix the problem for you? Richard It fixes my small test case, I will try it on the full testsuite overnight. Steve
Re: atomic update of profile counters (issue7000044)
Function __gcov_indirect_call_profiler_atomic (which contains call to the atomic function) is always emitted in libgcov. Since we only link libatomic when -fprofile-gen-atomic is specified, we have to make the atomic function weak -- otherwise, there is a unsat for regular FDO gen build (of course, when the builtin is not expanded). An alternative it to always link libatomic together with libgcov. Then we don't need the weak stuff. I'm not sure when one is better. -Rong On Mon, Jan 7, 2013 at 12:36 PM, Richard Henderson r...@redhat.com wrote: On 01/03/2013 04:42 PM, Rong Xu wrote: It links libatomic when -fprofile-gen-atomic is specified for FDO instrumentation build. Here I assume libatomic is always installed. Andrew: do you think if this is reasonable? It also disables the functionality if target does not support weak (ie. TARGET_SUPPORTS_WEAK == 0). Since you're linking libatomic, you don't need weak references. I think its ok to assume libatomic is installed, given that the user has had to explicitly use the command-line option. r~
Re: [v3, build] Restrict -Wa,-nH use to Solaris (PR libstdc++/55594)
On 7 January 2013 16:39, Rainer Orth wrote: As reported in the PR, the AIX assembler also accepts the -nH option, but with completely different semantics. To avoid this, the current patch restricts checking the option to Solaris targets. Bootstrapped without regressions on i386-pc-solaris2.10 with Sun as (-Wa,-nH is added), x86_64-unknown-linux-gnu (test no longer performed), tested on AIX by David. Ok for mainline? This is OK, thanks.
[PATCH] Minor VRP simplify_float_conversion_using_ranges tweaks (PR tree-optimization/54120)
Hi! As mentioned in the PR, the actual important bug has been fixed in range_fits_type_p by Richard Sandiford recently, so here are just two minor nits. An extension of a signed src_type to unsigned wider type is fine only if the vr doesn't have negative min or max, so always assuming we can extend is wrong (but not a very big deal, as we always pass unsigned_p = false when calling the function right now). The other change mattered in 4.7 where CODE_FOR_nothing is a big number, in 4.8 it is just a consistency issue when all the other can_float_p calls are compared with CODE_FOR_nothing (== 0). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? What about 4.7 (together with backport of Richard's http://gcc.gnu.org/viewcvs?root=gccview=revrev=194800 fix) after a while? 2013-01-07 Jakub Jelinek ja...@redhat.com PR tree-optimization/54120 * tree-vrp.c (range_fits_type_p): Don't allow src_precision precision from signed vr to unsigned_p if vr-min or vr-max is negative. (simplify_float_conversion_using_ranges): Test can_float_p against CODE_FOR_nothing. --- gcc/tree-vrp.c.jj 2013-01-02 21:05:34.137069022 +0100 +++ gcc/tree-vrp.c 2013-01-07 18:15:32.00351 +0100 @@ -8753,9 +8753,11 @@ range_fits_type_p (value_range_t *vr, un !POINTER_TYPE_P (src_type)) return false; - /* An extension is always fine, so is an identity transform. */ + /* An extension is fine unless VR is signed and unsigned_p, + and so is an identity transform. */ src_precision = TYPE_PRECISION (TREE_TYPE (vr-min)); - if (src_precision precision + if ((src_precision precision +!(unsigned_p !TYPE_UNSIGNED (src_type))) || (src_precision == precision TYPE_UNSIGNED (src_type) == unsigned_p)) return true; @@ -8813,7 +8815,7 @@ simplify_float_conversion_using_ranges ( mode = TYPE_MODE (TREE_TYPE (rhs1)); /* If we can do the conversion in the current input mode do nothing. */ else if (can_float_p (fltmode, TYPE_MODE (TREE_TYPE (rhs1)), - TYPE_UNSIGNED (TREE_TYPE (rhs1 + TYPE_UNSIGNED (TREE_TYPE (rhs1))) != CODE_FOR_nothing) return false; /* Otherwise search for a mode we can use, starting from the narrowest integer mode available. */ Jakub
[PATCH] Another non-prototype builtin issue (PR middle-end/55890)
Hi!
evaluate_stmt can be crashed similarly to what you've fixed today.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-01-07 Jakub Jelinek ja...@redhat.com
PR middle-end/55890
* tree-ssa-ccp.c (evaluate_stmt): Use gimple_call_builtin_p.
* gcc.dg/torture/pr55890-3.c: New test.
--- gcc/tree-ssa-ccp.c.jj 2012-11-19 14:41:17.0 +0100
+++ gcc/tree-ssa-ccp.c 2013-01-07 18:53:39.952854381 +0100
@@ -1546,7 +1546,6 @@ evaluate_stmt (gimple stmt)
!is_constant)
{
enum gimple_code code = gimple_code (stmt);
- tree fndecl;
val.lattice_val = VARYING;
val.value = NULL_TREE;
val.mask = double_int_minus_one;
@@ -1593,10 +1592,9 @@ evaluate_stmt (gimple stmt)
|| POINTER_TYPE_P (TREE_TYPE (rhs1)))
val = bit_value_binop (code, TREE_TYPE (rhs1), rhs1, rhs2);
}
- else if (code == GIMPLE_CALL
- (fndecl = gimple_call_fndecl (stmt))
- DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
+ else if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
{
+ tree fndecl = gimple_call_fndecl (stmt);
switch (DECL_FUNCTION_CODE (fndecl))
{
case BUILT_IN_MALLOC:
--- gcc/testsuite/gcc.dg/torture/pr55890-3.c.jj 2013-01-07 18:51:27.415614201
+0100
+++ gcc/testsuite/gcc.dg/torture/pr55890-3.c2013-01-07 18:51:22.864640151
+0100
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+
+void *memmove ();
+
+void *
+bar ()
+{
+ return memmove ();
+}
Jakub
Re: [patch] Performance patch for MIPS conditional move in expr.c
On Thu, 2012-11-15 at 13:39 -0800, Andrew Pinski wrote: I was posting it for Steve's benefit really. I was in the process of updating the patch to the trunk and trying it out there before doing a formal submission :). As I found out the testcase needs to be changed to work with the new mips target test infrastructure. I will post a revised patch with the removal of the internal bug number once I finish fixing the testcase itself. After fixing up the testcase I find xori still in the resulting code: gcc$ ./cc1 t.c -O1 -o - -DNOMIPS16= -quiet -mabi=n32 -march=mips64 |grep xor xori$2,$4,0x1 But that is because combine produces: Trying 34 - 35: Failed to match this instruction: (set (reg:SI 194 [ D.1393 ]) (if_then_else:SI (xor:SI (reg:SI 200 [ d ]) (const_int 1 [0x1])) (reg:SI 6 $6 [ c ]) (reg:SI 5 $5 [ b ]))) But does not switch around the if_then_else as reg 200 has a non zero bits of just 1. I will look into fix the rest of the problem later today. So the above patch is a way forward but not the full fix. Thanks, Andrew Pinski Andrew, are you still planning on submitting this patch? I have been running with your new *movGPR:mode_on_GPR2:mode_ne instruction and that part at least works fine. I would like to get at least that much checked in for GCC 4.8. Steve Ellcey sell...@mips.com
Re: Support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes:
ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
ll and sc is disabled with -mno-llsc and works.
cvt.w.s is replaced by trunc.w.s. This seems to work.
Probably showing my ignorance, but I couldn't see this in the patch.
I disabled 64 bit FPU instructions by -msoft-float. This works, but
using -msingle-float fails. This would be the better
configuration. There are still 64 bit FPU instructions used (e.g. dmfc1
$2,$f0 when using long double multiplication). So -msingle-float
doesn't seem to work on generic mips64-linux-gnu.
Right. That combination hasn't really been defined. What happens
for plain doubles? Do you pass those in FPRs or GPRs?
I tried to disable dmult and ddiv (see mips.md). Disabling worked, but
now muldi3 calls itself in libgcc2. I thought this should work, because
I got this working with GCC 4.3, but the latest GCC version is a
problem. multi3 is calling muldi3, so that muldi3 should be able to use
mulsi3, because it is the same C code in libgcc2. Can someone get me
some hints or comments? How can this be debugged?
Not sure, sorry.
Does someone know how to enable TImode in MIPS ABI o32 (this doesn't
need to use the 128 bit instructions at the moment)? There is some old
code for the Playstation 2 which needs this. I know that TImode is
supported in ABI n32, but some code uses also the 32 bit FPU and FPU
registers are not available with -msoft-float in inline assembler.
The n32 TImode support you mention uses pairs of GPRs, whereas I imagine
you'd eventually want to use a single 128-bit GPR. Is that right?
TImode in the current n32 sense doesn't really make practical sense
for 32-bit targets. We'd be dealing with quad registers in that case.
I think it would only make sense with TImode registers.
ISTR the TImode registers being a can of worms, especially with the
optimisation to only store the lower 64 bits if the upper 64 weren't used.
(Am I remembering that right?)
When you submit the TImode register support, please make the support
itself a separate patch from the ABI changes. I.e. one patch to
add TImode registers, one to add TImode to o32, one to add single-GPR
TImode to n32, etc. For the record, I think all those patches would be
too invasive this late into the 4.8 cycle so would have to wait for 4.9.
Also, any ABI changes should be conditional on a new flag rather than
keyed off the architecture. That flag would then be the default for
your new configuration.
What is the best way to change the alignment to 128 bit for all
structures and stack in any MIPS ABI? Much old code for the Playstation
2 expects this.
The stack is STACK_BOUNDARY (already 128 for n32). Do you mean the
padding of all structure types, or just global structure variables?
If the former, it sounds like ROUND_TYPE_ALIGN, but also sounds scary :-)
If the latter, it's DATA_ALIGNMENT.
@@ -15801,6 +15816,11 @@ mips_reorg_process_insns (void)
if (TARGET_FIX_VR4120 || TARGET_FIX_24K)
cfun-machine-all_noreorder_p = false;
+ /* Code compiled for R5900 can't be all noreorder because
+ we rely on the assembler to work around some errata. */
+ if (TARGET_MIPS5900)
+cfun-machine-all_noreorder_p = false;
+
/* The same is true for -mfix-vr4130 if we might generate MFLO or
MFHI instructions. Note that we avoid using MFLO and MFHI if
the VR4130 MACC and DMACC instructions are available instead;
Please fold this into the clause above it.
+/* Target supports instructions dmult and dmultu (integer). */
+#define TARGET_HAS_DMULT (TARGET_64BIT \
+ !TARGET_MIPS5900)
Please use ISA_HAS_* for consistency with other macros. I think it'd
be better to drop the '(integer)'.
+/* Target supports instructions mult and multu in 32 bit mode (integer). */
+#define TARGET_HAS_MULT (mips_isa = 1)
...and here drop 'in 32 bit mode (integer)'. 32-bit-mode isn't really
relevant here.
+/* Target supports instructions dmult and dmultu (integer). */
+#define TARGET_HAS_DDIV (TARGET_64BIT
\
+ !TARGET_MIPS5900)
Same as above.
+/* Target supports instructions mult and multu in 32 bit mode (integer). */
+#define TARGET_HAS_DIV (mips_isa = 1)
Here too, plus div rather than mult.
@@ -841,10 +859,10 @@ struct mips_cpu_info {
/* ISA has the integer conditional move instructions introduced in mips4 and
ST Loongson 2E/2F. */
-#define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE || TARGET_LOONGSON_2EF)
+#define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE || TARGET_LOONGSON_2EF
|| TARGET_MIPS5900)
GCC has a strict 80-column limit, so please make this:
#define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE \
|| TARGET_LOONGSON_2EF \
|| TARGET_MIPS5900)
/* ISA has LDC1 and
Re: [PATCH] Adding target rdos to GCC
Hello Uros,
I tried to use your suggestion and use DEFAULT_SECTION_THRESHOLD
in i386.opt, however this doesn't work for me. It seems the default is
always
65536 regardless of what I define in rdos.h. Therefore, I kept the design
as it was before.
Changing name to TARGET_RDOS seems reasonable, and this has been changed.
The location of the defines are also changed to the positions you proposed.
I added another include-file (rdos32.h) for the 32-bit target. Currently,
the
32-bit target is supported with OpenWatcom. While I want to make sure
the header-files compile for both 32- and 64-bits, 32-bit support is not
my primary target right now. I just need a GCC that can build the 32-bit
version.
New change log:
* config/gthr.m4: Added rdos thread header.
* gcc/config/i386/i386.c: Provided a way to define a default setting for
medium memory model and PIC using TARGET_RDOS define. Provided a way to
define a default value for large-data-threshold.
* gcc/config/i386/i386.h: Defined TARGET_RDOS macro. Defined default value
for large-data-threshold.
* gcc/config/i386/i386.md: Added r14 and r15 register names.
* gcc/config/i386/i386.opt: Changed initial value for large-data-threshold
to 0 to allow detection of modification.
* gcc/config/i386/rdos.h: Added new file for 64-bit rdos target.
* gcc/config/i386/rdos32.h: Added new file for 32-bit rdos target.
* gcc/config.gcc: Added rdos targets
Leif Ekblad
- Original Message -
From: Uros Bizjak ubiz...@gmail.com
To: gcc-patches@gcc.gnu.org
Cc: Leif Ekblad l...@rdos.net; H.J. Lu hjl.to...@gmail.com
Sent: Sunday, January 06, 2013 9:32 PM
Subject: Re: [PATCH] Adding target rdos to GCC
Hello!
Updated patches with the suggestions below, except that the initial value
is 0
(which is not meaningful). I also added a setting in rdos target file to
use r15
for PIC instead of rbx.
*** gcc-4.8-20121230/gcc/config/i386/i386.c Thu Dec 27 02:58:06 2012
--- gcc-work/gcc/config/i386/i386.c Sun Jan 6 14:10:34 2013
+ if (ix86_section_threshold == 0)
+ ix86_section_threshold = DEFAULT_SECTION_THRESHOLD;
Please see attached patch on how to initialize an option.
*** gcc-4.8-20121230/gcc/config/i386/i386.h Wed Dec 19 17:04:12 2012
--- gcc-work/gcc/config/i386/i386.h Sun Jan 6 13:24:26 2013
+ #define TARGET_MEDIUM_PIC 0
You should just use TARGET_RDOS here (also, please see attached patch).
+ /* Default threshold for putting data in large sections with x86-64
+medium memory model */
+ #define DEFAULT_SECTION_THRESHOLD 65536
Do not put this define in the middle of i386.h section that deals with
alignment...
*** gcc-4.8-20121230/gcc/config/i386/rdos.h Thu Jan 1 01:00:00 1970
--- gcc-work/gcc/config/i386/rdos.h Sun Jan 6 13:20:12 2013
+ #undef REAL_PIC_OFFSET_TABLE_REGNUM
+ #define REAL_PIC_OFFSET_TABLE_REGNUM R15_REG
Is this header also used for 32bit target? You should not use REX
registers for 32bit targets.
+ #undef TARGET_MEDIUM_PIC
+ #define TARGET_MEDIUM_PIC 1
TARGET_RDOS
+ #define DEFAULT_SECTION_THRESHOLD0x10
No hex numbers here. Also, you will need to #undef this first to
override the default in i386.h.
*** gcc-4.8-20121230/gcc/config.gcc Thu Nov 22 00:33:40 2012
--- gcc-work/gcc/config.gcc Fri Jan 4 21:08:46 2013
+ i[34567]86-*-rdos*)
+ tm_file=${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
newlib-stdint.h
+ ;;
You forgot to include i386/rdos.h here (other headers too?). It is
needed at least for TARGET_EXECUTABLE_SUFFIX define.
Uros.
gcc-base.diff
Description: Binary data
Re: [Patch, wwwdocs] Update Fortran part of the GCC 4.8 release notes
On Thu, 20 Dec 2012, Tobias Burnus wrote: The following patch updates the Fortran part of the GCC 4.8 release notes at http://gcc.gnu.org/gcc-4.8/changes.html#fortran Nice! I had a look and made a couple of editorial changes which should not change any of the statements. If you'd like to see some adjusted (or clarified) or have further suggestions, let me know and I'll take care. Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.77 retrieving revision 1.78 diff -u -3 -p -r1.77 -r1.78 --- changes.html3 Jan 2013 05:11:30 - 1.77 +++ changes.html7 Jan 2013 22:31:45 - 1.78 @@ -246,20 +246,21 @@ B b(42); // OK ul liCompatibility notice: ul - liModule files: The version of the module files (code.mod/code) + liModule files: The version of module files (code.mod/code) has been incremented. Fortran codeMODULE/codes compiled by earlier GCC versions have to be recompiled, when they are codeUSE/coded by -files compiled with GCC 4.8, because GCC 4.8 is not able to read -code.mod/code file of earlier GCC versions; attempting to do so -gives an error message. Note: The ABI of the produced assembler data -itself has not changed; object files and libraries are fully compatible -to older versions. (Except as noted below.)/li - liABI: Some internal names (name in the assembler/object file) have +files compiled with GCC 4.8. GCC 4.8 is not able to read +code.mod/code files created by earlier versions; attempting to do so + gives an error message.br/ + Note: The ABI of the produced assembler data itself has not changed; + object files and libraries are fully compatible +with older versions except as noted below./li + liABI: Some internal names (used in the assembler/object file) have changed for symbols declared in the specification part of a module. -If the module ndash; or a file using such a symbol via use -association ndash; is recompiled, the module and all files which -directly use such symbols have to be recompiled. The change only -affects the following kind of module symbols: + If an affected module ndash; or a file using it via use + association ndash; is recompiled, the module and all files which + directly use such symbols have to be recompiled as well. This change + only affects the following kind of module symbols: ul liProcedure pointers. Note: C-interoperable function pointers (codetype(c_funptr)/code) are not affected nor are @@ -276,12 +277,12 @@ B b(42); // OK liThe codea href=http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html; -Wc-binding-type/a/code warning option has been added (disabled -by default), which warns if the a variable might not be C interoperable. In +by default). It warns if the a variable might not be C interoperable; in particular, if the variable has been declared using an intrinsic type with default kind instead of using a kind parameter defined for C -interoperability in the intrinsic codeISO_C_Binding/code module. Before, -the warning was always printed. The code-Wc-binding-type/code option -is enabled by code-Wall/code./li +interoperability in the intrinsic codeISO_C_Binding/code module. +Before, this warning was always printed. The code-Wc-binding-type/code +option is enabled by code-Wall/code./li liThe a href=http://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html; @@ -334,7 +335,7 @@ B b(42); // OK lia href=http://gcc.gnu.org/wiki/Fortran2003Status;Fortran 2003/a: ul liSupport for unlimited polymorphic variables (codeCLASS(*)/code) - has been added. Note that nonconstant character lengths are not yet + has been added. Nonconstant character lengths are not yet supported./li /ul/li
[wwwdocs] Objective-C/Darwin related updates for the GCC 4.6 release notes
Going through some older mails (as some may have noticed), I found this patch which Iain was had done, and which I had reviewed, but which somehow did not make it in. Applied now, with some fuzzing manually adjusted. Gerald --- changes.html.orig 2012-10-03 07:02:42.198917592 -1000 +++ changes.html2013-01-06 18:54:44.729487237 -1000 @@ -716,8 +716,7 @@ liAs a result of these enhancements, GCC can now be used to build Objective-C and Objective-C++ software that uses Foundation and other important system frameworks with the NeXT runtime on -Darwin 9 and Darwin 10 (Mac OS X 10.5 and 10.6). Currently this is for -m32 code only./li +Darwin 9 and Darwin 10 (OSX 10.5 and 10.6)./li liMany bugs in the compiler have been fixed in this release; in particular, LTO can now be used when compiling Objective-C and @@ -1013,6 +1012,14 @@ allocators have been re-written to make more use of code.zerofill/code sections. For non-debug code, this can reduce object file size significantly./li + liObjective-C family 64-bit support (NeXT ABI 2).br / + Initial support has been added to support 64-bit Objective-C code + using the Darwin/OS X native (NeXT) runtime. ABI version 2 will be + selected automatically when 64-bit code is built./li + liObjective-C family 32-bit ABI 1.br / + For 32-bit code ABI 1 is also now also allowed. At present it must + be selected manually using code-fobjc-abi-version=1/code where + applicable - i.e. on Darwin 9/10 (OS X 10.5/10.6)./li /ul/li lix86 Architecture ul
Re: [Patch, fortran] PR55618 - [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
On Mon, Jan 07, 2013 at 11:57:27PM +0100, Paul Richard Thomas wrote: Dear All, This is a rather 'obvious' fix that returns gfortran to full compliance in the IVS testsuite. The testcase checks that various other combinations of arguments to elemental procedures work correctly. I gave up trying to find which commit caused the problem because there were so many candidates! Bootstrapped and regtested on FC17/x86_64 - OK for trunk Yes. -- Steve
Re: [PATCH, dataflow]: Fix PR55845, 454.calculix miscompares on x86 AVX due to movement of vzeroupper
On Mon, Jan 07, 2013 at 05:52:23PM +0100, Uros Bizjak wrote:
TBH, I'm not that familiar with the RTL infrastructure enough to
answer these questions. While I can spend some time on this problem,
and probably waste quite some reviewer's time, the problem is not that
trivial as I hoped to be, so I would kindly ask someone with better
understanding of this part of the compiler for the proper solution.
After discussion with rth on IRC, this modified patch just uses
volatile_insn_p, making all UNSPEC_VOLATILE (wherever in insn) and asm
volatile into a complete scheduling barrier for optimizations that use this
function.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-01-08 Jakub Jelinek ja...@redhat.com
Uros Bizjak ubiz...@gmail.com
PR rtl-optimization/55845
* df-problems.c (can_move_insns_across): Stop scanning at
volatile_insn_p source instruction or give up if
across_from .. across_to range contains any volatile_insn_p
instructions.
2012-01-08 Uros Bizjak ubiz...@gmail.com
Vladimir Yakovlev vladimir.b.yakov...@intel.com
PR rtl-optimization/55845
* gcc.target/i386/pr55845.c: New test.
--- gcc/df-problems.c.jj2012-11-19 14:41:26.181898964 +0100
+++ gcc/df-problems.c 2013-01-07 18:38:33.064974313 +0100
@@ -3858,6 +3858,8 @@ can_move_insns_across (rtx from, rtx to,
}
if (NONDEBUG_INSN_P (insn))
{
+ if (volatile_insn_p (PATTERN (insn)))
+ return false;
memrefs_in_across |= for_each_rtx (PATTERN (insn), find_memory,
NULL);
note_stores (PATTERN (insn), find_memory_stores,
@@ -3917,7 +3919,9 @@ can_move_insns_across (rtx from, rtx to,
if (NONDEBUG_INSN_P (insn))
{
if (may_trap_or_fault_p (PATTERN (insn))
- (trapping_insns_in_across || other_branch_live != NULL))
+ (trapping_insns_in_across
+ || other_branch_live != NULL
+ || volatile_insn_p (PATTERN (insn
break;
/* We cannot move memory stores past each other, or move memory
--- gcc/testsuite/gcc.target/i386/pr55845.c.jj 2013-01-07 18:30:19.168801389
+0100
+++ gcc/testsuite/gcc.target/i386/pr55845.c 2013-01-07 18:30:19.168801389
+0100
@@ -0,0 +1,39 @@
+/* { dg-do run } */
+/* { dg-require-effective-target avx } */
+/* { dg-options -O3 -ffast-math -fschedule-insns -mavx -mvzeroupper } */
+
+#include avx-check.h
+
+#define N 100
+
+double
+__attribute__((noinline))
+foo (int size, double y[], double x[])
+{
+ double sum = 0.0;
+ int i;
+ for (i = 0, sum = 0.; i size; i++)
+sum += y[i] * x[i];
+ return (sum);
+}
+
+static void
+__attribute__ ((noinline))
+avx_test ()
+{
+ double x[N];
+ double y[N];
+ double s;
+ int i;
+
+ for (i = 0; i N; i++)
+{
+ x[i] = i;
+ y[i] = i;
+}
+
+ s = foo (N, y, x);
+
+ if (s != 328350.0)
+abort ();
+}
Jakub
Re: [wwwdocs] Document libstdc++ changes and minimum MinGW-w64 version requirement.
On 8 January 2013 00:17, Jonathan Wakely wrote: On 3 January 2013 05:14, Gerald Pfeifer wrote: On Sat, 15 Dec 2012, Jonathan Wakely wrote: Committed to wwwdocs. Thanks, Jonathan. Where it says, Added code--disable-libstdcxx-verbose/code configure option, would it make sense to add a half-sentence that describes the purpose of this option? Well ideally I'd just link to the libstdc++ documentation describing the option, but of course onlinedocs is still far too old to show the new option! So here's another wwwdocs patch, which I've committed. I also made this small fix: diff -u -r1.79 changes.html --- htdocs/gcc-4.8/changes.html 8 Jan 2013 00:17:03 - 1.79 +++ htdocs/gcc-4.8/changes.html 8 Jan 2013 00:19:45 - @@ -255,7 +255,7 @@ GCC versions have to be recompiled, when they are codeUSE/coded by files compiled with GCC 4.8. GCC 4.8 is not able to read code.mod/code files created by earlier versions; attempting to do so - gives an error message.br/ + gives an error message.br / Note: The ABI of the produced assembler data itself has not changed; object files and libraries are fully compatible with older versions except as noted below./li
Re: Support for MIPS r5900
On Mon, 7 Jan 2013, Richard Sandiford wrote: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. This has raised my attention -- AFAICS the binutils change recently approved correctly disables DMULT, DDIV, CVT.W.S, etc. for -march=r5900, but does not do that for LL or SC. I think that should be fixed. And I gather LLD and SCD should then be disabled as well. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? Do you pass those in FPRs or GPRs? IIUC the R5900 has an FPU that is functionally the same as that of the R4640/R4650. If that is the case, then there is no way to pass doubles in FPRs -- there is no room to store the upper halves. The single-precision FPU of the R4640/R4650 processors can be configured with CP0.Status.FR to present a register file of either 16 or 32 32-bit registers. The upper halves are not implemented. Frankly I don't think we have an ABI to express doubles on such platforms -- we could approximate one by passing doubles in GPRs and singles in FPRs (where mandated by o32), but that would really be an entirely new ABI. The compiler could presumably be taught to call soft-float routines for double arithmetic and emit FP machine code for single arithmetic. I'm not sure how feasible the use of single float could be in the soft-float library. Things would get more complicated if one wanted to run a real OS such as Linux on the R5900 and let the kernel FP emulator handle the missing double FP automagically -- this is a little bit out of scope here as regular -mdouble-float would then just do, but makes me wonder whether -mfp32 should really be enforced (as opposed to just defaulted) for the R5900, hmm... Maciej
Re: Support for MIPS r5900
On 01/07/2013 02:52 PM, Richard Sandiford wrote: I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? Do you pass those in FPRs or GPRs? IIRC we defined doubles as 32bits wide in our old port. We simply didn't support 64bit wide doubles. I don't remember what mechanism we used to make this happen. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Not sure, sorry. IIRC I simply disabled muldi3_internal2 and I think we defined away everything related to timode except register-register moves. Jeff
[AARCH64] Remove %r from asm_printf
Hi,
ASM_FPRINTF_EXTENSIONS was copied from the arm back-end and is not
needed. Please find attached the patch that replaces %r in asm_fprintf
with reg_names. The definition of ASM_FPRINTF_EXTENSIONS is
removed as it is no longer needed.
Please review the patch and let me know if there should be any
modifications?
Build and tested on aarch64-thunder-elf (using Cavium's internal
simulator).
Thanks,
Naveen.H.S
2013-01-08 Naveen H.S naveen.hurugalaw...@caviumnetworks.com
* config/aarch64/aarch64.c (aarch64_print_operand): Replace %r
in asm_fprintf with reg_names.
(aarch64_print_operand_address): Likewise.
(aarch64_return_addr): Likewise.
* config/aarch64/aarch64.h (ASM_FPRINTF_EXTENSIONS): Remove.--- gcc/config/aarch64/aarch64.c 2013-01-07 17:04:51.295005008 +0530
+++ gcc/config/aarch64/aarch64.c 2013-01-08 09:39:10.497028308 +0530
@@ -3278,7 +3278,7 @@ aarch64_print_operand (FILE *f, rtx x, c
return;
}
- asm_fprintf (f, %r, REGNO (x) + 1);
+ asm_fprintf (f, %s, reg_names [REGNO (x) + 1]);
break;
case 'Q':
@@ -3288,7 +3288,7 @@ aarch64_print_operand (FILE *f, rtx x, c
output_operand_lossage (invalid operand for '%%%c', code);
return;
}
- asm_fprintf (f, %r, REGNO (x) + (WORDS_BIG_ENDIAN ? 1 : 0));
+ asm_fprintf (f, %s, reg_names [REGNO (x) + (WORDS_BIG_ENDIAN ? 1 : 0)]);
break;
case 'R':
@@ -3298,7 +3298,7 @@ aarch64_print_operand (FILE *f, rtx x, c
output_operand_lossage (invalid operand for '%%%c', code);
return;
}
- asm_fprintf (f, %r, REGNO (x) + (WORDS_BIG_ENDIAN ? 0 : 1));
+ asm_fprintf (f, %s, reg_names [REGNO (x) + (WORDS_BIG_ENDIAN ? 0 : 1)]);
break;
case 'm':
@@ -3402,7 +3402,7 @@ aarch64_print_operand (FILE *f, rtx x, c
switch (GET_CODE (x))
{
case REG:
- asm_fprintf (f, %r, REGNO (x));
+ asm_fprintf (f, %s, reg_names [REGNO (x)]);
break;
case MEM:
@@ -3522,36 +3522,36 @@ aarch64_print_operand_address (FILE *f,
{
case ADDRESS_REG_IMM:
if (addr.offset == const0_rtx)
- asm_fprintf (f, [%r], REGNO (addr.base));
+ asm_fprintf (f, [%s], reg_names [REGNO (addr.base)]);
else
- asm_fprintf (f, [%r,%wd], REGNO (addr.base),
+ asm_fprintf (f, [%s,%wd], reg_names [REGNO (addr.base)],
INTVAL (addr.offset));
return;
case ADDRESS_REG_REG:
if (addr.shift == 0)
- asm_fprintf (f, [%r,%r], REGNO (addr.base),
- REGNO (addr.offset));
+ asm_fprintf (f, [%s,%s], reg_names [REGNO (addr.base)],
+ reg_names [REGNO (addr.offset)]);
else
- asm_fprintf (f, [%r,%r,lsl %u], REGNO (addr.base),
- REGNO (addr.offset), addr.shift);
+ asm_fprintf (f, [%s,%s,lsl %u], reg_names [REGNO (addr.base)],
+ reg_names [REGNO (addr.offset)], addr.shift);
return;
case ADDRESS_REG_UXTW:
if (addr.shift == 0)
- asm_fprintf (f, [%r,w%d,uxtw], REGNO (addr.base),
+ asm_fprintf (f, [%s,w%d,uxtw], reg_names [REGNO (addr.base)],
REGNO (addr.offset) - R0_REGNUM);
else
- asm_fprintf (f, [%r,w%d,uxtw %u], REGNO (addr.base),
+ asm_fprintf (f, [%s,w%d,uxtw %u], reg_names [REGNO (addr.base)],
REGNO (addr.offset) - R0_REGNUM, addr.shift);
return;
case ADDRESS_REG_SXTW:
if (addr.shift == 0)
- asm_fprintf (f, [%r,w%d,sxtw], REGNO (addr.base),
+ asm_fprintf (f, [%s,w%d,sxtw], reg_names [REGNO (addr.base)],
REGNO (addr.offset) - R0_REGNUM);
else
- asm_fprintf (f, [%r,w%d,sxtw %u], REGNO (addr.base),
+ asm_fprintf (f, [%s,w%d,sxtw %u], reg_names [REGNO (addr.base)],
REGNO (addr.offset) - R0_REGNUM, addr.shift);
return;
@@ -3559,27 +3559,27 @@ aarch64_print_operand_address (FILE *f,
switch (GET_CODE (x))
{
case PRE_INC:
- asm_fprintf (f, [%r,%d]!, REGNO (addr.base),
+ asm_fprintf (f, [%s,%d]!, reg_names [REGNO (addr.base)],
GET_MODE_SIZE (aarch64_memory_reference_mode));
return;
case POST_INC:
- asm_fprintf (f, [%r],%d, REGNO (addr.base),
+ asm_fprintf (f, [%s],%d, reg_names [REGNO (addr.base)],
GET_MODE_SIZE (aarch64_memory_reference_mode));
return;
case PRE_DEC:
- asm_fprintf (f, [%r,-%d]!, REGNO (addr.base),
+ asm_fprintf (f, [%s,-%d]!, reg_names [REGNO (addr.base)],
GET_MODE_SIZE (aarch64_memory_reference_mode));
return;
case POST_DEC:
- asm_fprintf (f, [%r],-%d, REGNO (addr.base),
+ asm_fprintf (f, [%s],-%d, reg_names [REGNO (addr.base)],
GET_MODE_SIZE (aarch64_memory_reference_mode));
return;
case PRE_MODIFY:
- asm_fprintf (f, [%r,%wd]!, REGNO (addr.base),
+ asm_fprintf (f, [%s,%wd]!, reg_names [REGNO (addr.base)],
INTVAL (addr.offset));
return;
case POST_MODIFY:
- asm_fprintf (f, [%r],%wd, REGNO (addr.base),
+ asm_fprintf (f, [%s],%wd, reg_names [REGNO (addr.base)],
INTVAL (addr.offset));
return;
default:
@@ -3588,7 +3588,7 @@ aarch64_print_operand_address (FILE *f,
[Patch, AARCH64] Define REVERSIBLE_CC_MODE
Hi,
AARCH64 back-end defines REVERSE_CONDITION but not REVERSIBLE_CC_MODE.
REVERSE_CONDITION is used only in case REVERSIBLE_CC_MODE (mode) is
nonzero.
Please find attached the patch that defines REVERSIBLE_CC_MODE for
aarch64 back-end. Please review the patch and let me know if there should be any
modifications?
Build and tested on aarch64-thunder-elf (using Cavium's internal
simulator).
Thanks,
Naveen.H.S
2013-01-08 Naveen H.S naveen.hurugalaw...@caviumnetworks.com
* config/aarch64/aarch64.h (REVERSIBLE_CC_MODE): Define.--- gcc/config/aarch64/aarch64.h 2013-01-08 09:42:21.081034770 +0530
+++ gcc/config/aarch64/aarch64.h 2013-01-08 09:43:52.277037865 +0530
@@ -709,6 +709,14 @@ do { \
#define SELECT_CC_MODE(OP, X, Y) aarch64_select_cc_mode (OP, X, Y)
+/* A C expression whose value is one if it is always safe to reverse a
+ comparison whose mode is MODE. If `SELECT_CC_MODE' can ever return
+ MODE for a floating-point inequality comparison, then
+ `REVERSIBLE_CC_MODE (MODE)' must be zero.
+ You need not define this macro if it would always returns zero or if the
+ floating-point format is anything other than `IEEE_FLOAT_FORMAT'. */
+#define REVERSIBLE_CC_MODE(MODE) 1
+
#define REVERSE_CONDITION(CODE, MODE) \
(((MODE) == CCFPmode || (MODE) == CCFPEmode) \
? reverse_condition_maybe_unordered (CODE) \
Re: [Patch, fortran] PR55618 - [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
On Tue, Jan 08, 2013 at 07:20:19AM +0100, Paul Richard Thomas wrote: Dear Steve, Thanks - committed as revision 195004. I should also have asked if it's OK for 4.6 and 4.7? Yes, it is okay with the usual 2 to 3 days of cooking on trunk before committing. Of course, as you noted the patch was 'obvious', so if you're constrained on time use your judgement and commit when you can. -- Steve
Re: [PATCH, dataflow]: Fix PR55845, 454.calculix miscompares on x86 AVX due to movement of vzeroupper
On Tue, Jan 8, 2013 at 12:26 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Jan 07, 2013 at 05:52:23PM +0100, Uros Bizjak wrote: TBH, I'm not that familiar with the RTL infrastructure enough to answer these questions. While I can spend some time on this problem, and probably waste quite some reviewer's time, the problem is not that trivial as I hoped to be, so I would kindly ask someone with better understanding of this part of the compiler for the proper solution. After discussion with rth on IRC, this modified patch just uses volatile_insn_p, making all UNSPEC_VOLATILE (wherever in insn) and asm volatile into a complete scheduling barrier for optimizations that use this function. Thanks! Just two little nits in the testcase: +foo (int size, double y[], double x[]) foo (int size, double *y, double *x) + return (sum); return sum; Uros.
Re: Support for MIPS r5900
Richard Sandiford rdsandif...@googlemail.com writes: Jürgen Urban juergenur...@gmx.de writes: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. Maciej's reply made me realise that this sounded like I was responding to all three lines. The LL and SC stuff is fine. It was the CVT.W.S bit that I couldn't see. Sorry for the confusion. Richard
Re: [asan] Use -fno-shrink-wrap for null-deref-1.c test
Jakub Jelinek ja...@redhat.com writes: 2012-12-19 Jakub Jelinek ja...@redhat.com * c-c++-common/asan/null-deref-1.c: Add -fno-shrink-wrap to dg-options. This looks OK to me, thanks. -- Dodji
