Re: Mention of gcc 4.5 as first version with plugin support
Thank you Dave for this documentation patch that looks OK to my casual eyes. Let's CC the documentation maintainers. Dave Johansen a écrit: > Currently, the plugin documentation doesn't mention that it requires > gcc 4.5 or later. The patch to add this statement is attached and > here's the ChangeLog: > > 2013-01-10 Dave Johansen > > * gcc/doc/plugins.texi: Added gcc.4.5.0 or later note to > Plugins documentation. > > Index: gcc/doc/plugins.texi > === > --- gcc/doc/plugins.texi (revision 195102) > +++ gcc/doc/plugins.texi (working copy) > @@ -17,6 +17,9 @@ > transforming code, or analyzing information, plugins > can be quite useful. > > +GCC plugin support is available in GCC version 4.5.0 and > +later. > + > @menu > * Plugins loading:: How can we load plugins. > * Plugin API:: The APIs for plugins. -- Dodji
[patch] Disable Ada front-end checking in release mode
Hi, the Ada part of the Ada front-end is compiled with -gnata, which boils down to a form of dynamic type checking for the AST, i.e. something roughly equivalent to Tree checking for the front-ends of the C family of compilers. This patch aligns the Ada compiler with them by disabling it in --enable-checking=release mode. Issues flagged by this checking are usually benign on release branches and gigi has a slew of gcc_assert's that stop the compiler in serious cases. Bootstrapped on x86_64-suse-linux (w and w/o --enable-checking=release), OK for the mainline? 2013-01-11 Eric Botcazou * Makefile.tpl (BOOT_ADAFLAGS): Remove -gnata. * Makefile.in: Regenerate. gcc/ 2013-01-11 Eric Botcazou * configure.ac (Tree checking): Set TREECHECKING to yes if enabled. Substitute TREECHECKING. * configure: Regenerate. * Makefile.in (TREECHECKING): New. gcc/ada/ 2013-01-11 Eric Botcazou * gcc-interface/Make-lang.in (COMMON_ADAFLAGS): Remove -gnata. (CHECKING_ADAFLAGS): New. (ALL_ADAFLAGS): Include CHECKING_ADAFLAGS. -- Eric BotcazouIndex: gcc/ada/gcc-interface/Make-lang.in === --- gcc/ada/gcc-interface/Make-lang.in (revision 195091) +++ gcc/ada/gcc-interface/Make-lang.in (working copy) @@ -45,7 +45,12 @@ RMDIR = rm -rf # Extra flags to pass to recursive makes. -COMMON_ADAFLAGS= -gnatpg -gnata +COMMON_ADAFLAGS= -gnatpg +ifeq ($(TREECHECKING),) +CHECKING_ADAFLAGS= +else +CHECKING_ADAFLAGS= -gnata +endif WARN_ADAFLAGS= -W -Wall # For native builds, the base compiler might be old and we need to arrange for @@ -59,7 +64,8 @@ else ADAFLAGS= $(COMMON_ADAFLAGS) endif -ALL_ADAFLAGS = $(CFLAGS) $(ADA_CFLAGS) $(ADAFLAGS) $(WARN_ADAFLAGS) +ALL_ADAFLAGS = \ + $(CFLAGS) $(ADA_CFLAGS) $(ADAFLAGS) $(CHECKING_ADAFLAGS) $(WARN_ADAFLAGS) FORCE_DEBUG_ADAFLAGS = -g ADA_CFLAGS = ADA_INCLUDES = -nostdinc -I- -I. -Iada -I$(srcdir)/ada -I$(srcdir)/ada/gcc-interface Index: gcc/configure.ac === --- gcc/configure.ac (revision 195012) +++ gcc/configure.ac (working copy) @@ -471,6 +471,7 @@ if test x$ac_tree_checking != x ; then routines will also be enabled by this option. ]) TREEBROWSER=tree-browser.o + TREECHECKING=yes fi if test x$ac_types_checking != x ; then AC_DEFINE(ENABLE_TYPES_CHECKING, 1, @@ -479,6 +480,7 @@ if test x$ac_types_checking != x ; then ]) fi AC_SUBST(TREEBROWSER) +AC_SUBST(TREECHECKING) if test x$ac_rtl_checking != x ; then AC_DEFINE(ENABLE_RTL_CHECKING, 1, [Define if you want all operations on RTL (the basic data structure Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 195012) +++ gcc/Makefile.in (working copy) @@ -1487,6 +1487,10 @@ ALL_HOST_OBJS = $(ALL_HOST_FRONTEND_OBJS BACKEND = libbackend.a main.o @TREEBROWSER@ libcommon-target.a libcommon.a \ $(CPPLIB) $(LIBDECNUMBER) +# This is defined to "yes" if Tree checking is enabled, which roughly means +# front-end checking. +TREECHECKING = @TREECHECKING@ + MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \ insn-output.c insn-recog.c insn-emit.c insn-extract.c insn-peep.c \ insn-attr.h insn-attr-common.h insn-attrtab.c insn-dfatab.c \ Index: Makefile.tpl === --- Makefile.tpl (revision 195012) +++ Makefile.tpl (working copy) @@ -367,7 +367,7 @@ BUILD_PREFIX_1 = @BUILD_PREFIX_1@ # here so that they can be overridden by Makefile fragments. BOOT_CFLAGS= -g -O2 BOOT_LDFLAGS= -BOOT_ADAFLAGS=-gnatpg -gnata +BOOT_ADAFLAGS= -gnatpg AWK = @AWK@ SED = @SED@
[PATCH libgcc] Fix ARM uclinux libgcc config order issue
Hi,
The patch is to adjust ARM uclinux libgcc config order of arm/t-bpabi and t-
arm since LIB1ASMFUNCS defined in t-bpabi is overridden in t-arm.
Is it OK for trunk, 4.8 and 4.7?
Thanks!
-Zhenqiang
2012-03-11 Zhenqiang Chen
* config.host (arm*-*-uclinux*): Move arm/t-arm before arm/t-bpabi.
diff --git a/libgcc/config.host b/libgcc/config.host index ffd047f..eb65941
100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -332,10 +332,10 @@ arm*-*-linux*)# ARM GNU/Linux with
ELF
;;
arm*-*-uclinux*) # ARM ucLinux
tmake_file="${tmake_file} t-fixedpoint-gnu-prefix"
+ tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf
t-softfp-excl arm/t-softfp t-softfp"
tmake_file="${tmake_file} arm/t-bpabi"
tm_file="$tm_file arm/bpabi-lib.h"
unwind_header=config/arm/unwind-arm.h
- tmake_file="$tmake_file arm/t-arm arm/t-elf t-softfp-sfdf
t-softfp-excl arm/t-softfp t-softfp"
extra_parts="$extra_parts crti.o crtn.o"
;;
arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
Re: Support for MIPS r5900
"Maciej W. Rozycki" writes: > And in any case I insist that the instructions are correctly marked in > the opcode table. I agree that it would be better to exclude the unimplemented instructions. Jürgen: if you're happy to submit a patch along those lines, I promise to review it. BTW Maciej, sorry to be prickly about this, but: where I live, "I insist" has a very domineering ring to it, at least in this kind of context. The implication tends to be that "having insisted, I really expect it to happen, simply because it is _I_ who insisted". Maybe it's not the same everywhere though. Richard
[PATCH] Fix PR44061
This fixes PR44061 by computing a false range for __builtin_constant_p
of parameters in VRP.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-01-11 Richard Guenther
PR tree-optimization/44061
* tree-vrp.c (extract_range_basic): Compute zero as
value-range for __builtin_constant_p of function parameters.
* gcc.dg/pr44061.c: New testcase.
Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c (revision 195085)
--- gcc/tree-vrp.c (working copy)
*** extract_range_basic (value_range_t *vr,
*** 3566,3573
bool sop = false;
tree type = gimple_expr_type (stmt);
! if (INTEGRAL_TYPE_P (type)
! && gimple_stmt_nonnegative_warnv_p (stmt, &sop))
set_value_range_to_nonnegative (vr, type,
sop || stmt_overflow_infinity (stmt));
else if (vrp_stmt_computes_nonzero (stmt, &sop)
--- 3566,3585
bool sop = false;
tree type = gimple_expr_type (stmt);
! /* If the call is __builtin_constant_p and the argument is a
! function parameter resolve it to false. This avoids bogus
! array bound warnings.
! ??? We could do this as early as inlining is finished. */
! if (gimple_call_builtin_p (stmt, BUILT_IN_CONSTANT_P))
! {
! tree arg = gimple_call_arg (stmt, 0);
! if (TREE_CODE (arg) == SSA_NAME
! && SSA_NAME_IS_DEFAULT_DEF (arg)
! && TREE_CODE (SSA_NAME_VAR (arg)) == PARM_DECL)
! set_value_range_to_null (vr, type);
! }
! else if (INTEGRAL_TYPE_P (type)
! && gimple_stmt_nonnegative_warnv_p (stmt, &sop))
set_value_range_to_nonnegative (vr, type,
sop || stmt_overflow_infinity (stmt));
else if (vrp_stmt_computes_nonzero (stmt, &sop)
Index: gcc/testsuite/gcc.dg/pr44061.c
===
*** gcc/testsuite/gcc.dg/pr44061.c (revision 0)
--- gcc/testsuite/gcc.dg/pr44061.c (working copy)
***
*** 0
--- 1,16
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -Wall" } */
+
+ int a[2];
+ int foo (int q)
+ {
+ if (__builtin_constant_p (q))
+ {
+ if (q == 4)
+ return a[4]; /* { dg-bogus "array subscript is above array bounds" } */
+ else
+ return a[0];
+ }
+ else
+ return a[q];
+ }
[patch,libgcc] Fix fixed-bit.c build warning
Variables min_high and min_low are set but not used which cases build warnings, fixed by this patch. Build fine for i686-pc-linux-gnu and avr-unknown-none, the latter definitely using this code. Ok for trunk? Johann * fixed-bit.c (SATFRACT) : Only declare / set min_low, min_high if TO_MODE_UNSIGNED == 0. (SATFRACT) : Only declare / set min_low, min_high if FROM_MODE_UNSIGNED == 0 and TO_MODE_UNSIGNED == 0.
Re: [PATCH] Fix PR55882
On Thu, 10 Jan 2013, Eric Botcazou wrote:
> > The problem with this intermediate inconsistency is that ...
> >
> > > That's why only the final result should matter and need be correct.
> >
> > ... this can't be ensured anymore. In some cases the inconsistency
> > between the mem attributes and what XEXP(MEM, 0) represents can't be
> > repaired by the later bitpos adjustments, or better it can be only be
> > repaired by falling back to the conservative side for e.g. the alignment,
> > because we don't store enough information in the mem attributes to recover
> > what was lost.
>
> Indeed, looking at the history of the code shows that the alignment handling
> via MEM_REF and get_object_alignment is an afterthought. Originally, it was
> set only in a few specific cases:
>
> /* We can set the alignment from the type if we are making an object,
> this is an INDIRECT_REF, or if TYPE_ALIGN_OK. */
>
> and also for DECL_P and CONSTANT_CLASS_P. That was it, so this was actually
> the alignment of the base and disregarding BITPOS was fine.
Yes, in these cases bitpos is zero. It's wrong in the !align_computed
path and possibly in the ARRAY_REF -> DECL_P path (only not as
optimistic as it could be).
> > When briefly discussing this yesterday I suggested (without having the
> > code in front of me) that it be best to simply set the mem attributes only
> > at the very end, after having computed to final MEM address including all
> > adjustments, instead of generating wrong mem attributes initially and
> > hoping for the adjustments to make it come out right at the end.
>
> Maybe, but for 4.7 (and probably 4.8) I think we should be conservative and
> only fix the problems recently introduced.
>
> So, in the end, I think that we should go either for Richard's initial patch
> in this thread, possibly with a ??? comment along the lines of:
>
> /* ??? If we haven't computed the alignment yet, compute it now. Note
> that, if already computed above, the alignment is that of the base
> object of T so it is OK to have disregarded BITPOS above. However,
> here we are using get_object_alignment_1 which returns the precise
> alignment of T so we need to account for the BITPOS adjustment. */
> if (!align_computed)
>
> or for Richard's initial patch + the removal of the MEM_REF block (which is
> midway between Richard's initial patch and Richard's last patch).
Thus I'm preparing a patch that applies to both 4.7 and 4.8 at this
point, leaving some holes I see open (which are not to be closed in
the same way due to differences in behavior of get_object_alignment
on the 4.7 branch vs. trunk).
Bootstrap and regtest on x86_64-unknown-linux-gnu running, Eric,
can you give this a strict-align target testing on the 4.7 branch?
Martin, can you re-test this on sparc (it's slightly different again)?
I'm going to remove the MEM_REF block as a followup (we can't backport
that due to pessimizations this will cause due to different
get_object_alignment behavior - yet, unless we backport that change
as well), it's a source of wrong alignment as well, due to the
usage of MAX () - the get_object_alignment result will never shrink
alignment this way (and thus implicitely relies on attrs.align
being BITS_PER_UNIT when !align_computed).
The get_object_alignment behavior change is
2012-07-18 Richard Guenther
* tree.h (get_object_or_type_alignment): Remove.
* builtins.c (get_object_alignment_2): New function copied from
get_object_alignment_1. Take extra argument to indicate whether
we take the address of EXP. Rework to use type alignment
information
if not, and return whether the result is an approximation or not.
(get_object_alignment_1): Wrap around get_object_alignment_2.
(get_pointer_alignment_1): Call get_object_alignment_2 indicating
we take the address.
(get_object_or_type_alignment): Remove.
* expr.c (expand_assignment): Call get_object_alignment.
(expand_expr_real_1): Likewise.
and followups.
Thanks,
Richard.
2013-01-11 Richard Biener
PR middle-end/55882
* emit-rtl.c (set_mem_attributes_minus_bitpos): Correctly
account for bitpos when computing alignment.
* gcc.dg/torture/pr55882.c: New testcase.
Index: gcc/emit-rtl.c
===
*** gcc/emit-rtl.c (revision 195102)
--- gcc/emit-rtl.c (working copy)
*** set_mem_attributes_minus_bitpos (rtx ref
*** 1839,1845
if (!align_computed)
{
! unsigned int obj_align = get_object_alignment (t);
attrs.align = MAX (attrs.align, obj_align);
}
}
--- 1839,1850
if (!align_computed)
{
! unsigned int obj_align;
! unsigned HOST_WIDE_INT obj_bitpos;
! get_object_alignment_1 (t, &obj_align, &obj_bitpos);
! obj_bi
Re: [patch] Disable Ada front-end checking in release mode
On Fri, Jan 11, 2013 at 10:08 AM, Eric Botcazou wrote: > Hi, > > the Ada part of the Ada front-end is compiled with -gnata, which boils down to > a form of dynamic type checking for the AST, i.e. something roughly equivalent > to Tree checking for the front-ends of the C family of compilers. This patch > aligns the Ada compiler with them by disabling it in --enable-checking=release > mode. Issues flagged by this checking are usually benign on release branches > and gigi has a slew of gcc_assert's that stop the compiler in serious cases. > > Bootstrapped on x86_64-suse-linux (w and w/o --enable-checking=release), OK > for the mainline? Ok. Thanks, Richard. > > 2013-01-11 Eric Botcazou > > * Makefile.tpl (BOOT_ADAFLAGS): Remove -gnata. > * Makefile.in: Regenerate. > > > gcc/ > 2013-01-11 Eric Botcazou > > * configure.ac (Tree checking): Set TREECHECKING to yes if enabled. > Substitute TREECHECKING. > * configure: Regenerate. > * Makefile.in (TREECHECKING): New. > > > gcc/ada/ > 2013-01-11 Eric Botcazou > > * gcc-interface/Make-lang.in (COMMON_ADAFLAGS): Remove -gnata. > (CHECKING_ADAFLAGS): New. > (ALL_ADAFLAGS): Include CHECKING_ADAFLAGS. > > > -- > Eric Botcazou
Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg
Gabriel Dos Reis writes:
> On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote:
>
>> But during the instantiation of the *members* of test, we try to
>> instantiate Alias>, without coercing (and thus without
>> folding) the argument {the_truth}. We do this using
>> instantiate_alias_template, called from tsubst.
>>
>> The patch below makes sure instantiate_alias_template coerces the
>> arguments it uses to instantiate the alias template, like what I
>> understood you are suggesting. I have tested it without boostrap and a
>> full boostrap is currently running.
>
> Hmm, is it necessary to coerce all levels as opposed to just the
> innermost arguments?
>
> -- Gaby
Jason Merrill writes:
> On 01/10/2013 11:11 AM, Gabriel Dos Reis wrote:
>> Hmm, is it necessary to coerce all levels as opposed to just the
>> innermost arguments?
>
> No. But if you read the code, it's really only coercing the innermost
> level.
Correct. I even documented that in the descriptive comment of the
function. But ...
> Just the name is misleading.
... as the name seems to be confusing, I have changed it to
coerce_innermost_template_parms. I hope that is less confusing.
>> If this approach looks acceptable, could I replace (part of) the
>> template argument coercing code in lookup_class_template_1 with the new
>> coerce_template_parms_all_level I introduced in this patch?
>
> Yes.
OK. I have done that in the patch below that passed bootstrap and
regression testing on x86_64-unknown-linux-gnu against trunk.
If nothing else, I'd need your opinion on this; in the template argument
coercing code in lookup_template_1 does this:
/* We temporarily reduce the length of the ARGLIST so
that coerce_template_parms will see only the arguments
corresponding to the template parameters it is
examining. */
TREE_VEC_LENGTH (arglist)--;
but when I read the code, it looks like this is not necessary. Am I
missing something? In any case, I haven't put that code in the new
coerce_innermost_template_parms. Is that OK?
Thanks.
gcc/cp/
PR c++/55663
* pt.c (coerce_innermost_template_parms): New static function.
(instantiate_alias_template): Use it here.
(lookup_template_class_1): Use it here too, for ease of
maintenance's sake.
gcc/testsuite/
PR c++/55663
* g++.dg/cpp0x/alias-decl-31.C: New test.
---
gcc/cp/pt.c| 130 -
gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C | 20 +
2 files changed, 93 insertions(+), 57 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 30bafa0..67e6c97 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -130,6 +130,8 @@ static tree tsubst_initializer_list (tree, tree);
static tree get_class_bindings (tree, tree, tree, tree);
static tree coerce_template_parms (tree, tree, tree, tsubst_flags_t,
bool, bool);
+static tree coerce_innermost_template_parms (tree, tree, tree, tsubst_flags_t,
+ bool, bool);
static void tsubst_enum(tree, tree, tree);
static tree add_to_template_args (tree, tree);
static tree add_outermost_template_args (tree, tree);
@@ -6742,6 +6744,61 @@ coerce_template_parms (tree parms,
return new_inner_args;
}
+/* Like coerce_template_parms. If PARMS represents all template
+ parameters levels, this function returns a vector of vectors
+ representing all the resulting argument levels. Note that in this
+ case, only the innermost arguments are coerced because the
+ outermost ones are supposed to have been coerced already.
+
+ Otherwise, if PARMS represents only (the innermost) vector of
+ parameters, this function returns a vector containing just the
+ innermost resulting arguments. */
+
+static tree
+coerce_innermost_template_parms (tree parms,
+ tree args,
+ tree in_decl,
+ tsubst_flags_t complain,
+ bool require_all_args,
+ bool use_default_args)
+{
+ int parms_depth = TMPL_PARMS_DEPTH (parms);
+ int args_depth = TMPL_ARGS_DEPTH (args);
+ tree coerced_args;
+
+ if (parms_depth > 1)
+{
+ coerced_args = make_tree_vec (parms_depth);
+ tree level;
+ int cur_depth;
+
+ for (level = parms, cur_depth = parms_depth;
+ parms_depth > 0 && level != NULL_TREE;
+ level = TREE_CHAIN (level), --cur_depth)
+ {
+ tree l;
+ if (cur_depth == args_depth)
+ l = coerce_template_parms (TREE_VALUE (level),
+ args, in_decl, complain,
+ require_all_args,
+ use_default_args);
+ else
+ l =
Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg
Gabriel Dos Reis writes: > On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote: >> >> Also, I am not sure if this patch would be appropriate for commit, now >> that we are in 'regression-only' mode. But seeing this alias-template >> related thing not working hurts me. :) So at worst I'll schedule the >> patch for when stage1 opens again. > > It is certainly a blocker for some people here using both constexpr > and template alias. (The code uses a technique documented in the > upcoming 4th edition of TC++PL which is due anytime now. It would be > embarrassing if GCC-4.8 didn't accept it.) /me nods. Hopefully when the review is done, we can ask our friendly release managers to consider interceding for us in this matter. :-) -- Dodji
Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg
On Fri, Jan 11, 2013 at 11:41:34AM +0100, Dodji Seketeli wrote: > Gabriel Dos Reis writes: > > > On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote: > >> > >> Also, I am not sure if this patch would be appropriate for commit, now > >> that we are in 'regression-only' mode. But seeing this alias-template > >> related thing not working hurts me. :) So at worst I'll schedule the > >> patch for when stage1 opens again. > > > > It is certainly a blocker for some people here using both constexpr > > and template alias. (The code uses a technique documented in the > > upcoming 4th edition of TC++PL which is due anytime now. It would be > > embarrassing if GCC-4.8 didn't accept it.) > > /me nods. > > Hopefully when the review is done, we can ask our friendly release > managers to consider interceding for us in this matter. :-) This is ok for 4.8 from RM POV. Jakub
RE: [PATCH] Yet another non-prototype builtin issue (PR middle-end/55890)
Tom, are you going to apply this patch?
There are similar failures on arm-none-eabi after r195008:
FAIL: gcc.dg/torture/pr55890-3.c -O0 (internal compiler error)
FAIL: gcc.dg/torture/pr55890-3.c -O0 (test for excess errors)
FAIL: gcc.dg/torture/pr55890-3.c -O1 (internal compiler error)
FAIL: gcc.dg/torture/pr55890-3.c -O1 (test for excess errors)
ICE with segfault same backtrace as in your report.
The failures are with -OO and -O1 but the test passes with -O2.
Your patch fixes these failures. I haven't tested the patch beyond that.
Thanks,
Greta
> -Original Message-
> From: Tom de Vries [mailto:tom_devr...@mentor.com]
> Sent: 09 January 2013 10:11
> To: Richard Biener
> Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org
> Subject: [PATCH] Yet another non-prototype builtin issue (PR middle-
> end/55890)
>
> Richard,
>
> I've build r195008 for target mips64-linux-gnu with low optimization
> level
> ({CFLAGS,CXXFLAGS,BOOT_CFLAGS}='-g -O0'), and noticed failures for
> gcc.dg/torture/pr55890-{1,2,3}.c at -O0 and -O1 (which are not there
> without the
> low optimization level).
>
> The -O1 pr55890-1.c failure looks like this:
> ...
> $ mips64-linux-gnu-gcc gcc/testsuite/gcc.dg/torture/pr55890-1.c
> -fno-diagnostics-show-caret -O1 -S -o pr55890-1.s
> gcc/testsuite/gcc.dg/torture/pr55890-1.c: In function 'main':
> gcc/testsuite/gcc.dg/torture/pr55890-1.c:6:11: internal compiler error:
> Segmentation fault
> 0x86dad80 crash_signal
> gcc/toplev.c:334
> 0x82bec14 expand_call(tree_node*, rtx_def*, int)
> gcc/calls.c:3139
> 0x82adae3 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
> int)
> gcc-mainline/gcc/builtins.c:6866
> 0x83d5484 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**)
> gcc-mainline/gcc/expr.c:10141
> 0x82d7721 expand_call_stmt
> gcc-mainline/gcc/cfgexpand.c:2115
> 0x82d77eb expand_gimple_stmt_1
> gcc/cfgexpand.c:2153
> 0x82d7e51 expand_gimple_stmt
> gcc/cfgexpand.c:2305
> 0x82d8f76 expand_gimple_basic_block
> gcc/cfgexpand.c:4084
> 0x82d9d53 gimple_expand_cfg
> gcc/cfgexpand.c:4603
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See for instructions.
> ...
>
> The segv occurs when evaluating GET_MODE (args[arg_nr].reg) here:
> ...
> if (pass == 1 && (return_flags & ERF_RETURNS_ARG))
> {
> int arg_nr = return_flags & ERF_RETURN_ARG_MASK;
> if (PUSH_ARGS_REVERSED)
> arg_nr = num_actuals - arg_nr - 1;
> if (args[arg_nr].reg
> && valreg
> && REG_P (valreg)
> && GET_MODE (args[arg_nr].reg) == GET_MODE (valreg))
> call_fusage
> = gen_rtx_EXPR_LIST (TYPE_MODE (TREE_TYPE
> (args[arg_nr].tree_value)),
> gen_rtx_SET (VOIDmode, valreg,
> args[arg_nr].reg),
> call_fusage);
> }
> ...
>
> The expression (return_flags & ERF_RETURNS_ARG) is true because we're
> calculating return_flags using fndecl == memmove, and for memmove we're
> indeed
> returning the first arg.
>
> So arg_nr evaluates to 0, and we're accessing args[arg_nr].reg. But
> num_actuals
> is 0, so args is the result of alloca (0) and args[arg_nr] contains
> some random
> value, which causes the segv when evaluating GET_MODE
> (args[arg_nr].reg) (unless
> args[arg_nr].reg happens to be NULL, in which case we don't get there).
>
> Attached patch fixes this by testing whether arg_nr is in range before
> using it.
> Using the patch and a cc1 recompile, I'm able to run pr55890-{1,2,3}.c
> successfully.
>
> OK for trunk after I've tested this on mips64?
>
> Thanks,
> - Tom
>
> 2013-01-09 Tom de Vries
>
> PR middle-end/55890
> * calls.c (expand_call): Check if arg_nr is valid.
[PATCH] Fix PR55936
VRP no longer (since 4.1.2 at least) can optimize vrp06.c in one go
because we happen to chose a symbolic range when
Intersecting
[j_12(D), j_12(D)] EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4
elements)
and
[10, 30] EQUIVALENCES: { i_9(D) i_26 } (2 elements)
to
[j_12(D), j_12(D)] EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4
elements)
that pessimizes further refinement of ranges which happens
without looking at equivalences. We also seem to not consider
equivalences when folding predicates during propagation (anyone
can create a regression testcase out of that now? we really
should do that), thus it's important to choose [10, 30] above
to be able to fold the following < 0 test.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2013-01-11 Richard Biener
PR tree-optimization/55936
* tree-vrp.c (intersect_ranges): As fallback choose the
range we can easiest refine further.
* gcc.dg/tree-ssa/vrp06.c: Adjust.
Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c (revision 195103)
--- gcc/tree-vrp.c (working copy)
*** intersect_ranges (enum value_range_type
*** 7782,7791
else
gcc_unreachable ();
}
!
! /* As a fallback simply use { *VRTYPE, *VR0MIN, *VR0MAX } as
! result for the intersection. That's always a conservative
! correct estimate. */
return;
}
--- 7782,7804
else
gcc_unreachable ();
}
! else
! {
! /* As a fallback simply use the range that is closest to
!an integer constant range. That's always a conservative
!correct estimate. */
! if (((TREE_CODE (*vr0min) == INTEGER_CST)
! + (TREE_CODE (*vr0max) == INTEGER_CST)
! + (*vr0type == VR_RANGE))
! < ((TREE_CODE (vr1min) == INTEGER_CST)
!+ (TREE_CODE (vr1max) == INTEGER_CST)
!+ (vr1type == VR_RANGE)))
! {
! *vr0type = vr1type;
! *vr0min = vr1min;
! *vr0max = vr1max;
! }
! }
return;
}
Index: gcc/testsuite/gcc.dg/tree-ssa/vrp06.c
===
*** gcc/testsuite/gcc.dg/tree-ssa/vrp06.c (revision 195103)
--- gcc/testsuite/gcc.dg/tree-ssa/vrp06.c (working copy)
*** foo (int i, int j, int a)
*** 27,31
/* { dg-final { scan-tree-dump-times "Folding predicate i_\[0-9\]+.*0 to 0" 1
"vrp1" } } */
/* { dg-final { scan-tree-dump-times "Folding predicate j_\[0-9\]+.*0 to 1" 1
"vrp1" } } */
! /* { dg-final { scan-tree-dump-times "Folding predicate
i_\[0-9]+.*j_\[0-9\]+.* to 0" 1 "vrp1" { xfail *-*-* } } } */
/* { dg-final { cleanup-tree-dump "vrp1" } } */
--- 27,31
/* { dg-final { scan-tree-dump-times "Folding predicate i_\[0-9\]+.*0 to 0" 1
"vrp1" } } */
/* { dg-final { scan-tree-dump-times "Folding predicate j_\[0-9\]+.*0 to 1" 1
"vrp1" } } */
! /* { dg-final { scan-tree-dump-times "Folding predicate
i_\[0-9]+.*j_\[0-9\]+.* to 0" 1 "vrp1" } } */
/* { dg-final { cleanup-tree-dump "vrp1" } } */
Re: [PATCH] Fix PR55936
On Fri, Jan 11, 2013 at 12:06:04PM +0100, Richard Biener wrote:
>
> VRP no longer (since 4.1.2 at least) can optimize vrp06.c in one go
> because we happen to chose a symbolic range when
Just FYI, GCC never optimized that apparently, at least in r10
(vrp06.c has been added in r100478) vrp didn't fold any of the 3 foldings
looked for by the testcase, and in r102000 it folded just the first 2 and
not the third (and from that point onwards), don't have anything in between
though.
> *** gcc/testsuite/gcc.dg/tree-ssa/vrp06.c (revision 195103)
> --- gcc/testsuite/gcc.dg/tree-ssa/vrp06.c (working copy)
> *** foo (int i, int j, int a)
> *** 27,31
>
> /* { dg-final { scan-tree-dump-times "Folding predicate i_\[0-9\]+.*0 to 0"
> 1 "vrp1" } } */
> /* { dg-final { scan-tree-dump-times "Folding predicate j_\[0-9\]+.*0 to 1"
> 1 "vrp1" } } */
> ! /* { dg-final { scan-tree-dump-times "Folding predicate
> i_\[0-9]+.*j_\[0-9\]+.* to 0" 1 "vrp1" { xfail *-*-* } } } */
> /* { dg-final { cleanup-tree-dump "vrp1" } } */
> --- 27,31
>
> /* { dg-final { scan-tree-dump-times "Folding predicate i_\[0-9\]+.*0 to 0"
> 1 "vrp1" } } */
> /* { dg-final { scan-tree-dump-times "Folding predicate j_\[0-9\]+.*0 to 1"
> 1 "vrp1" } } */
> ! /* { dg-final { scan-tree-dump-times "Folding predicate
> i_\[0-9]+.*j_\[0-9\]+.* to 0" 1 "vrp1" } } */
> /* { dg-final { cleanup-tree-dump "vrp1" } } */
If you are changing the testcase again, please replace all .* with \[^\n\r\]* ,
so that it doesn't match 0 to 0 etc. from different lines.
Jakub
Re: [wwwdocs] mention caret diagnostics and Wpedantic
On Thu, 10 Jan 2013, Manuel López-Ibáñez wrote: > I haven't heard any complaints about the caret diagnostics being > enabled by default, so I am tempted to think it will stay like it is > for GCC 4.8. This patch documents that and also the new -Wpedantic. > OK? Nice! +By default, each diagnostic emitted includes the original How about adding "now includes" to emphasize this is new behavior, as opposed to a summary/introduction ahead of the next item? + -Werror=pedantic is not equivalent to Can you make this not (or just not)? + -Wno-pedantic. I believe you'll want to close this with at the end. Looks good to me. Gerald PS: Your mailer attached the patch as Application/OCTET-STREAM, not text.
Re: [PATCH] Fix PR55936
On Fri, 11 Jan 2013, Jakub Jelinek wrote:
> On Fri, Jan 11, 2013 at 12:06:04PM +0100, Richard Biener wrote:
> >
> > VRP no longer (since 4.1.2 at least) can optimize vrp06.c in one go
> > because we happen to chose a symbolic range when
>
> Just FYI, GCC never optimized that apparently, at least in r10
> (vrp06.c has been added in r100478) vrp didn't fold any of the 3 foldings
> looked for by the testcase, and in r102000 it folded just the first 2 and
> not the third (and from that point onwards), don't have anything in between
> though.
The SLE10 gcc 4.1 based compiler folds the last test to i_1 != i_16
which then cfgcleanup figures out as false.
So it worked in some sense (that is, there is a regression).
> > *** gcc/testsuite/gcc.dg/tree-ssa/vrp06.c (revision 195103)
> > --- gcc/testsuite/gcc.dg/tree-ssa/vrp06.c (working copy)
> > *** foo (int i, int j, int a)
> > *** 27,31
> >
> > /* { dg-final { scan-tree-dump-times "Folding predicate i_\[0-9\]+.*0 to
> > 0" 1 "vrp1" } } */
> > /* { dg-final { scan-tree-dump-times "Folding predicate j_\[0-9\]+.*0 to
> > 1" 1 "vrp1" } } */
> > ! /* { dg-final { scan-tree-dump-times "Folding predicate
> > i_\[0-9]+.*j_\[0-9\]+.* to 0" 1 "vrp1" { xfail *-*-* } } } */
> > /* { dg-final { cleanup-tree-dump "vrp1" } } */
> > --- 27,31
> >
> > /* { dg-final { scan-tree-dump-times "Folding predicate i_\[0-9\]+.*0 to
> > 0" 1 "vrp1" } } */
> > /* { dg-final { scan-tree-dump-times "Folding predicate j_\[0-9\]+.*0 to
> > 1" 1 "vrp1" } } */
> > ! /* { dg-final { scan-tree-dump-times "Folding predicate
> > i_\[0-9]+.*j_\[0-9\]+.* to 0" 1 "vrp1" } } */
> > /* { dg-final { cleanup-tree-dump "vrp1" } } */
>
> If you are changing the testcase again, please replace all .* with \[^\n\r\]*
> ,
> so that it doesn't match 0 to 0 etc. from different lines.
Ok.
Richard.
Re: [PATCH] Yet another non-prototype builtin issue (PR middle-end/55890)
On 11/01/13 12:02, Greta Yorsh wrote: > Tom, are you going to apply this patch? Greta, While testing I've ran into several issues with timeouts (not related to this patch) that I needed to address, so it took me a bit, but I started the latest build & test run yesterday evening so I expect to checked in the patch later today. Thanks, - Tom
Re: [RFC, x86] Changes for AVX and AVX2 processors
I've fixed Changelog. Can we commit the patch to trunk now? 2012-12-27 Vladimir Yakovlev * config/i386/i386-c.c (ix86_target_macros_internal): New case. (ix86_target_macros_internal): Likewise. * config/i386/i386.c (m_CORE2I7): Removed. (m_CORE_HASWELL): New macro. (m_CORE_ALL): Likewise. (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL. (initial_ix86_arch_features): Likewise. (processor_target_table): Initializations for Core avx2. (cpu_names): New names "core-avx2". (ix86_option_override_internal): Changed PROCESSOR_COREI7 by PROCESSOR_CORE_HASWELL. (ix86_issue_rate): New case. (ia32_multipass_dfa_lookahead): Likewise. (ix86_sched_init_global): Likewise. * config/i386/i386.h (TARGET_HASWELL): New macro. (target_cpu_default): New TARGET_CPU_DEFAULT_haswell. (processor_type): New PROCESSOR_HASWELL. 2013/1/10 Jakub Jelinek : > On Thu, Jan 10, 2013 at 12:28:24PM +0100, Uros Bizjak wrote: >> On Thu, Jan 10, 2013 at 12:12 PM, Vladimir Yakovlev >> wrote: >> >> > It seems I didn't sent a patch with last changes. Sorry if so. >> > >> > Vladimir >> > >> > 2012-12-27 Vladimir Yakovlev > Missing > at the end of line. > >> > >> > * config/i386/i386-c.c (ix86_target_macros_internal): New case. >> > (ix86_target_macros_internal): Likewise. > > There is some additional space at the beginning of this line (note, all > ChangeLog lines but the one with date should be tab indented, not space). > > Jakub
Re: [RFC, x86] Changes for AVX and AVX2 processors
On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote: > I've fixed Changelog. Can we commit the patch to trunk now? > > 2012-12-27 Vladimir Yakovlev > > * config/i386/i386-c.c (ix86_target_macros_internal): New case. > (ix86_target_macros_internal): Likewise. > > * config/i386/i386.c (m_CORE2I7): Removed. > (m_CORE_HASWELL): New macro. > (m_CORE_ALL): Likewise. > (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL. > (initial_ix86_arch_features): Likewise. > (processor_target_table): Initializations for Core avx2. > (cpu_names): New names "core-avx2". > (ix86_option_override_internal): Changed PROCESSOR_COREI7 by > PROCESSOR_CORE_HASWELL. > (ix86_issue_rate): New case. > (ia32_multipass_dfa_lookahead): Likewise. > (ix86_sched_init_global): Likewise. > > * config/i386/i386.h (TARGET_HASWELL): New macro. > (target_cpu_default): New TARGET_CPU_DEFAULT_haswell. > (processor_type): New PROCESSOR_HASWELL. Uros already acked the patch, so it certainly is ok to commit now. Jakub
Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg
Jakub Jelinek writes: > On Fri, Jan 11, 2013 at 11:41:34AM +0100, Dodji Seketeli wrote: >> Gabriel Dos Reis writes: >> >> > On Thu, Jan 10, 2013 at 9:22 AM, Dodji Seketeli wrote: >> >> >> >> Also, I am not sure if this patch would be appropriate for commit, now >> >> that we are in 'regression-only' mode. But seeing this alias-template >> >> related thing not working hurts me. :) So at worst I'll schedule the >> >> patch for when stage1 opens again. >> > >> > It is certainly a blocker for some people here using both constexpr >> > and template alias. (The code uses a technique documented in the >> > upcoming 4th edition of TC++PL which is due anytime now. It would be >> > embarrassing if GCC-4.8 didn't accept it.) >> >> /me nods. >> >> Hopefully when the review is done, we can ask our friendly release >> managers to consider interceding for us in this matter. :-) > > This is ok for 4.8 from RM POV. Thank you! -- Dodji
Re: [RFC, x86] Changes for AVX and AVX2 processors
I sent the patch. Send it once more. 2013/1/11 Jakub Jelinek : > On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote: >> I've fixed Changelog. Can we commit the patch to trunk now? >> >> 2012-12-27 Vladimir Yakovlev >> >> * config/i386/i386-c.c (ix86_target_macros_internal): New case. >> (ix86_target_macros_internal): Likewise. >> >> * config/i386/i386.c (m_CORE2I7): Removed. >> (m_CORE_HASWELL): New macro. >> (m_CORE_ALL): Likewise. >> (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL. >> (initial_ix86_arch_features): Likewise. >> (processor_target_table): Initializations for Core avx2. >> (cpu_names): New names "core-avx2". >> (ix86_option_override_internal): Changed PROCESSOR_COREI7 by >> PROCESSOR_CORE_HASWELL. >> (ix86_issue_rate): New case. >> (ia32_multipass_dfa_lookahead): Likewise. >> (ix86_sched_init_global): Likewise. >> >> * config/i386/i386.h (TARGET_HASWELL): New macro. >> (target_cpu_default): New TARGET_CPU_DEFAULT_haswell. >> (processor_type): New PROCESSOR_HASWELL. > > Uros already acked the patch, so it certainly is ok to commit now. > > Jakub patch1 Description: Binary data
Re: [patch,libgcc] Fix fixed-bit.c build warning
Georg-Johann Lay wrote:
> Variables min_high and min_low are set but not used which cases build
> warnings,
> fixed by this patch.
Better attach the patch...
> Build fine for i686-pc-linux-gnu and avr-unknown-none, the latter definitely
> using this code.
>
> Ok for trunk?
>
> Johann
>
>
> * fixed-bit.c (SATFRACT) : Only
> declare / set min_low, min_high if TO_MODE_UNSIGNED == 0.
> (SATFRACT) : Only declare / set min_low,
> min_high if FROM_MODE_UNSIGNED == 0 and TO_MODE_UNSIGNED == 0.
Index: libgcc/fixed-bit.c
===
--- libgcc/fixed-bit.c (revision 194964)
+++ libgcc/fixed-bit.c (working copy)
@@ -761,11 +761,12 @@ SATFRACT (FROM_FIXED_C_TYPE a)
#if FROM_MODE_UNSIGNED == 0
BIG_SINT_C_TYPE high, low;
BIG_SINT_C_TYPE max_high, max_low;
+#if TO_MODE_UNSIGNED == 0
BIG_SINT_C_TYPE min_high, min_low;
+#endif
#else
BIG_UINT_C_TYPE high, low;
BIG_UINT_C_TYPE max_high, max_low;
- BIG_UINT_C_TYPE min_high, min_low;
#endif
#if TO_FBITS > FROM_FBITS
BIG_UINT_C_TYPE utemp;
@@ -812,13 +813,12 @@ SATFRACT (FROM_FIXED_C_TYPE a)
#endif
#if TO_MODE_UNSIGNED == 0
- min_high = -1;
stemp = (BIG_SINT_C_TYPE)1 << (BIG_WIDTH - 1);
stemp = stemp >> (BIG_WIDTH - 1 - TO_I_F_BITS);
+#if FROM_MODE_UNSIGNED == 0
+ min_high = -1;
min_low = stemp;
-#else
- min_high = 0;
- min_low = 0;
+#endif
#endif
#if FROM_MODE_UNSIGNED == 0 && TO_MODE_UNSIGNED == 0
@@ -957,7 +957,7 @@ FRACT (FROM_INT_C_TYPE a)
#endif /* defined(FRACT) && FROM_TYPE == 1 && TO_TYPE == 4 */
/* Signed int -> Fixed with saturation. */
-#if defined(SATFRACT) && defined(L_satfract) &&FROM_TYPE == 1 && TO_TYPE == 4
+#if defined(SATFRACT) && defined(L_satfract) && FROM_TYPE == 1 && TO_TYPE == 4
TO_FIXED_C_TYPE
SATFRACT (FROM_INT_C_TYPE a)
{
@@ -966,8 +966,8 @@ SATFRACT (FROM_INT_C_TYPE a)
FROM_INT_C_TYPE x = a;
BIG_SINT_C_TYPE high, low;
BIG_SINT_C_TYPE max_high, max_low;
- BIG_SINT_C_TYPE min_high, min_low;
#if TO_MODE_UNSIGNED == 0
+ BIG_SINT_C_TYPE min_high, min_low;
BIG_SINT_C_TYPE stemp;
#endif
#if BIG_WIDTH != TO_FBITS
@@ -1008,12 +1008,7 @@ SATFRACT (FROM_INT_C_TYPE a)
stemp = (BIG_SINT_C_TYPE)1 << (BIG_WIDTH - 1);
stemp = stemp >> (BIG_WIDTH - 1 - TO_I_F_BITS);
min_low = stemp;
-#else
- min_high = 0;
- min_low = 0;
-#endif
-#if TO_MODE_UNSIGNED == 0
/* Signed -> Signed. */
if ((BIG_SINT_C_TYPE) high > (BIG_SINT_C_TYPE) max_high
|| ((BIG_SINT_C_TYPE) high == (BIG_SINT_C_TYPE) max_high
Re: [RFC, x86] Changes for AVX and AVX2 processors
On Fri, Jan 11, 2013 at 1:14 PM, Vladimir Yakovlev wrote: > I sent the patch. Send it once more. > > 2013/1/11 Jakub Jelinek : >> On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote: >>> I've fixed Changelog. Can we commit the patch to trunk now? >>> >>> 2012-12-27 Vladimir Yakovlev >>> >>> * config/i386/i386-c.c (ix86_target_macros_internal): New case. >>> (ix86_target_macros_internal): Likewise. >>> >>> * config/i386/i386.c (m_CORE2I7): Removed. >>> (m_CORE_HASWELL): New macro. >>> (m_CORE_ALL): Likewise. >>> (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL. >>> (initial_ix86_arch_features): Likewise. >>> (processor_target_table): Initializations for Core avx2. >>> (cpu_names): New names "core-avx2". >>> (ix86_option_override_internal): Changed PROCESSOR_COREI7 by >>> PROCESSOR_CORE_HASWELL. >>> (ix86_issue_rate): New case. >>> (ia32_multipass_dfa_lookahead): Likewise. >>> (ix86_sched_init_global): Likewise. >>> >>> * config/i386/i386.h (TARGET_HASWELL): New macro. >>> (target_cpu_default): New TARGET_CPU_DEFAULT_haswell. >>> (processor_type): New PROCESSOR_HASWELL. >> >> Uros already acked the patch, so it certainly is ok to commit now. Yes, the patch is OK, you can commit it to mainline SVN. If you are unable to commit, please say so in the patch proposal, so someone will commit the patch for you (as explained in [1]). [1] http://gcc.gnu.org/contribute.html Uros.
Re: [RFC, x86] Changes for AVX and AVX2 processors
Kirill, Could you commit patch? 2013-01-11 Vladimir Yakovlev * config/i386/i386-c.c (ix86_target_macros_internal): New case. (ix86_target_macros_internal): Likewise. * config/i386/i386.c (m_CORE2I7): Removed. (m_CORE_HASWELL): New macro. (m_CORE_ALL): Likewise. (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL. (initial_ix86_arch_features): Likewise. (processor_target_table): Initializations for Core avx2. (cpu_names): New names "core-avx2". (ix86_option_override_internal): Changed PROCESSOR_COREI7 by PROCESSOR_CORE_HASWELL. (ix86_issue_rate): New case. (ia32_multipass_dfa_lookahead): Likewise. (ix86_sched_init_global): Likewise. * config/i386/i386.h (TARGET_HASWELL): New macro. (target_cpu_default): New TARGET_CPU_DEFAULT_haswell. (processor_type): New PROCESSOR_HASWELL. 2013/1/11 Uros Bizjak : > On Fri, Jan 11, 2013 at 1:14 PM, Vladimir Yakovlev > wrote: >> I sent the patch. Send it once more. >> >> 2013/1/11 Jakub Jelinek : >>> On Fri, Jan 11, 2013 at 03:25:47PM +0400, Vladimir Yakovlev wrote: I've fixed Changelog. Can we commit the patch to trunk now? 2012-12-27 Vladimir Yakovlev * config/i386/i386-c.c (ix86_target_macros_internal): New case. (ix86_target_macros_internal): Likewise. * config/i386/i386.c (m_CORE2I7): Removed. (m_CORE_HASWELL): New macro. (m_CORE_ALL): Likewise. (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL. (initial_ix86_arch_features): Likewise. (processor_target_table): Initializations for Core avx2. (cpu_names): New names "core-avx2". (ix86_option_override_internal): Changed PROCESSOR_COREI7 by PROCESSOR_CORE_HASWELL. (ix86_issue_rate): New case. (ia32_multipass_dfa_lookahead): Likewise. (ix86_sched_init_global): Likewise. * config/i386/i386.h (TARGET_HASWELL): New macro. (target_cpu_default): New TARGET_CPU_DEFAULT_haswell. (processor_type): New PROCESSOR_HASWELL. >>> >>> Uros already acked the patch, so it certainly is ok to commit now. > > Yes, the patch is OK, you can commit it to mainline SVN. If you are > unable to commit, please say so in the patch proposal, so someone will > commit the patch for you (as explained in [1]). > > [1] http://gcc.gnu.org/contribute.html > > Uros. patch1 Description: Binary data
Re: [PATCH] Fix complex lowering with inline asm (PR tree-optimization/55921)
Jakub Jelinek writes:
> + __asm ("" : "=r" (cf) : "0" (ucf1.ll));
gcc/testsuite/gcc.c-torture/compile/pr55921.c:17:3: error: 'asm' operand has
impossible constraints
gcc/testsuite/gcc.c-torture/compile/pr55921.c:19:3: error: 'asm' operand has
impossible constraints
OK? This still triggers the original bug.
Andreas.
2013-01-11 Andreas Schwab
* gcc.c-torture/compile/pr55921.c: Don't use matching constraints.
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr55921.c
b/gcc/testsuite/gcc.c-torture/compile/pr55921.c
index 8ac9e9b..94b7bce 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr55921.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr55921.c
@@ -14,8 +14,8 @@ foo (ucf *in, ucf *out, _Complex float r)
_Complex float cf;
ucf1.ll = in[i].ll;
- __asm ("" : "=r" (cf) : "0" (ucf1.ll));
+ __asm ("" : "=r" (cf) : "r" (ucf1.ll));
cf *= r;
- __asm ("" : "=r" (ucf1.ll) : "0" (cf));
+ __asm ("" : "=r" (ucf1.ll) : "r" (cf));
out[i].ll = ucf1.ll;
}
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
[PATCH] Update config.sub from config repo
Hi! I committed this patch: 2013-01-11 Jan-Benedict Glaw * config.sub: Update from config repo. Index: config.sub === --- config.sub (revision 195104) +++ config.sub (working copy) @@ -4,7 +4,7 @@ # 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, # 2011, 2012, 2013 Free Software Foundation, Inc. -timestamp='2013-01-04' +timestamp='2013-01-11' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -290,6 +290,7 @@ | mipsisa64r2 | mipsisa64r2el \ | mipsisa64sb1 | mipsisa64sb1el \ | mipsisa64sr71k | mipsisa64sr71kel \ + | mipsr5900 | mipsr5900el \ | mipstx39 | mipstx39el \ | mn10200 | mn10300 \ | moxie \ @@ -407,6 +408,7 @@ | mipsisa64r2-* | mipsisa64r2el-* \ | mipsisa64sb1-* | mipsisa64sb1el-* \ | mipsisa64sr71k-* | mipsisa64sr71kel-* \ + | mipsr5900-* | mipsr5900el-* \ | mipstx39-* | mipstx39el-* \ | mmix-* \ | mt-* \ MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of:Arroganz verkürzt fruchtlose Gespräche. the second : -- Jan-Benedict Glaw signature.asc Description: Digital signature
Re: [PATCH] Fix complex lowering with inline asm (PR tree-optimization/55921)
On Fri, 11 Jan 2013, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > + __asm ("" : "=r" (cf) : "0" (ucf1.ll));
>
> gcc/testsuite/gcc.c-torture/compile/pr55921.c:17:3: error: 'asm' operand has
> impossible constraints
> gcc/testsuite/gcc.c-torture/compile/pr55921.c:19:3: error: 'asm' operand has
> impossible constraints
>
> OK? This still triggers the original bug.
Ok.
Thanks,
Richard.
> Andreas.
>
> 2013-01-11 Andreas Schwab
>
> * gcc.c-torture/compile/pr55921.c: Don't use matching constraints.
>
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr55921.c
> b/gcc/testsuite/gcc.c-torture/compile/pr55921.c
> index 8ac9e9b..94b7bce 100644
> --- a/gcc/testsuite/gcc.c-torture/compile/pr55921.c
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr55921.c
> @@ -14,8 +14,8 @@ foo (ucf *in, ucf *out, _Complex float r)
>_Complex float cf;
>
>ucf1.ll = in[i].ll;
> - __asm ("" : "=r" (cf) : "0" (ucf1.ll));
> + __asm ("" : "=r" (cf) : "r" (ucf1.ll));
>cf *= r;
> - __asm ("" : "=r" (ucf1.ll) : "0" (cf));
> + __asm ("" : "=r" (ucf1.ll) : "r" (cf));
>out[i].ll = ucf1.ll;
> }
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend
PING^2: PATCH: PR sanitizer/55374: [asan] -static-libasan -static-libstdc++ doesn't work
On Sat, Dec 8, 2012 at 9:13 AM, H.J. Lu wrote:
> On Thu, Nov 22, 2012 at 6:45 AM, H.J. Lu wrote:
>> Hi,
>>
>> libasan should come first before any language-specific
>> adjustment/addition. Otherwise, we got
>>
>> g++ -fsanitize=address -static-libasan ...
>>
>> /usr/local/bin/ld: error:
>> /export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
>> multiple definition of 'operator delete(void*)'
>> /usr/local/bin/ld:
>> /export/build/gnu/gcc-asan/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(del_op.o):
>> previous definition here
>>
>> This patch adds prepend_lang_specific_driver to prepend command line before
>> language-specific adjustment/addition of flags. OK to install?
>>
>> Thanks.
>>
>>
>> H.J.
>> ---
>> 2012-11-22 H.J. Lu
>>
>> PR driver/55374
>> * gcc.c (prepend_lang_specific_driver): New function.
>> (process_command): Use it.
>>
>> diff --git a/gcc/gcc.c b/gcc/gcc.c
>> index 0f8bcea..41474aa 100644
>> --- a/gcc/gcc.c
>> +++ b/gcc/gcc.c
>> @@ -3604,6 +3604,80 @@ set_option_handlers (struct cl_option_handlers
>> *handlers)
>>handlers->handlers[2].mask = CL_TARGET;
>> }
>>
>> +/* Prepend command line before language-specific adjustment/addition of
>> + flags. */
>> +
>> +void
>> +prepend_lang_specific_driver (struct cl_decoded_option **in_decoded_options,
>> + unsigned int *in_decoded_options_count,
>> + int *in_added_libraries)
>> +{
>> + unsigned int i, argc;
>> +
>> + /* The new argument list will be contained in this. */
>> + struct cl_decoded_option *new_decoded_options;
>> +
>> + /* The argument list. */
>> + struct cl_decoded_option *decoded_options;
>> +
>> + bool add_libasan = false;
>> + bool static_libasan = false;
>> +
>> + argc = *in_decoded_options_count;
>> + decoded_options = *in_decoded_options;
>> +
>> + for (i = 1; i < argc; i++)
>> +switch (decoded_options[i].opt_index)
>> + {
>> + case OPT_fsanitize_address:
>> + add_libasan = true;
>> + break;
>> + case OPT_static_libasan:
>> + static_libasan = true;
>> + break;
>> + }
>> +
>> + if (add_libasan)
>> +{
>> + /* Add -lasan before language-specific adjustment/addition. */
>> + unsigned int added_argc;
>> +
>> + added_argc = 1;
>> +#ifdef HAVE_LD_STATIC_DYNAMIC
>> + if (static_libasan)
>> + added_argc += 2;
>> +#endif
>> +
>> + new_decoded_options = XNEWVEC (struct cl_decoded_option,
>> +argc + added_argc);
>> +
>> + i = 0;
>> + do
>> + {
>> + new_decoded_options[i] = decoded_options[i];
>> + i++;
>> + }
>> + while (i < argc);
>> +
>> +#ifdef HAVE_LD_STATIC_DYNAMIC
>> + if (static_libasan)
>> + generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
>> +&new_decoded_options[i++]);
>> +#endif
>> + generate_option (OPT_l, "asan", 1, CL_DRIVER,
>> + &new_decoded_options[i++]);
>> +#ifdef HAVE_LD_STATIC_DYNAMIC
>> + if (static_libasan)
>> + generate_option (OPT_Wl_, LD_DYNAMIC_OPTION, 1, CL_DRIVER,
>> +&new_decoded_options[i++]);
>> +#endif
>> +
>> + *in_decoded_options_count = i;
>> + *in_decoded_options = new_decoded_options;
>> + *in_added_libraries = 1;
>> +}
>> +}
>> +
>> /* Create the vector `switches' and its contents.
>> Store its length in `n_switches'. */
>>
>> @@ -3695,6 +3769,11 @@ process_command (unsigned int decoded_options_count,
>> or an automatically created GCC_EXEC_PREFIX from
>> decoded_options[0].arg. */
>>
>> + /* Prepend command line before language-specific adjustment/addition of
>> + flags. */
>> + prepend_lang_specific_driver (&decoded_options, &decoded_options_count,
>> + &added_libraries);
>> +
>>/* Do language-specific adjustment/addition of flags. */
>>lang_specific_driver (&decoded_options, &decoded_options_count,
>> &added_libraries);
>
> PING.
>
> A simple testcase:
>
> [hjl@gnu-6 gcc]$ cat /tmp/bad.cc
> #include
>
> int
> main ()
> {
> int *buf = new int(30);
> buf[30]=1;
> return 0;
> }
> [hjl@gnu-6 gcc]$ ./release/usr/gcc-4.8.0/bin/g++ -fsanitize=address
> /tmp/bad.cc
> -static-libasan -static-libstdc++
> /export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libasan.a(asan_new_delete.o):
> In function `operator new(unsigned long)':
> /export/gnu/import/git/gcc/libsanitizer/asan/asan_new_delete.cc:41: multiple
> definition of `operator new(unsigned long)'
> /export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libstdc++.a(new_op.o):/export/gnu/import/git/gcc/libstdc++-v3/libsupc++/new_op.cc:45:
> first defin
[PATCH] Fix verify_node_sharing
For PHIs we call walk_tree with a function that expects to be
called from walk_gimple_op ...
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-01-11 Richard Biener
* tree-cfg.c (verify_node_sharing_1): Split out from ...
(verify_node_sharing): ... here.
(verify_gimple_in_cfg): Use verify_node_sharing_1 for walk_tree.
Index: gcc/tree-cfg.c
===
*** gcc/tree-cfg.c (revision 195103)
--- gcc/tree-cfg.c (working copy)
*** tree_node_can_be_shared (tree t)
*** 4462,4474
return false;
}
! /* Called via walk_gimple_stmt. Verify tree sharing. */
static tree
! verify_node_sharing (tree *tp, int *walk_subtrees, void *data)
{
! struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
! struct pointer_set_t *visited = (struct pointer_set_t *) wi->info;
if (tree_node_can_be_shared (*tp))
{
--- 4482,4493
return false;
}
! /* Called via walk_tree. Verify tree sharing. */
static tree
! verify_node_sharing_1 (tree *tp, int *walk_subtrees, void *data)
{
! struct pointer_set_t *visited = (struct pointer_set_t *) data;
if (tree_node_can_be_shared (*tp))
{
*** verify_node_sharing (tree *tp, int *walk
*** 4482,4487
--- 4501,4515
return NULL;
}
+ /* Called via walk_gimple_stmt. Verify tree sharing. */
+
+ static tree
+ verify_node_sharing (tree *tp, int *walk_subtrees, void *data)
+ {
+ struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
+ return verify_node_sharing_1 (tp, walk_subtrees, wi->info);
+ }
+
static bool eh_error_found;
static int
verify_eh_throw_stmt_node (void **slot, void *data)
*** verify_gimple_in_cfg (struct function *f
*** 4534,4540
for (i = 0; i < gimple_phi_num_args (phi); i++)
{
tree arg = gimple_phi_arg_def (phi, i);
! tree addr = walk_tree (&arg, verify_node_sharing, visited, NULL);
if (addr)
{
error ("incorrect sharing of tree nodes");
--- 4562,4569
for (i = 0; i < gimple_phi_num_args (phi); i++)
{
tree arg = gimple_phi_arg_def (phi, i);
! tree addr = walk_tree (&arg, verify_node_sharing_1,
!visited, NULL);
if (addr)
{
error ("incorrect sharing of tree nodes");
PING^2: [PATCH] Filter out -fsanitize=address if not in combined tree in libiberty
On Wed, Dec 12, 2012 at 6:20 AM, H.J. Lu wrote: > On Thu, Nov 29, 2012 at 9:40 AM, H.J. Lu wrote: >> Hi, >> >> When GCC is configured with --with-build-config="bootstrap-asan", all >> -flto tests will fail since -fsanitize=address is used to compile host >> libiberty, which is used to create liblto_plugin.so, and linker isn't >> compiled with -fsanitize=address. This patch filters out >> -fsanitize=address from CFLAGS if we aren't in a combined tree with >> binutils. OK to install? >> >> Thanks. >> >> H.J. >> --- >> 2012-11-21 H.J. Lu >> >> * Makefile.in (CFLAGS): Filter out -fsanitize=address if in GCC >> tree, but not in a combined tree with binutils. >> * configure.ac (COMBINED_TREE_FALSE): New AC_SUBST. >> * configure: Regenerated. >> > > PING. > PING. -- H.J.
PING^2: [PATCH Filter out -fsanitize=address if not in combined tree in lto-plugin
On Wed, Dec 12, 2012 at 6:21 AM, H.J. Lu wrote: > On Thu, Nov 29, 2012 at 9:38 AM, H.J. Lu wrote: >> Hi, >> >> When GCC is configured with --with-build-config="bootstrap-asan", all >> -flto tests will fail since -fsanitize=address is used to compile >> liblto_plugin.so and linker isn't compiled with -fsanitize=address. >> This patch filters out -fsanitize=address from CFLAGS if we aren't >> in a combined tree with binutils. OK to install? >> >> >> H.J. >> --- >> --- >> lto-plugin/Makefile.am| 7 +++ >> lto-plugin/Makefile.in| 5 + >> lto-plugin/configure | 18 +++--- >> lto-plugin/configure.ac | 4 >> 5 files changed, 39 insertions(+), 3 deletions(-) >> create mode 100644 lto-plugin/ChangeLog.asan >> >> 2012-11-21 H.J. Lu >> >> * Makefile.am (CFLAGS): Filter out -fsanitize=address if not >> in a combined tree of GCC and binutils. >> (LDFLAGS): Likewise. >> * configure.ac (COMBINED_TREE): New AM_CONDITIONAL. >> * Makefile.in: Regenerated. >> * configure: Likewise. >> > > PING. > PING. -- H.J.
Re: [patch,libgcc] Fix fixed-bit.c build warning
On Fri, Jan 11, 2013 at 4:16 AM, Georg-Johann Lay wrote: >> >> * fixed-bit.c (SATFRACT) : Only >> declare / set min_low, min_high if TO_MODE_UNSIGNED == 0. >> (SATFRACT) : Only declare / set min_low, >> min_high if FROM_MODE_UNSIGNED == 0 and TO_MODE_UNSIGNED == 0. This is OK. Thanks. Ian
Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg
On 01/11/2013 05:38 AM, Dodji Seketeli wrote: but when I read the code, it looks like this is not necessary. Am I missing something? In any case, I haven't put that code in the new coerce_innermost_template_parms. Is that OK? I agree that it seems unnecessary. But to be safe, let's leave lookup_template_class_1 alone until after 4.8 branches. Jason
Re: Mention of gcc 4.5 as first version with plugin support
On Thu, Jan 10, 2013 at 11:00 PM, Dave Johansen wrote: > 2013-01-10 Dave Johansen > > * gcc/doc/plugins.texi: Added gcc.4.5.0 or later note to > Plugins documentation. OK. Diego.
[RFC, middlend] Fix for PR54218
Hi, I am sending a patch which solves the debugging issue (PR 54218). The fix is to allocate stack space only once for parameters in expand pass. The patch is attached. Could someone suggest if its right ? Thanks, George 54218.patch Description: Binary data
Re: [RFC, middlend] Fix for PR54218
On Fri, Jan 11, 2013 at 8:17 AM, George Thomas
wrote:
> Hi,
>
> I am sending a patch which solves the debugging issue (PR 54218).
>
> The fix is to allocate stack space only once for parameters in expand pass.
>
> The patch is attached. Could someone suggest if its right ?
I have just a formatting issue:
+ if (TREE_CODE (SSA_NAME_VAR (var)) != PARM_DECL)
+ {
+if (!bitmap_bit_p (SA.partition_has_default_def, i))
I think it would have been better if you had done instead:
if (TREE_CODE (SSA_NAME_VAR (var)) != PARM_DECL
&& !bitmap_bit_p (SA.partition_has_default_def, i))
So there are no other white space changes.
Also missing a changelog entry too.
Thanks,
Andrew
Re: [PATCH] PR c++/55663 - constexpr function templ instantiation considered non-const as alias templ arg
Jason Merrill writes:
> On 01/11/2013 05:38 AM, Dodji Seketeli wrote:
>> but when I read the code, it looks like this is not necessary. Am I
>> missing something? In any case, I haven't put that code in the new
>> coerce_innermost_template_parms. Is that OK?
>
> I agree that it seems unnecessary. But to be safe, let's leave
> lookup_template_class_1 alone until after 4.8 branches.
OK, here are the patches I am proposing then. The first one is the one
I'd like to commit to 4.8 and the second one would be scheduled for 4.9
when its branch opens.
Is that OK?
gcc/cp/
PR c++/55663
* pt.c (coerce_innermost_template_parms): New static function.
(instantiate_alias_template): Use it here.
gcc/testsuite/
PR c++/55663
* g++.dg/cpp0x/alias-decl-31.C: New test.
---
gcc/cp/pt.c| 64 ++
gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C | 20 ++
2 files changed, 84 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 6d78dd2..62fa2d9 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -130,6 +130,8 @@ static tree tsubst_initializer_list (tree, tree);
static tree get_class_bindings (tree, tree, tree, tree);
static tree coerce_template_parms (tree, tree, tree, tsubst_flags_t,
bool, bool);
+static tree coerce_innermost_template_parms (tree, tree, tree, tsubst_flags_t,
+ bool, bool);
static void tsubst_enum(tree, tree, tree);
static tree add_to_template_args (tree, tree);
static tree add_outermost_template_args (tree, tree);
@@ -6742,6 +6744,61 @@ coerce_template_parms (tree parms,
return new_inner_args;
}
+/* Like coerce_template_parms. If PARMS represents all template
+ parameters levels, this function returns a vector of vectors
+ representing all the resulting argument levels. Note that in this
+ case, only the innermost arguments are coerced because the
+ outermost ones are supposed to have been coerced already.
+
+ Otherwise, if PARMS represents only (the innermost) vector of
+ parameters, this function returns a vector containing just the
+ innermost resulting arguments. */
+
+static tree
+coerce_innermost_template_parms (tree parms,
+ tree args,
+ tree in_decl,
+ tsubst_flags_t complain,
+ bool require_all_args,
+ bool use_default_args)
+{
+ int parms_depth = TMPL_PARMS_DEPTH (parms);
+ int args_depth = TMPL_ARGS_DEPTH (args);
+ tree coerced_args;
+
+ if (parms_depth > 1)
+{
+ coerced_args = make_tree_vec (parms_depth);
+ tree level;
+ int cur_depth;
+
+ for (level = parms, cur_depth = parms_depth;
+ parms_depth > 0 && level != NULL_TREE;
+ level = TREE_CHAIN (level), --cur_depth)
+ {
+ tree l;
+ if (cur_depth == args_depth)
+ l = coerce_template_parms (TREE_VALUE (level),
+ args, in_decl, complain,
+ require_all_args,
+ use_default_args);
+ else
+ l = TMPL_ARGS_LEVEL (args, cur_depth);
+
+ if (l == error_mark_node)
+ return error_mark_node;
+
+ SET_TMPL_ARGS_LEVEL (coerced_args, cur_depth, l);
+ }
+}
+ else
+coerced_args = coerce_template_parms (INNERMOST_TEMPLATE_PARMS (parms),
+ args, in_decl, complain,
+ require_all_args,
+ use_default_args);
+ return coerced_args;
+}
+
/* Returns 1 if template args OT and NT are equivalent. */
static int
@@ -14642,6 +14699,13 @@ instantiate_alias_template (tree tmpl, tree args,
tsubst_flags_t complain)
ggc_free (tinst);
return error_mark_node;
}
+
+ args =
+coerce_innermost_template_parms (DECL_TEMPLATE_PARMS (tmpl),
+args, tmpl, complain,
+/*require_all_args=*/true,
+/*use_default_args=*/true);
+
tree r = instantiate_template (tmpl, args, complain);
pop_tinst_level ();
/* We can't free this if a pending_template entry or last_error_tinst_level
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C
new file mode 100644
index 000..83eea47
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-31.C
@@ -0,0 +1,20 @@
+// Origin: PR c++/55663
+// { dg-do compile { target c++11 } }
+
+template
+constexpr bool the_truth () { return true; }
+
+template
+ struct Takes_bool { };
+
+template
+ using Alias = Takes_bool;
+
+template
+ struct test { using type = Alias()>; };
+
+int m
Re: Support for MIPS r5900
On Fri, 11 Jan 2013, Richard Sandiford wrote: > BTW Maciej, sorry to be prickly about this, but: where I live, "I insist" > has a very domineering ring to it, at least in this kind of context. > The implication tends to be that "having insisted, I really expect it to > happen, simply because it is _I_ who insisted". Maybe it's not the same > everywhere though. That's probably a shortcoming of my English skills -- sorry about that -- I didn't want to sound impolite or to insult anyone, especially you, Jürgen. Your contribution is very welcome even if there are minor issues there or some design decisions are not immediately obvious to everyone. Please feel free to disagree or argue if you think any opinion expressed does not convince you. Maciej
[PATCH, committed] Add '__' to __builtin_ia32_packssdw256 documentation
Another issue that was noticed was __builtin_ia32_packssdw256 did not have the initial '__'. I committed this patch as obvious to both the trunk and GCC 4.7. 2013-01-11 Michael Meissner * doc/extend.texi (X86 Built-in Functions): Add missing '__' in front of __builtin_ia32_packssdw256. Index: gcc/doc/extend.texi === --- gcc/doc/extend.texi (revision 195110) +++ gcc/doc/extend.texi (working copy) @@ -10430,7 +10430,7 @@ v32qi __builtin_ia32_mpsadbw256 (v32qi,v v32qi __builtin_ia32_pabsb256 (v32qi) v16hi __builtin_ia32_pabsw256 (v16hi) v8si __builtin_ia32_pabsd256 (v8si) -v16hi builtin_ia32_packssdw256 (v8si,v8si) +v16hi __builtin_ia32_packssdw256 (v8si,v8si) v32qi __builtin_ia32_packsswb256 (v16hi,v16hi) v16hi __builtin_ia32_packusdw256 (v8si,v8si) v32qi __builtin_ia32_packuswb256 (v16hi,v16hi) -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
[PATCH, committed] Fix whitespace issue in x86 builtin documentation
Somebody within IBM pointed out to me that the documentation for the x86 __builtin_ia32_padd256b and __builtin_ia32_pavgb256 were missing a space between the type and the __builtin name. I committed this patch as obvious to the trunk, and will update gcc 4.7 shortly. 2013-01-11 Michael Meissner * doc/extend.texi (X86 Built-in Functions): Add whitespace in __builtin_ia32_paddb256 and __builtin_ia32_pavgb256 documentation. Index: gcc/doc/extend.texi === --- gcc/doc/extend.texi (revision 195108) +++ gcc/doc/extend.texi (working copy) @@ -10434,7 +10434,7 @@ v16hi builtin_ia32_packssdw256 (v8si,v8s v32qi __builtin_ia32_packsswb256 (v16hi,v16hi) v16hi __builtin_ia32_packusdw256 (v8si,v8si) v32qi __builtin_ia32_packuswb256 (v16hi,v16hi) -v32qi__builtin_ia32_paddb256 (v32qi,v32qi) +v32qi __builtin_ia32_paddb256 (v32qi,v32qi) v16hi __builtin_ia32_paddw256 (v16hi,v16hi) v8si __builtin_ia32_paddd256 (v8si,v8si) v4di __builtin_ia32_paddq256 (v4di,v4di) @@ -10445,7 +10445,7 @@ v16hi __builtin_ia32_paddusw256 (v16hi,v v4di __builtin_ia32_palignr256 (v4di,v4di,int) v4di __builtin_ia32_andsi256 (v4di,v4di) v4di __builtin_ia32_andnotsi256 (v4di,v4di) -v32qi__builtin_ia32_pavgb256 (v32qi,v32qi) +v32qi __builtin_ia32_pavgb256 (v32qi,v32qi) v16hi __builtin_ia32_pavgw256 (v16hi,v16hi) v32qi __builtin_ia32_pblendvb256 (v32qi,v32qi,v32qi) v16hi __builtin_ia32_pblendw256 (v16hi,v16hi,int) -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: [Patch, Fortran] PR 55072: [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
Le 10/01/2013 20:39, Janus Weil a écrit : Ping! (What do we do with this little bugger?) @Paul: Was your comment 19 in the PR meant as an OK for my patch (submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html), or was it just a general agreement with the previous comments? FWIW, I regard the patch as a (conservative) improvement, thus certainly acceptable. For: >>> @@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * >>>this_array_result = false; >>>/* Passing address of the array if it is not pointer or >>> assumed-shape. */ >>> - if (full_array_var&& g77&& !this_array_result) >>> + if (full_array_var&& g77&& !this_array_result >>> +&& sym->ts.type != BT_DERIVED&& sym->ts.type != BT_CLASS) I would have used instead: && expr->expr_type == EXPR_VARIABLE && ref == NULL) to make the optimization available to variables of derived type. As we are now in stage4, your version should probably be preferred though. Regarding: Regarding the wrong code: I fear that some code involving non-BT_DERIVED could lead to wrong code, e.g. "a(:)%x". I don't have an example for that I don't think this can happen as the test for non-derived type is on the root symbol (`a' in your example). For other cases, to be honest, I can't make any sense of all the booleans interacting with each other in that code area (this_array_result, g77, contiguous vs. gfc_is_simply_contiguous, ...). Regarding the missed optimization, bah, maybe we can defer to 4.9+? Mikael
Re: [libgomp / Fortran, Patch] PR55884 - Add -fintrinsic-module-path= and use it
Le 07/01/2013 16:07, Tobias Burnus a écrit : diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c index e05b935..0e0a71d 100644 --- a/gcc/fortran/options.c +++ b/gcc/fortran/options.c @@ -845,6 +845,7 @@ gfc_handle_option (size_t scode, const char *arg, int value, break; case OPT_fintrinsic_modules_path: +case OPT_fintrinsic_modules_path_: gfc_add_intrinsic_modules_path (arg); break; There are two other uses of OPT_fintrinsic_modules_path, needing the same fix. > Build and regtested on x86-64-gnu-linux. > OK for the trunk? > OK with the change above. Mikael
Re: [RFC, middlend] Fix for PR54218
On Fri, Jan 11, 2013 at 9:53 PM, Andrew Pinski wrote:
> On Fri, Jan 11, 2013 at 8:17 AM, George Thomas
> wrote:
>> Hi,
>>
>> I am sending a patch which solves the debugging issue (PR 54218).
>>
>> The fix is to allocate stack space only once for parameters in expand pass.
>>
>> The patch is attached. Could someone suggest if its right ?
>
> I have just a formatting issue:
> + if (TREE_CODE (SSA_NAME_VAR (var)) != PARM_DECL)
> + {
> +if (!bitmap_bit_p (SA.partition_has_default_def, i))
>
> I think it would have been better if you had done instead:
> if (TREE_CODE (SSA_NAME_VAR (var)) != PARM_DECL
> && !bitmap_bit_p (SA.partition_has_default_def, i))
>
I have attached the updated patch with the changes suggested.
Also adding a dejagnu test case to reproduce the bug.
> So there are no other white space changes.
>
> Also missing a changelog entry too.
>
I am adding the change logs below.
2013-01-11 George Thomas
Senthil Kumar Selvaraj
PR middle-end/54218
* gcc/cfgexpand.c (expand_used_vars ) :Added
a step to not allocate stack space if its a parameter
* gcc.dg/pr54218.c : New test
Hoping that the changes are fine for trunk.
Thanks,
George
PR54218.patch
Description: Binary data
[PATCH] Avoid invalid sharing of ADDR_EXPRs (PR fortran/55935)
Hi!
As discussed in the PR, the extra verification of location blocks Richard
posted recently fails on some Fortran testcases. The problem is that
ADDR_EXPRs in static const var initializers contain locations (fixed by the
trans-expr.c hunks), and that gimple-fold makes the ADDR_EXPRs shared, so
even with the fortran FE hunks alone when the gimplifier sets location
we get invalid blocks anyway. In the PR we were discussing putting the
unshare_expr at the beginning of canonicalize_constructor_val, unfortunately
that breaks Ada bootstrap, because it is undesirable when record_reference
calls that function. So this alternative patch moves the unshare_expr calls
to gimple-fold.c canonicalize_constructor_val callers.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Alternatively the get_symbol_constant_value unshare_expr call could move
from canonicalize_constructor_val argument to return val; line, both
locations have some advantages and disadvantages (the one in patch might
create unnecessary garbage if canonicalize_constructor_val returns NULL
or non-min_invariant, the other way would create garbage with the trees
created by canonicalize_constructor_val itself (they would be created
and immediately unshared).
2013-01-11 Jakub Jelinek
PR fortran/55935
* gimple-fold.c (get_symbol_constant_value): Call
unshare_expr.
(fold_gimple_assign): Don't call unshare_expr here.
(fold_ctor_reference): Call unshare_expr.
* trans-expr.c (gfc_conv_structure): Call
unshare_expr_without_location on the ctor elements.
--- gcc/gimple-fold.c.jj2013-01-11 09:02:55.0 +0100
+++ gcc/gimple-fold.c 2013-01-11 15:42:52.485630537 +0100
@@ -202,7 +202,7 @@ get_symbol_constant_value (tree sym)
tree val = DECL_INITIAL (sym);
if (val)
{
- val = canonicalize_constructor_val (val, sym);
+ val = canonicalize_constructor_val (unshare_expr (val), sym);
if (val && is_gimple_min_invariant (val))
return val;
else
@@ -378,7 +378,7 @@ fold_gimple_assign (gimple_stmt_iterator
}
else if (DECL_P (rhs))
- return unshare_expr (get_symbol_constant_value (rhs));
+ return get_symbol_constant_value (rhs);
/* If we couldn't fold the RHS, hand over to the generic
fold routines. */
@@ -2941,7 +2941,7 @@ fold_ctor_reference (tree type, tree cto
/* We found the field with exact match. */
if (useless_type_conversion_p (type, TREE_TYPE (ctor))
&& !offset)
-return canonicalize_constructor_val (ctor, from_decl);
+return canonicalize_constructor_val (unshare_expr (ctor), from_decl);
/* We are at the end of walk, see if we can view convert the
result. */
@@ -2950,7 +2950,7 @@ fold_ctor_reference (tree type, tree cto
&& operand_equal_p (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (ctor)), 0))
{
- ret = canonicalize_constructor_val (ctor, from_decl);
+ ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
if (ret)
STRIP_NOPS (ret);
--- gcc/fortran/trans-expr.c.jj 2013-01-11 09:02:50.0 +0100
+++ gcc/fortran/trans-expr.c2013-01-11 10:43:54.071921147 +0100
@@ -6137,6 +6137,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
gfc_symbol *vtabs;
vtabs = cm->initializer->symtree->n.sym;
vtab = gfc_build_addr_expr (NULL_TREE, gfc_get_symbol_decl (vtabs));
+ vtab = unshare_expr_without_location (vtab);
CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, vtab);
}
else if (cm->ts.u.derived && strcmp (cm->name, "_size") == 0)
@@ -6150,6 +6151,7 @@ gfc_conv_structure (gfc_se * se, gfc_exp
TREE_TYPE (cm->backend_decl),
cm->attr.dimension, cm->attr.pointer,
cm->attr.proc_pointer);
+ val = unshare_expr_without_location (val);
/* Append it to the constructor list. */
CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
Jakub
Re: [patch, Fortran] PR 55806 - Inefficient ANY with array constructors
Le 01/01/2013 21:18, Thomas Koenig a écrit :
Hello world,
the attached patch replaces ANY(a, b, c) with a .or. b .or c,
leading to reduced execution time. It also handles ALL, PRODUCT
and SUM.
This fixes a bug noted by Michael Metcalf.
Regression-tested. OK for trunk?
A few comments below.
Mikael
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 194760)
+++ frontend-passes.c (Arbeitskopie)
@@ -180,7 +183,172 @@ optimize_expr (gfc_expr **e, int *walk_subtrees AT
return 0;
}
+/* Auxiliary function to handle the arguments to reduction intrnisics.
+ If the function is a scalar, just copy it; otherwise Returns the new
+ element, the old one can be freed. */
+static gfc_expr *
+copy_walk_reduction_arg (gfc_expr *e, gfc_expr *fn)
+{
+ gfc_expr *fcn;
+ const char *new_name;
+ gfc_actual_arglist *actual_arglist;
+
+ if (e->rank == 0 || e->expr_type == EXPR_FUNCTION)
+fcn = gfc_copy_expr (e);
+ else
+{
+ fcn = gfc_get_expr ();
+ fcn->expr_type = EXPR_FUNCTION;
+ fcn->value.function.isym = fn->value.function.isym;
+ actual_arglist = gfc_get_actual_arglist ();
+ actual_arglist->expr = gfc_copy_expr (e);
+ actual_arglist->next = gfc_get_actual_arglist ();
Another one is needed. I get a segmentation fault with SUM.
[...]
+
+/* Callback function for optimzation of reductions to scalars. Transform
+ ANY ([f1,f2,f3, ...]) to f1 .or. f2 .or. f3 .or. ..., with ANY,
+ SUM and PRODUCT correspondingly. Handly only the simple cases without
+ MASK and DIM. */
+
+static int
+callback_reduction (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data ATTRIBUTE_UNUSED)
+{
+ gfc_expr *fn, *arg;
+ gfc_intrinsic_op op;
+ gfc_isym_id id;
+ gfc_actual_arglist *a;
+ gfc_actual_arglist *dim;
+ gfc_constructor *c;
+ gfc_expr *res, *new_expr;
+
+ fn = *e;
+
+ if (fn->rank != 0 || fn->expr_type != EXPR_FUNCTION
+ || fn->value.function.isym == NULL)
+return 0;
+
+ id = fn->value.function.isym->id;
+
+ if (id != GFC_ISYM_SUM && id != GFC_ISYM_PRODUCT
+ && id != GFC_ISYM_ANY && id != GFC_ISYM_ALL)
+return 0;
+
+ a = fn->value.function.actual;
+
+ /* Don't handle MASK or DIM. */
+
+ dim = a->next;
+
+ if (dim != NULL)
+{
Minor, but I think you can assume dim != NULL. Same for mask.
+ gfc_actual_arglist *mask;
+
+ if (dim->expr != NULL)
+ return 0;
+
+ mask = dim->next;
+ if (mask != NULL)
+ if ( mask->expr != NULL)
+ return 0;
+}
+
+ arg = a->expr;
+
+ if (arg->expr_type != EXPR_ARRAY)
+return 0;
+
+ switch (id)
+{
+case GFC_ISYM_SUM:
+ op = INTRINSIC_PLUS;
+ break;
+
+case GFC_ISYM_PRODUCT:
+ op = INTRINSIC_TIMES;
+ break;
+
+case GFC_ISYM_ANY:
+ op = INTRINSIC_OR;
+ break;
+
+case GFC_ISYM_ALL:
+ op = INTRINSIC_AND;
+ break;
+
+default:
+ return 0;
+}
+
+ c = gfc_constructor_first (arg->value.constructor);
+
+ if (c == NULL)
+return 0;
+
+ res = copy_walk_reduction_arg (c->expr, fn);
+
+ c = gfc_constructor_next (c);
+ while (c)
+{
+ new_expr = gfc_get_expr ();
+ new_expr->ts = fn->ts;
+ new_expr->expr_type = EXPR_OP;
+ new_expr->rank = fn->rank;
+ new_expr->where = fn->where;
+ new_expr->value.op.op = op;
+ new_expr->value.op.op1 = res;
+ new_expr->value.op.op2 = copy_walk_reduction_arg (c->expr, fn);
+ res = new_expr;
+ c = gfc_constructor_next (c);
+}
+
+ gfc_simplify_expr (res, 0);
+ *e = res;
+ gfc_free_expr (fn);
+
+ /* We changed things from under the expression walker. Walking the
+ old tree would mess up things, so let's not do that. */
+ return 1;
I think this prevents any further reduction optimization. The following
variant of your test case doesn't avoid the temporary:
do i=1,3
if (any([abs(a(i,1) - b(i,1)) > acc, &
(j==i+1,j=3,8)])) cycle
if (any([abs(a(i,2) - b(i,2)) > acc, &
abs(a(i,3) - b(i,3)) > acc, lo(i,:)])) cycle
c = c + i
end do
Re: [Patch, Fortran] PR 55072: [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
Hi Mikael, >> Ping! (What do we do with this little bugger?) >> >> @Paul: Was your comment 19 in the PR meant as an OK for my patch >> (submitted here: http://gcc.gnu.org/ml/fortran/2012-12/msg00097.html), >> or was it just a general agreement with the previous comments? >> > FWIW, I regard the patch as a (conservative) improvement, thus certainly > acceptable. To be conservative was exactly my intention, since a) trunk is in stage 4 and b) I wanted something that is safe for backporting to 4.6 and 4.7 (where we certainly can not afford to introduce any new wrong-code regressions). @@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * this_array_result = false; /* Passing address of the array if it is not pointer or assumed-shape. */ - if (full_array_var&& g77&& !this_array_result) + if (full_array_var&& g77&& !this_array_result +&& sym->ts.type != BT_DERIVED&& sym->ts.type != BT_CLASS) > > I would have used instead: > && expr->expr_type == EXPR_VARIABLE && ref == NULL) > > to make the optimization available to variables of derived type. > As we are now in stage4, your version should probably be preferred though. Ok, I will leave it as it is then. > Regarding: > Regarding the wrong code: I fear that some code involving non-BT_DERIVED could lead to wrong code, e.g. "a(:)%x". I don't have an example for that >>> > I don't think this can happen as the test for non-derived type is on the > root symbol (`a' in your example). For other cases, to be honest, I can't > make any sense of all the booleans interacting with each other in that code > area (this_array_result, g77, contiguous vs. gfc_is_simply_contiguous, ...). > > Regarding the missed optimization, bah, maybe we can defer to 4.9+? Yes, certainly the upcoming release should better produce code that is fully correct, rather than "fast but wrong" ;) Thanks for your review (which I read as an OK for all branches, right?). Will commit soon. Cheers, Janus
Re: [Patch, libfortran] Improve performance of byte swapped IO
PING.
Slightly updated patch attached, which further improves the generic
size fallback that is used when the element size is not 2/4/8 bytes.
Changing the us_perf benchmark to use real(10), with the v2 patch the
performance is:
Unformatted sequential write/read performance test
Record size Write MB/s Read MB/s
==
4 59.02855042952208586.019754350948787
8 79.02832706313059095.803502000733374
16 99.980457395413296138.68367462874946
32 122.56886206338788180.05609910155042
64 152.00478266944486212.69931319407567
128 197.74137934940202235.19728791956828
256 155.36245780017779244.60578379215929
512 157.13385845966246245.07467397691480
1024 177.26553799130201260.44908357795623
2048 208.22852888945587260.21587143113527
4096 222.88410474980634262.66162209490591
8192 226.71167580652920265.81191407123663
16384 206.51818241747065263.59395165591724
32768 230.18707026455866265.88990325026526
65536 229.19783089391504268.04485112932684
131072 231.1221566209267.40543904427710
262144 230.72012123598142267.60086931504122
524288 230.48959460456055268.78750211303725
With the new v3 patch I get
Unformatted sequential write/read performance test
Record size Write MB/s Read MB/s
==
4 59.77906112123994192.777125264010024
8 92.727504266051341126.64775563782673
16 128.94793911163904184.69194300482837
32 169.78916283536847267.06752001266767
64 209.50296476919556341.60515130910238
128 236.36709738360679416.73212655882151
256 251.79029695383340465.46804746749740
512 259.62269939828633500.87346060356265
1024 265.08842337586458508.95530627428275
2048 268.71795530051884532.12211365683640
4096 280.86546884821030546.88907054369884
8192 286.96049684823578569.60958187426183
16384 292.04368984868103608.11503416324865
32768 292.96677387959392629.80651297065833
65536 291.69098580137114624.27103478079641
131072 292.75666234956418605.99766136491496
262144 291.35520038228975611.59061455535834
524288 292.15446100501691623.76232623081580
On Sat, Jan 5, 2013 at 11:13 PM, Janne Blomqvist
wrote:
> On Sat, Jan 5, 2013 at 5:35 PM, Richard Biener
> wrote:
>> On Fri, Jan 4, 2013 at 11:35 PM, Andreas Schwab
>> wrote:
>>> Janne Blomqvist writes:
>>>
diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index c8ecc3a..bf2250a 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -140,15 +140,21 @@ unformatted_backspace (st_parameter_filepos *fpp,
gfc_unit *u)
}
else
{
+ uint32_t u32;
+ uint64_t u64;
switch (length)
{
case sizeof(GFC_INTEGER_4):
- reverse_memcpy (&m4, p, sizeof (m4));
+ memcpy (&u32, p, sizeof (u32));
+ u32 = __builtin_bswap32 (u32);
+ m4 = *(GFC_INTEGER_4*)&u32;
>>>
>>> Isn't that an aliasing violation?
>>
>> It looks like one. Why not simply do
>>
>>m4 = (GFC_INTEGER_4) u32;
>>
>> ? I suppose GFC_INTEGER_4 is always the same size as uint32_t but signed?
>
> Yes, GFC_INTEGER_4 is a typedef for int32_t. As for why I didn't do
> the above, C99 6.3.1.3(3) says that if the unsigned value is outside
> the range of the signed variable, the result is
> implementation-defined. Though I suppose the sensible
> "implementation-defined behavior" in this case on a two's complement
> target is to just do a bitwise copy.
>
> Anyway, to be really safe one could use memcpy instead; the compiler
> optimizes small fixed size memcpy's just fine. Updated patch attached.
>
>
> --
> Janne Blomqvist
--
Janne Blomqvist
bswap3.diff
Description: Binary data
Re: Mention of gcc 4.5 as first version with plugin support
On Fri, 11 Jan 2013 09:58:49 +0100
Dodji Seketeli wrote:
> Thank you Dave for this documentation patch that looks OK to my casual
> eyes. Let's CC the documentation maintainers.
>
> Dave Johansen a écrit:
>
> >
> > +GCC plugin support is available in GCC version 4.5.0 and
> > +later.
Maybe we should say that a later version is preferable.
IIRC 4.5 plugin support was not very good -it was more an experimental stage
than
anything else. I believe that we should not encourage people to write plugins
against
4.5.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: [Patch, Fortran] PR 55072: [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
Le 11/01/2013 21:31, Janus Weil a écrit : Thanks for your review (which I read as an OK for all branches, right?). Well, from my point of view it is OK, but I was actually hoping Tobias would ack it himself.
Re: [Patch, Fortran] PR 55072: [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
To be clear - I was awaiting a formal submission but indicating that I would OK it when it was made. I completely missed the posting of 16th December. OK by me for trunk, followed by 4.6 and 4.7. Cheers Paul On 11 January 2013 21:51, Mikael Morin wrote: > Le 11/01/2013 21:31, Janus Weil a écrit : > >> Thanks for your review (which I read as an OK for all branches, >> right?). >> > Well, from my point of view it is OK, but I was actually hoping Tobias would > ack it himself. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[lra] resync with trunk
Hello Vlad, The attached patch back-ports to the LRA branch (or foward-ports, depending on how you look at it :-) all the changes made on the trunk to LRA. Bootstrapped&tested on powerpc64-unknown-linux-gnu[1] and ia64-unknown-linux-gnu[2], and cross-built and tested mipsisa64-elf [3]. [1] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01098.html [2] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01129.html [3] http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01120.html OK for the LRA branch? Thanks, Ciao! Steven lra_trunk_resync.diff Description: Binary data
