Re: [PATCH] x86: emit tzcnt unconditionally
On Mon, May 7, 2012 at 7:43 AM, Jakub Jelinek ja...@redhat.com wrote:
Index: i386.md
===
--- i386.md (revision 187217)
+++ i386.md (working copy)
@@ -12112,9 +12112,22 @@
(set (match_operand:SWI48 0 register_operand =r)
(ctz:SWI48 (match_dup 1)))]
- bsf{imodesuffix}\t{%1, %0|%0, %1}
+{
+ if (optimize_function_for_size_p (cfun))
+ return bsf{imodesuffix}\t{%1, %0|%0, %1};
+ else if (TARGET_BMI)
+ return tzcnt{imodesuffix}\t{%1, %0|%0, %1};
+ else
+ /* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI. */
+ return rep; bsf{imodesuffix}\t{%1, %0|%0, %1};
+}
Shouldn't that be done only for generic tuning? If somebody uses
-mtune=native, then emitting rep; bsf is overkill, the code is intended
to be run on a CPU without (or with TARGET_BMI with) tzcnt insn support.
Yes, this is a good idea.
Something like attached patch?
Thanks,
Uros.
Index: i386.md
===
--- i386.md (revision 187223)
+++ i386.md (working copy)
@@ -12114,18 +12114,22 @@
{
if (optimize_function_for_size_p (cfun))
-return bsf{imodesuffix}\t{%1, %0|%0, %1};
+;
else if (TARGET_BMI)
return tzcnt{imodesuffix}\t{%1, %0|%0, %1};
- else
+ else if (TARGET_GENERIC)
/* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI. */
return rep; bsf{imodesuffix}\t{%1, %0|%0, %1};
+
+ return bsf{imodesuffix}\t{%1, %0|%0, %1};
}
[(set_attr type alu1)
(set_attr prefix_0f 1)
(set (attr prefix_rep)
(if_then_else
- (match_test optimize_function_for_size_p (cfun))
+ (and (match_test optimize_function_for_size_p (cfun))
+ (not (ior (match_test TARGET_BMI)
+ (match_test TARGET_GENERIC
(const_string 0)
(const_string 1)))
(set_attr mode MODE)])
@@ -12137,18 +12141,22 @@
{
if (optimize_function_for_size_p (cfun))
-return bsf{imodesuffix}\t{%1, %0|%0, %1};
+;
else if (TARGET_BMI)
return tzcnt{imodesuffix}\t{%1, %0|%0, %1};
- else
+ else if (TARGET_GENERIC)
/* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI. */
return rep; bsf{imodesuffix}\t{%1, %0|%0, %1};
+
+ return bsf{imodesuffix}\t{%1, %0|%0, %1};
}
[(set_attr type alu1)
(set_attr prefix_0f 1)
(set (attr prefix_rep)
(if_then_else
- (match_test optimize_function_for_size_p (cfun))
+ (and (match_test optimize_function_for_size_p (cfun))
+ (not (ior (match_test TARGET_BMI)
+ (match_test TARGET_GENERIC
(const_string 0)
(const_string 1)))
(set_attr mode MODE)])
Re: [PATCH] x86: emit tzcnt unconditionally
On Mon, May 07, 2012 at 09:36:38AM +0200, Uros Bizjak wrote:
On Mon, May 7, 2012 at 7:43 AM, Jakub Jelinek ja...@redhat.com wrote:
Index: i386.md
===
--- i386.md (revision 187217)
+++ i386.md (working copy)
@@ -12112,9 +12112,22 @@
(set (match_operand:SWI48 0 register_operand =r)
(ctz:SWI48 (match_dup 1)))]
- bsf{imodesuffix}\t{%1, %0|%0, %1}
+{
+ if (optimize_function_for_size_p (cfun))
+ return bsf{imodesuffix}\t{%1, %0|%0, %1};
+ else if (TARGET_BMI)
+ return tzcnt{imodesuffix}\t{%1, %0|%0, %1};
+ else
+ /* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI. */
+ return rep; bsf{imodesuffix}\t{%1, %0|%0, %1};
+}
Shouldn't that be done only for generic tuning? If somebody uses
-mtune=native, then emitting rep; bsf is overkill, the code is intended
to be run on a CPU without (or with TARGET_BMI with) tzcnt insn support.
Yes, this is a good idea.
Something like attached patch?
Yeah, but probably with the TARGET_BMI and optimize_function_for_size_p
lines swapped.
Because i386.h defines
CTZ_DEFINED_VALUE_AT_ZERO to 1 for TARGET_BMI, therefore it isn't
undefined for TARGET_BMI, so even for -Os you can't just use bsf.
Jakub
Re: [Patch, Fortran] PR53255 - fix type-bound operator handling
Hi Tobias, Nice call! Apart from s/wronly/wrongly/ in the testcase, this is certainly OK for trunk and, I would suggest, as far back as you have the intestinal fortitude to go. I suspect, without checking, that the patch might not do the right thing on 4.5. Thanks for the patch for what you carrectly describe as a nasty wrong code bug. Cheers Paul On 6 May 2012 19:05, Tobias Burnus bur...@net-b.de wrote: Dear all, if one uses TYPE(extended), the overridden specific procedure (trace_ext to the TBP trace) associated with an operator (.tr.) is not called - but the TBP of the base type. It correctly works for polymorphic types. Build and regtested on x86-64-linux. OK for the trunk? As it is a nasty wrong-code bug (but no regression), I wonder whether it should be backported - and, if so, to which version - 4.7 only? (Affected are GCC 4.5 to 4.8.) Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PATCH] Make sizetypes no longer sign-extending
Sure, no opposition by me to applying the whole set of patches.
Done now.
This has introduced a couple of ACATS failures on x86:
FAIL: c52102a
FAIL: c52102c
The problem is that a builtin_memmove is wrongly folded into an assignment
between MEM_EXPRs, although source and destination are slices which overlap.
In fold_builtin_memory_op:
(gdb) p debug_generic_expr(destvar)
a[0 ...]{lb: 4294967292 sz: 4}
$14 = void
(gdb) p debug_generic_expr(dest_base)
a
$15 = void
(gdb) p dest_offset
$16 = -137438953344
get_ref_base_and_extent (unlike get_inner_reference) doesn't correctly compute
the offset for ARRAY_REF/ARRAY_RANGE_REF. The code is also duplicated in
fold_const_aggregate_ref_1. Fixing this yields another ACATS failure:
FAIL: cd2a31a
because fold_array_ctor_reference needs to be adjusted backwards for the now
correct offset computed by get_ref_base_and_extent.
Tentative fix attached. Tested on x86_64-suse-linux and i586-suse-linux.
2012-05-07 Eric Botcazou ebotca...@adacore.com
* tree-dfa.c (get_ref_base_and_extent) ARRAY_REF: Do the offset
computation using the precision of the index type.
* gimple-fold.c (fold_const_aggregate_ref_1) ARRAY_REF: Likewise.
(fold_array_ctor_reference): Do index computations in the index type.
--
Eric Botcazou
Index: gimple-fold.c
===
--- gimple-fold.c (revision 187216)
+++ gimple-fold.c (working copy)
@@ -2745,7 +2745,7 @@ fold_array_ctor_reference (tree type, tr
double_int low_bound, elt_size;
double_int index, max_index;
double_int access_index;
- tree domain_type = NULL_TREE;
+ tree domain_type = NULL_TREE, index_type = NULL_TREE;
HOST_WIDE_INT inner_offset;
/* Compute low bound and elt size. */
@@ -2755,6 +2755,7 @@ fold_array_ctor_reference (tree type, tr
{
/* Static constructors for variably sized objects makes no sense. */
gcc_assert (TREE_CODE (TYPE_MIN_VALUE (domain_type)) == INTEGER_CST);
+ index_type = TREE_TYPE (TYPE_MIN_VALUE (domain_type));
low_bound = tree_to_double_int (TYPE_MIN_VALUE (domain_type));
}
else
@@ -2778,6 +2779,10 @@ fold_array_ctor_reference (tree type, tr
access_index = double_int_udiv (uhwi_to_double_int (offset / BITS_PER_UNIT),
elt_size, TRUNC_DIV_EXPR);
access_index = double_int_add (access_index, low_bound);
+ if (index_type)
+access_index = double_int_ext (access_index,
+ TYPE_PRECISION (index_type),
+ TYPE_UNSIGNED (index_type));
/* And offset within the access. */
inner_offset = offset % (double_int_to_uhwi (elt_size) * BITS_PER_UNIT);
@@ -2788,6 +2793,11 @@ fold_array_ctor_reference (tree type, tr
return NULL_TREE;
index = double_int_sub (low_bound, double_int_one);
+ if (index_type)
+index = double_int_ext (index,
+ TYPE_PRECISION (index_type),
+ TYPE_UNSIGNED (index_type));
+
FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (ctor), cnt, cfield, cval)
{
/* Array constructor might explicitely set index, or specify range
@@ -2805,7 +2815,14 @@ fold_array_ctor_reference (tree type, tr
}
}
else
- max_index = index = double_int_add (index, double_int_one);
+ {
+ index = double_int_add (index, double_int_one);
+ if (index_type)
+ index = double_int_ext (index,
+TYPE_PRECISION (index_type),
+TYPE_UNSIGNED (index_type));
+ max_index = index;
+ }
/* Do we have match? */
if (double_int_cmp (access_index, index, 1) = 0
@@ -2960,18 +2977,23 @@ fold_const_aggregate_ref_1 (tree t, tree
if (TREE_CODE (TREE_OPERAND (t, 1)) == SSA_NAME
valueize
(idx = (*valueize) (TREE_OPERAND (t, 1)))
- host_integerp (idx, 0))
+ TREE_CODE (idx) == INTEGER_CST)
{
tree low_bound, unit_size;
+ double_int doffset;
/* If the resulting bit-offset is constant, track it. */
if ((low_bound = array_ref_low_bound (t),
- host_integerp (low_bound, 0))
+ TREE_CODE (low_bound) == INTEGER_CST)
(unit_size = array_ref_element_size (t),
- host_integerp (unit_size, 1)))
+ host_integerp (unit_size, 1))
+ (doffset = double_int_sext
+ (double_int_sub (TREE_INT_CST (idx),
+ TREE_INT_CST (low_bound)),
+ TYPE_PRECISION (TREE_TYPE (idx))),
+ double_int_fits_in_shwi_p (doffset)))
{
- offset = TREE_INT_CST_LOW (idx);
- offset -= TREE_INT_CST_LOW (low_bound);
+ offset = double_int_to_shwi (doffset);
offset *= TREE_INT_CST_LOW (unit_size);
offset *= BITS_PER_UNIT;
Index: tree-dfa.c
===
--- tree-dfa.c (revision 187216)
+++ tree-dfa.c (working copy)
@@ -814,21 +814,24 @@ get_ref_base_and_extent (tree exp, HOST_
{
tree index = TREE_OPERAND (exp, 1);
tree low_bound, unit_size;
+ double_int doffset;
/* If the resulting bit-offset is constant, track it.
Re: [Fortran, patch] PR 52158 - Regression on character function with gfortran 4.7
Hello,
On 05/06/2012 09:37 PM, Alessandro Fanfarillo wrote:
The patch is bootstrapped and tested on x86_64-unknown-linux-gnu - gcc
version 4.8.0 20120506 (experimental)
2012-05-06 Alessandro Fanfarillofanfarillo@gmail.com
Paul Thomaspa...@gcc.gnu.org
Tobias Burnusbur...@net-b.de
PR fortran/52158
* resolve.c (resolve_fl_derived0): Add a new condition in the if
statement of the deferred-length character component error block.
* trans-expr (gfc_conv_procedure_call): Add new checks in the if
statement on component's attributes (regarding PR 45170).
Typo: trans-expr - trans-expr.c.
Well, either the second PR is related to the commit - then one should have
PR fortran/52158
PR fortran/45170
- or it is only that vaguely related that one should only mention it in
the patch submittal email.
As it fixes an ICE mentioned in PR 45170, I would add it. (I think one
should close that PR, create PRs for the remaining issues and possibly a
meta bug for tracking. That PR is really a mess.)
The description Add new checks in the if statement on component's
attributes is true but it makes the implicit assumption that the reader
knows that the commit is about ts.deferred. I had written something
like the following:
* resolve.c (resolve_fl_derived0): Allow TBPs with deferred-length
results.
* trans-expr (gfc_conv_procedure_call): Handle TBP with deferred-length
results.
I am sure one can write a nicer ChangeLog text, but at least it points
to TBP (type-bound procedures) and to functions which have
deferred-length-character result variable. (Actually, procedure-pointer
components are also affected.)
2012-05-06 Alessandro Fanfarillofanfarillo@gmail.com
Damian Rousondam...@rouson.net
PR fortran/45170
Typically, the bug reporters are only acknowledged via the PR itself
(and sometimes via a comment in the test case). That should be sufficient.
Additionally, you should quote the same PRs as in the actual patch
(fortran/ChangeLog). The test case tests that PR 52158 is fixed - and it
tests that the bug reported in comment 19 of PR 45170 is solved.
- if (ts.deferred (sym-attr.allocatable || sym-attr.pointer))
+ if (ts.deferred ((!comp (sym-attr.allocatable
+ || sym-attr.pointer)) || (comp (comp-attr.allocatable
+ || comp-attr.pointer
The spacing is wrong: You have a 14 before the || but you should
have 1 tab followed by 6 spaces. (I don't think that this is a problem
of the email client as the if line still have a tab.)
Additionally, the line breaks have been wrongly placed; it should be:
+ if (ts.deferred
+ ((!comp (sym-attr.allocatable || sym-attr.pointer))
+ || (comp (comp-attr.allocatable || comp-attr.pointer
That way one sees more easily which belongs together. The is below
ts; the || is one to the right of the ( to which this part of the
expression belongs.
--- gcc-4.8/gcc/testsuite/gfortran.dg/deferred_type_param_3.f90 1970-01-01
01:00:00.0 +0100
+++ gcc-4.8-patched/gcc/testsuite/gfortran.dg/deferred_type_param_3.f90
2012-05-06
19:26:29.498829273 +0200
@@ -0,0 +1,21 @@
+! { dg-do compile }
+!
+! PR fortran/45170
As above: You should also list PR fortran/52158.
As I realized when looking at the ChangeLog: Proc pointers are also
affected. I think one could append the following code to the test case,
which gives the same error without the patch. (Untested with the patch.)
module test
implicit none
type t
procedure(deferred_len), pointer, nopass :: ppt
end type t
contains
function deferred_len()
character(len=:), allocatable :: deferred_len
deferred_len = 'abc'
end function deferred_len
subroutine doIt()
type(t) :: x
x%ppt = deferred_len
if (abc /= x%ppt()) call abort ()
end subroutine doIt
end module test
use test
call doIt ()
end
Otherwise, the patch looks OK.
Thanks for the contribution - and congratulation to your first GCC patch.
Tobias
PS: For bean counters: There is a GCC copyright assignment entry for
Alessandro since 2012-04-18.
Re: [Patch, Fortran] PR53255 - fix type-bound operator handling
Hi, Nice call! Apart from s/wronly/wrongly/ in the testcase, this is certainly OK for trunk and, I would suggest, as far back as you have the intestinal fortitude to go. I suspect, without checking, that the patch might not do the right thing on 4.5. agreed. Apart from the fact that the patch might not even be applicable for 4.5, which I'm sure of (without checking), the 4.5 release was never recommended for serious OOP applications, and many thing just don't work there (since it was our first experimental OOP release). Therefore I think it's not worth going further back than 4.6. Thanks for the patch, Janus On 6 May 2012 19:05, Tobias Burnus bur...@net-b.de wrote: Dear all, if one uses TYPE(extended), the overridden specific procedure (trace_ext to the TBP trace) associated with an operator (.tr.) is not called - but the TBP of the base type. It correctly works for polymorphic types. Build and regtested on x86-64-linux. OK for the trunk? As it is a nasty wrong-code bug (but no regression), I wonder whether it should be backported - and, if so, to which version - 4.7 only? (Affected are GCC 4.5 to 4.8.) Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [Fortran, patch] PR 52158 - Regression on character function with gfortran 4.7
Hi Alessandro, my name is Alessandro, I'm a newbie of GCC and helped by Tobias Burnus and Paul Thomas I'll try to add support for final subroutines. since Tobias already reviewed your patch, I just want to say: Welcome to the team :) We're certainly looking forward to your contributions! Having final subroutines in gfortran will be great progress. Btw, one thing that you may want to look into on your way to FINAL is proper deallocation of polymorphic variables(cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321). This is one thing which is still missing in our OOP implementation, and it's serious in the sense that almost any sensible OOP program produces memory leaks with gfortran right now. It is not exactly a prerequisite to FINAL, but at least similar in spirit. Maybe both features can even be implemented with similar techniques. I actually had some plans to implement it myself, but currently I'm not able to spend large amounts of time on gfortran (unfortunately). In any case, I wish you all the best for your efforts ... Cheers, Janus
Re: [PATCH] Make sizetypes no longer sign-extending
On Mon, 7 May 2012, Eric Botcazou wrote:
Sure, no opposition by me to applying the whole set of patches.
Done now.
This has introduced a couple of ACATS failures on x86:
FAIL: c52102a
FAIL: c52102c
The problem is that a builtin_memmove is wrongly folded into an assignment
between MEM_EXPRs, although source and destination are slices which overlap.
In fold_builtin_memory_op:
(gdb) p debug_generic_expr(destvar)
a[0 ...]{lb: 4294967292 sz: 4}
$14 = void
(gdb) p debug_generic_expr(dest_base)
a
$15 = void
(gdb) p dest_offset
$16 = -137438953344
get_ref_base_and_extent (unlike get_inner_reference) doesn't correctly
compute
the offset for ARRAY_REF/ARRAY_RANGE_REF. The code is also duplicated in
fold_const_aggregate_ref_1. Fixing this yields another ACATS failure:
FAIL: cd2a31a
because fold_array_ctor_reference needs to be adjusted backwards for the now
correct offset computed by get_ref_base_and_extent.
Tentative fix attached. Tested on x86_64-suse-linux and i586-suse-linux.
Yeah, this kind of fallout is expected.
The patch is ok.
Thanks,
Richard.
Re: strengthen protection against REG_EQUIV/EQUAL on !REG set
Richard Sandiford rdsandif...@googlemail.com writes:
Olivier Hainque hain...@adacore.com writes:
Hello Richard,
Re $subject, at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01515.html
You suggested:
Would be nice to use a single function that knows about the extra
contraints here. Maybe something like the attached?
2012-04-24 ...
* rtl.h (set_for_reg_notes): Declare.
* emit-rtl.c (set_for_reg_notes): New function.
(set_unique_reg_note): Use it.
* optabs.c (add_equal_note): Likewise.
I had answered:
Looks cleaner indeed. Do you want me to test ?
I gave it a try. Your patch bootstraps and regtests fine on mainline for
x86-linux.
Sorry, was going to test this earlier, but got distracted by
lower-subreg stuff. I need to fix the subreg handling so that
we check whether the inner part of a SUBREG is a REG (done in
my copy at home). I also wanted to make sure there were no
asm differences due to notes being wrongly dropped.
So I tried compiling some recent cc1 .ii files on x86_64 at -O2.
The only differences were in fixed-value.ii. In this case we
used to create:
---
(insn 899 898 900 68 (parallel [
(set (reg/f:DI 597)
(plus:DI (reg/f:DI 20 frame)
(const_int -32 [0xffe0])))
(clobber (reg:CC 17 flags))
]) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:568 252 {*adddi_1}
(nil))
(insn 900 899 901 72 (parallel [
(set (reg:DI 598)
(plus:DI (reg:DI 597)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:568 -1
(nil))
(insn 901 900 902 72 (set (mem/f:DI (plus:DI (reg/f:DI 56 virtual-outgoing-args)
(const_int 24 [0x18])) [0 S8 A64])
(reg:DI 598)) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:568 -1
(expr_list:REG_EQUAL (plus:DI (reg:DI 597)
(const_int 8 [0x8]))
(nil)))
[...other uses of 597...]
(insn 921 920 922 73 (parallel [
(set (reg:DI 604)
(plus:DI (reg:DI 603)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:580 -1
(nil))
---
where 901 has a REG_EQUAL note against a MEM. cse1 changes the note to:
---
(insn 901 900 902 68 (set (mem/f:DI (plus:DI (reg/f:DI 7 sp)
(const_int 24 [0x18])) [0 S8 A64])
(reg/f:DI 598)) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:568 62
{*movdi_internal_rex64}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -24 [0xffe8]))
(nil)))
---
but doesn't touch 921 (probably worth finding out why). cse2 then sees
this note and records it as having the same value as both the MEM and
reg 598. So when it comes to insn 921 and replaces the source with reg 598,
it also adds a note:
---
(insn 921 1285 939 71 (set (reg/f:DI 698)
(reg/f:DI 598)) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:580 62
{*movdi_internal_rex64}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -24 [0xffe8]))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
---
Reload is then able to use this information to drop the 698 and
rematerialise it where necessary. After the patch we just get:
---
(insn 921 1285 939 71 (set (reg/f:DI 698)
(reg/f:DI 598)) /home/richards/gcc/HEAD/gcc/gcc/fixed-value.c:580 62
{*movdi_internal_rex64}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
---
The problem here seems to be some inconsistency about what is considered
constant in cse. The condition for table elements is:
elt-is_const = (CONSTANT_P (x) || fixed_base_plus_p (x));
But the condition for values that been calculated through folding
(e.g. because no note exists) is:
if (src_const == 0
(CONSTANT_P (src_folded)
/* Consider (minus (label_ref L1) (label_ref L2)) as
constant here so we will record it. This allows us
to fold switch statements when an ADDR_DIFF_VEC is used. */
|| (GET_CODE (src_folded) == MINUS
GET_CODE (XEXP (src_folded, 0)) == LABEL_REF
GET_CODE (XEXP (src_folded, 1)) == LABEL_REF)))
src_const = src_folded, src_const_elt = elt;
Don't use DWARF 4 on Solaris
Solaris bootstrap on mainline is currently broken with the native
linker: linking stage1 libgcc_s.so fails like this:
ld: fatal: unwind table: file _divdi3_s.o: section .eh_frame: bad cie version
0: offset 0x20
It turns out that ld cannot handle CIE version 3. The wrong error message
nonwithstanding, it requires CIE version 1.
CR 7166576 (ld/elfdump need to support DWARF-4) has been filed for this
issue and adding proper DWARF-3/4 support is under investigation by the
linker maintainers.
For the time being, I work around this as on Darwin by defaulting to
DWARF-2 unless something else is specified explicitly. For consistency,
I'm doing this always, even if using GNU ld, which could be
reconsidered.
Bootstrapped on i386-pc-solaris2.{9, 10, 11} and sparc-sun-solaris2.{9,
10, 11} with as/ld, gas/ld, gas/gld, installed on mainline.
Rainer
2012-05-04 Rainer Orth r...@cebitec.uni-bielefeld.de
* config/sol2.c (solaris_override_options): New function.
* config/sol2-protos.h (solaris_override_options): Declare.
* config/sol2.h (SUBTARGET_OVERRIDE_OPTIONS): Define.
# HG changeset patch
# Parent 9ee70e3b93194a9a802f878a7502ae5e5519c180
Don't use DWARF 4 on Solaris
diff --git a/gcc/config/sol2-protos.h b/gcc/config/sol2-protos.h
--- a/gcc/config/sol2-protos.h
+++ b/gcc/config/sol2-protos.h
@@ -1,6 +1,6 @@
/* Operating system specific prototypes to be used when targeting GCC for any
Solaris 2 system.
- Copyright 2004, 2007, 2010, 2011 Free Software Foundation, Inc.
+ Copyright 2004, 2007, 2010, 2011, 2012 Free Software Foundation, Inc.
This file is part of GCC.
@@ -24,6 +24,7 @@ extern void solaris_elf_asm_comdat_secti
extern void solaris_file_end (void);
extern void solaris_insert_attributes (tree, tree *);
extern void solaris_output_init_fini (FILE *, tree);
+extern void solaris_override_options (void);
/* In sol2-c.c. */
extern void solaris_register_pragmas (void);
diff --git a/gcc/config/sol2.c b/gcc/config/sol2.c
--- a/gcc/config/sol2.c
+++ b/gcc/config/sol2.c
@@ -1,5 +1,6 @@
/* General Solaris system support.
- Copyright (C) 2004, 2005 , 2007, 2010, 2011 Free Software Foundation, Inc.
+ Copyright (C) 2004, 2005 , 2007, 2010, 2011, 2012
+ Free Software Foundation, Inc.
Contributed by CodeSourcery, LLC.
This file is part of GCC.
@@ -282,3 +283,12 @@ solaris_file_end (void)
htab_traverse (solaris_comdat_htab, solaris_define_comdat_signature, NULL);
}
+
+void
+solaris_override_options (void)
+{
+ /* Don't emit DWARF3/4 unless specifically selected. Solaris ld cannot
+ handle CIE version 3 in .eh_frame. */
+ if (!global_options_set.x_dwarf_version)
+dwarf_version = 2;
+}
diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -99,6 +99,12 @@ along with GCC; see the file COPYING3.
TARGET_SUB_OS_CPP_BUILTINS(); \
} while (0)
+#define SUBTARGET_OVERRIDE_OPTIONS \
+ do { \
+solaris_override_options (); \
+ } while (0)
+
+
/* It's safe to pass -s always, even if -g is not used. Those options are
handled by both Sun as and GNU as. */
#define ASM_SPEC_BASE \
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[libatomic] Don't include XCFLAGS in CFLAGS
Solaris 10 and 11/x86 bootstrap is currently broken configuring the 64-bit libatomic: configure aborts with configure:3499: /var/gcc/regression/trunk/11-gcc/build/./gcc/xgcc -B/var/gcc/regression/trunk/11-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -m64 -g -O2 -march=i486 -mtune=i386 -fomit-frame-pointer conftest.c 5 conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set /* confdefs.h */ ^ conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set /* confdefs.h */ ^ configure:3503: $? = 1 configure:3540: result: configure: failed program was: [...] configure:3546: error: in `/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/amd64/libatomic': configure:3549: error: C compiler cannot create executables See `config.log' for more details. The problem lies in the -march=i486 -mtune=i386 options which shouldn't be there in combination with -m64. They stem from the CFLAGS passed in from the default (32-bit) multilib. They are expected to be in XCFLAGS only exactly for that reason, but appear also in CFLAGS. The root cause turns out to be a typo in configure.ac, where for -pthreads detection XCFLAGS are added to CFLAGS instead of the correct XPCFLAGS. The following patch fixes this and allows bootstrap to finish. Ok for mainline (I guess this is obvious)? Rainer 2012-05-04 Rainer Orth r...@cebitec.uni-bielefeld.de * configure.ac: Add $XPCFLAGS to CFLAGS, not $XCFLAGS. * configure: Regenerate. # HG changeset patch # Parent aa7a50ce274c373b20883a2a508fcb99145229ac Don't include XCFLAGS in CFLAGS diff --git a/libatomic/configure b/libatomic/configure --- a/libatomic/configure +++ b/libatomic/configure @@ -14421,7 +14421,7 @@ rm -f core conftest.err conftest.$ac_obj fi rm -f core conftest.err conftest.$ac_objext \ conftest$ac_exeext conftest.$ac_ext - CFLAGS=$save_CFLAGS $XCFLAGS + CFLAGS=$save_CFLAGS $XPCFLAGS ;; esac diff --git a/libatomic/configure.ac b/libatomic/configure.ac --- a/libatomic/configure.ac +++ b/libatomic/configure.ac @@ -206,7 +206,7 @@ case $config_path in [pthread_t t; pthread_create(t,NULL,g,NULL);])], [], [AC_MSG_ERROR([Pthreads are required to build libatomic])])]) - CFLAGS=$save_CFLAGS $XCFLAGS + CFLAGS=$save_CFLAGS $XPCFLAGS ;; esac -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[libatomic] Allow for objects in libatomic_la_LIBADD
After the previous libatomic patch, many testcases fail on Solaris/x86 like this: FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors) Excess errors: Undefined first referenced symbol in file __atomic_compare_exchange_1 /var/tmp//cc7jayIi.o ld: fatal: symbol referencing errors. No output written to . WARNING: libatomic.c/atomic-compare-exchange-1.c compilation failed to produce executable This is caused by the fact that the libatomic.map-sun rule currently only expects archives in libatomic_la_LIBADD, but here it contains objects instead. This is a great demonstration why the current massive duplication of such rules among versioned libraries is a mess: the libjava rules had this right. Unifying all this is still on my agenda. The following patch fixes this and fixes all but a few testcases which fail for unrelated reasons (yet to be determined/reported). I've not only regenerated Makefile.in, but also aclocal.m4, since automake complained configure.ac:84: version mismatch. This is Automake 1.11.1, configure.ac:84: but the definition used by this AM_INIT_AUTOMAKE configure.ac:84: comes from Automake 1.11.3. You should recreate configure.ac:84: aclocal.m4 with aclocal and run automake again. and 1.11.1 is the current required version. Ok for mainline? Rainer 2012-05-05 Rainer Orth r...@cebitec.uni-bielefeld.de * Makefile.am (libatomic.map-sun): Handle objects in libatomic_la_LIBADD. * aclocal.m4: Regenerate. * Makefile.in: Regenerate. # HG changeset patch # Parent 0114ed05eb41c51370fdc050784072611a025da8 Allow for objects in libatomic_la_LIBADD diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am --- a/libatomic/Makefile.am +++ b/libatomic/Makefile.am @@ -56,7 +56,7 @@ libatomic.map-sun : $(top_srcdir)/libato $(top_srcdir)/libatomic.map \ $(libatomic_la_OBJECTS:%.lo=.libs/%.o) \ `echo $(libatomic_la_LIBADD) | \ - sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ + sed 's,\([^/ ]*\)\.l\([ao]\),.libs/\1.\2,g'` \ $@ || (rm -f $@ ; exit 1) endif else -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[patch] Tighten GIMPLE_SWITCH verification
Hello, When I moved the first bits of the switch lowering code from stmt.c, I didn't anticipate that the GIMPLE passes can sometimes perform transformations that break the rules the gimplifier uses while lowering SWITCH_EXPRs. The attached patch adds the expected rules to the GIMPLE_SWITCH verifier. Bootstraptest running on powerpc64-unknown-linux-gnu. OK if it passes? Ciao! Steven gimple_switch_verify.diff Description: Binary data
Re: [Patch] Bump minimum required MPFR version
On Sun, May 6, 2012 at 7:24 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Sun, May 6, 2012 at 2:39 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, May 6, 2012 at 10:33 AM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
in http://gcc.gnu.org/install/prerequisites.html we say that GCC
requires at least MPFR 2.4.2, but in the toplevel configure.ac we only
require 2.3.1, printing a warning that the result is likely to be
buggy if the version is lower than 2.4.2.
The attached patch bumps the minimum version to 2.4.0. We started
requiring 2.3.1, which was released on 2008-01-29, on 2009-04-08, that
is, about 1 year and a few months after the release. MPFR 2.4.0 was
released on 2009-01-26, so by now it's 3 years old. And by the time we
release 4.8 it's most likely over 4 years old already.
For some background, the fortran frontend recently started using
mpfr_fmod to fix some bugs in the constant folding of the MOD and
MODULO intrinsics, effectively requiring at least MPFR 2.4.0 in order
to build.
Also, if this patch is accepted the middle-end could be modified to
constant fold BUILT_IN_FMOD{F,,L} relatively easily, something which
isn't done today.
Ok for trunk?
Please make the check match documentation, thus 2.4.2, not 2.4.0.
Something like the attached patch? FWIW, this removes the distinction
we have between buggy, but builds and ok.
Ok for trunk?
The change that bumped the documented requirement was logged with
+2010-01-31 Kaveh R. Ghazi gh...@caip.rutgers.edu
+
+ * doc/install.texi: Update recommended GMP/MPFR/MPC versions.
which suggests a recommended version. So I'd revert my earlier comment
and if 2.4.0 builds ok then we should check for that version instead.
Thus, the earlier patch is ok.
Thanks,
Richard.
2012-05-06 Janne Blomqvist j...@gcc.gnu.org
* configure.ac: Bump minimum MPFR version to 2.4.2.
* configure: Regenerated.
--
Janne Blomqvist
Re: [patch] Tighten GIMPLE_SWITCH verification
On Mon, May 7, 2012 at 1:28 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, When I moved the first bits of the switch lowering code from stmt.c, I didn't anticipate that the GIMPLE passes can sometimes perform transformations that break the rules the gimplifier uses while lowering SWITCH_EXPRs. The attached patch adds the expected rules to the GIMPLE_SWITCH verifier. Bootstraptest running on powerpc64-unknown-linux-gnu. OK if it passes? Ok! Thanks, Richard. Ciao! Steven
[testsuite] Allow for / comments in g++.dg/debug/dwarf2/nested-3.C
g++.dg/debug/dwarf2/nested-3.C currently FAILs on Solaris/x86 and
Darwin/x86 (scan-assembler), for two reasons:
* First of all, Solaris uses / instead of # as comment character. There
seem to be many others, but I cannot tell which of them are relevant
for this testcase.
* Even with this fixed, the test still fails with Sun as which doesn't
support .uleb128. Instead of the expected
.uleb128 0x5 # (DIE (0x39) DW_TAG_subprogram)
the .s files has
.byte 0x5 / uleb128 0x5; (DIE (0x138) DW_TAG_subprogram)
This patch fixes both issues.
Tested with the appropriate runtest invocation on i386-pc-solaris2.11
(as and gas), x86_64-apple-darwin11.3.0, and x86_64-unknown-linux-gnu.
Ok for mainline?
Rainer
2012-05-05 Rainer Orth r...@cebitec.uni-bielefeld.de
* g++.dg/debug/dwarf2/nested-3.C: Allow for / comments and missing
.uleb128 support in assembler output.
# HG changeset patch
# Parent 1b4b86e2af2f270c64ff1f5549825c8a5a853139
Allow for / comments in g++.dg/debug/dwarf2/nested-3.C
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C b/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
--- a/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
@@ -59,4 +59,4 @@ main ()
//
// Hence the scary regexp:
//
-// { dg-final { scan-assembler \[^\n\r\]*\\(DIE \\(0x(\[0-9a-f\]+)\\) DW_TAG_namespace\\)\[\n\r\]+\[^\n\r\]*\thread\[\^\n\r]+\[\n\r\]+(\[^\n\r\]*\[\n\r\]+)+\[^\n\r\]*\\(DIE \\(0x(\[0-9a-f\]+)\\) DW_TAG_class_type\\)(\[\n\r\]+\[^\n\r\]*)+\Executor\[^\n\r\]+\[\n\r\]+\[^\n\r\]*DW_AT_declaration\[\n\r\]+\[^\n\r\]*DW_AT_signature\[^#\]*# \\(DIE\[^\n\r\]*DW_TAG_subprogram\\)\[\n\r\]+(\[^\n\r\]*\[\n\r\]+)+\[^\n\r\]*\CurrentExecutor\[^\n\r\]+\[\n\r\]+(\[^\n\r\]*\[\n\r\]+)+(\[^\n\r\]*\[\n\r\]+)+\[^\n\r\]*end of children of DIE 0x\\3\[\n\r]+\[^\n\r\]*end of children of DIE 0x\\1\[\n\r]+ } }
+// { dg-final { scan-assembler \[^\n\r\]*\\(DIE \\(0x(\[0-9a-f\]+)\\) DW_TAG_namespace\\)\[\n\r\]+\[^\n\r\]*\thread\[\^\n\r]+\[\n\r\]+(\[^\n\r\]*\[\n\r\]+)+\[^\n\r\]*\\(DIE \\(0x(\[0-9a-f\]+)\\) DW_TAG_class_type\\)(\[\n\r\]+\[^\n\r\]*)+\Executor\[^\n\r\]+\[\n\r\]+\[^\n\r\]*DW_AT_declaration\[\n\r\]+\[^\n\r\]*DW_AT_signature\[^#/\]*\[#/\] \[^\n\r\]*\\(DIE\[^\n\r\]*DW_TAG_subprogram\\)\[\n\r\]+(\[^\n\r\]*\[\n\r\]+)+\[^\n\r\]*\CurrentExecutor\[^\n\r\]+\[\n\r\]+(\[^\n\r\]*\[\n\r\]+)+(\[^\n\r\]*\[\n\r\]+)+\[^\n\r\]*end of children of DIE 0x\\3\[\n\r]+\[^\n\r\]*end of children of DIE 0x\\1\[\n\r]+ } }
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch] Bump minimum required MPFR version
On 05/07/2012 01:32 PM, Richard Guenther wrote:
On Sun, May 6, 2012 at 7:24 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
On Sun, May 6, 2012 at 2:39 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, May 6, 2012 at 10:33 AM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
in http://gcc.gnu.org/install/prerequisites.html we say that GCC
requires at least MPFR 2.4.2, but in the toplevel configure.ac we only
require 2.3.1, printing a warning that the result is likely to be
buggy if the version is lower than 2.4.2.
The attached patch bumps the minimum version to 2.4.0. We started
requiring 2.3.1, which was released on 2008-01-29, on 2009-04-08, that
is, about 1 year and a few months after the release. MPFR 2.4.0 was
released on 2009-01-26, so by now it's 3 years old. And by the time we
release 4.8 it's most likely over 4 years old already.
For some background, the fortran frontend recently started using
mpfr_fmod to fix some bugs in the constant folding of the MOD and
MODULO intrinsics, effectively requiring at least MPFR 2.4.0 in order
to build.
Also, if this patch is accepted the middle-end could be modified to
constant fold BUILT_IN_FMOD{F,,L} relatively easily, something which
isn't done today.
Ok for trunk?
Please make the check match documentation, thus 2.4.2, not 2.4.0.
Something like the attached patch? FWIW, this removes the distinction
we have between buggy, but builds and ok.
Ok for trunk?
The change that bumped the documented requirement was logged with
+2010-01-31 Kaveh R. Ghazi gh...@caip.rutgers.edu
+
+ * doc/install.texi: Update recommended GMP/MPFR/MPC versions.
which suggests a recommended version. So I'd revert my earlier comment
and if 2.4.0 builds ok then we should check for that version instead.
The webpage disagrees. Quoting
http://gcc.gnu.org/install/prerequisites.html:
==
MPFR Library version 2.4.2 (or later)
Necessary to build GCC. It can be downloaded from
http://www.mpfr.org/. If an MPFR source distribution is found in a
subdirectory of your GCC sources named mpfr, it will be built together
with GCC. Alternatively, if MPFR is already installed but it is not in
your default library search path, the --with-mpfr configure option
should be used. See also --with-mpfr-lib and --with-mpfr-include.
=
(for reference: mpfr 2.4.2 was released on 30 November 2009).
Cheers,
- Tobi
Thus, the earlier patch is ok.
Thanks,
Richard.
2012-05-06 Janne Blomqvist j...@gcc.gnu.org
* configure.ac: Bump minimum MPFR version to 2.4.2.
* configure: Regenerated.
--
Janne Blomqvist
--
Tobias Schlüter
Am Coulombwall 1, Zi. 317
85748 Garching b. München
Tel.: +49/89/289-14157
[PATCH] Testcase for PR42987
Committed.
Richard.
2012-05-07 Richard Guenther rguent...@suse.de
PR lto/42987
* g++.dg/lto/pr42987_0.C: New testcase.
* g++.dg/lto/pr42987_1.C: Likewise.
Index: gcc/testsuite/g++.dg/lto/pr42987_0.C
===
--- gcc/testsuite/g++.dg/lto/pr42987_0.C(revision 0)
+++ gcc/testsuite/g++.dg/lto/pr42987_0.C(revision 0)
@@ -0,0 +1,22 @@
+// { dg-lto-do run }
+// { dg-lto-options { { -flto -g } { -flto -flto-partition=none -g } } }
+
+#include typeinfo
+
+struct B {
+ virtual void b() {}
+};
+
+static B* f() {
+ struct D : public B {
+ };
+
+ return new D;
+}
+
+extern B* g();
+
+int main () {
+ if (typeid (*f()) == typeid (*g()))
+return 1;
+}
Index: gcc/testsuite/g++.dg/lto/pr42987_1.C
===
--- gcc/testsuite/g++.dg/lto/pr42987_1.C(revision 0)
+++ gcc/testsuite/g++.dg/lto/pr42987_1.C(revision 0)
@@ -0,0 +1,14 @@
+struct B {
+ virtual void b() {}
+};
+
+static B* f() {
+ struct D : public B {
+ };
+
+ return new D;
+}
+
+B* g() {
+ return f();
+}
Re: [patch][m68k] Remove sched_branch_type, reduce genattrtab run time to reasonable numbers
Steven Bosscher stevenb@gmail.com writes: Tested by building a cross to m68k-linux. OK for trunk? Ok with a changelog. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[libgcc] Use i386-cpuinfo.c on all i386 targets
gcc.target/i386/builtin_target.c currently FAILs on Solaris/x86 (and
also on on *86*-*-freebsd*, judging from testresults):
FAIL: gcc.target/i386/builtin_target.c (test for excess errors)
WARNING: gcc.target/i386/builtin_target.c compilation failed to produce
executable
Excess errors:
Undefined first referenced
symbol in file
__cpu_indicator_init/var/tmp//ccj7aaTp.o
ld: fatal: symbol referencing errors. No output written to .
The problem is that the test is run on all i?86/x86_64 targets, but
i386-cpuinfo.c is only added to libgcc on a select smaller set of
targets, only those using glibc, it seems. AFAICS there's nothing
glibc-specific in that file (with the possible exection of constructor
priority, which might depend on gld), so I suggest to use it everywhere.
In order for this to work, one needs to check if init priority is
supported by the toolchain used, otherwise i386-cpuinfo.c will fail to
compile. It seems that the only thing you loose if it's not is the
ability to use __builtin_cpu_* in constructors without explicitly
calling __builtin_cpu_init, which seems like an acceptable limitation if
documented (not yet in this patch).
I'm now introducing a config header for libgcc to contain the test
results, but to avoid clashes with the (still used) headers in gcc, I'm
calling it auto-target.h (like gcc's auto-host.h). Makefile.in still
contained references to the generic config.h, but that file doesn't
exist, so I've reused them for auto-target.h.
Bootstrapped without regressions on i386-pc-solaris2.11 (as/ld, gas/ld,
gas/gld). Ok for mainline?
Rainer
2012-04-26 Rainer Orth r...@cebitec.uni-bielefeld.de
libgcc:
* config.host (i[34567]86-*-linux*, x86_64-*-linux*)
(i[34567]86-*-kfreebsd*-gnu, x86_64-*-kfreebsd*-gnu)
(i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*): Move
i386/t-cpuinfo ...
(i[34567]86-*-*, x86_64-*-*): ... here.
* config/i386/libgcc-bsd.ver (GCC_4.8.0): New version.
* config/i386/libgcc-sol2.ver (GCC_4.8.0): New version.
* config/i386/i386-cpuinfo.c: Rename to ...
* config/i386/cpuinfo.c: ... this.
* config/i386/t-cpuinfo (LIB2ADD): Reflect this.
* configure.ac (AC_CONFIG_HEADER): Call for auto-target.h.
(libgcc_cv_init_priority): New test.
* configure: Regenerate.
* config.in: New file.
* Makefile.in (clean): Rename config.h to auto-target.h.
(config.h): Likewise.
(stamp-h): Likewise.
* config/i386/cpuinfo.c (auto-target.h): Include.
(CONSTRUCTOR_PRIORITY): Define.
(__cpu_indicator_init): Use it.
gcc
* config/i386/i386.c: Update comments for i386-cpuinfo.c name
change.
# HG changeset patch
# Parent eab812ef23d92c2aea25c912aef933f4c8cd0d27
Use i386-cpuinfo.c on all i386 targets
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -27699,7 +27699,7 @@ ix86_init_mmx_sse_builtins (void)
}
/* This builds the processor_model struct type defined in
- libgcc/config/i386/i386-cpuinfo.c */
+ libgcc/config/i386/cpuinfo.c */
static tree
build_processor_model_struct (void)
@@ -27759,7 +27759,7 @@ make_var_decl (tree type, const char *na
}
/* FNDECL is a __builtin_cpu_is or a __builtin_cpu_supports call that is folded
- into an integer defined in libgcc/config/i386/i386-cpuinfo.c */
+ into an integer defined in libgcc/config/i386/cpuinfo.c */
static tree
fold_builtin_cpu (tree fndecl, tree *args)
@@ -27769,8 +27769,7 @@ fold_builtin_cpu (tree fndecl, tree *arg
DECL_FUNCTION_CODE (fndecl);
tree param_string_cst = NULL;
- /* This is the order of bit-fields in __processor_features in
- i386-cpuinfo.c */
+ /* This is the order of bit-fields in __processor_features in cpuinfo.c */
enum processor_features
{
F_CMOV = 0,
@@ -27788,7 +27787,7 @@ fold_builtin_cpu (tree fndecl, tree *arg
};
/* These are the values for vendor types and cpu types and subtypes
- in i386-cpuinfo.c. Cpu types and subtypes should be subtracted by
+ in cpuinfo.c. Cpu types and subtypes should be subtracted by
the corresponding start value. */
enum processor_model
{
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -121,7 +121,7 @@ installcheck:
.PHONY: all clean
clean:
- -rm -f config.h libgcc_tm.h stamp-h stmp-ldirs libgcc.map
+ -rm -f auto-target.h libgcc_tm.h stamp-h stmp-ldirs libgcc.map
-rm -f *$(objext)
-rm -f *.dep
-rm -f *.a
@@ -139,9 +139,9 @@ Makefile: $(srcdir)/Makefile.in config.s
# Depending on Makefile makes sure that config.status has been re-run
# if needed. This prevents problems with parallel builds.
-config.h: stamp-h ; @true
+auto-target.h: stamp-h ; @true
stamp-h: $(srcdir)/config.in config.status Makefile
-
[PATCH] Fix VRP with DECL_BY_REFERENCE RESULT_DECLs (PR tree-optimization/53239)
Hi!
If returning an addressable result by value, the C++ FE makes
it returned by reference, RESULT_DECL in that case is DECL_BY_REFERENCE
REFERENCE_TYPE. VRP shouldn't in that case assume the result is
VR_UNDEFINED, instead it only knows that it is nonnull.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-05-07 Jakub Jelinek ja...@redhat.com
PR tree-optimization/53239
* tree-vrp.c (get_value_range): Set VR of
SSA_NAME_IS_DEFAULT_DEF of DECL_BY_REFERENCE RESULT_DECL
to nonnull.
* g++.dg/opt/vrp3.C: New test.
* g++.dg/opt/vrp3-aux.cc: New file.
* g++.dg/opt/vrp3.h: New file.
--- gcc/tree-vrp.c.jj 2012-03-13 19:59:16.0 +0100
+++ gcc/tree-vrp.c 2012-05-07 08:46:16.008803053 +0200
@@ -695,17 +695,22 @@ get_value_range (const_tree var)
/* If VAR is a default definition of a parameter, the variable can
take any value in VAR's type. */
sym = SSA_NAME_VAR (var);
- if (SSA_NAME_IS_DEFAULT_DEF (var)
- TREE_CODE (sym) == PARM_DECL)
+ if (SSA_NAME_IS_DEFAULT_DEF (var))
{
- /* Try to use the nonnull attribute to create ~[0, 0]
-anti-ranges for pointers. Note that this is only valid with
-default definitions of PARM_DECLs. */
- if (POINTER_TYPE_P (TREE_TYPE (sym))
- nonnull_arg_p (sym))
+ if (TREE_CODE (sym) == PARM_DECL)
+ {
+ /* Try to use the nonnull attribute to create ~[0, 0]
+anti-ranges for pointers. Note that this is only valid with
+default definitions of PARM_DECLs. */
+ if (POINTER_TYPE_P (TREE_TYPE (sym))
+ nonnull_arg_p (sym))
+ set_value_range_to_nonnull (vr, TREE_TYPE (sym));
+ else
+ set_value_range_to_varying (vr);
+ }
+ else if (TREE_CODE (sym) == RESULT_DECL
+ DECL_BY_REFERENCE (sym))
set_value_range_to_nonnull (vr, TREE_TYPE (sym));
- else
- set_value_range_to_varying (vr);
}
return vr;
--- gcc/testsuite/g++.dg/opt/vrp3.C.jj 2012-05-07 09:09:08.574648044 +0200
+++ gcc/testsuite/g++.dg/opt/vrp3.C 2012-05-07 09:09:03.138678376 +0200
@@ -0,0 +1,47 @@
+// PR tree-optimization/53239
+// { dg-do run }
+// { dg-options -O2 }
+// { dg-additional-sources vrp3-aux.cc }
+
+#include vrp3.h
+
+struct M
+{
+ M (R m);
+ R val;
+ static int compare (M const , M const );
+};
+
+inline M const
+min (M const t1, M const t2)
+{
+ return R::compare (t1.val, t2.val) 0 ? t1 : t2;
+}
+
+M::M (R m)
+{
+ val = m;
+}
+
+M
+test (M *x)
+{
+ M n (R (0, 0));
+
+ for (int i = 0; i 2; i++)
+{
+ M p = x[i];
+ n = min (n, p);
+}
+
+ if (n.val.r2 != 2 || n.val.r1 != 1)
+__builtin_abort ();
+ return n;
+}
+
+int
+main ()
+{
+ M x[2] = { M (R (1, 2)), M (R (1, 1)) };
+ test (x);
+}
--- gcc/testsuite/g++.dg/opt/vrp3-aux.cc.jj 2012-05-07 09:09:22.060567366
+0200
+++ gcc/testsuite/g++.dg/opt/vrp3-aux.cc2012-05-07 09:09:28.538528045
+0200
@@ -0,0 +1,21 @@
+// { dg-do compile }
+// { dg-options }
+
+#include vrp3.h
+
+R::R ()
+{
+ r1 = r2 = 1;
+}
+
+R::R (int n, int d)
+{
+ r1 = n;
+ r2 = d;
+}
+
+int
+R::compare (R const r, R const s)
+{
+ return (int) (r.r1 * s.r2 - s.r1 * r.r2);
+}
--- gcc/testsuite/g++.dg/opt/vrp3.h.jj 2012-05-07 09:09:41.402448593 +0200
+++ gcc/testsuite/g++.dg/opt/vrp3.h 2012-05-07 09:09:46.509420562 +0200
@@ -0,0 +1,9 @@
+struct R
+{
+ long long r1, r2;
+ void copy (R const r) { r1 = r.r1; r2 = r.r2; }
+ R ();
+ explicit R (int, int);
+ R (R const r) { copy (r); }
+ static int compare (R const , R const );
+};
Jakub
Re: [libgcc] Use i386-cpuinfo.c on all i386 targets
Il 07/05/2012 14:09, Rainer Orth ha scritto: gcc.target/i386/builtin_target.c currently FAILs on Solaris/x86 (and also on on *86*-*-freebsd*, judging from testresults): FAIL: gcc.target/i386/builtin_target.c (test for excess errors) WARNING: gcc.target/i386/builtin_target.c compilation failed to produce executable Excess errors: Undefined first referenced symbol in file __cpu_indicator_init/var/tmp//ccj7aaTp.o ld: fatal: symbol referencing errors. No output written to . The problem is that the test is run on all i?86/x86_64 targets, but i386-cpuinfo.c is only added to libgcc on a select smaller set of targets, only those using glibc, it seems. AFAICS there's nothing glibc-specific in that file (with the possible exection of constructor priority, which might depend on gld), so I suggest to use it everywhere. In order for this to work, one needs to check if init priority is supported by the toolchain used, otherwise i386-cpuinfo.c will fail to compile. It seems that the only thing you loose if it's not is the ability to use __builtin_cpu_* in constructors without explicitly calling __builtin_cpu_init, which seems like an acceptable limitation if documented (not yet in this patch). I'm now introducing a config header for libgcc to contain the test results, but to avoid clashes with the (still used) headers in gcc, I'm calling it auto-target.h (like gcc's auto-host.h). Makefile.in still contained references to the generic config.h, but that file doesn't exist, so I've reused them for auto-target.h. Bootstrapped without regressions on i386-pc-solaris2.11 (as/ld, gas/ld, gas/gld). Ok for mainline? Rainer 2012-04-26 Rainer Orth r...@cebitec.uni-bielefeld.de libgcc: * config.host (i[34567]86-*-linux*, x86_64-*-linux*) (i[34567]86-*-kfreebsd*-gnu, x86_64-*-kfreebsd*-gnu) (i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*): Move i386/t-cpuinfo ... (i[34567]86-*-*, x86_64-*-*): ... here. * config/i386/libgcc-bsd.ver (GCC_4.8.0): New version. * config/i386/libgcc-sol2.ver (GCC_4.8.0): New version. * config/i386/i386-cpuinfo.c: Rename to ... * config/i386/cpuinfo.c: ... this. * config/i386/t-cpuinfo (LIB2ADD): Reflect this. * configure.ac (AC_CONFIG_HEADER): Call for auto-target.h. (libgcc_cv_init_priority): New test. * configure: Regenerate. * config.in: New file. * Makefile.in (clean): Rename config.h to auto-target.h. (config.h): Likewise. (stamp-h): Likewise. * config/i386/cpuinfo.c (auto-target.h): Include. (CONSTRUCTOR_PRIORITY): Define. (__cpu_indicator_init): Use it. gcc * config/i386/i386.c: Update comments for i386-cpuinfo.c name change. Looks good. Paolo
Re: [PATCH] Fix VRP with DECL_BY_REFERENCE RESULT_DECLs (PR tree-optimization/53239)
On Mon, May 7, 2012 at 2:30 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
If returning an addressable result by value, the C++ FE makes
it returned by reference, RESULT_DECL in that case is DECL_BY_REFERENCE
REFERENCE_TYPE. VRP shouldn't in that case assume the result is
VR_UNDEFINED, instead it only knows that it is nonnull.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok also for branches (where you think it fits).
Thanks,
Richard.
2012-05-07 Jakub Jelinek ja...@redhat.com
PR tree-optimization/53239
* tree-vrp.c (get_value_range): Set VR of
SSA_NAME_IS_DEFAULT_DEF of DECL_BY_REFERENCE RESULT_DECL
to nonnull.
* g++.dg/opt/vrp3.C: New test.
* g++.dg/opt/vrp3-aux.cc: New file.
* g++.dg/opt/vrp3.h: New file.
--- gcc/tree-vrp.c.jj 2012-03-13 19:59:16.0 +0100
+++ gcc/tree-vrp.c 2012-05-07 08:46:16.008803053 +0200
@@ -695,17 +695,22 @@ get_value_range (const_tree var)
/* If VAR is a default definition of a parameter, the variable can
take any value in VAR's type. */
sym = SSA_NAME_VAR (var);
- if (SSA_NAME_IS_DEFAULT_DEF (var)
- TREE_CODE (sym) == PARM_DECL)
+ if (SSA_NAME_IS_DEFAULT_DEF (var))
{
- /* Try to use the nonnull attribute to create ~[0, 0]
- anti-ranges for pointers. Note that this is only valid with
- default definitions of PARM_DECLs. */
- if (POINTER_TYPE_P (TREE_TYPE (sym))
- nonnull_arg_p (sym))
+ if (TREE_CODE (sym) == PARM_DECL)
+ {
+ /* Try to use the nonnull attribute to create ~[0, 0]
+ anti-ranges for pointers. Note that this is only valid with
+ default definitions of PARM_DECLs. */
+ if (POINTER_TYPE_P (TREE_TYPE (sym))
+ nonnull_arg_p (sym))
+ set_value_range_to_nonnull (vr, TREE_TYPE (sym));
+ else
+ set_value_range_to_varying (vr);
+ }
+ else if (TREE_CODE (sym) == RESULT_DECL
+ DECL_BY_REFERENCE (sym))
set_value_range_to_nonnull (vr, TREE_TYPE (sym));
- else
- set_value_range_to_varying (vr);
}
return vr;
--- gcc/testsuite/g++.dg/opt/vrp3.C.jj 2012-05-07 09:09:08.574648044 +0200
+++ gcc/testsuite/g++.dg/opt/vrp3.C 2012-05-07 09:09:03.138678376 +0200
@@ -0,0 +1,47 @@
+// PR tree-optimization/53239
+// { dg-do run }
+// { dg-options -O2 }
+// { dg-additional-sources vrp3-aux.cc }
+
+#include vrp3.h
+
+struct M
+{
+ M (R m);
+ R val;
+ static int compare (M const , M const );
+};
+
+inline M const
+min (M const t1, M const t2)
+{
+ return R::compare (t1.val, t2.val) 0 ? t1 : t2;
+}
+
+M::M (R m)
+{
+ val = m;
+}
+
+M
+test (M *x)
+{
+ M n (R (0, 0));
+
+ for (int i = 0; i 2; i++)
+ {
+ M p = x[i];
+ n = min (n, p);
+ }
+
+ if (n.val.r2 != 2 || n.val.r1 != 1)
+ __builtin_abort ();
+ return n;
+}
+
+int
+main ()
+{
+ M x[2] = { M (R (1, 2)), M (R (1, 1)) };
+ test (x);
+}
--- gcc/testsuite/g++.dg/opt/vrp3-aux.cc.jj 2012-05-07 09:09:22.060567366
+0200
+++ gcc/testsuite/g++.dg/opt/vrp3-aux.cc 2012-05-07 09:09:28.538528045
+0200
@@ -0,0 +1,21 @@
+// { dg-do compile }
+// { dg-options }
+
+#include vrp3.h
+
+R::R ()
+{
+ r1 = r2 = 1;
+}
+
+R::R (int n, int d)
+{
+ r1 = n;
+ r2 = d;
+}
+
+int
+R::compare (R const r, R const s)
+{
+ return (int) (r.r1 * s.r2 - s.r1 * r.r2);
+}
--- gcc/testsuite/g++.dg/opt/vrp3.h.jj 2012-05-07 09:09:41.402448593 +0200
+++ gcc/testsuite/g++.dg/opt/vrp3.h 2012-05-07 09:09:46.509420562 +0200
@@ -0,0 +1,9 @@
+struct R
+{
+ long long r1, r2;
+ void copy (R const r) { r1 = r.r1; r2 = r.r2; }
+ R ();
+ explicit R (int, int);
+ R (R const r) { copy (r); }
+ static int compare (R const , R const );
+};
Jakub
Re: [testsuite] Allow for / comments in g++.dg/debug/dwarf2/nested-3.C
OK, thanks. Jason
[PATCH] Fix PR53195, properly add referenced vars during IPA-CP
We fail to add referenced vars when inline copies are instantiated
from clones created from IPA-CP. That later leads to ICEs in
remove-unused-locals because var_ann has not been allocated.
Bootstrapped and tested on x86_64-unknown-linux-gnu, LTO bootstrapped.
Applied to trunk and branch.
Richard.
2012-05-07 Richard Guenther rguent...@suse.de
PR tree-optimization/53195
* tree-inline.c (setup_one_parameter): Properly add referenced
vars from the parameters new known value.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 187228)
+++ gcc/tree-inline.c (working copy)
@@ -2607,6 +2607,17 @@ setup_one_parameter (copy_body_data *id,
/* Make gimplifier happy about this variable. */
DECL_SEEN_IN_BIND_EXPR_P (var) = 1;
+ /* We are eventually using the value - make sure all variables
+ referenced therein are properly recorded. */
+ if (value
+ gimple_in_ssa_p (cfun)
+ TREE_CODE (value) == ADDR_EXPR)
+{
+ tree base = get_base_address (TREE_OPERAND (value, 0));
+ if (base TREE_CODE (base) == VAR_DECL)
+ add_referenced_var (base);
+}
+
/* If the parameter is never assigned to, has no SSA_NAMEs created,
we would not need to create a new variable here at all, if it
weren't for debug info. Still, we can just use the argument
Re: [PATCH 2/2] Minor refactoring of tree-vect-patterns.c
Ian Lance Taylor wrote: It looks like you checked in a version of this patch to gcc-4_7-branch. However, the version you committed used false where it should have used NULL, causing a bootstrap failure in stage 2 when not using building in release mode: ../../gccgo-gcc/gcc/tree-vect-patterns.c: In function 'gimple_statement_d* vect_single_imm_use(gimple)': ../../gccgo-gcc/gcc/tree-vect-patterns.c:104:12: error: converting 'false' to pointer type 'gimple' [-Werror=conversion-null] ../../gccgo-gcc/gcc/tree-vect-patterns.c:107:12: error: converting 'false' to pointer type 'gimple' [-Werror=conversion-null] I committed the appended patch to fix this problem. Please double-check the code to make sure it is correct. Thanks. Oops, sorry for the breakage. Yes, that was clearly a merge error when adapting the patch to 4.7 (in 4.7, tree-vect-patterns.c does not yet support SLP, which means some of the tests needed to be modified). You fix looks correct to me; thanks for looking into this! Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Speed up insn-attrtab.c compilation
Hi,
neverending story. Maybe this time something gets in :)
This patch changes generation of insn-attrtab.c to:
* order attributes topologically (so that the inlining genattrtab does
is as effective as possible, and doesn't hit the size limits too much)
* adjusts the rtx_cost for the attribute tests to correctly account for
all tests (even the cheap ones have an impact after all)
* lowers the limits for inlining
* only uses an optimized new value if it actually is cheaper than
the old value (and overall not too expensive)
* limits the number of predicates we remember from if/elseif/elseif
cascades to optimize further elseif tests (doesn't change code on x86,
but reduces generation time)
The effect is that insn-attrtab.c on x86_64 is 2.9 MB instead of 6.0 MB,
and that compilation of insn-attrtab.c with an unoptimized (i.e. stage1)
cc1 is done in 45 seconds instead of 269 seconds. The genattrtab call
itself (unoptimized genattrtab) takes 9.5 seconds instead of 9.1.
This was before Steven implemented the three file split, with that split
take the above as cumulative time, the overall speedup transfers to the
split version.
Compilation time on x86_64-linux, with an unoptimized cc1(plus), with -g
-O2:
unpatchedpatched
big-code.c 157.1s 157.4s
kdecore.cc 304.3s 301.9s
(i.e. noise).
In particular this patch doesn't contain my controversial variant of
caching get_attr_xxx calls (which dynamically calls those functions more
often than Jakubs variant). Still a good speedup, though.
Regstrapping on x86_64-linux in progress. Okay if that passes? (I'd like
to retain the #if 0 code therein, it's just a generator and it helps
easily debugging the topsort thingy if something breaks)
Ciao,
Michael.
---
* genattrtab.c (attr_rtx_cost): Move earlier, start with cost being 1.
(simplify_test_exp): Handle one more case of distributive law,
decrease cost threshold.
(tests_attr_p, get_attr_order): New functions.
(optimize_attrs): Use topological order, inline only cheap values.
(write_attr_set): Reset our_known_true after some time.
Index: genattrtab.c
===
--- genattrtab.c(revision 187098)
+++ genattrtab.c(working copy)
@@ -1636,6 +1636,57 @@ write_length_unit_log (void)
printf (EXPORTED_CONST int length_unit_log = %u;\n, length_unit_log);
}
+/* Compute approximate cost of the expression. Used to decide whether
+ expression is cheap enough for inline. */
+static int
+attr_rtx_cost (rtx x)
+{
+ int cost = 1;
+ enum rtx_code code;
+ if (!x)
+return 0;
+ code = GET_CODE (x);
+ switch (code)
+{
+case MATCH_OPERAND:
+ if (XSTR (x, 1)[0])
+ return 10;
+ else
+ return 1;
+
+case EQ_ATTR_ALT:
+ return 1;
+
+case EQ_ATTR:
+ /* Alternatives don't result into function call. */
+ if (!strcmp_check (XSTR (x, 0), alternative_name))
+ return 1;
+ else
+ return 5;
+default:
+ {
+ int i, j;
+ const char *fmt = GET_RTX_FORMAT (code);
+ for (i = GET_RTX_LENGTH (code) - 1; i = 0; i--)
+ {
+ switch (fmt[i])
+ {
+ case 'V':
+ case 'E':
+ for (j = 0; j XVECLEN (x, i); j++)
+ cost += attr_rtx_cost (XVECEXP (x, i, j));
+ break;
+ case 'e':
+ cost += attr_rtx_cost (XEXP (x, i));
+ break;
+ }
+ }
+ }
+ break;
+}
+ return cost;
+}
+
/* Take a COND expression and see if any of the conditions in it can be
simplified. If any are known true or known false for the particular insn
code, the COND can be further simplified.
@@ -2262,57 +2313,6 @@ simplify_or_tree (rtx exp, rtx *pterm, i
return exp;
}
-/* Compute approximate cost of the expression. Used to decide whether
- expression is cheap enough for inline. */
-static int
-attr_rtx_cost (rtx x)
-{
- int cost = 0;
- enum rtx_code code;
- if (!x)
-return 0;
- code = GET_CODE (x);
- switch (code)
-{
-case MATCH_OPERAND:
- if (XSTR (x, 1)[0])
- return 10;
- else
- return 0;
-
-case EQ_ATTR_ALT:
- return 0;
-
-case EQ_ATTR:
- /* Alternatives don't result into function call. */
- if (!strcmp_check (XSTR (x, 0), alternative_name))
- return 0;
- else
- return 5;
-default:
- {
- int i, j;
- const char *fmt = GET_RTX_FORMAT (code);
- for (i = GET_RTX_LENGTH (code) - 1; i = 0; i--)
- {
- switch (fmt[i])
- {
- case 'V':
- case 'E':
- for (j = 0; j XVECLEN (x, i); j++)
- cost += attr_rtx_cost (XVECEXP (x, i, j));
- break;
- case 'e':
- cost += attr_rtx_cost (XEXP (x,
Re: [patch] Tighten GIMPLE_SWITCH verification
On Mon, May 7, 2012 at 1:34 PM, Richard Guenther richard.guent...@gmail.com wrote: On Mon, May 7, 2012 at 1:28 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, When I moved the first bits of the switch lowering code from stmt.c, I didn't anticipate that the GIMPLE passes can sometimes perform transformations that break the rules the gimplifier uses while lowering SWITCH_EXPRs. The attached patch adds the expected rules to the GIMPLE_SWITCH verifier. Bootstraptest running on powerpc64-unknown-linux-gnu. OK if it passes? Ok! Thanks. I've committed a slightly weaker version that allows the type of case label values to be different from the index type, as long as all case labels have the same type and the type precision of the index type is not less than the case label value type. I allowed that earlier in the gimplifier to avoid fold_converting case label values to larger types and then back to smaller types. Bootstrappedtested on powerpc64-unknown-linux-gnu, committed as r187242. Ciao! Steven
remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
Hello, This is a followup on a discussion we had a while ago, starting with http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01543.html The original issue was the vxworks port unduly clobbering explicit SPE related options on powerpc, which it still does. The proposed patch at the time was to prevent the clobbering locally, adding guards in the vxworks.h code as there are in a few other targets already. Joseph and David suggested to address this in a more general fashion, along lines proposed in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html The attached patch is a first shot in this direction. Only lightly tested at this point, posted to get a first round of comments to validate that this corresponds to what was suggested. This indeed allows significant simplifications - cleaner configuration model, defaults control factorized, no need for e500-double.h any more. I'll be happy to do what I can to help in getting this in eventually. One piece that for sure needs updating is The TARGET_NO_LWSYNC change suggests that maybe keeping a TARGET_E500 macro would make sense after all, to convey cpu features an E500 core which happens to imply SPE support and no LWSYNC. We could have a TARGET_E500MC as well to make it clear that the latter family differs from the former. That's actually a detail in the set of changes at hand. In addition to what I understood of the suggestions made in the aforementioned thread, this patch includes a change on the choice of rs6000_cpu in options_override, so that it treats a --with-cpu passed at configure time as an implicit -mcpu in absence of an explicit one. This sounds reasonable and is useful for the more general change we're discussing. This patch allowed me to build a few configurations with as-expected results on gcc 4.7 base. The patch applies as-is on mainline. My first attempt at building there failed, with --target=powerpc-eabispe --with-cpu=8548 --enable-languages=c --disable-libada (internal compiler error on unwind-dw2.c) This failure reproduces with an unpatched tree as well, so there's something already broken in this area. I suppose I can can look into this one first. I'd appreciate feedback on the more general patch nevetheless :) (whether that's the right direction, things that you think should be done differently, indications as to how you'd like to proceed further (testing etc), ...) Thanks much in advance, Olivier 2012-05-07 Olivier Hainque hain...@adacore.com config/rs6000: * rs6000-opts.h (enum processor_type): Add PROCESSOR_PPC8548. * rs6000-cpus.def: Reference it for cpu=8548. * rs6000.md (cpu attribute definition): Add ppc8548. * 8540.md: indicate that the units/patterns apply to ppc8548 as well. * rs6000.c (rs6000_option_override_internal): Rename default_cpu into implicit_cpu, conveying what --with-cpu was passed at configure time. Treat implicit_cpu as have_cpu. Pick defaults for SPE related flags, check that what is queried is supported by the selected configuration. Rework the single/double_float and MASK_STRING resets to hit for all the E500 cores (854x + E500MC variants). Select the ppc8540 costs for PROCESSOR_PPC8548 as well. (rs6000_issue_rate): case CPU_PPC8548 together with CPU_PPC8540. (rs6000_use_sched_lookahead): Likewise, rewriting function as a case statement instead of a sequence of ifs. * rs6000.h (TARGET_E500): Remove. (TARGET_NO_LWSYNC): Adjust accordingly. * e500.h (TARGET_E500): Remove. (CHECK_E500_OPTIONS): Adjust accordingly. * eabispe.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Remove. (TARGET_DEFAULT): Reformat definition to match the one in linuxspe.h. * linuxspe.h: Likewise. * vxworks.h: Remove bogus TARGET_E500 overrides and superfluous comments. * e500-double.h: Remove. gcc: * config.gcc (pick a default with_cpu): For powerpc*-*-*spe*, default to with_cpu=8548 if --enable-e500-double, and to 8540 otherwise. (set misc flags section): For powerpc*|rs6000*, remove inclusion of e500-double.h for --enable-e500-double. e500.dif Description: video/dv
Re: Optimize calls to functions that return one of their arguments
On 05/03/2012 07:47 PM, Richard Sandiford wrote: Richard Guentherrichard.guent...@gmail.com writes: On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidtber...@codesourcery.com wrote: This patch allows us to recognize that even if the argument to memcpy lives across the call, we can allocate it to a call-used register by reusing the return value of the function. Non-IRA RTL bits look good to me FWIW. Vlad, any opinions on the IRA bits? Bernd
[patch] PR53245
Hello, This patch fixes PR53245. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk? Ciao! Steven PR middle-end/53245 * gimplify.c (preprocess_case_label_vec_for_gimple): If low or high is folded to a type boundary value, verify that the resulting case label is still a care range. Index: gimplify.c === --- gimplify.c (revision 187219) +++ gimplify.c (working copy) @@ -1658,6 +1658,10 @@ preprocess_case_label_vec_for_gimple (VEC(tree,hea tree_int_cst_compare (high, max_value) 0) high = max_value; high = fold_convert (index_type, high); + + /* We may have folded a case range to a one-value case. */ + if (tree_int_cst_equal (low, high)) + high = NULL_TREE; } }
Re: [patch] PR53245
On Mon, May 7, 2012 at 4:35 PM, Steven Bosscher stevenb@gmail.com wrote: Hello, This patch fixes PR53245. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk? Ok. Thanks, Richard. Ciao! Steven PR middle-end/53245 * gimplify.c (preprocess_case_label_vec_for_gimple): If low or high is folded to a type boundary value, verify that the resulting case label is still a care range. Index: gimplify.c === --- gimplify.c (revision 187219) +++ gimplify.c (working copy) @@ -1658,6 +1658,10 @@ preprocess_case_label_vec_for_gimple (VEC(tree,hea tree_int_cst_compare (high, max_value) 0) high = max_value; high = fold_convert (index_type, high); + + /* We may have folded a case range to a one-value case. */ + if (tree_int_cst_equal (low, high)) + high = NULL_TREE; } }
Re: [patch] PR53245
On Mon, May 7, 2012 at 7:35 AM, Steven Bosscher stevenb@gmail.com wrote: Hello, This patch fixes PR53245. Bootstrappedtested on powerpc64-unknown-linux-gnu. OK for trunk? Ciao! Steven PR middle-end/53245 * gimplify.c (preprocess_case_label_vec_for_gimple): If low or high is folded to a type boundary value, verify that the resulting case label is still a care range. Can you add the testcase in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53245#c1 Thanks. -- H.J.
Re: [C++ Patch] for c++/51214
On 05/06/2012 04:06 PM, Fabien Chêne wrote: + if (late_enum_values) + VEC_safe_push (tree, gc, late_enum_values, decl); I would think you could walk the TYPE_VALUES list directly, rather than copy it into a temporary VEC. Jason
Re: [PATCH] x86: emit tzcnt unconditionally
On Mon, May 7, 2012 at 10:00 AM, Jakub Jelinek ja...@redhat.com wrote:
Shouldn't that be done only for generic tuning? If somebody uses
-mtune=native, then emitting rep; bsf is overkill, the code is intended
to be run on a CPU without (or with TARGET_BMI with) tzcnt insn support.
Yes, this is a good idea.
Something like attached patch?
Yeah, but probably with the TARGET_BMI and optimize_function_for_size_p
lines swapped.
Because i386.h defines
CTZ_DEFINED_VALUE_AT_ZERO to 1 for TARGET_BMI, therefore it isn't
undefined for TARGET_BMI, so even for -Os you can't just use bsf.
I have committed following patch:
2012-05-07 Uros Bizjak ubiz...@gmail.com
* config/i386/i386.md (ctzmode2): Emit rep;bsf
only for TARGET_GENERIC, when not optimizing for size.
(*ffsmode_1): Ditto.
Tested on x86_64-pc-linux-gnu {,-m32}.
Uros.
Index: i386.md
===
--- i386.md (revision 187223)
+++ i386.md (working copy)
@@ -12113,21 +12113,25 @@
(ctz:SWI48 (match_dup 1)))]
{
- if (optimize_function_for_size_p (cfun))
-return bsf{imodesuffix}\t{%1, %0|%0, %1};
- else if (TARGET_BMI)
+ if (TARGET_BMI)
return tzcnt{imodesuffix}\t{%1, %0|%0, %1};
- else
+ else if (optimize_function_for_size_p (cfun))
+;
+ else if (TARGET_GENERIC)
/* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI. */
return rep; bsf{imodesuffix}\t{%1, %0|%0, %1};
+
+ return bsf{imodesuffix}\t{%1, %0|%0, %1};
}
[(set_attr type alu1)
(set_attr prefix_0f 1)
(set (attr prefix_rep)
(if_then_else
- (match_test optimize_function_for_size_p (cfun))
- (const_string 0)
- (const_string 1)))
+ (ior (match_test TARGET_BMI)
+ (and (not (match_test optimize_function_for_size_p (cfun)))
+(match_test TARGET_GENERIC)))
+ (const_string 1)
+ (const_string 0)))
(set_attr mode MODE)])
(define_insn ctzmode2
@@ -12136,21 +12140,25 @@
(clobber (reg:CC FLAGS_REG))]
{
- if (optimize_function_for_size_p (cfun))
-return bsf{imodesuffix}\t{%1, %0|%0, %1};
- else if (TARGET_BMI)
+ if (TARGET_BMI)
return tzcnt{imodesuffix}\t{%1, %0|%0, %1};
- else
+ else if (optimize_function_for_size_p (cfun))
+;
+ else if (TARGET_GENERIC)
/* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI. */
return rep; bsf{imodesuffix}\t{%1, %0|%0, %1};
+
+ return bsf{imodesuffix}\t{%1, %0|%0, %1};
}
[(set_attr type alu1)
(set_attr prefix_0f 1)
(set (attr prefix_rep)
(if_then_else
- (match_test optimize_function_for_size_p (cfun))
- (const_string 0)
- (const_string 1)))
+ (ior (match_test TARGET_BMI)
+ (and (not (match_test optimize_function_for_size_p (cfun)))
+(match_test TARGET_GENERIC)))
+ (const_string 1)
+ (const_string 0)))
(set_attr mode MODE)])
(define_expand clzmode2
Re: PR 40752: -Wconversion generates false warnings for operands not larger than target type
Hi,
On 06/11/2010 10:23 PM, Manuel López-Ibáñez wrote:
On 11 August 2009 02:01, Joseph S. Myersjos...@codesourcery.com wrote:
On Tue, 11 Aug 2009, Manuel López-Ibáñez wrote:
Modified the patch to make use of the new c-c++-common testsuite.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK for trunk?
I still think the warnings for these cases are mostly correct (there are
cases where you may be able to make deductions about the range of possible
values of the expression being converted) and appropriate, and if disabled
should be disabled under some separate -Wno-conversion-whatever option.
-Wno-conversion-after-promotion ?
I am not sure what would be a good name, but I think it is worth to
allow silencing these warnings, so suggestions are welcome.
it looks like this PR is still open today, and I think resolving it one
way or the other isn't much work... Thus I'm asking: shall we actually
have a new -Wno-conversion-after-promotion? Or, alternately - the issue
came up quite often in recent times, because other widespread compilers
don't warn - suppress the warning only in case of conditional expressions:
char
foo(bool haveBar, char bar_)
{
return haveBar ? bar_ : 0;
};
What do you think?
Thanks,
Paolo.
Re: Optimize calls to functions that return one of their arguments
On 05/07/2012 10:30 AM, Bernd Schmidt wrote: On 05/03/2012 07:47 PM, Richard Sandiford wrote: Richard Guentherrichard.guent...@gmail.com writes: On Sat, Apr 28, 2012 at 5:31 PM, Bernd Schmidtber...@codesourcery.com wrote: This patch allows us to recognize that even if the argument to memcpy lives across the call, we can allocate it to a call-used register by reusing the return value of the function. Non-IRA RTL bits look good to me FWIW. Vlad, any opinions on the IRA bits? Sorry, Bernd. I was on vacation last week. I'll look at this today.
Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
On May 7, 2012, at 15:57 , Olivier Hainque wrote:
My first attempt at building there failed, with
--target=powerpc-eabispe --with-cpu=8548 --enable-languages=c
--disable-libada
(internal compiler error on unwind-dw2.c) This failure reproduces with
an unpatched tree as well, so there's something already broken in this area.
This appears to be a fallout of the (very nice !) prologue/epilogue
cleanup series issued last april, in particular rev 186797 corresponding to
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01014.html (Alan cc'ed)
This piece:
(emit_frame_save): Don't handle reg+reg addressing.
introduces an assert on which we now trip compiling unwind-dw2.c for SPE
configurations. We now fall into the TARGET_SPE_ABI part of
/* Some cases that need register indexed addressing. */
gcc_checking_assert (!((TARGET_ALTIVEC_ABI ALTIVEC_VECTOR_MODE (mode))
|| (TARGET_VSX ALTIVEC_OR_VSX_VECTOR_MODE (mode))
|| (TARGET_E500_DOUBLE mode == DFmode)
|| (TARGET_SPE_ABI
SPE_VECTOR_MODE (mode)
!SPE_CONST_OFFSET_OK (offset;
in emit_frame_save while compiling uw_install_context.
The call comes from this part of rs6000_emit_prologue:
/* ??? There's no need to emit actual instructions here, but it's the
easiest way to get the frame unwind information emitted. */
if (crtl-calls_eh_return)
{
unsigned int i, regno;
for (i = 0; ; ++i)
{
regno = EH_RETURN_DATA_REGNO (i);
if (regno == INVALID_REGNUM)
break;
emit_frame_save (frame_reg_rtx, reg_mode, regno,
info-ehrd_offset + frame_off + reg_size * (int) i,
sp_off - frame_off);
}
}
The crash reproduces on this artificial reproducer:
void install (long offset, void * handler)
{
volatile int x [4096];
__builtin_eh_return (offset, handler);
}
configure --enable-languages=c --disable-libada --target=powerpc-eabispe
make ...
./cc1 ice.c
...
ice.c: In function install:
ice.c:6:1: internal compiler error: in emit_frame_save, at
config/rs6000/rs6000.c:18979
Re: [libatomic] Don't include XCFLAGS in CFLAGS
On 05/07/2012 04:14 AM, Rainer Orth wrote: 2012-05-04 Rainer Orthr...@cebitec.uni-bielefeld.de * configure.ac: Add $XPCFLAGS to CFLAGS, not $XCFLAGS. * configure: Regenerate. Ok. r~
Re: [libatomic] Allow for objects in libatomic_la_LIBADD
On 05/07/2012 04:23 AM, Rainer Orth wrote: 2012-05-05 Rainer Orthr...@cebitec.uni-bielefeld.de * Makefile.am (libatomic.map-sun): Handle objects in libatomic_la_LIBADD. * aclocal.m4: Regenerate. * Makefile.in: Regenerate. Ok. r~
Re: [PATCH] libgcov support for profile collection in region of interest (issue6186044)
+Honza and Nathan.
David
On Thu, May 3, 2012 at 10:52 AM, Teresa Johnson tejohn...@google.com wrote:
This patch adds functionality to libgcov to enable user applications to
collect profile data only in regions of interest. This is useful, for
example, to collect profile data from a long-running server only
during the time when it is serving requests.
Specifically, the new routines __gcov_reset will clear all profile counters
to zero and __gcov_dump will write out the profile information collected so
far. A global variable is used to prevent writing out the profile a
second time during exit.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Is this ok for trunk?
Thanks,
Teresa
2012-05-03 Teresa Johnson tejohn...@google.com
* libgcc/libgcov.c (gcov_clear, __gcov_reset): New functions.
(__gcov_dump): Ditto.
(gcov_dump_complete): New global variable.
(__gcov_flush): Outline functionality now in gcov_clear.
* gcc/gcov-io.h (__gcov_reset, __gcov_dump): Declare.
Index: libgcc/libgcov.c
===
--- libgcc/libgcov.c (revision 187048)
+++ libgcc/libgcov.c (working copy)
@@ -48,6 +48,8 @@ see the files COPYING3 and COPYING.RUNTIME respect
#ifdef L_gcov
void __gcov_init (struct gcov_info *p __attribute__ ((unused))) {}
void __gcov_flush (void) {}
+void __gcov_reset (void) {}
+void __gcov_dump (void) {}
#endif
#ifdef L_gcov_merge_add
@@ -91,6 +93,9 @@ static struct gcov_info *gcov_list;
/* Size of the longest file name. */
static size_t gcov_max_filename = 0;
+/* Flag when the profile has already been dumped via __gcov_dump(). */
+static int gcov_dump_complete = 0;
+
/* Make sure path component of the given FILENAME exists, create
missing directories. FILENAME must be writable.
Returns zero on success, or -1 if an error occurred. */
@@ -286,6 +291,11 @@ gcov_exit (void)
char *gi_filename, *gi_filename_up;
gcov_unsigned_t crc32 = 0;
+ /* Prevent the counters from being dumped a second time on exit when the
+ application already wrote out the profile using __gcov_dump(). */
+ if (gcov_dump_complete)
+ return;
+
memset (all_prg, 0, sizeof (all_prg));
/* Find the totals for this execution. */
memset (this_prg, 0, sizeof (this_prg));
@@ -679,6 +689,37 @@ gcov_exit (void)
}
}
+/* Reset all counters to zero. */
+
+static void
+gcov_clear (void)
+{
+ const struct gcov_info *gi_ptr;
+
+ for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
+ {
+ unsigned f_ix;
+
+ for (f_ix = 0; f_ix gi_ptr-n_functions; f_ix++)
+ {
+ unsigned t_ix;
+ const struct gcov_fn_info *gfi_ptr = gi_ptr-functions[f_ix];
+
+ if (!gfi_ptr || gfi_ptr-key != gi_ptr)
+ continue;
+ const struct gcov_ctr_info *ci_ptr = gfi_ptr-ctrs;
+ for (t_ix = 0; t_ix != GCOV_COUNTERS; t_ix++)
+ {
+ if (!gi_ptr-merge[t_ix])
+ continue;
+
+ memset (ci_ptr-values, 0, sizeof (gcov_type) * ci_ptr-num);
+ ci_ptr++;
+ }
+ }
+ }
+}
+
/* Add a new object file onto the bb chain. Invoked automatically
when running an object file's global ctors. */
@@ -730,38 +771,38 @@ init_mx_once (void)
void
__gcov_flush (void)
{
- const struct gcov_info *gi_ptr;
-
init_mx_once ();
__gthread_mutex_lock (__gcov_flush_mx);
gcov_exit ();
- for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
- {
- unsigned f_ix;
+ gcov_clear ();
- for (f_ix = 0; f_ix gi_ptr-n_functions; f_ix++)
- {
- unsigned t_ix;
- const struct gcov_fn_info *gfi_ptr = gi_ptr-functions[f_ix];
+ __gthread_mutex_unlock (__gcov_flush_mx);
+}
- if (!gfi_ptr || gfi_ptr-key != gi_ptr)
- continue;
- const struct gcov_ctr_info *ci_ptr = gfi_ptr-ctrs;
- for (t_ix = 0; t_ix != GCOV_COUNTERS; t_ix++)
- {
- if (!gi_ptr-merge[t_ix])
- continue;
-
- memset (ci_ptr-values, 0, sizeof (gcov_type) * ci_ptr-num);
- ci_ptr++;
- }
- }
- }
+/* Function that can be called from application to reset counters to zero,
+ in order to collect profile in region of interest. */
- __gthread_mutex_unlock (__gcov_flush_mx);
+void
+__gcov_reset (void)
+{
+ gcov_clear ();
+ /* Re-enable dumping to support collecting profile in multiple regions
+ of interest. */
+ gcov_dump_complete = 0;
}
+/* Function that can be called from application to write profile collected
+ so far, in order to collect profile in region of interest. */
+
+void
+__gcov_dump (void)
+{
+ gcov_exit ();
+ /* Prevent profile from being dumped a second time on application exit. */
+ gcov_dump_complete = 1;
+}
+
#endif /* L_gcov */
#ifdef L_gcov_merge_add
Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
On Mon, 7 May 2012, Olivier Hainque wrote: Joseph and David suggested to address this in a more general fashion, along lines proposed in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html The attached patch is a first shot in this direction. Only lightly tested at this point, posted to get a first round of comments to validate that this corresponds to what was suggested. I haven't checked the details of the patch, but it does look substantially along the lines of what I think the logic should be. -- Joseph S. Myers jos...@codesourcery.com
[C++ Patch] PR 53158
Hi,
for this testcase:
int main()
{
auto a = []() { return true; };
auto b = []() { return a(); }; // { dg-error 'a' is not captured }
int c, d;
while (b() c d)
{
}
}
we produce meaningless diagnostics for the while loop (stemming from b()
but the caret is also in the wrong place, a separate issue):
error: invalid operands of types ‘void’ and ‘int’ to binary ‘operator!=’
because nothing notices in cp_parser_lambda_body that
cp_parser_expression went wrong, thus finish_return_stmt (expr) is
called on expr == error_mark_node. The way I'm handling the problem is
by returning false to the caller, cp_parser_lambda_expression, which is
already equipped to smoothly handle errors and return back error_mark_node.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2012-05-07 Paolo Carlini paolo.carl...@oracle.com
PR c++/53158
* parser.c (cp_parser_lambda_body): Return a boolean, false if
cp_parser_expression returns error_mark_node;
(cp_parser_lambda_expression): Check the latter.
/testsuite
2012-05-07 Paolo Carlini paolo.carl...@oracle.com
PR c++/53158
* g++.dg/cpp0x/lambda/lambda-err2.C: New.
Index: testsuite/g++.dg/cpp0x/lambda/lambda-err2.C
===
--- testsuite/g++.dg/cpp0x/lambda/lambda-err2.C (revision 0)
+++ testsuite/g++.dg/cpp0x/lambda/lambda-err2.C (revision 0)
@@ -0,0 +1,12 @@
+// PR c++/53158
+// { dg-do compile { target c++11 } }
+
+int main()
+{
+ auto a = []() { return true; };
+ auto b = []() { return a(); }; // { dg-error 'a' is not captured }
+ int c, d;
+ while (b() c d)
+{
+}
+}
Index: cp/parser.c
===
--- cp/parser.c (revision 187249)
+++ cp/parser.c (working copy)
@@ -1848,7 +1848,7 @@ static void cp_parser_lambda_introducer
(cp_parser *, tree);
static bool cp_parser_lambda_declarator_opt
(cp_parser *, tree);
-static void cp_parser_lambda_body
+static bool cp_parser_lambda_body
(cp_parser *, tree);
/* Statements [gram.stmt.stmt] */
@@ -8101,7 +8101,7 @@ cp_parser_lambda_expression (cp_parser* parser)
ok = cp_parser_lambda_declarator_opt (parser, lambda_expr);
if (ok)
- cp_parser_lambda_body (parser, lambda_expr);
+ ok = cp_parser_lambda_body (parser, lambda_expr);
else if (cp_parser_require (parser, CPP_OPEN_BRACE, RT_OPEN_BRACE))
cp_parser_skip_to_end_of_block_or_statement (parser);
@@ -8466,11 +8466,13 @@ cp_parser_lambda_declarator_opt (cp_parser* parser
but which requires special handling.
LAMBDA_EXPR is the current representation of the lambda expression. */
-static void
+static bool
cp_parser_lambda_body (cp_parser* parser, tree lambda_expr)
{
bool nested = (current_function_decl != NULL_TREE);
bool local_variables_forbidden_p = parser-local_variables_forbidden_p;
+ bool ok = true;
+
if (nested)
push_function_context ();
else
@@ -8540,6 +8542,8 @@ cp_parser_lambda_body (cp_parser* parser, tree lam
cp_parser_require_keyword (parser, RID_RETURN, RT_RETURN);
expr = cp_parser_expression (parser, /*cast_p=*/false, idk);
+ if (expr == error_mark_node)
+ ok = false;
cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
cp_parser_require (parser, CPP_CLOSE_BRACE, RT_CLOSE_BRACE);
@@ -8579,6 +8583,8 @@ cp_parser_lambda_body (cp_parser* parser, tree lam
pop_function_context();
else
--function_depth;
+
+ return ok;
}
/* Statements [gram.stmt.stmt] */
[AVR,committed]: Fix ICE for plus_constant with bad mode
Committed to fix ICE during library build from r187199: http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00255.html Johann
Re: [patch] Fix plugin-enabled LTO with cross-native build
On Fri, May 4, 2012 at 10:35 AM, Eric Botcazou ebotca...@adacore.com wrote: 2012-05-04 Eric Botcazou ebotca...@adacore.com * configure.ac (PLUGIN_LD): Rename into... (PLUGIN_LD_SUFFIX): ...this and strip the target_alias triplet. * config.in: Regenerate. * configure: Likewise. * collect2.c (main): Set plugin_ld_suffix to PLUGIN_LD_SUFFIX. OK. Diego.
Re: User directed Function Multiversioning via Function Overloading (issue5752064)
On Wed, May 2, 2012 at 11:04 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, May 2, 2012 at 10:44 AM, Sriraman Tallam tmsri...@google.com wrote: 1. Since AVX SSE4 SSSE3 SSE3 SSE2 SSE, with foo for AVX and SSE3, on AVX processors, which foo will be selected? foo for AVX will get called since that appears ahead. The dispatching is done in the same order in which the functions are specified. If, potentially, two foo versions can be dispatched for an architecture, the first foo will get called. There is no way right now to specify the order in which the dispatching should be done. This is very fragile. We know ISAs and processors. The source order should be irrelevant. I am not sure it is always possible keep this dispatching unambiguous to the user. It might be better to let the user specify a priority for each version to control the order of dispatching. Still, one way to implement what you said is to assign a significance number to each ISA, where the number of sse4 sse, for instance. Then, the dispatching can be done in the descending order of significance. What do you think? This sounds reasonable. You should also take processor into account when doing this. I thought about this earlier and I was thinking along the lines of letting the user specify a priority for each version, when there is ambiguity. 2. I don't see any tests for __builtin_cpu_supports (XXX) nor __builtin_cpu_is (XXX). I think you need tests for them. This is already there as part of the previous CPU detection patch that was submitted. Please see gcc.target/i386/builtin_target.c. Did you want something else? gcc.target/i386/builtin_target.c doesn't test if __builtin_cpu_supports (XXX) and __builtin_cpu_is (XXX) are implemented correctly. Oh, you mean like doing a CPUID again in the test case itself and checking, ok. Yes. BTW, I think you should also add FMA support to config/i386/i386-cpuinfo.c. I am preparing a patch for this. I will send it your way soon enough. Thanks, -Sri. Thanks. -- H.J.
Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
On Mon, May 7, 2012 at 12:10 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 7 May 2012, Olivier Hainque wrote: Joseph and David suggested to address this in a more general fashion, along lines proposed in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01667.html The attached patch is a first shot in this direction. Only lightly tested at this point, posted to get a first round of comments to validate that this corresponds to what was suggested. I haven't checked the details of the patch, but it does look substantially along the lines of what I think the logic should be. Yes, exactly. If we can work through the fallout, this is exactly the type of cleanup I envisioned. Thanks, David
Re: [C++ Patch] PR 53158
I don't think the diagnostic is meaningless; since a() is ill-formed, b() has type void. But we ought to give a more helpful message when an expression used as a truth value has an unsuitable type. Jason
Re: [C++ Patch] PR 53158
On 05/07/2012 07:16 PM, Jason Merrill wrote: I don't think the diagnostic is meaningless; since a() is ill-formed, b() has type void. Sure we do understand it ;) But we ought to give a more helpful message when an expression used as a truth value has an unsuitable type. Thus something much more general than the lambda context of the PR. Ok, I can see what I can do. Thanks! Paolo.
Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
On May 7, 2012, at 18:59 , David Edelsohn wrote: Yes, exactly. If we can work through the fallout, this is exactly the type of cleanup I envisioned. Great :) Thanks, David Do you want a PR for the fallout ? It is not related to this patch at all. I can look into it further and make suggestions but this is part of a recent prologue/epilogue reorg with which I'm not yet too familiar. Olivier
Re: [C++ Patch] PR 53158
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
On 05/07/2012 07:16 PM, Jason Merrill wrote:
I don't think the diagnostic is meaningless; since a() is ill-formed,
b() has type void.
Sure we do understand it ;)
But we ought to give a more helpful message when an expression used
as a truth value has an unsuitable type.
Thus something much more general than the lambda context of the PR.
Ok, I can see what I can do.
I think this is the minimal testcase we are looking for:
void foo();
void bar(int a, int b)
{
if (foo() a b)
;
}
the error message is the same we see in PR 53158, thus:
a.cc:5:20: error: invalid operands of types ‘void’ and ‘int’ to binary
‘operator!=’
if (foo() a b)
If I take out the 'a b' subexpression, we get:
a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
if (foo())
Is this the error message we want to see for the former testcase, or we
want something slightly different?
Thanks!
Paolo.
[google/gcc-4_6] Fission improvements and bug fixes (issue6189052)
This patch is for the google/gcc-4_6 branch.
Fission improvements and bug fixes. Move the .debug_loc section to the
.dwo file, and eliminates the .debug_ref section, replacing references
to range list entries with offsets relative to the value given by
DW_AT_GNU_ranges_base.
Bootstrapped and tested on x86_64.
2012-05-07 Sterling Augustine saugust...@google.com
Cary Coutant ccout...@google.com
include/
* dwarf2.h (enum dwarf_form): Remove DW_FORM_GNU_ref_index.
(enum dwarf_attribute): Replace DW_AT_GNU_ref_base with
DW_AT_GNU_ranges_base.
gcc/
* gcc/dwarf2out.c (debug_ref_section): Remove.
(struct dw_loc_list_struct): Add begin_index, end_index fields.
(DEBUG_REF_SECTION): Remove.
(DEBUG_NORM_MACINFO_SECTION, DEBUG_DWO_MACINFO_SECTION): New macros.
(DEBUG_MACINFO_SECTION): Define condtionally on
dwarf_split_debug_info.
(DEBUG_DWO_LOC_SECTION): New macro.
(DEBUG_REF_SECTION_LABEL): Remove.
debug_ref_section_label: Remove.
(dwarf_attr_name): Replace DW_AT_GNU_ref_base with
DW_AT_GNU_ranges_base.
(dwarf_form_name): Remove DW_FORM_GNU_ref_index.
(AT_index): Adjust comment.
(addr_index_table): Adjust comment.
(ref_index_table): Remove.
(add_ref_table_entry): Remove.
(add_AT_range_list): Save offset for direct references.
(size_of_die): Always use offset size for range list references.
(value_format): Use section offset for range list and location list
references.
(new_loc_list): Initialize begin_index and end_index.
(output_loc_list): Handle special format for .debug_loc.dwo sections.
(output_range_list_offset): Output plain offset for range list
reference when splitting dwarf info.
(output_loc_list_offset): Output plain offset for location list
reference when splitting dwarf info.
(output_attr_index_or_value): Remove case dw_val_class_range_list.
(output_die): Call output_range_list_offset for range list references.
(add_top_level_skeleton_die_attrs): Remove DW_AT_GNU_ref_base.
(add_enumerator_pubname): Remove SEP parameter; add correct pubtype
entry for anonymous enums.
(add_pubtype): Add correct pubtype entry for anonymous enums.
(gen_enumeration_type_die): Likewise.
(dwarf2out_init): Create .debug_loc.dwo section; remove
debug_ref_section.
(output_ref_table): Remove.
(index_location_lists): Set begin_index and end_index for each item
in a location list.
(dwarf2out_finish): Add DW_AT_macro_info to the compile_unit DIE
instead of the skeleton. Don't call index_location_lists when not
splitting dwarf info. Add DW_AT_GNU_ranges_base attribute to
compile_unit DIE. Move generation of loc_section_label to
dwarf2out_init. Remove .debug_ref section.
Index: include/dwarf2.h
===
--- include/dwarf2.h(revision 187169)
+++ include/dwarf2.h(working copy)
@@ -185,7 +185,6 @@ enum dwarf_form
DW_FORM_ref_sig8 = 0x20,
#define DW_FORM_sig8 DW_FORM_ref_sig8 /* Note: The use of DW_FORM_sig8 is
deprecated. */
/* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */
-DW_FORM_GNU_ref_index = 0x1f00,
DW_FORM_GNU_addr_index = 0x1f01,
DW_FORM_GNU_str_index = 0x1f02
};
@@ -358,7 +357,7 @@ enum dwarf_attribute
/* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */
DW_AT_GNU_dwo_name = 0x2130,
DW_AT_GNU_dwo_id = 0x2131,
-DW_AT_GNU_ref_base = 0x2132,
+DW_AT_GNU_ranges_base = 0x2132,
DW_AT_GNU_addr_base = 0x2133,
DW_AT_GNU_pubnames = 0x2134,
DW_AT_GNU_pubtypes = 0x2135,
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 187169)
+++ gcc/dwarf2out.c (working copy)
@@ -229,7 +229,6 @@ static GTY(()) section *debug_skeleton_i
static GTY(()) section *debug_abbrev_section;
static GTY(()) section *debug_skeleton_abbrev_section;
static GTY(()) section *debug_aranges_section;
-static GTY(()) section *debug_ref_section;
static GTY(()) section *debug_addr_section;
static GTY(()) section *debug_macinfo_section;
static GTY(()) section *debug_line_section;
@@ -4437,8 +4436,10 @@ dw_loc_descr_node;
their entire life. */
typedef struct GTY(()) dw_loc_list_struct {
dw_loc_list_ref dw_loc_next;
- const char *begin; /* Label for begin address of range */
- const char *end; /* Label for end address of range */
+ const char *begin; /* Label and index for begin address of range */
+ unsigned int begin_index;
+ const char *end; /* Label and index for end address of range */
+ unsigned int end_index;
char *ll_symbol; /* Label for beginning of location list.
Only on head of
[Patch,AVR,trunk,4.7]: Implement PR53256
AVR-LibC switched from using either signal /or/ interrupt function
attribute to using both at the same time.
This was never documented or implemented but worked accidentally for
some time, but results in wrong code for 4.7+
This patch adds better documentation of these attributes and makes
'interrupt' silently override 'signal'.
Besides that, some more sanity checking is done for function attributes.
ASM_DECLARE_FUNCTION_NAME just served to check isr names.
All the checking is done in the new hook TARGET_SET_CURRENT_FUNCTION
now so that ASM_DECLARE_FUNCTION_NAME from defaults.h can be used,
thus some clean-up in elf.h
Ok for trunk and 4.7?
Johann
PR target/53256
* config/avr/elf.h (ASM_DECLARE_FUNCTION_NAME): Remove.
* config/avr/avr-protos.h (avr_asm_declare_function_name): Remove.
* config/avr/avr.h (struct machine_function): Add attributes_checked_p.
* config/avr/avr.c (avr_asm_declare_function_name): Remove.
(expand_prologue): Move initialization of cfun-machine-is_naked,
is_interrupt, is_signal, is_OS_task, is_OS_main from here to...
(avr_regs_to_save): Ditto.
(avr_set_current_function): ...this new static function.
(TARGET_SET_CURRENT_FUNCTION): New define.
(avr_function_ok_for_sibcall): Use cfun-machine-is_* instead of
checking attributes of current_function_decl.
(signal_function_p): Rename to avr_signal_function_p.
(interrupt_function_p): Rename to avr_interrupt_function_p.
* doc/extend.texi (Function Attributes): Better explanation of
'interrupt' and 'signal for AVR. Move 'ifunc' down for
alphabetical order.
Index: config/avr/elf.h
===
--- config/avr/elf.h (revision 187252)
+++ config/avr/elf.h (working copy)
@@ -32,11 +32,6 @@
#undef STRING_LIMIT
#define STRING_LIMIT ((unsigned) 64)
-/* Take care of `signal' and `interrupt' attributes. */
-#undef ASM_DECLARE_FUNCTION_NAME
-#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
- avr_asm_declare_function_name ((FILE), (NAME), (DECL))
-
/* Output alignment 2**1 for jump tables. */
#undef ASM_OUTPUT_BEFORE_CASE_LABEL
#define ASM_OUTPUT_BEFORE_CASE_LABEL(FILE, PREFIX, NUM, TABLE) \
Index: config/avr/avr-protos.h
===
--- config/avr/avr-protos.h (revision 187252)
+++ config/avr/avr-protos.h (working copy)
@@ -26,7 +26,6 @@ extern int function_arg_regno_p (int r);
extern void avr_cpu_cpp_builtins (struct cpp_reader * pfile);
extern enum reg_class avr_regno_reg_class (int r);
extern void asm_globalize_label (FILE *file, const char *name);
-extern void avr_asm_declare_function_name (FILE *, const char *, tree);
extern void order_regs_for_local_alloc (void);
extern int avr_initial_elimination_offset (int from, int to);
extern int avr_simple_epilogue (void);
Index: config/avr/avr.c
===
--- config/avr/avr.c (revision 187259)
+++ config/avr/avr.c (working copy)
@@ -138,12 +138,6 @@ static const char* out_movqi_mr_r (rtx,
static const char* out_movhi_mr_r (rtx, rtx[], int*);
static const char* out_movsi_mr_r (rtx, rtx[], int*);
-static int avr_naked_function_p (tree);
-static int interrupt_function_p (tree);
-static int signal_function_p (tree);
-static int avr_OS_task_function_p (tree);
-static int avr_OS_main_function_p (tree);
-static int avr_regs_to_save (HARD_REG_SET *);
static int get_sequence_length (rtx insns);
static int sequent_regs_live (void);
static const char *ptrreg_to_str (int);
@@ -491,7 +485,7 @@ avr_naked_function_p (tree func)
by the interrupt attribute. */
static int
-interrupt_function_p (tree func)
+avr_interrupt_function_p (tree func)
{
return avr_lookup_function_attribute1 (func, interrupt);
}
@@ -500,7 +494,7 @@ interrupt_function_p (tree func)
by the signal attribute. */
static int
-signal_function_p (tree func)
+avr_signal_function_p (tree func)
{
return avr_lookup_function_attribute1 (func, signal);
}
@@ -522,6 +516,80 @@ avr_OS_main_function_p (tree func)
}
+/* Implement `TARGET_SET_CURRENT_FUNCTION'. */
+/* Sanity cheching for above function attributes. */
+
+static void
+avr_set_current_function (tree decl)
+{
+ location_t loc;
+ const char *isr;
+
+ if (decl == NULL_TREE
+ || current_function_decl == NULL_TREE
+ || current_function_decl == error_mark_node
+ || cfun-machine-attributes_checked_p)
+return;
+
+ loc = DECL_SOURCE_LOCATION (decl);
+
+ cfun-machine-is_naked = avr_naked_function_p (decl);
+ cfun-machine-is_signal = avr_signal_function_p (decl);
+ cfun-machine-is_interrupt = avr_interrupt_function_p (decl);
+ cfun-machine-is_OS_task = avr_OS_task_function_p (decl);
+ cfun-machine-is_OS_main = avr_OS_main_function_p (decl);
+
+ isr = cfun-machine-is_interrupt ? interrupt : signal;
+
+ /* Too much
Re: [PATCH, Android] Stack protector enabling for Android target
On 6/05/2012, at 7:02 PM, Igor Zamyatin wrote: Hi! The patch enables stack protector for Android. Android targets don't contain necessary information in features.h so we explicitly enable stack protector for Android. Bootstrapped and regtested on x86_64. Ok to commit? Thanks, Igor 2012-05-06 Igor Zamyatin igor.zamya...@intel.com * configure.ac: Stack protector enabling for Android targets. * configure: Regenerate. diff --git a/gcc/configure.ac b/gcc/configure.ac index 86b4bea..c1012d6 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -4545,6 +4545,8 @@ AC_CACHE_CHECK(__stack_chk_fail in target C library, gcc_cv_libc_provides_ssp, [gcc_cv_libc_provides_ssp=no case $target in + *-android*) + gcc_cv_libc_provides_ssp=yes;; *-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu) [# glibc 2.4 and later provides __stack_chk_fail and # either __stack_chk_guard, or TLS access to stack guard canary. What you really want is to enable stack protector for Bionic libc, which is often synonymous with -android* target, but not always. Let's enable ssp based on whether __BIONIC__ is defined in the libc headers (i.e., add a grep test for __BIONIC__ in sys/cdefs.h) Also please add a comment along the lines of all versions of Bionic support stack protector. Which exact target did you test this on? X86_64-*-* is a pretty broad definition. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: [C++ Patch] PR 53158
On 7 May 2012 19:40, Paolo Carlini paolo.carl...@oracle.com wrote:
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
if (foo())
Is this the error message we want to see for the former testcase, or we want
something slightly different?
If foo() is printed with %qE, and now that we have caret
diagnostics, I would expect the message to be:
error: could not convert expression from 'void' to 'bool'
For comparison, this is what Clang gives:
/tmp/webcompile/_8320_0.cc:7:6: error: value of type 'void' is not
contextually convertible to 'bool'
if (foo() a b)
^
/tmp/webcompile/_8320_0.cc:7:12: error: invalid operands to binary
expression ('void' and 'bool')
if (foo() a b)
~ ^ ~
2 errors generated.
G++ could do better in this case, foo() is likely to be some kind of
FUNCTION_DECL, so g++ could be smarter and say something like:
error: could not convert return type of 'foo' from 'void' to 'bool'
note: 'foo' declared here
Just a suggestion.
Cheers,
Manuel.
Re: [PATCH, Android] Stack protector enabling for Android target
On Mon, May 7, 2012 at 11:04 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote: On 6/05/2012, at 7:02 PM, Igor Zamyatin wrote: Hi! The patch enables stack protector for Android. Android targets don't contain necessary information in features.h so we explicitly enable stack protector for Android. Bootstrapped and regtested on x86_64. Ok to commit? Thanks, Igor 2012-05-06 Igor Zamyatin igor.zamya...@intel.com * configure.ac: Stack protector enabling for Android targets. * configure: Regenerate. diff --git a/gcc/configure.ac b/gcc/configure.ac index 86b4bea..c1012d6 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -4545,6 +4545,8 @@ AC_CACHE_CHECK(__stack_chk_fail in target C library, gcc_cv_libc_provides_ssp, [gcc_cv_libc_provides_ssp=no case $target in + *-android*) + gcc_cv_libc_provides_ssp=yes;; *-*-linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu) [# glibc 2.4 and later provides __stack_chk_fail and # either __stack_chk_guard, or TLS access to stack guard canary. What you really want is to enable stack protector for Bionic libc, which is often synonymous with -android* target, but not always. Let's enable ssp based on whether __BIONIC__ is defined in the libc headers (i.e., add a grep test for __BIONIC__ in sys/cdefs.h) Also please add a comment along the lines of all versions of Bionic support stack protector. Which exact target did you test this on? X86_64-*-* is a pretty broad definition. We are working on x86_64-*-linux-android target, which uses x32. -- H.J.
Re: [C++ Patch] PR 53158
Hi,
On 05/07/2012 08:07 PM, Manuel López-Ibáñez wrote:
On 7 May 2012 19:40, Paolo Carlinipaolo.carl...@oracle.com wrote:
On 05/07/2012 07:18 PM, Paolo Carlini wrote:
a.cc:5:12: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
if (foo())
Is this the error message we want to see for the former testcase, or we want
something slightly different?
If foo() is printed with %qE, and now that we have caret
diagnostics, I would expect the message to be:
error: could not convert expression from 'void' to 'bool'
A basic fix seems reasonably easy (modulo the caret in the wrong place,
I guess we have to pass down more locations): instead of just
unconditionally forwarding to c_common_truthvalue_conversion from
cp_truthvalue_conversion, which seems a bad idea, given this comment
preceding the former:
/* Prepare expr to be an argument of a TRUTH_NOT_EXPR,
or for an `if' or `while' statement or ?..: exp. It should already
have been validated to be of suitable type; otherwise, a bad
diagnostic may result.
note in particular the last two lines ;) we could tell apart CALL_EXPRs
and pass those through condition_conversion (tree expr). Seems ok also
from the optimization point of view, becase CALL_EXPRs are not handled
by c_common_truthvalue_conversion, and just forwarded to
cp_build_binary_op to build an appropriate (incorrect in this specific
case) NE_EXPR.
Something like the quick hack below gives:
a.cc:5:20: error: could not convert ‘foo()’ from ‘void’ to ‘bool’
if (foo() a b)
Paolo.
//
Index: typeck.c
===
--- typeck.c(revision 187249)
+++ typeck.c(working copy)
@@ -4782,7 +4782,11 @@ cp_truthvalue_conversion (tree expr)
return ret;
}
else
-return c_common_truthvalue_conversion (input_location, expr);
+{
+ if (TREE_CODE (expr) == CALL_EXPR)
+ return condition_conversion (expr);
+ return c_common_truthvalue_conversion (input_location, expr);
+}
}
/* Just like cp_truthvalue_conversion, but we want a
CLEANUP_POINT_EXPR. */
Go patch committed: Don't permit !0
This patch from Rémy Oudompheng fixes a bug in the Go frontend: it was
permitting the ! unary operator with integer operands, but in the Go
language ! is only permitted with boolean operands. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and
4.7 branch.
Ian
diff -r 838f1f13015d go/expressions.cc
--- a/go/expressions.cc Fri May 04 12:30:49 2012 -0700
+++ b/go/expressions.cc Mon May 07 11:19:42 2012 -0700
@@ -3606,8 +3606,7 @@
return Expression::make_error(this-location());
}
- if (op == OPERATOR_PLUS || op == OPERATOR_MINUS
- || op == OPERATOR_NOT || op == OPERATOR_XOR)
+ if (op == OPERATOR_PLUS || op == OPERATOR_MINUS || op == OPERATOR_XOR)
{
Numeric_constant nc;
if (expr-numeric_constant_value(nc))
@@ -3697,10 +3696,10 @@
else
go_unreachable();
+case OPERATOR_XOR:
+ break;
+
case OPERATOR_NOT:
-case OPERATOR_XOR:
- break;
-
case OPERATOR_AND:
case OPERATOR_MULT:
return false;
@@ -3911,6 +3910,10 @@
break;
case OPERATOR_NOT:
+ if (!type-is_boolean_type())
+ this-report_error(_(expected boolean type));
+ break;
+
case OPERATOR_XOR:
if (type-integer_type() == NULL
!type-is_boolean_type())
Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
On Mon, May 7, 2012 at 1:24 PM, Olivier Hainque hain...@adacore.com wrote: On May 7, 2012, at 18:59 , David Edelsohn wrote: Yes, exactly. If we can work through the fallout, this is exactly the type of cleanup I envisioned. Great :) Thanks, David Do you want a PR for the fallout ? It is not related to this patch at all. I can look into it further and make suggestions but this is part of a recent prologue/epilogue reorg with which I'm not yet too familiar. You can open a PR, but I assume that you mean fixing the problem before the patch is committed. I would like to give Alan a chance to comment and look into it. Thanks, David
Re: [C++ Patch] PR 53158
On 05/07/2012 08:23 PM, Paolo Carlini wrote:
Index: typeck.c
===
--- typeck.c(revision 187249)
+++ typeck.c(working copy)
@@ -4782,7 +4782,11 @@ cp_truthvalue_conversion (tree expr)
return ret;
}
else
-return c_common_truthvalue_conversion (input_location, expr);
+{
+ if (TREE_CODE (expr) == CALL_EXPR)
+ return condition_conversion (expr);
+ return c_common_truthvalue_conversion (input_location, expr);
+}
}
/* Just like cp_truthvalue_conversion, but we want a
CLEANUP_POINT_EXPR. */
Well, not exactly like this because it recurses forever when the code is
fine ;) but I think you get the idea, we don't want to unconditionally
use c_common_truthvalue_conversion and we want to stop *before* trying
to synthesize a NE_EXPR.
About the error message proper, the locations are currently pretty wrong
for these code paths - is always too advanced, at the end of the
expression, I'm afraid fixing that will require touching quite a few
lines of code.
Paolo.
Go patch committed: Fix handling of ^'a'
This patch from Rémy Oudompheng fixes the handling of ^'a' or -'^' in the Go frontend. It used to crash, rather than computing the appropriate value. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch. Ian #part type=text/x-diff filename=~/foo.patch disposition=inline description=patch #/part
Go patch committed: Fix handling of ^'a'
This patch from Rémy Oudompheng fixes the handling of ^'a' or -'^' in the Go frontend. It used to crash, rather than computing the appropriate value. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch. Ian #part type=text/x-diff filename=~/foo.patch disposition=inline description=patch #/part
Go patch committed: Don't treat 0x123i as 123i
This patch from Rémy Oudompheng fixes the Go frontend lexer to not treat
0x123i as 123i. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r 8671bcd0c298 go/lex.cc
--- a/go/lex.cc Mon May 07 11:35:33 2012 -0700
+++ b/go/lex.cc Mon May 07 11:50:46 2012 -0700
@@ -1012,7 +1012,9 @@
}
}
- if (*p != '.' *p != 'i' !Lex::could_be_exponent(p, pend))
+ // A partial token that looks like an octal literal might actually be the
+ // beginning of a floating-point or imaginary literal.
+ if (base == 16 || (*p != '.' *p != 'i' !Lex::could_be_exponent(p, pend)))
{
std::string s(pnum, p - pnum);
mpz_t val;
Re: [C Patch]: pr52543
On May 4, 2012, at 4:01 PM, Georg-Johann Lay wrote: Mike Stump schrieb: On May 3, 2012, at 12:50 PM, Georg-Johann Lay wrote: It's hardly possible to write proper rtx_costs for SET: 1) What should be the cost of (const_int 1) if you don't see the machine mode? Is it QI, is it HI, is it SI or whatever? You can choose to see the complete expression in its entirety and form the cost for it. (set (reg:DI 1) (const_int 1)) Sorry, for the dumb question, but I still don't get it. Ah, so, I answered the question, if there are no machine independent bugs, how would you do it... Unstated in my email, is that I think that anybody (the machine independent code) that wants a better cost, needs to ask a more complete question of the port. I view TARGET_RTX_COSTS as the answer for that question. Stated differently, if an optimization pass has the information, a mode, a memory space, the containing expression, and those details matter, then you should merely submit bug fix requests for each instance to have them include those details into the question, as those details matter. If you only get the question x = (const_int 1) outer = SET, and this comes from other than rtx_costs, than this would be such an instance where the machine independent code should be changed. If it comes from rtx_costs in the recursive case, then previous to this question _was_ a question for the more complete case that the port ignored. TARGET_RTX_COSTS gets called with x = (const_int 1) and outer = SET for example. How do I get SET_DEST from that information? I don't now if lower-subreg.s ever emits such cost requests, but several passes definitely do. They are wrong (overly simplistic). There are machines with complex instructions sets like 4-operand OR and combined OR and SHIFT or similar. Instead of writing hundreds or thousands of lines in rtx_costs and XEXP TARGET_RTX_COSTS (effectively rewriting insn-recog.c) it would be straight forward to attach costs to insns and use recog + insn_attr to get the costs. I tried that approach (write costs as insn attribute and use recog to get the costs) in a backend and it works smooth and really helped to keep the backend clean and maintainable. Wow, cool. I have costs, and I'd like a solution that feels cleaner to me, that certainly feels cleaner. Calling recog seems scary to me... the problem is that your supposed to get the costs of arbitrarily large code snippets, if you need multiple insns, you're supposed to add of all of them up. Does this solution work when multiple instructions are needed? If recog says it isn't a valid instruction, what do you do? I shudder at the thought of replicating combine or reload... 3) Likewise, the costs of MEM are peeled of MEM and pass just the address without any information on the MEM like it's address space. Cost might highly depend on the address space involved. Yes, that is why on my machine: (set (mem) (reg)) has one set of costs, and (set (reg) (mem)) What hook are we talking about? TARGET_RTX_COSTS? (not called with outer=PATTERN) This one... I merely saw an instance where the machine independent code asked the right question...
Re: [google/gcc-4_6_2-mobile] Port of Android target support in i386 for google/gcc-4_6_2-mobile branch
I would like to port this patch to google/gcc-4_6 and also google/gcc-4_6_2-mobile. From reading the patch, it does not change config for non-Android target. bootstrap,crosstool tests finished successfully on google/gcc-4_6. Built ARM android toolchain successfully. OK? Thanks, Jing On Thu, May 3, 2012 at 1:51 AM, Ilya Enkovich enkovich@gmail.com wrote: Hi, here is a port of Android support patch (http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00944.html) for google/gcc-4_6_2-mobile branch. Is it OK? Bootstrapped on linux-x86_64. Successfullly used for NDK release build and Android ICS build. Thanks, Ilya --- 2012-05-03 Enkovich Ilya ilya.enkov...@intel.com * config/linux-android.h (ANDROID_STARTFILE_SPEC): Fix shared case. (ANDROID_ENDFILE_SPEC): Likewise. * config/i386/linux.h (TARGET_OS_CPP_BUILTINS): Add Android builtins. (LINUX_TARGET_CC1_SPEC): New. (CC1_SPEC): Support Android. (LINUX_TARGET_LINK_SPEC): New. (LINK_SPEC): Support Android. (LIB_SPEC): New. (STARTFILE_SPEC): New. (LINUX_TARGET_ENDFILE_SPEC): New. (ENDFILE_SPEC): Support Android. * config/i386/linux64.h: Likewise.
Re: PR 53249: Multiple address modes for same address space
On Sun, May 6, 2012 at 11:41 AM, Richard Sandiford rdsandif...@googlemail.com wrote: x32 uses a mixture of MEM address modes for the same address space. Some MEMs have SImode addresses, some have DImode. This means that the currently common idiom: targetm.addr_space.address_mode (MEM_ADDR_SPACE (mem)) isn't trustworthy. We have to use the mode of the address if it has one, and only fall back on the above for VOIDmode (CONST_INT) addresses. We actually already have two (identical) functions to calculate such a mode. The patch below puts the function in a more general place and uses it instead of the above for rtl-level stuff. I'm not sure whether what x32 is doing is a good thing, but I like the patch anyway because (a) it removes a duplicated function and (b) it at least abstracts the concept away. Bootstrapped regression-tested on x86_64-linux-gnu. Also tested to make sure that there were no differences for cc1 .ii files for MIPS n32, o32 and n64. (I used MIPS to get LO_SUM coverage.) OK to install? Richard gcc/ PR middle-end/53249 * dwarf2out.h (get_address_mode): Move declaration to... * rtl.h: ...here. * dwarf2out.c (get_address_mode): Move definition to... * rtlanal.c: ...here. * var-tracking.c (get_address_mode): Delete. * combine.c (find_split_point): Use get_address_mode instead of targetm.addr_space.address_mode. * cselib.c (cselib_record_sets): Likewise. * dse.c (canon_address, record_store): Likewise. * emit-rtl.c (adjust_address_1, offset_address): Likewise. * expr.c (move_by_pieces, emit_block_move_via_loop, store_by_pieces) (store_by_pieces_1, expand_assignment, store_expr, store_constructor) (expand_expr_real_1): Likewise. * ifcvt.c (noce_try_cmove_arith): Likewise. * optabs.c (maybe_legitimize_operand_same_code): Likewise. * reload.c (find_reloads): Likewise. * sched-deps.c (sched_analyze_1, sched_analyze_2): Likewise. * sel-sched-dump.c (debug_mem_addr_value): Likewise. X32 results look good: http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00704.html Thanks. -- H.J.
[rtl, patch] combine concat+shuffle
Hello,
this patch combines for vectors a concat and a shuffle. An example on x86
would be:
__m128d f(double d){
__m128d x=_mm_setr_pd(-d,d);
return _mm_shuffle_pd(x,x,1);
}
which was compiled as:
vmovsd .LC0(%rip), %xmm1
vxorpd %xmm0, %xmm1, %xmm1
vunpcklpd %xmm0, %xmm1, %xmm0
vshufpd $1, %xmm0, %xmm0, %xmm0
and with the patch:
vmovsd .LC0(%rip), %xmm1
vxorpd %xmm0, %xmm1, %xmm1
vunpcklpd %xmm1, %xmm0, %xmm0
This happens a lot in my code, for interval arithmetics, where I have a
number d, build an interval (-d,d) from it, then subtract that interval
from an other one, and subtraction is implemented as shufpd+addpd.
The patch is quite specialized, but I guessed I could start there, and it
can always be generalized later.
For the testsuite, since the patch is not in a particular target, it would
be better to have a generic test (in gcc.dg?), but I don't really know how
to write a generic one, so would a test in gcc.target/i386 that scans
the asm for shuf or perm be ok?
Ah, and if I use __builtin_shuffle instead of _mm_shuffle_pd, the patch
works without -mavx, but -mavx uses vpermilpd (ie a vec_select:V2DF
(reg:V2DF) ...) instead of a vshufpd, so I'll probably want to handle that
too later. I thought about doing a general transformation from
vec_select(vec_concat(x,x),*) to vec_select(x,*) (reducing the indexes in
* so they fit), but that seemed way too dangerous.
--
Marc GlisseIndex: simplify-rtx.c
===
--- simplify-rtx.c (revision 187228)
+++ simplify-rtx.c (working copy)
@@ -3268,10 +3268,32 @@ simplify_binary_operation_1 (enum rtx_co
if (GET_MODE (vec) == mode)
return vec;
}
+ /* If we build {a,b} then permute it, build the result directly. */
+ if (XVECLEN (trueop1, 0) == 2
+ CONST_INT_P (XVECEXP (trueop1, 0, 0))
+ CONST_INT_P (XVECEXP (trueop1, 0, 1))
+ GET_CODE (trueop0) == VEC_CONCAT
+ rtx_equal_p (XEXP (trueop0, 0), XEXP (trueop0, 1))
+ GET_CODE (XEXP (trueop0, 0)) == VEC_CONCAT
+ GET_MODE (XEXP (trueop0, 0)) == mode)
+ {
+ int offset0 = INTVAL (XVECEXP (trueop1, 0, 0)) % 2;
+ int offset1 = INTVAL (XVECEXP (trueop1, 0, 1)) % 2;
+ rtx baseop = XEXP (trueop0, 0);
+ rtx baseop0 = XEXP (baseop , 0);
+ rtx baseop1 = XEXP (baseop , 1);
+ baseop0 = avoid_constant_pool_reference (baseop0);
+ baseop1 = avoid_constant_pool_reference (baseop1);
+
+ return simplify_gen_binary (VEC_CONCAT, mode,
+offset0 ? baseop1 : baseop0,
+offset1 ? baseop1 : baseop0);
+ }
+
return 0;
case VEC_CONCAT:
{
enum machine_mode op0_mode = (GET_MODE (trueop0) != VOIDmode
? GET_MODE (trueop0)
Re: [google/gcc-4_6_2-mobile] Port of Android target support in i386 for google/gcc-4_6_2-mobile branch
OK for Google branches. On Mon, May 7, 2012 at 12:21 PM, Jing Yu jin...@google.com wrote: I would like to port this patch to google/gcc-4_6 and also google/gcc-4_6_2-mobile. From reading the patch, it does not change config for non-Android target. bootstrap,crosstool tests finished successfully on google/gcc-4_6. Built ARM android toolchain successfully. OK? Thanks, Jing On Thu, May 3, 2012 at 1:51 AM, Ilya Enkovich enkovich@gmail.com wrote: Hi, here is a port of Android support patch (http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00944.html) for google/gcc-4_6_2-mobile branch. Is it OK? Bootstrapped on linux-x86_64. Successfullly used for NDK release build and Android ICS build. Thanks, Ilya --- 2012-05-03 Enkovich Ilya ilya.enkov...@intel.com * config/linux-android.h (ANDROID_STARTFILE_SPEC): Fix shared case. (ANDROID_ENDFILE_SPEC): Likewise. * config/i386/linux.h (TARGET_OS_CPP_BUILTINS): Add Android builtins. (LINUX_TARGET_CC1_SPEC): New. (CC1_SPEC): Support Android. (LINUX_TARGET_LINK_SPEC): New. (LINK_SPEC): Support Android. (LIB_SPEC): New. (STARTFILE_SPEC): New. (LINUX_TARGET_ENDFILE_SPEC): New. (ENDFILE_SPEC): Support Android. * config/i386/linux64.h: Likewise.
[RFC PATCH, i386]: Implement ix86_set_reg_reg_cost, fix PR 53250 Splitting reg failure.
Hello!
Attached patch implements reg-reg move cost function for x86, as
required by new lower-subreg.c patch. The patch fixes:
FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 Splitting reg
failure on 32bit x86 targets, and for following testcase:
long long test (long long a, long long b)
{
return a * b;
}
reverts generated asm code from:
test:
subl$12, %esp
movl%edi, 8(%esp)
movl28(%esp), %edi
movl%ebx, (%esp)
movl16(%esp), %ecx
movl%esi, 4(%esp)
movl20(%esp), %ebx
movl24(%esp), %esi
movl%edi, %eax
imull %ecx, %eax
imull %esi, %ebx
addl%eax, %ebx
movl%ecx, %eax
mull%esi
movl4(%esp), %esi
movl%edx, %edi
addl%ebx, %edi
movl(%esp), %ebx
movl%edi, %edx
movl8(%esp), %edi
addl$12, %esp
ret
back to:
test:
pushl %ebx
movl8(%esp), %edx
movl16(%esp), %eax
movl12(%esp), %ebx
movl20(%esp), %ecx
imull %eax, %ebx
imull %edx, %ecx
mull%edx
addl%ebx, %ecx
addl%ecx, %edx
popl%ebx
ret
Patch was tested on x86_64-pc-linux-gnu {,-m32}.
I have also #define LOG_COST 1 temporarily and looked at generated
cost calculations for various -msse* settings.
I will wait for a day for possible comments on the implementation
before the patch will be committed to mainline SVN.
Uros.
Re: [RFC PATCH, i386]: Implement ix86_set_reg_reg_cost, fix PR 53250 Splitting reg failure.
On Mon, May 7, 2012 at 10:35 PM, Uros Bizjak ubiz...@gmail.com wrote:
Now with a patch and ChangeLog:
2012-05-07 Uros Bizjak ubiz...@gmail.com
PR target/53250
* config/i386/i386.c (ix86_set_reg_reg_cost): New function.
(ix86_rtx_costs): Handle SET.
Patch was tested on x86_64-pc-linux-gnu {,-m32}.
I have also #define LOG_COST 1 temporarily and looked at generated
cost calculations for various -msse* settings.
I will wait for a day for possible comments on the implementation
before the patch will be committed to mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 187259)
+++ config/i386/i386.c (working copy)
@@ -31861,6 +31861,52 @@ ix86_modes_tieable_p (enum machine_mode mode1, enu
return false;
}
+/* Return the cost of moving between two registers of mode MODE. */
+
+static int
+ix86_set_reg_reg_cost (enum machine_mode mode)
+{
+ unsigned int units = UNITS_PER_WORD;
+
+ switch (GET_MODE_CLASS (mode))
+{
+default:
+ break;
+
+case MODE_CC:
+ units = GET_MODE_SIZE (CCmode);
+ break;
+
+case MODE_FLOAT:
+ if ((TARGET_SSE2 mode == TFmode)
+ || (TARGET_80387 mode == XFmode)
+ || ((TARGET_80387 || TARGET_SSE2) mode == DFmode)
+ || ((TARGET_80387 || TARGET_SSE) mode == SFmode))
+ units = GET_MODE_SIZE (mode);
+ break;
+
+case MODE_COMPLEX_FLOAT:
+ if ((TARGET_SSE2 mode == TCmode)
+ || (TARGET_80387 mode == XCmode)
+ || ((TARGET_80387 || TARGET_SSE2) mode == DCmode)
+ || ((TARGET_80387 || TARGET_SSE) mode == SCmode))
+ units = GET_MODE_SIZE (mode);
+ break;
+
+case MODE_VECTOR_INT:
+case MODE_VECTOR_FLOAT:
+ if ((TARGET_AVX VALID_AVX256_REG_MODE (mode))
+ || (TARGET_SSE2 VALID_SSE2_REG_MODE (mode))
+ || (TARGET_SSE VALID_SSE_REG_MODE (mode))
+ || (TARGET_MMX VALID_MMX_REG_MODE (mode)))
+ units = GET_MODE_SIZE (mode);
+}
+
+ /* Return the cost of moving between two registers of mode MODE,
+ assuming that the move will be in pieces of at most UNITS bytes. */
+ return COSTS_N_INSNS ((GET_MODE_SIZE (mode) + units - 1) / units);
+}
+
/* Compute a (partial) cost for rtx X. Return true if the complete
cost has been computed, and false if subexpressions should be
scanned. In either case, *TOTAL contains the cost result. */
@@ -31875,6 +31921,15 @@ ix86_rtx_costs (rtx x, int code, int outer_code_i,
switch (code)
{
+case SET:
+ if (register_operand (SET_DEST (x), VOIDmode)
+ reg_or_0_operand (SET_SRC (x), VOIDmode))
+ {
+ *total = ix86_set_reg_reg_cost (GET_MODE (SET_DEST (x)));
+ return true;
+ }
+ return false;
+
case CONST_INT:
case CONST:
case LABEL_REF:
Re: remove TARGET_E500 and factorize SPE defaults computation in powerpc ports
On May 7, 2012, at 21:27 , Olivier Hainque wrote: Of course. That was actually my point in offering to open a PR, so that Alan (who did the nice recent reorg) can take it from there. He will certainly be more efficient than me in resolving this :) PR 53271
PATCH: Update longlong.h from GLIBC
Hi,
I am preparing to update GLIBC longlong.h from GCC. This patch updates
GCC longlong.h to use a URL instead of an FSF postal address and replace
spaces with tab. OK to install?
Since I'd like to simply copy longlong.h from GCC release branch to GLIBC,
Is this also OK for 4.7 branch?
Thanks.
H.J.
---
2012-05-07 H.J. Lu hongjiu...@intel.com
* longlong.h: Use a URL instead of an FSF postal address.
Replace spaces with tab.
diff --git a/libgcc/longlong.h b/libgcc/longlong.h
index 2026377..4fa9d46 100644
--- a/libgcc/longlong.h
+++ b/libgcc/longlong.h
@@ -25,9 +25,8 @@
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, write to the Free
- Software Foundation, 51 Franklin Street, Fifth Floor, Boston,
- MA 02110-1301, USA. */
+ License along with the GNU C Library; if not, see
+ http://www.gnu.org/licenses/. */
/* You have to define the following before including this file:
@@ -383,21 +382,21 @@ UDItype __umulsidi3 (USItype, USItype);
do { \
register SItype __r0 __asm__ (0);
\
register SItype __r1 __asm__ (1) = (m0); \
-\
+ \
__asm__ (mr\t%%r0,%3 \
- : =r (__r0), =r (__r1)
\
- : r (__r1), r (m1));
\
+: =r (__r0), =r (__r1) \
+: r (__r1), r (m1)); \
(xh) = __r0; (xl) = __r1; \
} while (0)
#define sdiv_qrnnd(q, r, n1, n0, d) \
- do { \
+ do { \
register SItype __r0 __asm__ (0) = (n1); \
register SItype __r1 __asm__ (1) = (n0); \
-\
+ \
__asm__ (dr\t%%r0,%4 \
- : =r (__r0), =r (__r1)
\
- : r (__r0), r (__r1), r (d)); \
+: =r (__r0), =r (__r1) \
+: r (__r0), r (__r1), r (d));\
(q) = __r1; (r) = __r0;\
} while (0)
#endif /* __zarch__ */
@@ -840,9 +839,9 @@ UDItype __umulsidi3 (USItype, USItype);
#define count_trailing_zeros(count,x) \
do { \
__asm__ (ffsd %2,%0 \
-: =r ((USItype) (count)) \
-: 0 ((USItype) 0), \
- r ((USItype) (x)));\
+ : =r ((USItype) (count)) \
+ : 0 ((USItype) 0),\
+ r ((USItype) (x))); \
} while (0)
#endif /* __ns32000__ */
@@ -858,7 +857,7 @@ UDItype __umulsidi3 (USItype, USItype);
|| defined (__ppc__) /* Darwin */\
|| (defined (PPC) ! defined (CPU_FAMILY)) /* gcc 2.7.x GNUSysV */\
|| (defined (PPC) defined (CPU_FAMILY)/* VxWorks */ \
- CPU_FAMILY == PPC)\
+ CPU_FAMILY == PPC)\
) W_TYPE_SIZE == 32
#define add_ss(sh, sl, ah, al, bh, bl) \
do { \
@@ -899,7 +898,7 @@ UDItype __umulsidi3 (USItype, USItype);
|| defined (__ppc__)\
|| (defined (PPC) ! defined (CPU_FAMILY)) /* gcc 2.7.x GNUSysV */ \
|| (defined (PPC) defined (CPU_FAMILY)/* VxWorks */ \
- CPU_FAMILY == PPC)
+ CPU_FAMILY == PPC)
#define umul_ppmm(ph, pl, m0, m1) \
do { \
USItype __m0 = (m0), __m1 = (m1); \
@@ -1067,7 +1066,7 @@ UDItype __umulsidi3 (USItype, USItype);
#define udiv_qrnnd(q, r, n1, n0, d) \
do { \
extern UWtype __udiv_qrnnd_16 (UWtype, UWtype)
[PATCH] Add option for dumping to stderr (issue6190057)
This is the first patch for planned improvements to dump
infrastructure. Please reference the discussion in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html.
The following small patch allows selective tree and rtl dumps on
stderr instead of named files. Later -fopt-info can be implemented in
form of -fdump-xxx-stderr.
Bootstrapped and tested on x86_64 with one added testcase. Okay for
trunk?
Thanks,
Sharad
2012-05-07 Sharad Singhai sing...@google.com
* doc/invoke.texi: Add documentation for new option.
* tree-dump.c (dump_begin): Handle stderr appropriately.
(dump_end): Likewise.
(dump_switch_p_1): Likewise.
* tree-pass.h (enum tree_dump_index): Add new constant.
* testsuite/g++.dg/other/dump-stderr-1.C: New test.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 187265)
+++ doc/invoke.texi (working copy)
@@ -5322,20 +5322,23 @@ Here are some examples showing uses of these optio
@item -d@var{letters}
@itemx -fdump-rtl-@var{pass}
+@itemx -fdump-rtl-@var{pass-stderr}
@opindex d
Says to make debugging dumps during compilation at times specified by
@var{letters}. This is used for debugging the RTL-based passes of the
compiler. The file names for most of the dumps are made by appending
a pass number and a word to the @var{dumpname}, and the files are
-created in the directory of the output file. Note that the pass
-number is computed statically as passes get registered into the pass
-manager. Thus the numbering is not related to the dynamic order of
-execution of passes. In particular, a pass installed by a plugin
-could have a number over 200 even if it executed quite early.
-@var{dumpname} is generated from the name of the output file, if
-explicitly specified and it is not an executable, otherwise it is the
-basename of the source file. These switches may have different effects
-when @option{-E} is used for preprocessing.
+created in the directory of the output file. If the @option{-stderr} is
+appended to the longer form of the dump option then the dump is
+done on stderr instead of named files. Note that the pass number is
+computed statically as passes get registered into the pass manager.
+Thus the numbering is not related to the dynamic order of execution of
+passes. In particular, a pass installed by a plugin could have a
+number over 200 even if it executed quite early. @var{dumpname} is
+generated from the name of the output file, if explicitly specified
+and it is not an executable, otherwise it is the basename of the
+source file. These switches may have different effects when
+@option{-E} is used for preprocessing.
Debug dumps can be enabled with a @option{-fdump-rtl} switch or some
@option{-d} option @var{letters}. Here are the possible
@@ -5599,6 +5602,10 @@ These dumps are defined but always produce empty f
@opindex fdump-rtl-all
Produce all the dumps listed above.
+@item -fdump-rtl-all-stderr
+@opindex fdump-rtl-all-stderr
+Produce all the dumps on stderr.
+
@item -dA
@opindex dA
Annotate the assembler output with miscellaneous debugging information.
@@ -5723,11 +5730,13 @@ counters for each function compiled.
Control the dumping at various stages of processing the intermediate
language tree to a file. The file name is generated by appending a
switch specific suffix to the source file name, and the file is
-created in the same directory as the output file. If the
-@samp{-@var{options}} form is used, @var{options} is a list of
-@samp{-} separated options which control the details of the dump. Not
-all options are applicable to all dumps; those that are not
-meaningful are ignored. The following options are available
+created in the same directory as the output file unless the option
+@option{stderr} is given. In case of @option{stderr}, the dump output is on
+the stderr. If the @samp{-@var{options}} form is used, @var{options}
+is a list of @samp{-} separated options which control the details or
+location of the dump. Not all options are applicable to all dumps;
+those that are not meaningful are ignored. The following options are
+available
@table @samp
@item address
@@ -5765,9 +5774,42 @@ Enable showing the tree dump for each statement.
Enable showing the EH region number holding each statement.
@item scev
Enable showing scalar evolution analysis details.
+@item slim
+Inhibit dumping of members of a scope or body of a function merely
+because that scope has been reached. Only dump such items when they
+are directly reachable by some other path. When dumping pretty-printed
+trees, this option inhibits dumping the bodies of control structures.
+@item stderr
+Instead of dumping into a named file, dump on to stderr. However, note
+that the @option{stderr} is considered weak, so in case of two
+conflicting dump options, the option to dump into file takes
+precedence regardless of the command line ordering.
Re: [PATCH] Add option for dumping to stderr (issue6190057)
On Mon, May 7, 2012 at 4:58 PM, Sharad Singhai sing...@google.com wrote: This is the first patch for planned improvements to dump infrastructure. Please reference the discussion in http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html. The following small patch allows selective tree and rtl dumps on stderr instead of named files. Later -fopt-info can be implemented in form of -fdump-xxx-stderr. Instead of -fdump-xxx-stderr, it will be better to have -fdump-xxx=yyy where yyy is a path to a file, with stderr and stdout having special meaning. -- Gaby
[C++ Patch and pubnames 1/2] Adjust testsuite results to match demangler (issue6205043)
This is the first in a series of patches to get split-dwarf debug output
(AKA the Fission project: http://gcc.gnu.org/wiki/DebugFission)
contributed to the mainline.
Under certain circumstances, dwarf2out.c:dwarf_name calls into the front end's
decl pretty-printer to produce names for debug info. These are used in turn
by the linker and GDB to build .gdb_index, among other things. However, the
decl pretty-printer and the demangler use slightly different conventions for
certain constructs, which leads to various inconsistencies in the debug info.
This is the first of two patches to change the decl pretty printer to match
the demangler. It changes the testsuite's expected output to match what will
be produced by the changed pretty printer.
I submit it for review first so that the changes in output created by the second
patch are easy to see.
There are two significant changes. First, it switches the order between,
for example, const char* to char const*. Note that the front-end's
infrastructure does not record the source code's original order.
The other significant difference change involves switching the string
{anonymous} to (anonymous namespace).
Tested in conjunction with the second patch in this series by running
the testsuite and observing no regresssions other than those fixed by this
patch.
OK for mainline?
Sterling
2012-05-07 Sterling Augustine saugust...@google.com
* gcc/testsuite/g++.old-deja/g++.pt/memtemp77.C (int main): Adjust
expected output.
* gcc/testsuite/g++.dg/ext/pretty3.C: Likewise.
* gcc/testsuite/g++.dg/diagnostic/bindings1.C: Likewise.
* gcc/testsuite/g++.dg/warn/Wuninitializable-member.C: Likewise.
* gcc/testsuite/g++.dg/warn/pr35711.C (int* foo): Likewise.
* gcc/testsuite/g++.dg/pr44486.C: Likewise.
Index: gcc/testsuite/g++.old-deja/g++.pt/memtemp77.C
===
--- gcc/testsuite/g++.old-deja/g++.pt/memtemp77.C (revision 187271)
+++ gcc/testsuite/g++.old-deja/g++.pt/memtemp77.C (working copy)
@@ -19,7 +19,7 @@
int main()
{
if (strcmp (S3double::h(7),
- static const char* S3T::h(U) [with U = int; T = double]) == 0)
+ static char const* S3T::h(U) [with U = int; T = double]) == 0)
return 0;
else
return 1;
Index: gcc/testsuite/g++.dg/ext/pretty3.C
===
--- gcc/testsuite/g++.dg/ext/pretty3.C (revision 187271)
+++ gcc/testsuite/g++.dg/ext/pretty3.C (working copy)
@@ -16,4 +16,4 @@
{
printf (%s\n, Dint().foo (0));
}
-// { dg-final { scan-assembler const char\\* DU::foo\\(typename BU::X\\)
} }
+// { dg-final { scan-assembler char const\\* DU::foo\\(typename BU::X\\)
} }
Index: gcc/testsuite/g++.dg/diagnostic/bindings1.C
===
--- gcc/testsuite/g++.dg/diagnostic/bindings1.C (revision 187271)
+++ gcc/testsuite/g++.dg/diagnostic/bindings1.C (working copy)
@@ -10,7 +10,7 @@
int main()
{
- if (strcmp (foo(x(), 3), const char* foo(T, typename T::type)
+ if (strcmp (foo(x(), 3), char const* foo(T, typename T::type)
[with T = x; typename T::type = int]) == 0)
return 0;
else
Index: gcc/testsuite/g++.dg/warn/Wuninitializable-member.C
===
--- gcc/testsuite/g++.dg/warn/Wuninitializable-member.C (revision 187271)
+++ gcc/testsuite/g++.dg/warn/Wuninitializable-member.C (working copy)
@@ -8,7 +8,7 @@
};
class Y {
- const int var;// { dg-warning non-static const member 'const int Y::var' in
class without a constructor }
+ const int var;// { dg-warning non-static const member 'int const Y::var' in
class without a constructor }
public:
int g(){ return 2*var; }
};
Index: gcc/testsuite/g++.dg/warn/pr35711.C
===
--- gcc/testsuite/g++.dg/warn/pr35711.C (revision 187271)
+++ gcc/testsuite/g++.dg/warn/pr35711.C (working copy)
@@ -4,5 +4,5 @@
int* foo (volatile int *p)
{
- return (int*)p; // { dg-warning cast from type 'volatile int\\*' to type
'int\\*' casts away qualifiers }
+ return (int*)p; // { dg-warning cast from type 'int volatile\\*' to type
'int\\*' casts away qualifiers }
}
Index: gcc/testsuite/g++.dg/pr44486.C
===
--- gcc/testsuite/g++.dg/pr44486.C (revision 187271)
+++ gcc/testsuite/g++.dg/pr44486.C (working copy)
@@ -7,4 +7,4 @@
int main() { f(); }
-// { dg-final { scan-assembler S \{anonymous\}::f } }
+// { dg-final { scan-assembler S \\(anonymous namespace\\)::f } }
--
This patch is available for review at http://codereview.appspot.com/6205043
Re: [PR tree-optimization/52558]: RFC: questions on store data race
Hi. Sorry for the delay. There were various tricky hiccups along the way to bootstrappability and regression cleanliness... On 04/26/12 04:51, Richard Guenther wrote: On Wed, 25 Apr 2012, Aldy Hernandez wrote: On 04/25/12 06:45, Richard Guenther wrote: On Tue, Apr 24, 2012 at 7:43 PM, Aldy Hernandezal...@redhat.com wrote: On 04/13/12 03:46, Richard Guenther wrote: On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezal...@redhat.com wrote: Speak of loads, I am keeping the information as an additional bitmap in `memory_accesses', as -refs_in_loop was set for stores as well, so I couldn't depend on it. Let me know if you have another idea. Hmm, refs_in_loop ~all_refs_stored_in_loop, so instead of + bitmap reads = VEC_index (bitmap, memory_accesses.reads_in_loop, + loop-num); + ref_read_in_loop_p = bitmap_bit_p (reads, ref-id); ref_read_in_loop_p = bitmap_bit_p (refs, ref-id) !bitmap_bit_p (stores, ref-id); ? But maybe that doesn't work if a ref is both read and stored to. Btw, rather than adding a bitmap to memory_accesses I'd rather add a mark_ref_loaded corresponding to mark_ref_stored (or rather merge both into one) and a bitmap to struct mem_ref. I have done so as mark_ref_loaded(). I first tried to merge both into a generic mark_ref(), to avoid iterating twice, but I was concerned with the early loop exit of !bitmap_bit_p(ref-stored, loop-num), not knowing if I should exit the loop altogether in the merged case or what. In either case, the code was somewhat convoluted, so I opted for a separate clean function. In scanning the gimple stream for the loads I noticed that instances of two component refs (say foo.bar) were not pointer comparable, so I am asking the alias oracle with refs_may_alias_p. It also seemed to make more sense wrt memory chunks that may alias. What do you think? This patch is far more robust and fully tested. Two wrenches to complicate things though... First, while inserting the code writing the _LSM_ temporary writes into the original variables, I found a handful of tests where the order of the writes mattered (aliased locations, inlined code, etc, IIRC). [This is in loops where multiple stores are moved.] So iterating and inserting on the exit edges caused the stores to be saved in reverse. I am now saving the edges and threading the code, so they happen in the correct order: if (foo_flag_lsm) foo = foo_lsm; if (foo2_flag_lsm) foo2 = foo2_lsm; actual_exit: This required some edge redirection so we didn't jump to the original actual exit prematurely when handling multiple moved stores. The dominator tree needed to be updated, and there is one instance where I couldn't find a clever way of saving the order without jumping through an inordinate amount of hoops. It seemed easier to call recompute_dominator. Second, avoiding the load, unless it happens in the loop like you have suggested, brought about some bogus unused warnings with the LSM temporaries. What happens is that compute_ssa() creates uses of the LSM temporaries that are not yet defined, so we end up with PHI nodes with a definition entry (D). Since we are sure the eventual uses will be gated by their corresponding flag, I created phi nodes with an initial value of 0 in the preheader of the loops in which they are used. This solved the problem. I also played with initializing to 0 at the entry block, but that seemed a bit too invasive. Andrew suggested the correct fix was to add a new pass that was able to do some ?? flow sensitive data flow analysis ?? that could discover these unreachable paths and insert the 0 phis at the start of the blocks automatically. But that seemed like far too much work, considering how long it's taken me to get this far ;-). Bootstraped and fully tested with multi_threaded_model_p=true hard-coded. This is the revision I'd like to contribute, sans the hardcoded value. What do you think? * cfg.c (alloc_aux_for_edge): Fix comment. (alloc_aux_for_edge): Remove static. * gimple.h (gimple_set_in_transaction): Remove. (gimple_in_transaction): Look in BB instead. (gimple_statement_base): Remove in_transaction field. * basic-block.h (enum bb_flags): Add BB_IN_TRANSACTION. (alloc_aux_for_edge): Protoize. * trans-mem.c (compute_transaction_bits): Place transaction bit information into basic blocks. * Makefile.in (tree-ssa-loop-im.o): Depend on TARGET_H. * doc/tm.texi: Regenerate. * tree-ssa-loop-im.c (execute_sm_if_changed): New. (execute_sm_if_changed_flag): New. (execute_sm_if_changed_flag_set): New. (execute_sm): Do not generate data races unless requested. (mark_ref): Rename from mark_ref_stored. Set loaded bit. (mem_ref_alloc): Initialize loaded field.
[patch] don't check for execute bits of the liblto plugin
The lto plugin is installed without x bits set, but gcc-ar.c still checks for
the execute bits. There is no need to have the lto plugin to have the x bits
set, so just check that it is readable.
Ok for the trunk and the 4.7 branch?
Matthias
* (main): Don't check for execute bits for the plugin.
--- gcc/gcc-ar.c
+++ gcc/gcc-ar.c
@@ -70,7 +70,7 @@
dir_separator,
LTOPLUGINSONAME,
NULL);
- if (access (plugin, X_OK))
+ if (access (plugin, R_OK))
{
fprintf (stderr, %s: Cannot find plugin %s\n, av[0], plugin);
exit (1);
Re: [PATCH] libgcov support for profile collection in region of interest (issue6186044)
+Honza and Nathan.
David
On Thu, May 3, 2012 at 10:52 AM, Teresa Johnson tejohn...@google.com wrote:
This patch adds functionality to libgcov to enable user applications to
collect profile data only in regions of interest. This is useful, for
example, to collect profile data from a long-running server only
during the time when it is serving requests.
Specifically, the new routines __gcov_reset will clear all profile counters
to zero and __gcov_dump will write out the profile information collected so
far. A global variable is used to prevent writing out the profile a
second time during exit.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Is this ok for trunk?
This seems resonable things to do. You need to add an documentation and make
sure they
go new L_* section, since not every app using libgcov needs necesarily those
two.
Honza
Thanks,
Teresa
2012-05-03 Teresa Johnson tejohn...@google.com
* libgcc/libgcov.c (gcov_clear, __gcov_reset): New functions.
(__gcov_dump): Ditto.
(gcov_dump_complete): New global variable.
(__gcov_flush): Outline functionality now in gcov_clear.
* gcc/gcov-io.h (__gcov_reset, __gcov_dump): Declare.
Index: libgcc/libgcov.c
===
--- libgcc/libgcov.c (revision 187048)
+++ libgcc/libgcov.c (working copy)
@@ -48,6 +48,8 @@ see the files COPYING3 and COPYING.RUNTIME respect
#ifdef L_gcov
void __gcov_init (struct gcov_info *p __attribute__ ((unused))) {}
void __gcov_flush (void) {}
+void __gcov_reset (void) {}
+void __gcov_dump (void) {}
#endif
#ifdef L_gcov_merge_add
@@ -91,6 +93,9 @@ static struct gcov_info *gcov_list;
/* Size of the longest file name. */
static size_t gcov_max_filename = 0;
+/* Flag when the profile has already been dumped via __gcov_dump(). */
+static int gcov_dump_complete = 0;
+
/* Make sure path component of the given FILENAME exists, create
missing directories. FILENAME must be writable.
Returns zero on success, or -1 if an error occurred. */
@@ -286,6 +291,11 @@ gcov_exit (void)
char *gi_filename, *gi_filename_up;
gcov_unsigned_t crc32 = 0;
+ /* Prevent the counters from being dumped a second time on exit when the
+ application already wrote out the profile using __gcov_dump(). */
+ if (gcov_dump_complete)
+ return;
+
memset (all_prg, 0, sizeof (all_prg));
/* Find the totals for this execution. */
memset (this_prg, 0, sizeof (this_prg));
@@ -679,6 +689,37 @@ gcov_exit (void)
}
}
+/* Reset all counters to zero. */
+
+static void
+gcov_clear (void)
+{
+ const struct gcov_info *gi_ptr;
+
+ for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
+ {
+ unsigned f_ix;
+
+ for (f_ix = 0; f_ix gi_ptr-n_functions; f_ix++)
+ {
+ unsigned t_ix;
+ const struct gcov_fn_info *gfi_ptr = gi_ptr-functions[f_ix];
+
+ if (!gfi_ptr || gfi_ptr-key != gi_ptr)
+ continue;
+ const struct gcov_ctr_info *ci_ptr = gfi_ptr-ctrs;
+ for (t_ix = 0; t_ix != GCOV_COUNTERS; t_ix++)
+ {
+ if (!gi_ptr-merge[t_ix])
+ continue;
+
+ memset (ci_ptr-values, 0, sizeof (gcov_type) * ci_ptr-num);
+ ci_ptr++;
+ }
+ }
+ }
+}
+
/* Add a new object file onto the bb chain. Invoked automatically
when running an object file's global ctors. */
@@ -730,38 +771,38 @@ init_mx_once (void)
void
__gcov_flush (void)
{
- const struct gcov_info *gi_ptr;
-
init_mx_once ();
__gthread_mutex_lock (__gcov_flush_mx);
gcov_exit ();
- for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
- {
- unsigned f_ix;
+ gcov_clear ();
- for (f_ix = 0; f_ix gi_ptr-n_functions; f_ix++)
- {
- unsigned t_ix;
- const struct gcov_fn_info *gfi_ptr = gi_ptr-functions[f_ix];
+ __gthread_mutex_unlock (__gcov_flush_mx);
+}
- if (!gfi_ptr || gfi_ptr-key != gi_ptr)
- continue;
- const struct gcov_ctr_info *ci_ptr = gfi_ptr-ctrs;
- for (t_ix = 0; t_ix != GCOV_COUNTERS; t_ix++)
- {
- if (!gi_ptr-merge[t_ix])
- continue;
-
- memset (ci_ptr-values, 0, sizeof (gcov_type) * ci_ptr-num);
- ci_ptr++;
- }
- }
- }
+/* Function that can be called from application to reset counters to zero,
+ in order to collect profile in region of interest. */
- __gthread_mutex_unlock (__gcov_flush_mx);
+void
+__gcov_reset (void)
+{
+ gcov_clear ();
+ /* Re-enable dumping to support collecting profile in multiple regions
+ of interest. */
+ gcov_dump_complete = 0;
}
+/* Function that can be called from
[C++ Patch and pubnames 2/2] Adjust c decl pretty printer to match demangler (issue6195056)
This is the second in the series of patches to make c decl pretty printing
more closely match the demangler. A full explanation is here:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html
OK for mainline?
Sterling
2012-05-07 Sterling Augustine saugust...@google.com
* c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Move
call to pp_c_type_qualifier_list from start to end of function.
* cp/error.c (dump_decl): Change {anonymous} to (anonymous
namespace)
(lang_decl_name): Handle (anonymous namespace) correctly.
Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c (revision 187271)
+++ c-family/c-pretty-print.c (working copy)
@@ -446,8 +446,6 @@ pp_c_specifier_qualifier_list (c_pretty_printer *p
{
const enum tree_code code = TREE_CODE (t);
- if (TREE_CODE (t) != POINTER_TYPE)
-pp_c_type_qualifier_list (pp, t);
switch (code)
{
case REFERENCE_TYPE:
@@ -494,6 +492,8 @@ pp_c_specifier_qualifier_list (c_pretty_printer *p
pp_simple_type_specifier (pp, t);
break;
}
+ if (TREE_CODE (t) != POINTER_TYPE)
+pp_c_type_qualifier_list (pp, t);
}
/* parameter-type-list:
Index: cp/error.c
===
--- cp/error.c (revision 187271)
+++ cp/error.c (working copy)
@@ -1028,7 +1028,7 @@ dump_decl (tree t, int flags)
dump_scope (CP_DECL_CONTEXT (t), flags);
flags = ~TFF_UNQUALIFIED_NAME;
if (DECL_NAME (t) == NULL_TREE)
- pp_cxx_ws_string (cxx_pp, M_({anonymous}));
+ pp_cxx_ws_string (cxx_pp, M_((anonymous namespace)));
else
pp_cxx_tree_identifier (cxx_pp, DECL_NAME (t));
}
@@ -2596,6 +2596,8 @@ lang_decl_name (tree decl, int v, bool translate)
if (TREE_CODE (decl) == FUNCTION_DECL)
dump_function_name (decl, TFF_PLAIN_IDENTIFIER);
+ else if (DECL_NAME (decl) == NULL TREE_CODE (decl) == NAMESPACE_DECL)
+pp_string (cxx_pp, M_((anonymous namespace)));
else
dump_decl (DECL_NAME (decl), TFF_PLAIN_IDENTIFIER);
--
This patch is available for review at http://codereview.appspot.com/6195056
Re: [PR tree-optimization/52558]: RFC: questions on store data race
On 05/07/2012 07:04 PM, Aldy Hernandez wrote: Andrew suggested the correct fix was to add a new pass that was able to do some ?? flow sensitive data flow analysis ?? that could discover these unreachable paths and insert the 0 phis at the start of the blocks automatically. But that seemed like far too much work, considering how long it's taken me to get this far ;-). Wait, no. I didn't suggest writing an entire generic pass was the correct fix for you... I said that this was a technique that a generic pass which identified this sort of flow sensitive data flow info could use to work within the CFG. Simply zeroing out uses of the load in PHI nodes on paths it has determined are not actually reachable by that value, and you were suppose to integrate just the bits of that technique that you required.. just replace any uses of your LSM temporary with 0. I never intended you should write an entire pass... Andrew
Re: [patch] support for multiarch systems
On 20.08.2011 21:51, Matthias Klose wrote:
Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system.
please find attached an updated for the trunk (2012-05-08). The multiarch
triplets are now defined in the Debian Wiki [1], and progress is made to get the
triplet definitions into Debian Policy [2].
Matthias
[1] http://wiki.debian.org/Multiarch/Tuples
[2] http://bugs.debian.org/664257
gcc/
2012-05-08 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file (alpha/t-linux
for alpha*-*-linux*, pa/t-linux for hppa*64*-*-linux*, ia64/t-glibc
for ia64*-*-linux*, rs6000/t-linux for powerpc-*-linux*, i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in MULTILIB_OSDIRNAMES,
Define MULTIARCH_DIRNAME.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/rs6000/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux-eabi: Likewise.
* config/i386/t-gnu: Likewise:
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/rs6000/t-linux: Likewise.
* config/rs6000/t-spe: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.
Index: libstdc++-v3/python/hook.in
===
--- libstdc++-v3/python/hook.in (revision 187271)
+++ libstdc++-v3/python/hook.in (working copy)
@@ -47,7 +47,10 @@
libdir = libdir[len (prefix):]
# Compute the ..s needed to get from libdir to the prefix.
-dotdots = ('..' + os.sep) * len (libdir.split (os.sep))
+backdirs = len (libdir.split (os.sep))
+if not os.path.basename(os.path.dirname(__file__)).startswith('lib'):
+backdirs += 1 # multiarch subdir
+dotdots = ('..' + os.sep) * backdirs
objfile = gdb.current_objfile ().filename
dir_ = os.path.join (os.path.dirname (objfile), dotdots, pythondir)
Index: gcc/common.opt
===
--- gcc/common.opt (revision 187271)
+++ gcc/common.opt (working copy)
@@ -345,6 +345,9 @@
-print-multi-os-directory
Driver Alias(print-multi-os-directory)
+-print-multiarch
+Driver Alias(print-multiarch)
+
-print-prog-name
Driver Separate Alias(print-prog-name=)
@@ -2286,6 +2289,10 @@
Common Joined Var(plugindir_string) Init(0)
-iplugindir=dir Set dir to be the default plugin directory
+imultiarch
+Common Joined Separate RejectDriver Var(imultiarch) Init(0)
+-imultiarch dir Set dir to be the multiarch include subdirectory
+
l
Driver Joined Separate
@@ -2342,6 +2349,9 @@
print-multi-os-directory
Driver Var(print_multi_os_directory)
+
+print-multiarch
+Driver Var(print_multiarch)
print-prog-name=
Driver JoinedOrMissing Var(print_prog_name)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 187271)
+++ gcc/Makefile.in (working copy)
@@ -350,6 +350,17 @@
enable_plugin = @enable_plugin@
+# Multiarch support
+enable_multiarch = @enable_multiarch@
+with_float = @with_float@
+ifeq ($(enable_multiarch),yes)
+ if_multiarch = $(1)
+else ifeq ($(enable_multiarch),auto-detect)
+
Re: [C++ Patch and pubnames 2/2] Adjust c decl pretty printer to match demangler (issue6195056)
On Mon, May 7, 2012 at 7:10 PM, Sterling Augustine
saugust...@google.com wrote:
This is the second in the series of patches to make c decl pretty printing
more closely match the demangler. A full explanation is here:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html
OK for mainline?
Now I realize something that is wrong with the previous patch.
Writing 'const T*' in C++ is very much wide spread style is also the
style used in the C++ standard, TC++PL (the de facto popular reference TC++PL),
our own C++ standard library implementation, and many popular modern
C++ textbooks.
It is a strongly well established style.
Changing the pretty printer to satisfy the demangler as opposed to users
look wrong headed.
-- Gaby
Sterling
2012-05-07 Sterling Augustine saugust...@google.com
* c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Move
call to pp_c_type_qualifier_list from start to end of function.
* cp/error.c (dump_decl): Change {anonymous} to (anonymous
namespace)
(lang_decl_name): Handle (anonymous namespace) correctly.
Index: c-family/c-pretty-print.c
===
--- c-family/c-pretty-print.c (revision 187271)
+++ c-family/c-pretty-print.c (working copy)
@@ -446,8 +446,6 @@ pp_c_specifier_qualifier_list (c_pretty_printer *p
{
const enum tree_code code = TREE_CODE (t);
- if (TREE_CODE (t) != POINTER_TYPE)
- pp_c_type_qualifier_list (pp, t);
switch (code)
{
case REFERENCE_TYPE:
@@ -494,6 +492,8 @@ pp_c_specifier_qualifier_list (c_pretty_printer *p
pp_simple_type_specifier (pp, t);
break;
}
+ if (TREE_CODE (t) != POINTER_TYPE)
+ pp_c_type_qualifier_list (pp, t);
}
/* parameter-type-list:
Index: cp/error.c
===
--- cp/error.c (revision 187271)
+++ cp/error.c (working copy)
@@ -1028,7 +1028,7 @@ dump_decl (tree t, int flags)
dump_scope (CP_DECL_CONTEXT (t), flags);
flags = ~TFF_UNQUALIFIED_NAME;
if (DECL_NAME (t) == NULL_TREE)
- pp_cxx_ws_string (cxx_pp, M_({anonymous}));
+ pp_cxx_ws_string (cxx_pp, M_((anonymous namespace)));
else
pp_cxx_tree_identifier (cxx_pp, DECL_NAME (t));
}
@@ -2596,6 +2596,8 @@ lang_decl_name (tree decl, int v, bool translate)
if (TREE_CODE (decl) == FUNCTION_DECL)
dump_function_name (decl, TFF_PLAIN_IDENTIFIER);
+ else if (DECL_NAME (decl) == NULL TREE_CODE (decl) == NAMESPACE_DECL)
+ pp_string (cxx_pp, M_((anonymous namespace)));
else
dump_decl (DECL_NAME (decl), TFF_PLAIN_IDENTIFIER);
--
This patch is available for review at http://codereview.appspot.com/6195056
Re: [C++ Patch] PR 53158
How do we even get to calling cp_truthvalue_conversion? Jason
Re: [C++ Patch] PR 53158
On 05/08/2012 04:10 AM, Jason Merrill wrote:
How do we even get to calling cp_truthvalue_conversion?
ocp_convert wants to do that, around line 750... And I have a brand new
proposal ;)
The patchlet below (which passes testing) leads to very consistent error
messages for the testcase in the PR, and:
void foo();
void bar(int a, int b)
{
if (foo())
;
}
and
void foo();
void bar(int a, int b)
{
if (foo() a b)
;
}
exactly the same actually. But maybe we want to differentiate somehow
what we emit for lambdas, but I don't think we want the status quo for
%qE for a lambda here, because it would be:
error: could not convert ‘b.main()::lambda()()’ from ‘void’ to ‘bool’
What do you think?
Thanks!
Paolo.
///
Index: testsuite/g++.dg/cpp0x/lambda/lambda-err2.C
===
--- testsuite/g++.dg/cpp0x/lambda/lambda-err2.C (revision 0)
+++ testsuite/g++.dg/cpp0x/lambda/lambda-err2.C (revision 0)
@@ -0,0 +1,12 @@
+// PR c++/53158
+// { dg-do compile { target c++11 } }
+
+int main()
+{
+ auto a = []() { return true; };
+ auto b = []() { return a(); }; // { dg-error 'a' is not captured }
+ int c, d;
+ while (b() c d) // { dg-error could not convert 'b\\(\\)' from 'void'
to 'bool' }
+{
+}
+}
Index: cp/error.c
===
--- cp/error.c (revision 187249)
+++ cp/error.c (working copy)
@@ -1897,6 +1897,13 @@ dump_expr (tree t, int flags)
if (TREE_CODE (ob) == ADDR_EXPR)
{
dump_expr (TREE_OPERAND (ob, 0), flags | TFF_EXPR_IN_PARENS);
+ /* Handle lambdas specially. */
+ if (TREE_CODE (fn) == FUNCTION_DECL
+DECL_NAME (fn) LAMBDA_FUNCTION_P (fn))
+ {
+ dump_call_expr_args (t, flags, true);
+ return;
+ }
pp_cxx_dot (cxx_pp);
}
else if (TREE_CODE (ob) != PARM_DECL
Index: cp/cvt.c
===
--- cp/cvt.c(revision 187249)
+++ cp/cvt.c(working copy)
@@ -743,6 +743,12 @@ ocp_convert (tree type, tree expr, int convtype, i
}
if (code == BOOLEAN_TYPE)
{
+ if (TREE_CODE (intype) == VOID_TYPE)
+ {
+ error (could not convert %qE from %void% to %bool%, expr);
+ return error_mark_node;
+ }
+
/* We can't implicitly convert a scoped enum to bool, so convert
to the underlying type first. */
if (SCOPED_ENUM_P (intype) (convtype CONV_STATIC))
Re: [google/gcc-4_6] Fission improvements and bug fixes (issue6189052)
On 12-05-07 10:56 , Cary Coutant wrote: 2012-05-07 Sterling Augustinesaugust...@google.com Cary Coutantccout...@google.com include/ * dwarf2.h (enum dwarf_form): Remove DW_FORM_GNU_ref_index. (enum dwarf_attribute): Replace DW_AT_GNU_ref_base with DW_AT_GNU_ranges_base. gcc/ * gcc/dwarf2out.c (debug_ref_section): Remove. (struct dw_loc_list_struct): Add begin_index, end_index fields. (DEBUG_REF_SECTION): Remove. (DEBUG_NORM_MACINFO_SECTION, DEBUG_DWO_MACINFO_SECTION): New macros. (DEBUG_MACINFO_SECTION): Define condtionally on dwarf_split_debug_info. (DEBUG_DWO_LOC_SECTION): New macro. (DEBUG_REF_SECTION_LABEL): Remove. debug_ref_section_label: Remove. (dwarf_attr_name): Replace DW_AT_GNU_ref_base with DW_AT_GNU_ranges_base. (dwarf_form_name): Remove DW_FORM_GNU_ref_index. (AT_index): Adjust comment. (addr_index_table): Adjust comment. (ref_index_table): Remove. (add_ref_table_entry): Remove. (add_AT_range_list): Save offset for direct references. (size_of_die): Always use offset size for range list references. (value_format): Use section offset for range list and location list references. (new_loc_list): Initialize begin_index and end_index. (output_loc_list): Handle special format for .debug_loc.dwo sections. (output_range_list_offset): Output plain offset for range list reference when splitting dwarf info. (output_loc_list_offset): Output plain offset for location list reference when splitting dwarf info. (output_attr_index_or_value): Remove case dw_val_class_range_list. (output_die): Call output_range_list_offset for range list references. (add_top_level_skeleton_die_attrs): Remove DW_AT_GNU_ref_base. (add_enumerator_pubname): Remove SEP parameter; add correct pubtype entry for anonymous enums. (add_pubtype): Add correct pubtype entry for anonymous enums. (gen_enumeration_type_die): Likewise. (dwarf2out_init): Create .debug_loc.dwo section; remove debug_ref_section. (output_ref_table): Remove. (index_location_lists): Set begin_index and end_index for each item in a location list. (dwarf2out_finish): Add DW_AT_macro_info to the compile_unit DIE instead of the skeleton. Don't call index_location_lists when not splitting dwarf info. Add DW_AT_GNU_ranges_base attribute to compile_unit DIE. Move generation of loc_section_label to dwarf2out_init. Remove .debug_ref section. OK. Diego.
Heads-up, PR53273: testsuite separation and dilution problem. Fix for PR53272
The problem was spotted while fixing PR53272, a target bug with
crisv32-* involving the error-prone notice_update_cc function.
When wrapping up the test-case to use as a run-test, adding main
and auxiliary functions to the reduced test-case unexpectedly
made the bug go away. This despite all functions (except main)
being decorated with noinline, noclone and the special marker
asm () ad finitum. See below: putting the two-file test-case
in a single file causes different code for the
rtc_update_irq_enable function in the .expand stage already.
That REALLY shouldn't happen. I hope this is just a bug and not
as it's supposed to be, but this is not the first time I notice
this general problem, hence this rant and PR53273:
It is, and you don't understand how this can be a problem, or
think I should just add the brand new function attribute
nofrobnicate? Well, having to add two files for each test-case
is enough of a problem on its own. The bigger problems is the
integrity of test-cases: there's no way to know that a future
optimization doesn't see through those separated files (like, an
LTO that is enabled always).
There *must* be a future-proof way to write test-cases marking
where cross-function optimizations should not happen. If it's
implemented as function-attribute-nofrobnicate so be it, but it
must not be limited to only the optimizations in place today.
Otherwise, some new middle-end generic optimization will
optimize away the test-case (and always return success), most
likely eliminating the point of the test. When the point of the
test-case is to cover code in a port or lower levels, optimizing
away the test-cases opens up for bugs to silently creep in; the
original bug or bugs in the functionality being covered. This
optimization-limiting mechanism really should, almost-must, work
within a single file. In a (semi-)perfect world, someone would
interate over the testsuite, adding such attributes to the
existing tests; I fear a lot of those that don't use noclone
are silently already just eliminated to exit (0). We're on a
slippery slope here: it started with having to add noinline
attributes, then noclone attributes, then the asm() marker.
Now that doesn't work anymore either. Can we just have a way to
limit those pesky cross-function optimizations and all their kin
once and for all?
Ok, enough ranting. If anyone knows off-hand why the code would
differ, feel free to add to PR53273, else I'll eventually
analyze it. It might just be a minor bug after all; like some
static branch prediction not being cleared when seeing a
noinline-marked function.
The test-case below and patch will be committed to trunk and the
4.7 branch as soon as testing for crisv32-elf finishes.
gcc/testsuite:
PR target/53272
* gcc.dg/torture/pr53272-1.c, gcc.dg/torture/pr53272-2.c: New test.
gcc:
PR target/53272
* config/cris/cris.c (cris_normal_notice_update_cc): For TARGET_V32,
when a constant source operand matches an I constraint, the no
CC0 change applies to a register-destination only, not a
strict_low_part-destination.
--- /dev/null Tue Oct 29 15:57:07 2002
+++ gcc/testsuite/gcc.dg/torture/pr53272-1.cTue May 8 03:07:52 2012
@@ -0,0 +1,39 @@
+/* { dg-do run } */
+/* { dg-additional-sources pr53272-2.c } */
+struct rtc_class_ops {
+ int (*f)(void *, unsigned int enabled);
+};
+
+struct rtc_device
+{
+ void *owner;
+ const struct rtc_class_ops *ops;
+ int ops_lock;
+};
+
+__attribute__ ((__noinline__, __noclone__))
+extern int foo(void *);
+__attribute__ ((__noinline__, __noclone__))
+extern void foobar(void *);
+
+__attribute__ ((__noinline__, __noclone__))
+int rtc_update_irq_enable(struct rtc_device *rtc, unsigned int enabled)
+{
+ int err;
+ asm volatile ();
+
+ err = foo(rtc-ops_lock);
+
+ if (err)
+ return err;
+
+ if (!rtc-ops)
+ err = -19;
+ else if (!rtc-ops-f)
+ err = -22;
+ else
+ err = rtc-ops-f(rtc-owner, enabled);
+
+ foobar(rtc-ops_lock);
+ return err;
+}
--- /dev/null Tue Oct 29 15:57:07 2002
+++ gcc/testsuite/gcc.dg/torture/pr53272-2.cTue May 8 02:23:21 2012
@@ -0,0 +1,39 @@
+__attribute__ ((__noinline__, __noclone__))
+int foo(void *x)
+{
+ asm ();
+ return *(int *) x != 42;
+}
+
+__attribute__ ((__noinline__, __noclone__))
+void foobar(void *x)
+{
+ asm ();
+ if (foo(x))
+__builtin_abort();
+}
+
+struct rtc_class_ops {
+ int (*f)(void *, unsigned int enabled);
+};
+
+struct rtc_device
+{
+ void *owner;
+ struct rtc_class_ops *ops;
+ int ops_lock;
+};
+
+extern __attribute__ ((__noinline__, __noclone__))
+int rtc_update_irq_enable(struct rtc_device *rtc, unsigned int);
+
+int main(void)
+{
+ struct rtc_class_ops ops = {(void *) 0};
+ struct rtc_device dev1 = {0, ops, 42};
+
+ if (rtc_update_irq_enable (dev1, 1) != -22)
+__builtin_abort ();
+
+ __builtin_exit (0);
+}
Index: gcc/config/cris/cris.c
===
--- gcc/config/cris/cris.c
