Re: [PATCH] Changes in mode switching
On Thu, Sep 20, 2012 at 8:06 AM, Vladimir Yakovlev vbyakov...@gmail.com wrote: The compiler with the patch and without post_reload.patch is built and works successfully. It has the only failure with avx-vzeroupper-3 test because of post reload problem. Ok, can you please elaborate a bit on this filure? Perhaps someone has an idea why reload moves unspec_volatile around? Thanks, Uros.
Re: Top Level GCC change questions
Steve Ellcey schrieb: DJ Delorie wrote: Is there any automation for this or is it still up to each person checking in files to copy stuff over by hand? There is no automation, as neither project was willing to cede control to the other. In general, any patch applied to one repo should be (and may be) applied to the other, but at the moment it's up to each committer to actually do it. OK. I also noticed a change that is in the config directory in GCC but not in binutils: [...] There are also these two changes to configure[.ac] http://gcc.gnu.org/viewcvs?view=revisionrevision=190967 http://gcc.gnu.org/viewcvs?view=revisionrevision=190887 I filed a copyright assignment for the GCC project, so I don't know if it is appropriate to sync these changes with other FSF projects where I did not file a copyright assignment. Johann
Re: [Patch] catch builtin_bswap16 construct
The attached patch catches C constructs: (A 8) | (A 8) where A is unsigned 16 bits and maps them to builtin_bswap16(A) which can provide more efficient implementations on some targets. This belongs in tree-ssa-math-opts.c:execute_optimize_bswap instead. When I implemented __builtin_bswap16, I didn't add this because I thought this would be overkill since the RTL combiner should be able to catch the pattern. Have you investigated on this front? But I don't have a strong opinion. -- Eric Botcazou
[PATCH] Fix PR C++/50970 -- Function pointer dereferenced twice in if statement on Arm cpu
Hi,
PR 50970 is a general c++ front-end issue for targets which define
TARGET_PTRMEMFUNC_VBIT_LOCATION ptrmemfunc_vbit_in_delta, although the
reporter had issues only on ARM.
Root cause: It misses a check for side effects when generating pfn and
delta related expressions.
In the failed case, op0 is a function call. pfn0 and delta0 are
expressions based on the return value of op0. Without the check, the
function will be called twice.
The patch is to add the check for op0.
No make check regression on ARM.
Is it OK for trunk?
Thanks!
-Zhenqiang
cp/ChangeLog:
2012-09-20 Zhenqiang Chen zhenqiang.c...@linaro.org
PR c++/50970
* typeck.c (cp_build_binary_op): Check side effects before generating
pfn and delta related expressions.
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index ad4b090..884f7d0 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4159,18 +4159,23 @@ cp_build_binary_op (location_t location,
if (TARGET_PTRMEMFUNC_VBIT_LOCATION
== ptrmemfunc_vbit_in_delta)
{
- tree pfn0 = pfn_from_ptrmemfunc (op0);
- tree delta0 = delta_from_ptrmemfunc (op0);
- tree e1 = cp_build_binary_op (location,
- EQ_EXPR,
- pfn0,
- build_zero_cst (TREE_TYPE (pfn0)),
- complain);
- tree e2 = cp_build_binary_op (location,
- BIT_AND_EXPR,
- delta0,
- integer_one_node,
- complain);
+ tree pfn0, delta0, e1, e2;
+
+ if (TREE_SIDE_EFFECTS (op0))
+ op0 = save_expr (op0);
+
+ pfn0 = pfn_from_ptrmemfunc (op0);
+ delta0 = delta_from_ptrmemfunc (op0);
+ e1 = cp_build_binary_op (location,
+ EQ_EXPR,
+ pfn0,
+ build_zero_cst (TREE_TYPE (pfn0)),
+ complain);
+ e2 = cp_build_binary_op (location,
+ BIT_AND_EXPR,
+ delta0,
+ integer_one_node,
+ complain);
if ((complain tf_warning)
c_inhibit_evaluation_warnings == 0
Re: [Patch] catch builtin_bswap16 construct
On 20 September 2012 09:12, Eric Botcazou ebotca...@adacore.com wrote: The attached patch catches C constructs: (A 8) | (A 8) where A is unsigned 16 bits and maps them to builtin_bswap16(A) which can provide more efficient implementations on some targets. This belongs in tree-ssa-math-opts.c:execute_optimize_bswap instead. OK I'll have a look at that. Actually I modified fold-const.c because it's here that the similar 32 bits pattern is turned into a rotate. When I implemented __builtin_bswap16, I didn't add this because I thought this would be overkill since the RTL combiner should be able to catch the pattern. Have you investigated on this front? But I don't have a strong opinion. No I didn't. As I said above, I looked at where the 32 bits pattern was handled and added the 16 bits one. Christophe.
[PATCH] Docs: lto.texi: Fix typo
Fix typo. The first are in the statement should be and.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
gcc/doc/lto.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gcc/doc/lto.texi b/gcc/doc/lto.texi
index 73fd831..68f8759 100644
--- a/gcc/doc/lto.texi
+++ b/gcc/doc/lto.texi
@@ -455,7 +455,7 @@ alone. The problem is that propagation of inter-procedural
information does not work well across functions and variables
that are called or referenced by other compilation units (such as
from a dynamically linked library). We say that such functions
-are variables are @emph{externally visible}.
+and variables are @emph{externally visible}.
To make the situation even more difficult, many applications
organize themselves as a set of shared libraries, and the default
--
1.7.3.4
[PATCH] PR c++/53609 - Wrong argument deduction for pack expansion in argument pack
Hello,
Consider this example:
1 templateclass...I struct List {};
2 templateint T struct Z {static const int value = T;};
3 templateint...T using LZ = ListZT...;
4
5 templateclass...U
6 struct F
7 {
8using N = LZU::value...; //#1 This should amount to
ListZU::value...
9 }
10
11 FZ1, Z2 ::N A; //#2
which G++ fails to compile, with this error message:
test-PR53609-3.cc: In instantiation of 'struct FZ1, Z2 ':
test-PR53609-3.cc:11:15: required from here
test-PR53609-3.cc:3:43: error: wrong number of template arguments (2, should be
1)
templateint...T using LZ = ListZT...;
^
test-PR53609-3.cc:2:24: error: provided for 'templateint T struct Z'
templateint T struct Z {static const int value = T;};
I think this is because in #1, when we substitute the argument pack
{U::value...} into the pack expansion ZT..., tsubst_pack_expansion
yields ZU::value..., instead of ZU::value..., so the instantiation
of LZ amounts to ListZU::value... , instead of
ListZU::value
The idea of this patch is to make tsubst_pack_expansion support
substituting an argument pack (into a pack expansion) where one of the
arguments (let's call it the Ith argument) is itself a pack expansion
P. In that case, the Ith element resulting from the substituting
should be a pack expansion P'.
The pattern of P' is then the pattern of P into which the pattern of
the Ith argument of the argument pack has been substituted.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (real_argument_pack_element_p)
(any_non_real_argument_pack_element_p)
(arg_pack_select_for_pack_expansion)
(set_arg_pack_select_index_for_pack_expansion): New static
functions.
(has_bare_parameter_packs): Factorized out of ...
(check_for_bare_parameter_packs): ... here.
(tsubst_pack_expansion): Support substituting an argument pack
that contains a pack expansion.
gcc/testsuite/
* g++.dg/cpp0x/variadic139.C: New test.
* g++.dg/cpp0x/variadic140.C: Likewise.
* g++.dg/cpp0x/variadic141.C: Likewise.
---
gcc/cp/pt.c | 151 --
gcc/testsuite/g++.dg/cpp0x/variadic139.C | 14 +++
gcc/testsuite/g++.dg/cpp0x/variadic140.C | 22 +
gcc/testsuite/g++.dg/cpp0x/variadic141.C | 22 +
4 files changed, 182 insertions(+), 27 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic139.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic140.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic141.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 16952bf..bcfe83f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3310,6 +3310,29 @@ make_pack_expansion (tree arg)
return result;
}
+/* Return NULL_TREE iff T contains *NO* unexpanded parameter packs.
+ Return the TREE_LIST of unexpanded parameter packs otherwise. */
+
+static tree
+has_bare_parameter_packs (tree t)
+{
+ tree parameter_packs = NULL_TREE;
+ struct find_parameter_pack_data ppd;
+
+ if (!processing_template_decl || !t || t == error_mark_node)
+return NULL_TREE;
+
+ if (TREE_CODE (t) == TYPE_DECL)
+t = TREE_TYPE (t);
+
+ ppd.parameter_packs = parameter_packs;
+ ppd.visited = pointer_set_create ();
+ cp_walk_tree (t, find_parameter_packs_r, ppd, ppd.visited);
+ pointer_set_destroy (ppd.visited);
+
+ return parameter_packs;
+}
+
/* Checks T for any bare parameter packs, which have not yet been
expanded, and issues an error if any are found. This operation can
only be done on full expressions or types (e.g., an expression
@@ -3327,19 +3350,7 @@ make_pack_expansion (tree arg)
bool
check_for_bare_parameter_packs (tree t)
{
- tree parameter_packs = NULL_TREE;
- struct find_parameter_pack_data ppd;
-
- if (!processing_template_decl || !t || t == error_mark_node)
-return false;
-
- if (TREE_CODE (t) == TYPE_DECL)
-t = TREE_TYPE (t);
-
- ppd.parameter_packs = parameter_packs;
- ppd.visited = pointer_set_create ();
- cp_walk_tree (t, find_parameter_packs_r, ppd, ppd.visited);
- pointer_set_destroy (ppd.visited);
+ tree parameter_packs = has_bare_parameter_packs (t);
if (parameter_packs)
{
@@ -9065,6 +9076,86 @@ make_fnparm_pack (tree spec_parm)
return extract_fnparm_pack (NULL_TREE, spec_parm);
}
+/* Return true iff the Ith element of the argument pack ARG_PACK is
+ *NOT* a pack expansion. */
+
+static bool
+real_argument_pack_element_p (tree arg_pack, int i)
+{
+ return !PACK_EXPANSION_P (TREE_VEC_ELT
+ (ARGUMENT_PACK_ARGS (arg_pack), i));
+}
+
+/* Return true iff ARG_PACK is an argument pack that contains a pack
+ expansion. */
+
+static bool
+any_non_real_argument_pack_element_p (tree arg_pack)
+{
+ if (arg_pack == NULL_TREE
+ || arg_pack == error_mark_node
+ || !ARGUMENT_PACK_P (arg_pack))
+return false;
+
+ for (int
Re: [PATCH] Docs: lto.texi: Fix typo
On 20 Sep 2012, at 09:27, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote:
Fix typo. The first are in the statement should be and.
Ok.
R.
Signed-off-by: Chen Wei-Ren che...@iis.sinica.edu.tw
---
gcc/doc/lto.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gcc/doc/lto.texi b/gcc/doc/lto.texi
index 73fd831..68f8759 100644
--- a/gcc/doc/lto.texi
+++ b/gcc/doc/lto.texi
@@ -455,7 +455,7 @@ alone. The problem is that propagation of
inter-procedural
information does not work well across functions and variables
that are called or referenced by other compilation units (such as
from a dynamically linked library). We say that such functions
-are variables are @emph{externally visible}.
+and variables are @emph{externally visible}.
To make the situation even more difficult, many applications
organize themselves as a set of shared libraries, and the default
--
1.7.3.4
[PATCH] Don't cast XNEWVEC's result
While reading tree-ssa-threadupdate.c I noticed that we're casting
XNEWVEC's result. This isn't done anywhere else and the macro
does the cast internally anyway, thus there's no need to repeat that.
Also there was a typo in copyright years, so I fixed that as well
while at it. Regtested/bootstrapped on x86_64.
2012-09-19 Marek Polacek pola...@redhat.com
* tree-ssa-threadupdate.c (mark_threaded_blocks): Don't cast XNEWVEC's
result.
(create_edge_and_update_destination_phis): Likewise.
--- gcc/tree-ssa-threadupdate.c.mp 2012-09-19 20:12:49.711262969 +0200
+++ gcc/tree-ssa-threadupdate.c 2012-09-19 20:17:42.427287843 +0200
@@ -1,5 +1,5 @@
/* Thread edges through blocks and update the control flow and SSA graphs.
- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2010, 201
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -362,7 +362,7 @@ create_edge_and_update_destination_phis
if (rd-outgoing_edge-aux)
{
- e-aux = (edge *) XNEWVEC (edge, 2);
+ e-aux = XNEWVEC (edge, 2);
THREAD_TARGET(e) = THREAD_TARGET (rd-outgoing_edge);
THREAD_TARGET2(e) = THREAD_TARGET2 (rd-outgoing_edge);
}
@@ -1143,7 +1143,7 @@ mark_threaded_blocks (bitmap threaded_bl
for (i = 0; i VEC_length (edge, threaded_edges); i += 3)
{
edge e = VEC_index (edge, threaded_edges, i);
- edge *x = (edge *) XNEWVEC (edge, 2);
+ edge *x = XNEWVEC (edge, 2);
e-aux = x;
THREAD_TARGET (e) = VEC_index (edge, threaded_edges, i + 1);
Marek
Re: [PATCH] Docs: lto.texi: Fix typo
On Thu, Sep 20, 2012 at 09:49:27AM +0100, rearn...@arm.com wrote: On 20 Sep 2012, at 09:27, 陳韋任 (Wei-Ren Chen) che...@iis.sinica.edu.tw wrote: Fix typo. The first are in the statement should be and. Ok. R. Thanks. Would you like to commit this for me? :) Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
[PATCH] Merge identical cases
In tree-ssa-operands.c in get_expr_operands we have two identical
cases, for SSA_NAME and {VAR,PARM,RESULT}_DECL. If that isn't
intentional (maybe it's clearer to split _*NAME and *_DECL--the
compiler will merge them anyway), we can merge those two cases.
Regtested/bootstrapped on x86_64.
2012-09-20 Marek Polacek pola...@redhat.com
* tree-ssa-operands.c (get_expr_operands): Merge identical cases.
--- gcc/tree-ssa-operands.c.mp 2012-09-20 11:22:40.364588965 +0200
+++ gcc/tree-ssa-operands.c 2012-09-20 11:29:40.178904905 +0200
@@ -1,5 +1,6 @@
/* SSA operands management for trees.
Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+ 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -841,9 +842,6 @@ get_expr_operands (gimple stmt, tree *ex
return;
case SSA_NAME:
- add_stmt_operand (expr_p, stmt, flags);
- return;
-
case VAR_DECL:
case PARM_DECL:
case RESULT_DECL:
Marek
Re: [PATCH] Combine location with block using block_locations
A lot of failures in the test suite have appeared between revisions 191485 and 191494 see http://gcc.gnu.org/ml/gcc-regression/2012-09/msg00327.html ). I have looked at the failure of libgomp.fortran/reduction1.f90: [macbook] f90/bug% gfc -O3 -g -fopenmp /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90 /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90: In function 'MAIN__._omp_fn.0': /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90:22:0: internal compiler error: in change_scope, at final.c:1543 !$omp reduction (+:i, ia, r, ra, d, da, c, ca) The backtrace is #0 fancy_abort (file=0x100a7b376 ../../work/gcc/final.c, line=1543, function=0x100b418b3 change_scope) at ../../work/gcc/diagnostic.c:1010 #1 0x00010045f9f9 in change_scope (orig_insn=value optimized out, s1=value optimized out, s2=value optimized out) at ../../work/gcc/final.c:1543 #2 0x000100463c40 in final_start_function (first=value optimized out, file=value optimized out, optimize_p=value optimized out) at ../../work/gcc/final.c:1613 #3 0x000100465761 in rest_of_handle_final () at ../../work/gcc/final.c:4291 #4 0x0001006486ea in execute_one_pass (pass=value optimized out) at ../../work/gcc/passes.c:2206 #5 0x000100648afd in execute_pass_list (pass=value optimized out) at ../../work/gcc/passes.c:2261 #6 0x000100648b0f in execute_pass_list (pass=value optimized out) at ../../work/gcc/passes.c:2262 #7 0x000100648b0f in execute_pass_list (pass=value optimized out) at ../../work/gcc/passes.c:2262 #8 0x000100365f4b in expand_function (node=value optimized out) at ../../work/gcc/cgraphunit.c:1609 #9 0x0001003680ba in compile () at ../../work/gcc/cgraphunit.c:1714 #10 0x00010036870f in finalize_compilation_unit () at ../../work/gcc/cgraphunit.c:2089 #11 0x0001005e0f27 in write_global_declarations () at ../../work/gcc/langhooks.c:323 #12 0x0001007047f1 in compile_file () at ../../work/gcc/toplev.c:560 #13 0x00010070663c in toplev_main (argc=value optimized out, argv=value optimized out) at ../../work/gcc/toplev.c:1863 #14 0x00010e14 in start () Could you have a look to this problem? TIA Dominique
Re: [PATCH, ARM] 64-bit shifts in NEON
On 18/09/12 18:06, Ulrich Weigand wrote:
Hello,
a while ago Andrew Stubbs posted a patch to use NEON registers
and instructions to perform 64-bit integer shifts:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01645.html
As Andrew no longer works on ARM, I've now picked this up and
reworked it a bit:
- Updated for current mainline changes.
- Fixed a typo in the left shift by 1 special case.
- Reworked constraint lists to have the NEON alternatives actually
reliably chosen in the left shift by register case.
- Noticed that arm_emit_coreregs_64bit_shift actually does *not*
need a scratch for shifting by constant in any case, which
simplifies the implementation a bit.
- Further minor simplifications cleanup.
Tested on arm-linux-gnueabi (--with-arch=armv7-a --with-float=softfp
--with-fpu=neon --with-mode=thumb) with no regressions.
OK for mainline?
Hmm, this is going to cause bottlenecks on Cortex-A15: writing a Neon
single-precision register and then reading it back as a double-precision
value will cause scheduling problems.
The awkward thing here is that the shift only uses the bottom 8 bits of
the register, even though the instruction takes a 64-bit register, so we
don't want to go to the trouble of sign-extending the value all the way
out to 64-bits.
A solution to this is to have the set of the shifter register done as a
lane-set operation rather than as a set of the lower register, but it
probably needs some thought as to how to achieve this without creating
other overheads.
R.
Bye,
Ulrich
ChangeLog:
2012-09-17 Andrew Stubbs a...@codesourcery.com
Ulrich Weigand ulrich.weig...@linaro.org
* config/arm/arm.c (arm_print_operand): Add new 'E' format code.
(arm_emit_coreregs_64bit_shift): Fix comment.
* config/arm/arm.h (enum reg_class): Add VFP_LO_REGS_EVEN.
(REG_CLASS_NAMES, REG_CLASS_CONTENTS, IS_VFP_CLASS): Likewise.
* config/arm/arm.md (opt, opt_enabled): New attributes.
(enabled): Use opt_enabled.
(ashldi3, ashrdi3, lshrdi3): Add TARGET_NEON case.
* config/arm/constraints.md (T): New register constraint.
* config/arm/iterators.md (rshifts): New code iterator.
(shift, shifttype): New code attributes.
* config/arm/neon.md (signed_shift_di3_neon, unsigned_shift_di3_neon,
ashldi3_neon_noclobber, ashldi3_neon, ashrdi3_neon_imm_noclobber,
lshrdi3_neon_imm_noclobber, shiftdi3_neon): New patterns.
Index: gcc/config/arm/arm.c
===
*** gcc/config/arm/arm.c(revision 191400)
--- gcc/config/arm/arm.c(working copy)
*** arm_print_operand (FILE *stream, rtx x,
*** 17280,17285
--- 17280,17303
}
return;
+ /* Print the VFP/Neon double precision register name that overlaps the
+given single-precision register. */
+ case 'E':
+ {
+ int mode = GET_MODE (x);
+
+ if (GET_MODE_SIZE (mode) != 4
+ || GET_CODE (x) != REG
+ || !IS_VFP_REGNUM (REGNO (x)))
+ {
+ output_operand_lossage (invalid operand for code '%c', code);
+ return;
+ }
+
+ fprintf (stream, d%d, (REGNO (x) - FIRST_VFP_REGNUM) 1);
+ }
+ return;
+
/* These two codes print the low/high doubleword register of a Neon quad
register, respectively. For pair-structure types, can also print
low/high quadword registers. */
*** arm_autoinc_modes_ok_p (enum machine_mod
*** 26293,26300
Input requirements:
- It is safe for the input and output to be the same register, but
early-clobber rules apply for the shift amount and scratch registers.
! - Shift by register requires both scratch registers. Shift by a
constant
! less than 32 in Thumb2 mode requires SCRATCH1 only. In all other
cases
the scratch registers may be NULL.
- Ashiftrt by a register also clobbers the CC register. */
void
--- 26311,26317
Input requirements:
- It is safe for the input and output to be the same register, but
early-clobber rules apply for the shift amount and scratch registers.
! - Shift by register requires both scratch registers. In all other cases
the scratch registers may be NULL.
- Ashiftrt by a register also clobbers the CC register. */
void
Index: gcc/config/arm/arm.h
===
*** gcc/config/arm/arm.h(revision 191254)
--- gcc/config/arm/arm.h(working copy)
*** enum reg_class
*** 1120,1125
--- 1120,1126
CORE_REGS,
VFP_D0_D7_REGS,
VFP_LO_REGS,
+ VFP_LO_REGS_EVEN,
VFP_HI_REGS,
VFP_REGS,
IWMMXT_REGS,
*** enum reg_class
*** 1146,1151
--- 1147,1153
Re: [C++ Patch / RFC] PR 52432
On 09/20/2012 06:08 AM, Jason Merrill wrote: OK. Thanks Jason. Unfortunately I can't apply the patch because apparently it triggers rather mysterious failures in the library testsuite, ICEs as Seg faults in 17_intro/headers/c++1998. I have troubles debugging it because I can't reproduce outside the testsuite (apparently it requires the library PCHs), also, if I run the testsuite again after build install the failures disappear. I even fear hardware problems on my machine. If somebody has the time to give the patchlet a try I would be curious to know if I'm alone in seeing such weird behaviors. Thanks, Paolo.
Re: [patch] split FRAME variables back into pieces
I really don't like this to be done outside of SRA (and it is written in a non-MEM_REF way). Could you elaborate on the latter point? If it can be improved, even in its current form... For the testcase in question we scalarize back 'i' in SRA (other scalars are optimized away already, but as SRA runs before DSE it still gets to see stores to FRAME.i). Now I wonder why we generate reasonable debug info even without inlining, thus there has to be a association to the original decls with the frame FIELD_DECLs. That is, lookup_decl_for_field should not be necessary and what we use for debug info generation should be used by SRA to assign a name to scalarized fields. The testcase is a toy example of course. That alone would not solve your issue because of the 'arr' field in the structure which cannot be scalarized (moved to a stand-alone decl) by SRA. That's one missed feature of SRA though, and generally useful. The improved scalarization of aggregates is the main point and what yielded the performance boost for SPARKSkein. So no, I don't think this patch is the right approach. OK, but I came to the opposite conclusion when I first tried to do it in SRA and I don't think I will change my mind in the near future. Never mind then. -- Eric Botcazou
Re: [C++ Patch / RFC] PR 52432
On 09/20/2012 12:58 PM, Paolo Carlini wrote: On 09/20/2012 06:08 AM, Jason Merrill wrote: OK. Thanks Jason. Unfortunately I can't apply the patch because apparently it triggers rather mysterious failures in the library testsuite, ICEs as Seg faults in 17_intro/headers/c++1998. Ah, ah, with today's mainline I see the weird failures also *without* the patch! Let's see if somebody else is experiencing the same issue, or it's just something broken on my system. Paolo.
Re: [PATCH] Don't cast XNEWVEC's result
On Thu, Sep 20, 2012 at 10:53 AM, Marek Polacek pola...@redhat.com wrote:
While reading tree-ssa-threadupdate.c I noticed that we're casting
XNEWVEC's result. This isn't done anywhere else and the macro
does the cast internally anyway, thus there's no need to repeat that.
Also there was a typo in copyright years, so I fixed that as well
while at it. Regtested/bootstrapped on x86_64.
Ok.
Thanks,
Richard.
2012-09-19 Marek Polacek pola...@redhat.com
* tree-ssa-threadupdate.c (mark_threaded_blocks): Don't cast XNEWVEC's
result.
(create_edge_and_update_destination_phis): Likewise.
--- gcc/tree-ssa-threadupdate.c.mp 2012-09-19 20:12:49.711262969 +0200
+++ gcc/tree-ssa-threadupdate.c 2012-09-19 20:17:42.427287843 +0200
@@ -1,5 +1,5 @@
/* Thread edges through blocks and update the control flow and SSA graphs.
- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2010, 201
+ Copyright (C) 2004, 2005, 2006, 2007, 2008, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -362,7 +362,7 @@ create_edge_and_update_destination_phis
if (rd-outgoing_edge-aux)
{
- e-aux = (edge *) XNEWVEC (edge, 2);
+ e-aux = XNEWVEC (edge, 2);
THREAD_TARGET(e) = THREAD_TARGET (rd-outgoing_edge);
THREAD_TARGET2(e) = THREAD_TARGET2 (rd-outgoing_edge);
}
@@ -1143,7 +1143,7 @@ mark_threaded_blocks (bitmap threaded_bl
for (i = 0; i VEC_length (edge, threaded_edges); i += 3)
{
edge e = VEC_index (edge, threaded_edges, i);
- edge *x = (edge *) XNEWVEC (edge, 2);
+ edge *x = XNEWVEC (edge, 2);
e-aux = x;
THREAD_TARGET (e) = VEC_index (edge, threaded_edges, i + 1);
Marek
Re: [PATCH] Merge identical cases
On Thu, Sep 20, 2012 at 11:54 AM, Marek Polacek pola...@redhat.com wrote:
In tree-ssa-operands.c in get_expr_operands we have two identical
cases, for SSA_NAME and {VAR,PARM,RESULT}_DECL. If that isn't
intentional (maybe it's clearer to split _*NAME and *_DECL--the
compiler will merge them anyway), we can merge those two cases.
Regtested/bootstrapped on x86_64.
Ok.
Thanks,
Richard.
2012-09-20 Marek Polacek pola...@redhat.com
* tree-ssa-operands.c (get_expr_operands): Merge identical cases.
--- gcc/tree-ssa-operands.c.mp 2012-09-20 11:22:40.364588965 +0200
+++ gcc/tree-ssa-operands.c 2012-09-20 11:29:40.178904905 +0200
@@ -1,5 +1,6 @@
/* SSA operands management for trees.
Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+ 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -841,9 +842,6 @@ get_expr_operands (gimple stmt, tree *ex
return;
case SSA_NAME:
- add_stmt_operand (expr_p, stmt, flags);
- return;
-
case VAR_DECL:
case PARM_DECL:
case RESULT_DECL:
Marek
[Patch] PR54635: Add addr_space_t argument to mode_dependent_address_p
mode_dependent_address_p is not sensitive to the address space of the passed
address. Thus, add an addr_space_t parameter to the hook.
Bootstapped without problems on x86-linux-gnu.
The patch is a no-op, it just adds the passing-around of the address space
information.
Ok to commit?
One more question:
This patch changes a target hook. Is there a place in the internals
that gathers changes by naming *all* the changed/extended/removed/poisoned
interfaces? So that developers can read the list of functions/macros/hooks
to learn if something interesting happened as they update the GCC sources?
Diff'ing the internals texi is tedious and too much noise as it would be
helpful to get a briefing.
Johann
PR 54635
* doc/tm.texi.in (TARGET_MODE_DEPENDENT_ADDRESS_P): Document new
parameter addrspace.
* doc/tm.texi: Regenerate.
* target.def (mode_dependent_address_p): Add addr_space_t parameter.
* targhooks.h (default_mode_dependent_address_p): Ditto.
* targhooks.c (default_mode_dependent_address_p): Ditto.
* expr.c (convert_move): Pass address space to mode_dependent_address_p.
* combine.c (combine_simplify_rtx): Ditto.
(make_extraction): Ditto.
(simplify_shift_const_1): Ditto.
(gen_lowpart_for_combine): Ditto.
* lower-subreg.c (simple_move_operand): Ditto.
* recog.c (simplify_while_replacing): Ditto.
(offsettable_address_addr_space_p): Ditto.
(mode_dependent_address_p): Ditto.
* simplify-rtx.c (simplify_unary_operation_1): Ditto.
(simplify_subreg): Ditto.
* config/m68k/m68k.md: Ditto.
* config/vax/vax.md: Ditto.
* config/vax/constraints.md (Q): Ditto.
* config/vax/predicates.md (indexed_memory_operand): Ditto.
* config/alpha/alpha.c (alpha_mode_dependent_address_p): Add
unused addr_space_t parameter.
* config/avr/avr.c (avr_mode_dependent_address_p): Ditto.
* config/h8300/h8300.c (h8300_mode_dependent_address_p): Ditto.
* config/m32r/m32r.c (m32r_mode_dependent_address_p): Ditto.
* config/rs6000/rs6000.c (rs6000_mode_dependent_address_p): Ditto.
* config/rx/rx.c (rx_mode_dependent_address_p): Ditto.
* config/sparc/sparc.c (sparc_mode_dependent_address_p): Ditto.
* config/stormy16/stormy16.c (xstormy16_mode_dependent_address_p):
Ditto.
* config/vax/vax.c (vax_mode_dependent_address_p): Ditto.
* config/xtensa/xtensa.c (xtensa_mode_dependent_address_p): Ditto.
Index: doc/tm.texi
===
--- doc/tm.texi (revision 191490)
+++ doc/tm.texi (working copy)
@@ -5611,8 +5611,9 @@ It is not necessary for this macro to co
address; but often a machine-dependent strategy can generate better code.
@end defmac
-@deftypefn {Target Hook} bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx @var{addr})
-This hook returns @code{true} if memory address @var{addr} can have
+@deftypefn {Target Hook} bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx @var{addr}, addr_space_t @var{addrspace})
+This hook returns @code{true} if memory address @var{addr} in address
+space @var{addrspace} can have
different meanings depending on the machine mode of the memory
reference it is used for or if the address is valid for some modes
but not others.
Index: doc/tm.texi.in
===
--- doc/tm.texi.in (revision 191490)
+++ doc/tm.texi.in (working copy)
@@ -5536,7 +5536,8 @@ address; but often a machine-dependent
@end defmac
@hook TARGET_MODE_DEPENDENT_ADDRESS_P
-This hook returns @code{true} if memory address @var{addr} can have
+This hook returns @code{true} if memory address @var{addr} in address
+space @var{addrspace} can have
different meanings depending on the machine mode of the memory
reference it is used for or if the address is valid for some modes
but not others.
Index: target.def
===
--- target.def (revision 191490)
+++ target.def (working copy)
@@ -1413,7 +1413,7 @@ DEFHOOK
DEFHOOK
(mode_dependent_address_p,
,
- bool, (const_rtx addr),
+ bool, (const_rtx addr, addr_space_t addrspace),
default_mode_dependent_address_p)
/* Given an invalid address X for a given machine mode, try machine-specific
Index: recog.h
===
--- recog.h (revision 191490)
+++ recog.h (working copy)
@@ -114,7 +114,7 @@ extern int offsettable_address_addr_spac
#define offsettable_address_p(strict,mode,addr) \
offsettable_address_addr_space_p ((strict), (mode), (addr), \
ADDR_SPACE_GENERIC)
-extern bool mode_dependent_address_p (rtx);
+extern bool mode_dependent_address_p (rtx, addr_space_t);
extern int recog (rtx, rtx, int *);
#ifndef GENERATOR_FILE
Index: targhooks.h
Re: [PATCH] Combine location with block using block_locations
Hi, On 09/19/2012 09:59 PM, Dehao Chen wrote: This patch was commited as r191494. I'm afraid I can't help *much* with the debugging, but on my x86_64-linux machine and a very straightforward configuration (--enable-languages=c++ --disable-multilib) after r191494 I'm seeing the following libstdc++ regressions. FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Does it make any sense to you? Please let me know if I can somehow help. Thanks, Paolo. /// In file included from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29, from /scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30: /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h: In member function 'virtual std::ctypechar::char_type std::ctypechar::do_widen(char) const': /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7: internal compiler error: Segmentation fault do_widen(char __c) const ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
Re: Use conditional casting with symtab_node
Hi, On Wed, 19 Sep 2012, Richard Guenther wrote: Just write: varpool_node *vnode; if ((vnode = node-try_variable ()) vnode-finalized) varpool_analyze_node (vnode); This has been the standard style for the past 2 decades and trading it for cascading if's is really a bad idea. Indeed. Btw, can we not provide a specialization for dynamic_cast ? This -try_... looks awkward to me compared to the more familiar vnode = dynamic_cast varpool_node (node) Gah. The less '' characters in source code the better. I'm not thrilled, but prefer the -try_ thingy. And yes, cascading if's for this idiom is bad. Ciao, Michael.
Re: Use conditional casting with symtab_node
Hi,
On Wed, 19 Sep 2012, Lawrence Crowl wrote:
On 9/19/12, Eric Botcazou ebotca...@adacore.com wrote:
The language syntax would bind the conditional into the
intializer, as in
if (varpool_node *vnode = (node-try_variable ()
vnode-finalized))
varpool_analyze_node (vnode);
which does not type-match.
So, if you want the type saftey and performance, the cascade
is really unavoidable.
Just write:
varpool_node *vnode;
if ((vnode = node-try_variable ()) vnode-finalized)
varpool_analyze_node (vnode);
This has been the standard style for the past 2 decades and
trading it for cascading if's is really a bad idea.
Assignments in if statements are known to cause confusion.
So? Make it:
varpool_node *vnode = node-try_variable ();
if (vnode vnode-finalized)
varpool_analyze_node (vnode);
The point of the change is to limit the scope of the variable
to the if statement, which prevents its unintended use later.
I'm not worried about this.
Why do you think cascading ifs is a bad idea?
Precedent. Confusion in case of dangling else (requiring more {}, and
hence even more indentation). Ugly.
Ciao,
Michael.
[AARCH64] [AARCH64-4.7] Use define_c_enum
I've just committed the attached to aarch64-branch and aarch64-4.7-branch. /MarcusFrom b0ca189452f5d12f013f7163570ccf4c97c374b0 Mon Sep 17 00:00:00 2001 From: Marcus Shawcroft marcus.shawcr...@arm.com Date: Thu, 20 Sep 2012 14:04:54 +0100 Subject: [PATCH 01/11] Use define_c_enum --- gcc/ChangeLog.aarch64 | 7 +++ gcc/config/aarch64/aarch64.md | 123 +++- gcc/config/aarch64/iterators.md | 81 ++ gcc/config/aarch64/sync.md | 12 +++- 4 files changed, 120 insertions(+), 103 deletions(-) diff --git a/gcc/ChangeLog.aarch64 b/gcc/ChangeLog.aarch64 index 4bab7ae..6baf152 100644 --- a/gcc/ChangeLog.aarch64 +++ b/gcc/ChangeLog.aarch64 @@ -1,3 +1,10 @@ +2012-09-20 Ramana Radhakrishnan ramana.radhakrish...@arm.com + + * config/aarch64/aarch64.md: Make unspec and unspecv constants + c_enums and split out to iterators.md and sync.md. + * config/aarch64/iterators.md: Add SIMD unspec c_enums. + * config/aarch64/sync.md: Add sync unspecv c_enums. + 2012-09-18 Ian Bolton ian.bol...@arm.com * config/aarch64/aarch64.h: Define CTZ_DEFINED_VALUE_AT_ZERO. diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index eeaaf63..e6086a9 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -65,108 +65,27 @@ ] ) -(define_constants - [ -(UNSPEC_NOP 0) -(UNSPEC_TLS 1) -(UNSPEC_CASESI 2) -(UNSPEC_GOTSMALLPIC3) -(UNSPEC_GOTSMALLTLS4) -(UNSPEC_PRLG_STK5) -(UNSPEC_MB 6) -(UNSPEC_ASHIFT_SIGNED 7) ; Used in aarch64-simd.md. -(UNSPEC_ASHIFT_UNSIGNED 8) ; Used in aarch64-simd.md. -(UNSPEC_FRINTZ9) -(UNSPEC_FRINTP 10) -(UNSPEC_FRINTM 11) -(UNSPEC_FRINTA 12) -(UNSPEC_FRINTI 13) -(UNSPEC_TLSDESC 14) -(UNSPEC_FRINTX 15) -(UNSPEC_FMAXV 16) ; Used in aarch64-simd.md. -(UNSPEC_FMINV 17) ; Used in aarch64-simd.md. -(UNSPEC_FADDV 18) ; Used in aarch64-simd.md. -(UNSPEC_ADDV 19) ; Used in aarch64-simd.md. -(UNSPEC_SMAXV 20) ; Used in aarch64-simd.md. -(UNSPEC_SMINV 21) ; Used in aarch64-simd.md. -(UNSPEC_UMAXV22) ; Used in aarch64-simd.md. -(UNSPEC_UMINV 23) ; Used in aarch64-simd.md. -(UNSPEC_SHADD 24) ; Used in aarch64-simd.md. -(UNSPEC_UHADD 25) ; Used in aarch64-simd.md. -(UNSPEC_SRHADD 26) ; Used in aarch64-simd.md. -(UNSPEC_URHADD 27) ; Used in aarch64-simd.md. -(UNSPEC_SHSUB 28) ; Used in aarch64-simd.md. -(UNSPEC_UHSUB 29) ; Used in aarch64-simd.md. -(UNSPEC_SRHSUB 30) ; Used in aarch64-simd.md. -(UNSPEC_URHSUB 31) ; Used in aarch64-simd.md. -(UNSPEC_ADDHN 32) ; Used in aarch64-simd.md. -(UNSPEC_RADDHN 33) ; Used in aarch64-simd.md. -(UNSPEC_SUBHN 34) ; Used in aarch64-simd.md. -(UNSPEC_RSUBHN 35) ; Used in aarch64-simd.md. -(UNSPEC_ADDHN2 36) ; Used in aarch64-simd.md. -(UNSPEC_RADDHN2 37) ; Used in aarch64-simd.md. -(UNSPEC_SUBHN2 38) ; Used in aarch64-simd.md. -(UNSPEC_RSUBHN2 39) ; Used in aarch64-simd.md. -(UNSPEC_SQDMULH 40) ; Used in aarch64-simd.md. -(UNSPEC_SQRDMULH 41) ; Used in aarch64-simd.md. -(UNSPEC_PMUL 42) ; Used in aarch64-simd.md. -(UNSPEC_USQADD 43) ; Used in aarch64-simd.md. -(UNSPEC_SUQADD 44) ; Used in aarch64-simd.md. -(UNSPEC_SQXTUN 45) ; Used in aarch64-simd.md. -(UNSPEC_SQXTN 46) ; Used in aarch64-simd.md. -(UNSPEC_UQXTN 47) ; Used in aarch64-simd.md. -(UNSPEC_SSRA 48) ; Used in aarch64-simd.md. -(UNSPEC_USRA 49) ; Used in aarch64-simd.md. -(UNSPEC_SRSRA 50) ; Used in aarch64-simd.md. -(UNSPEC_URSRA 51) ; Used in aarch64-simd.md. -(UNSPEC_SRSHR 52) ; Used in aarch64-simd.md. -(UNSPEC_URSHR 53) ; Used in aarch64-simd.md. -(UNSPEC_SQSHLU 54) ; Used in aarch64-simd.md. -(UNSPEC_SQSHL 55) ; Used in aarch64-simd.md. -(UNSPEC_UQSHL 56) ; Used in aarch64-simd.md. -(UNSPEC_SQSHRUN 57) ; Used in aarch64-simd.md. -(UNSPEC_SQRSHRUN 58) ; Used in aarch64-simd.md. -(UNSPEC_SQSHRN 59) ; Used in aarch64-simd.md. -(UNSPEC_UQSHRN 60) ; Used in aarch64-simd.md. -(UNSPEC_SQRSHRN 61) ; Used in aarch64-simd.md. -(UNSPEC_UQRSHRN 62) ; Used in aarch64-simd.md. -(UNSPEC_SSHL 63) ; Used in aarch64-simd.md. -(UNSPEC_USHL 64) ; Used in aarch64-simd.md. -(UNSPEC_SRSHL 65) ; Used in aarch64-simd.md. -(UNSPEC_URSHL 66) ; Used in aarch64-simd.md. -(UNSPEC_SQRSHL 67) ; Used in aarch64-simd.md. -(UNSPEC_UQRSHL 68) ; Used in aarch64-simd.md. -(UNSPEC_CMEQ 69) ; Used in aarch64-simd.md. -(UNSPEC_CMLE 70) ; Used in aarch64-simd.md. -(UNSPEC_CMLT 71) ; Used in aarch64-simd.md. -(UNSPEC_CMGE 72) ; Used in aarch64-simd.md. -(UNSPEC_CMGT 73) ; Used in aarch64-simd.md. -(UNSPEC_CMHS 74) ; Used in aarch64-simd.md. -(UNSPEC_CMHI 75) ; Used in aarch64-simd.md. -(UNSPEC_SSLI 76) ;
Re: [patch] split FRAME variables back into pieces
On Thu, Sep 20, 2012 at 12:56 PM, Eric Botcazou ebotca...@adacore.com wrote:
I really don't like this to be done outside of SRA (and it is written in a
non-MEM_REF way).
Could you elaborate on the latter point? If it can be improved, even in its
current form...
You rely on being able to see all FRAME accesses as component refs,
thus nothing transforms them into just MEM[FRAME, offset]. That's of
course something that can be easily broken by means of doing
some pointer arithmetic like (untested, but you get the idea)
foo()
{
int c[32];
int j;
bar()
{
int *p = c[4];
p = p + 1;
j = *p;
}
c[4] = 0;
bar();
return j;
}
this should get you j = MEM[CHAIN, 4]; in bar and thus a missing
component-ref when inlining.
I dont' think it's easily possible to recover from this in your scheme,
but it would be straight-forward for SRA (you basically look for the
base variable FRAME and special-case that completely for
replacement construction, also constraining accesses).
For the testcase in question we scalarize back
'i' in SRA (other scalars are optimized away already, but as SRA runs
before DSE it still gets to see stores to FRAME.i). Now I wonder
why we generate reasonable debug info even without inlining,
thus there has to be a association to the original decls with
the frame FIELD_DECLs. That is, lookup_decl_for_field should not be
necessary and what we use for debug info generation should be used by SRA
to assign a name to scalarized fields.
The testcase is a toy example of course.
Yes, I realize that.
That alone would not solve your issue because of the 'arr' field in
the structure which cannot be scalarized (moved to a stand-alone
decl) by SRA. That's one missed feature of SRA though, and generally
useful.
The improved scalarization of aggregates is the main point and what yielded
the performance boost for SPARKSkein.
So no, I don't think this patch is the right approach.
OK, but I came to the opposite conclusion when I first tried to do it in SRA
and I don't think I will change my mind in the near future. Never mind then.
Marking the FRAME VAR_DECL looks useful, maybe you can split that out
of your patch?
As of doing it in SRA what I'd do there is special-case FRAME for both
candidate consideration (so you get around the addressable issue)
and replacement generation.
Maybe you can open an enhancement bugreport for this and link
your patch / testcase to it?
Thanks,
Richard.
--
Eric Botcazou
Re: [PATCH] Combine location with block using block_locations
On 09/20/2012 03:04 PM, Paolo Carlini wrote: are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Take this only as a vague hint: I'm seeing many pch-related regressions here, between r191490 and r191501: http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01906.html http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01924.html Paolo.
Re: [Patch] PR54635: Add addr_space_t argument to mode_dependent_address_p
On Thu, 20 Sep 2012, Georg-Johann Lay wrote: mode_dependent_address_p is not sensitive to the address space of the passed address. Thus, add an addr_space_t parameter to the hook. Borderline obvious. :) (J/k; the added functionality seems obvious but the implementation may have non-obvious issues, though I saw none.) One more question: This patch changes a target hook. Is there a place in the internals that gathers changes by naming *all* the changed/extended/removed/poisoned interfaces? So that developers can read the list of functions/macros/hooks to learn if something interesting happened as they update the GCC sources? Someone once suggested an internal-changes web-page or file for the benefit of out-of-tree ports and patches, but I don't know what happened to that. I'd look in the wiki. Diff'ing the internals texi is tedious and too much noise as it would be helpful to get a briefing. Johann PR 54635 Better spell that PR other/54635 in the ChangeLog; if you don't get the syntax right it won't automatically show up in bugzilla. * doc/tm.texi.in (TARGET_MODE_DEPENDENT_ADDRESS_P): Document new parameter addrspace. ... brgds, H-P
Re: [PATCH] Combine location with block using block_locations
On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote: On 09/20/2012 03:04 PM, Paolo Carlini wrote: are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Take this only as a vague hint: I'm seeing many pch-related regressions here, between r191490 and r191501: r191502 is the jump function expression unsharing and location pruning patch of mine so if that revision fixes it, it's probably the same problem. (I'm still a bit surprised though, I thought the issue was an LTO one. But perhaps not.) Martin http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01906.html http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01924.html Paolo.
Re: Make cfun_push and cfun_pop also change current_function_decl
On Wed, Sep 19, 2012 at 3:15 PM, Martin Jambor mjam...@suse.cz wrote: Hi, this is my second attempt to make push_cfun and pop_cfun save and restore current_function_decl, so that code that wants to change the function context does not have to do the latter manually. This of course enforces that cfun and current_function_decl match at push_cfun points which is asserted and the patch checking_asserts that they match at cfun_pop times too, except when cfun is NULL and current_function_decl has been changed in order to interact with code shared with front-ends (and in some other cases, e.g. in dwarf2out.c). However, this code does not make pushing and popping NULL cfun cheaper because the patch is already quite big as it is. I will try doing that as a followup. The patch is very similar to what I have posted to the mailing list in August but without the two ugly spots (tricks in Ada front end and dwarf2out.c) which I have meanwhile sorted out differently. I have bootstrapped and tested the patch on x86_64-linux and have also LTO-built Firefox with it. OK for trunk? It looks like record_vars_into doesn't need to push/pop cfun at all (you can change that as a followup). Otherwise ok. Thanks, Richard. Thanks, Martin 2012-09-12 Martin Jambor mjam...@suse.cz * function.c (push_cfun): Check old current_function_decl matches old cfun, set new current_function_decl to the decl of the new cfun. (push_struct_function): Likewise. (pop_cfun): Likewise. (allocate_struct_function): Move call to invoke_set_current_function_hook to the end of the function. * cfgexpand.c (estimated_stack_frame_size): Do not set and restore current_function_decl. * cgraph.c (cgraph_release_function_body): Likewise. * cgraphunit.c (cgraph_process_new_functions): Likewise. (cgraph_add_new_function): Likewise. (cgraph_analyze_function): Likewise. (assemble_thunk): Set cfun to NULL at the end. (expand_function): Move call to set_cfun downwards. * gimple-low.c (record_vars_into): Only check current_function_decl before possibly doing push_cfun. * gimplify.c (gimplify_function_tree): Do not set and restore current_function_decl. * ipa-inline-analysis.c (compute_inline_parameters): Likewise. (inline_analyze_function): Likewise. * ipa-prop.c (ipa_analyze_node): Likewise. * ipa-pure-const.c (analyze_function): Likewise. * lto-streamer-in.c (lto_input_function_body): Do not set current_function_decl. * lto-streamer-out.c (output_function): Do not set and restore current_function_decl. * omp-low.c (finalize_task_copyfn): Likewise. (expand_omp_taskreg): Likewise. (create_task_copyfn): Likewise, move push_cfun up quite a bit. * passes.c (dump_passes): Do not set and restore current_function_decl. (do_per_function): Likewise. (do_per_function_toporder): Likewise. * trans-mem.c (ipa_tm_scan_irr_function): Likewise. (ipa_tm_transform_transaction): Likewise. (ipa_tm_transform_clone): Likewise. (ipa_tm_execute): Likewise. * tree-emutls.c (lower_emutls_function_body): Likewise. * tree-inline.c (initialize_cfun): Do not call pop_cfun. (tree_function_versioning): Do not call push_cfun, do not set and restore current_function_decl. Remove assert checking consistency of cfun and current_function_decl. * tree-profile.c (tree_profiling): Do not set and restore current_function_decl. * tree-sra.c (convert_callers_for_node): Do not set current_function_decl. (convert_callers): Do not restore current_function_decl. (modify_function): Do not set current_function_decl. * tree-ssa-structalias.c (ipa_pta_execute): Do not set and restore current_function_decl. fortran/ * trans-decl.c (gfc_get_extern_function_decl): Push NULL cfun. Do not set and restore current_function_decl. (gfc_init_coarray_decl): Do not set and restore current_function_decl. go/ * gofrontend/gogo-tree.cc (Gogo::write_initialization_function): Do not set and restore current_function_decl. (Gogo::write_globals): Likewise. (Named_object::get_tree): Likewise. lto/ * lto.c (lto_materialize_function): Call push_struct_function and pop_cfun. *** /tmp/WDLEAb_cfgexpand.c Wed Sep 19 14:29:03 2012 --- gcc/cfgexpand.c Mon Sep 17 14:48:19 2012 *** estimated_stack_frame_size (struct cgrap *** 1423,1432 HOST_WIDE_INT size = 0; size_t i; tree var; - tree old_cur_fun_decl = current_function_decl; struct function *fn = DECL_STRUCT_FUNCTION (node-symbol.decl); - current_function_decl =
[PATCH] Use automake no-dist for libatomic and libitm
Hi!
GCC 4.7.2 upload to ftp.gnu.org has been rejected again similarly to 4.4.4
upload 2.5 years ago, again on security issues with automake dist/distcheck
stuff that gcc never uses. From what I remember or can read in the
archives, we've resolved it at that point by making gcc owned libdirs use
automake no-dist option on the trunk, regenerating the imported libraries
with newer automake and for release branches which shouldn't be importing
external library sources anymore just make everything no-dist.
The following patch is the trunk part, taking care of no-dist for gcc owned
directories. I've used automake 1.11.1 to avoid bigger changes, the
problematic lines are all removed even by that versionw ith no-dist.
Ok for trunk?
2012-09-20 Jakub Jelinek ja...@redhat.com
PR other/43620
libatomic/
* configure.ac (AM_INIT_AUTOMAKE): Add no-dist.
* configure: Regenerate.
* Makefile.in: Regenerate.
libitm/
* configure.ac (AM_INIT_AUTOMAKE): Add no-dist.
* configure: Regenerate.
* Makefile.in: Regenerate.
--- libatomic/configure.ac.jj 2012-05-08 14:15:52.946811336 +0200
+++ libatomic/configure.ac 2012-09-20 14:09:06.710071512 +0200
@@ -76,12 +76,13 @@ target_alias=${target_alias-$host_alias}
# no-define: PACKAGE and VERSION will not be #define'd in config.h (a bunch
# of other PACKAGE_* variables will, however, and there's nothing
# we can do about that; they come from AC_INIT).
+# no-dist: we don't want 'dist' and related rules.
# foreign: we don't follow the normal rules for GNU packages (no COPYING
#file in the top srcdir, etc, etc), so stop complaining.
# -Wall: turns on all automake warnings...
# -Wno-portability: ...except this one, since GNU make is required.
# -Wno-override: ... and this one, since we do want this in testsuite.
-AM_INIT_AUTOMAKE([1.9.0 foreign -Wall -Wno-portability -Wno-override])
+AM_INIT_AUTOMAKE([1.9.0 foreign no-dist -Wall -Wno-portability -Wno-override])
AM_ENABLE_MULTILIB(, ..)
# Calculate toolexeclibdir
--- libatomic/configure.jj 2012-09-17 11:13:20.0 +0200
+++ libatomic/configure 2012-09-20 14:31:42.738332338 +0200
@@ -2571,6 +2570,7 @@ target_alias=${target_alias-$host_alias}
# no-define: PACKAGE and VERSION will not be #define'd in config.h (a bunch
# of other PACKAGE_* variables will, however, and there's nothing
# we can do about that; they come from AC_INIT).
+# no-dist: we don't want 'dist' and related rules.
# foreign: we don't follow the normal rules for GNU packages (no COPYING
#file in the top srcdir, etc, etc), so stop complaining.
# -Wall: turns on all automake warnings...
--- libatomic/Makefile.in.jj2012-05-08 14:15:52.0 +0200
+++ libatomic/Makefile.in 2012-09-20 14:22:47.671364331 +0200
@@ -43,12 +43,10 @@ target_triplet = @target@
@ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_2 = $(addsuffix
_8_1_.lo,$(SIZEOBJS))
@ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_3 = $(addsuffix
_16_1_.lo,$(SIZEOBJS))
subdir = .
-DIST_COMMON = $(am__configure_deps) $(srcdir)/../config.guess \
- $(srcdir)/../config.sub $(srcdir)/../depcomp \
- $(srcdir)/../install-sh $(srcdir)/../ltmain.sh \
- $(srcdir)/../missing $(srcdir)/../mkinstalldirs \
- $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
- $(srcdir)/auto-config.h.in $(top_srcdir)/configure ChangeLog
+DIST_COMMON = ChangeLog $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
+ $(top_srcdir)/configure $(am__configure_deps) \
+ $(srcdir)/auto-config.h.in $(srcdir)/../mkinstalldirs \
+ $(srcdir)/../depcomp
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
@@ -110,7 +108,6 @@ LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLF
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
SOURCES = $(libatomic_la_SOURCES) $(EXTRA_libatomic_la_SOURCES)
-DIST_SOURCES = $(libatomic_la_SOURCES) $(EXTRA_libatomic_la_SOURCES)
MULTISRCTOP =
MULTIBUILDTOP =
MULTIDIRS =
@@ -127,47 +124,10 @@ RECURSIVE_TARGETS = all-recursive check-
RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive\
distclean-recursive maintainer-clean-recursive
AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
- $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
- distdir dist dist-all distcheck
+ $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS
ETAGS = etags
CTAGS = ctags
DIST_SUBDIRS = $(SUBDIRS)
-DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-distdir = $(PACKAGE)-$(VERSION)
-top_distdir = $(distdir)
-am__remove_distdir = \
- { test ! -d $(distdir) \
-|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
- rm -fr $(distdir); }; }
-am__relativize = \
- dir0=`pwd`; \
-
Re: [PATCH] Combine location with block using block_locations
On 09/20/2012 04:05 PM, Martin Jambor wrote: On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote: On 09/20/2012 03:04 PM, Paolo Carlini wrote: are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Take this only as a vague hint: I'm seeing many pch-related regressions here, between r191490 and r191501: r191502 is the jump function expression unsharing and location pruning patch of mine so if that revision fixes it, it's probably the same problem. (I'm still a bit surprised though, I thought the issue was an LTO one. But perhaps not.) Note that the regressions are still there post r191502 (and that is consistent with what I'm seeing on my own machine): http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01954.html http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01962.html http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01970.html http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg01976.html Paolo.
Re: [PATCH] Combine location with block using block_locations
On Thu, Sep 20, 2012 at 03:26:29PM +0200, Paolo Carlini wrote: On 09/20/2012 03:04 PM, Paolo Carlini wrote: are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Take this only as a vague hint: I'm seeing many pch-related regressions here, between r191490 and r191501: r191502 is the jump function expression unsharing and location pruning patch of mine so if that revision fixes it, it's probably the same problem. (I'm still a bit surprised though, I thought the issue was an LTO one. But perhaps not.) Jump functions never go to PCH and you did not change any GTY annotations, so I would bet it is unrelated to that changes. Honza
[PATCH] Fix PR54634
This fixes PR54634, data-ref analysis does not properly model reads of global memory done by pure functions. So just give up. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-09-20 Richard Guenther rguent...@suse.de PR tree-optimization/54634 * tree-data-ref.c (get_references_in_stmt): For now give up for pure functions. Index: gcc/tree-data-ref.c === --- gcc/tree-data-ref.c (revision 191561) +++ gcc/tree-data-ref.c (working copy) @@ -4307,10 +4307,10 @@ get_references_in_stmt (gimple stmt, VEC *references = NULL; /* ASM_EXPR and CALL_EXPR may embed arbitrary side effects. - Calls have side-effects, except those to const or pure - functions. */ + As we cannot model data-references to not spelled out + accesses give up if they may occur. */ if ((stmt_code == GIMPLE_CALL -!(gimple_call_flags (stmt) (ECF_CONST | ECF_PURE))) +!(gimple_call_flags (stmt) ECF_CONST)) || (stmt_code == GIMPLE_ASM (gimple_asm_volatile_p (stmt) || gimple_vuse (stmt clobbers_memory = true;
Re: [PATCH] Use automake no-dist for libatomic and libitm
On Thu, Sep 20, 2012 at 3:30 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
GCC 4.7.2 upload to ftp.gnu.org has been rejected again similarly to 4.4.4
upload 2.5 years ago, again on security issues with automake dist/distcheck
stuff that gcc never uses. From what I remember or can read in the
archives, we've resolved it at that point by making gcc owned libdirs use
automake no-dist option on the trunk, regenerating the imported libraries
with newer automake and for release branches which shouldn't be importing
external library sources anymore just make everything no-dist.
The following patch is the trunk part, taking care of no-dist for gcc owned
directories. I've used automake 1.11.1 to avoid bigger changes, the
problematic lines are all removed even by that versionw ith no-dist.
Ok for trunk?
Ok.
Thanks,
Richard.
2012-09-20 Jakub Jelinek ja...@redhat.com
PR other/43620
libatomic/
* configure.ac (AM_INIT_AUTOMAKE): Add no-dist.
* configure: Regenerate.
* Makefile.in: Regenerate.
libitm/
* configure.ac (AM_INIT_AUTOMAKE): Add no-dist.
* configure: Regenerate.
* Makefile.in: Regenerate.
--- libatomic/configure.ac.jj 2012-05-08 14:15:52.946811336 +0200
+++ libatomic/configure.ac 2012-09-20 14:09:06.710071512 +0200
@@ -76,12 +76,13 @@ target_alias=${target_alias-$host_alias}
# no-define: PACKAGE and VERSION will not be #define'd in config.h (a bunch
# of other PACKAGE_* variables will, however, and there's
nothing
# we can do about that; they come from AC_INIT).
+# no-dist: we don't want 'dist' and related rules.
# foreign: we don't follow the normal rules for GNU packages (no COPYING
#file in the top srcdir, etc, etc), so stop complaining.
# -Wall: turns on all automake warnings...
# -Wno-portability: ...except this one, since GNU make is required.
# -Wno-override: ... and this one, since we do want this in testsuite.
-AM_INIT_AUTOMAKE([1.9.0 foreign -Wall -Wno-portability -Wno-override])
+AM_INIT_AUTOMAKE([1.9.0 foreign no-dist -Wall -Wno-portability
-Wno-override])
AM_ENABLE_MULTILIB(, ..)
# Calculate toolexeclibdir
--- libatomic/configure.jj 2012-09-17 11:13:20.0 +0200
+++ libatomic/configure 2012-09-20 14:31:42.738332338 +0200
@@ -2571,6 +2570,7 @@ target_alias=${target_alias-$host_alias}
# no-define: PACKAGE and VERSION will not be #define'd in config.h (a bunch
# of other PACKAGE_* variables will, however, and there's
nothing
# we can do about that; they come from AC_INIT).
+# no-dist: we don't want 'dist' and related rules.
# foreign: we don't follow the normal rules for GNU packages (no COPYING
#file in the top srcdir, etc, etc), so stop complaining.
# -Wall: turns on all automake warnings...
--- libatomic/Makefile.in.jj2012-05-08 14:15:52.0 +0200
+++ libatomic/Makefile.in 2012-09-20 14:22:47.671364331 +0200
@@ -43,12 +43,10 @@ target_triplet = @target@
@ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_2 = $(addsuffix
_8_1_.lo,$(SIZEOBJS))
@ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_3 = $(addsuffix
_16_1_.lo,$(SIZEOBJS))
subdir = .
-DIST_COMMON = $(am__configure_deps) $(srcdir)/../config.guess \
- $(srcdir)/../config.sub $(srcdir)/../depcomp \
- $(srcdir)/../install-sh $(srcdir)/../ltmain.sh \
- $(srcdir)/../missing $(srcdir)/../mkinstalldirs \
- $(srcdir)/Makefile.am $(srcdir)/Makefile.in \
- $(srcdir)/auto-config.h.in $(top_srcdir)/configure ChangeLog
+DIST_COMMON = ChangeLog $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
+ $(top_srcdir)/configure $(am__configure_deps) \
+ $(srcdir)/auto-config.h.in $(srcdir)/../mkinstalldirs \
+ $(srcdir)/../depcomp
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
$(top_srcdir)/../config/depstand.m4 \
@@ -110,7 +108,6 @@ LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLF
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@
SOURCES = $(libatomic_la_SOURCES) $(EXTRA_libatomic_la_SOURCES)
-DIST_SOURCES = $(libatomic_la_SOURCES) $(EXTRA_libatomic_la_SOURCES)
MULTISRCTOP =
MULTIBUILDTOP =
MULTIDIRS =
@@ -127,47 +124,10 @@ RECURSIVE_TARGETS = all-recursive check-
RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive\
distclean-recursive maintainer-clean-recursive
AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \
- $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \
- distdir dist dist-all distcheck
+ $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS
ETAGS = etags
CTAGS = ctags
DIST_SUBDIRS = $(SUBDIRS)
-DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-distdir = $(PACKAGE)-$(VERSION)
-top_distdir = $(distdir)
-am__remove_distdir = \
-
Re: [PATCH] Combine location with block using block_locations
Hi, Paolo, I'll look into the ICE problems now. Thanks, Dehao On Thu, Sep 20, 2012 at 9:04 PM, Paolo Carlini paolo.carl...@oracle.com wrote: Hi, On 09/19/2012 09:59 PM, Dehao Chen wrote: This patch was commited as r191494. I'm afraid I can't help *much* with the debugging, but on my x86_64-linux machine and a very straightforward configuration (--enable-languages=c++ --disable-multilib) after r191494 I'm seeing the following libstdc++ regressions. FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Does it make any sense to you? Please let me know if I can somehow help. Thanks, Paolo. /// In file included from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29, from /scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30: /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h: In member function 'virtual std::ctypechar::char_type std::ctypechar::do_widen(char) const': /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7: internal compiler error: Segmentation fault do_widen(char __c) const ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
Re: [Patch] PR54635: Add addr_space_t argument to mode_dependent_address_p
Hans-Peter Nilsson wrote: Georg-Johann Lay wrote: mode_dependent_address_p is not sensitive to the address space of the passed address. Thus, add an addr_space_t parameter to the hook. Borderline obvious. :) (J/k; the added functionality seems obvious but the implementation may have non-obvious issues, though I saw none.) What specifically? One more question: This patch changes a target hook. Is there a place in the internals that gathers changes by naming *all* the changed/extended/removed/poisoned interfaces? So that developers can read the list of functions/macros/hooks to learn if something interesting happened as they update the GCC sources? Someone once suggested an internal-changes web-page or file for the benefit of out-of-tree ports and patches, but I don't know what happened to that. I'd look in the wiki. Diff'ing the internals texi is tedious and too much noise as it would be helpful to get a briefing. Johann PR 54635 Better spell that PR other/54635 in the ChangeLog; if you don't get the syntax right it won't automatically show up in bugzilla. Okay with that change to the ChangeLog? Being unsure about the component, I chose other. Is middle-end better? AFAIK PR12345, PR 12345 and PR component/12345 entries are recognized and connected to bugzilla PRs? Johann
GCC 4.7.3 Status Report (2012-09-20)
Status == The GCC 4.7.2 release tarballs have been created and were uploaded to ftp.gnu.org. The GCC 4.7 branch is thus open again for regression and documentation fixes. Quality Data Priority # Change from Last Report --- --- P10 P2 84 + 10 P3 18 + 4 --- --- Total 102 + 14 Previous Report === http://gcc.gnu.org/ml/gcc/2012-09/msg00151.html
Re: [PATCH, ARM] 64-bit shifts in NEON
Richard Earnshaw wrote: Hmm, this is going to cause bottlenecks on Cortex-A15: writing a Neon single-precision register and then reading it back as a double-precision value will cause scheduling problems. Ok, that is a problem ... The awkward thing here is that the shift only uses the bottom 8 bits of the register, even though the instruction takes a 64-bit register, so we don't want to go to the trouble of sign-extending the value all the way out to 64-bits. We don't really care what the upper bits are set to. Would a vdup.32 Dn, Rm (instead of the vmov) help here, or does this likewise have performance issues? A solution to this is to have the set of the shifter register done as a lane-set operation rather than as a set of the lower register, but it probably needs some thought as to how to achieve this without creating other overheads. What instruction are you refering to here? Loads from memory? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [4.6 PATCH] Use automake no-dist everywhere
On Thu, Sep 20, 2012 at 6:34 AM, Jakub Jelinek ja...@redhat.com wrote: Similarly for 4.6 branch. Similar question for libgo, though I hope no syncing is being performed to such old release branch anymore. Correct: I am not syncing to the 4.6 branch. Go ahead and change it as needed. Ian
Re: [4.7 PATCH] Use automake no-dist everywhere
On Thu, Sep 20, 2012 at 6:33 AM, Jakub Jelinek ja...@redhat.com wrote: This is the 4.7 version. Not 100% sure about libgo, Ian, are you regularly syncing upstream libgo even into 4.7 branch, or only to trunk? I.e. are you find with this kind of change for libgo, or do you want to do such a change upstream, or do you need make dist/distcheck upstream and will take care of regenerating stuff with automake 1.11.6 or later? I am regularly syncing libgo patch fixes into both mainline and the 4.7 branch, only not right now because the 4.7 branch is closed (unless I'm out of date). If you want to commit this to the 4.7 branch now while it is closed, go ahead, and I will catch up. Normally I think it's preferable to make the change upstream first. Thanks. Ian
[patch] [ARM]
Starting with 4.4, GCC informs about that the `va_list' mangling has changed.
This makes builds a bit noisy, and maybe it's time to remove this
informational message in the trunk.
Matthias
2012-09-20 Matthias Klose d...@ubuntu.com
* gcc/config/arm/arm.c (arm_mangle_type): Don't warn anymore that
4.4 has changed the `va_list mangling.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 191561)
+++ gcc/config/arm/arm.c(working copy)
@@ -25072,16 +25072,7 @@
has to be managled as if it is in the std namespace. */
if (TARGET_AAPCS_BASED
lang_hooks.types_compatible_p (CONST_CAST_TREE (type), va_list_type))
-{
- static bool warned;
- if (!warned warn_psabi !in_system_header)
- {
- warned = true;
- inform (input_location,
- the mangling of %va_list% has changed in GCC 4.4);
- }
- return St9__va_list;
-}
+return St9__va_list;
/* Half-precision float. */
if (TREE_CODE (type) == REAL_TYPE TYPE_PRECISION (type) == 16)
Re: [patch, mips] Fix for PR 54619, GCC aborting with -O -mips16
On Wed, 2012-09-19 at 18:42 +0100, Richard Sandiford wrote: But the documentation says: This hook is never called with an invalid address. Since VOIDmode MEMs aren't valid, I think that should mean it's invalid to call this hook (and rtlanal.c:address_cost) with VOIDmode. I never got time to look at that though. (The culprit in the case I saw was tree-ssa-loop-ivopts.c. Sandra had some improvements in this area, so maybe they would fix this too.) Loading or storing BLKmode doesn't map to any instruction, so I don't think returning true for zero is any better than what we do now. Richard It looks like address_cost does get called with invalid addresses though and I think that happens on other platforms then MIPS, it is just that MIPS is the only one where the invalid address causes a compile time failure. For example, if you compile my test program without -mips16 the compiler does not abort but address_cost is still called with a VOIDmode MEM. What do you think about my patch minus the initial check for offset == 0? That would avoid the compile time abort. If we didn't want to do that it seems like address_cost should include a check for valid addresses before it calls the hook. I am sure that would cause failures on many platforms and get some attention. Steve Ellcey sell...@mips.com
MAINTAINERS (Write After Approval): Add myself.
As the subject says. 2012-09-20 Marek Polacek pola...@redhat.com * MAINTAINERS (Write After Approval): Add myself. --- gcc/MAINTAINERS.mp 2012-09-20 18:39:14.496681360 +0200 +++ gcc/MAINTAINERS 2012-09-20 18:40:35.031886515 +0200 @@ -473,6 +473,7 @@ Fernando Pereira prone...@gmail.com Kaushik Phatak kaushik.pha...@kpitcummins.com Nicolas Pitre n...@cam.org Paul Pluzhnikovppluzhni...@google.com +Marek Polacek pola...@redhat.com Antoniu Popantoniu@gmail.com Vladimir Prus vladi...@codesourcery.com Yao Qi y...@codesourcery.com Marek
Go 4.7 patch committed: Bring 4.7 branch up to date
I have committed this patch to the GCC 4.7 branch to bring it up to date
with the bug fixes that I have already committed to mainline.
Bootstrapped 4.7 branch and ran Go testsuite on
x86_64-unknown-linux-gnu.
Ian
2012-09-20 Ian Lance Taylor i...@google.com
* Make-lang.in (go/gogo.o): Depend on filenames.h.
Index: gcc/go/Make-lang.in
===
--- gcc/go/Make-lang.in (revision 190405)
+++ gcc/go/Make-lang.in (working copy)
@@ -289,10 +289,11 @@ go/gogo-tree.o: go/gofrontend/gogo-tree.
convert.h output.h $(DIAGNOSTIC_H) $(GO_TYPES_H) \
$(GO_EXPRESSIONS_H) $(GO_STATEMENTS_H) $(GO_RUNTIME_H) \
go/gofrontend/backend.h $(GO_GOGO_H)
-go/gogo.o: go/gofrontend/gogo.cc $(GO_SYSTEM_H) $(GO_C_H) \
- go/gofrontend/go-dump.h $(GO_LEX_H) $(GO_TYPES_H) $(GO_STATEMENTS_H) \
- $(GO_EXPRESSIONS_H) go/gofrontend/dataflow.h $(GO_RUNTIME_H) \
- $(GO_IMPORT_H) $(GO_EXPORT_H) go/gofrontend/backend.h $(GO_GOGO_H)
+go/gogo.o: go/gofrontend/gogo.cc $(GO_SYSTEM_H) \
+ $(srcdir)/../include/filenames.h $(GO_C_H) go/gofrontend/go-dump.h \
+ $(GO_LEX_H) $(GO_TYPES_H) $(GO_STATEMENTS_H) $(GO_EXPRESSIONS_H) \
+ go/gofrontend/dataflow.h $(GO_RUNTIME_H) $(GO_IMPORT_H) \
+ $(GO_EXPORT_H) go/gofrontend/backend.h $(GO_GOGO_H)
go/import.o: go/gofrontend/import.cc $(GO_SYSTEM_H) \
$(srcdir)/../include/filenames.h $(srcdir)/../include/simple-object.h \
$(GO_C_H) $(GO_GOGO_H) $(GO_LEX_H) $(GO_TYPES_H) $(GO_EXPORT_H) \
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc (revision 190405)
+++ gcc/go/gofrontend/gogo.cc (working copy)
@@ -6,6 +6,8 @@
#include go-system.h
+#include filenames.h
+
#include go-c.h
#include go-dump.h
#include lex.h
@@ -385,6 +387,57 @@ Gogo::import_package(const std::string
bool is_local_name_exported,
Location location)
{
+ if (filename.empty())
+{
+ error_at(location, import path is empty);
+ return;
+}
+
+ const char *pf = filename.data();
+ const char *pend = pf + filename.length();
+ while (pf pend)
+{
+ unsigned int c;
+ int adv = Lex::fetch_char(pf, c);
+ if (adv == 0)
+ {
+ error_at(location, import path contains invalid UTF-8 sequence);
+ return;
+ }
+ if (c == '\0')
+ {
+ error_at(location, import path contains NUL);
+ return;
+ }
+ if (c 0x20 || c == 0x7f)
+ {
+ error_at(location, import path contains control character);
+ return;
+ }
+ if (c == '\\')
+ {
+ error_at(location, import path contains backslash; use slash);
+ return;
+ }
+ if (Lex::is_unicode_space(c))
+ {
+ error_at(location, import path contains space character);
+ return;
+ }
+ if (c 0x7f strchr(!\#$%'()*,:;=?[]^`{|}, c) != NULL)
+ {
+ error_at(location, import path contains invalid character '%c', c);
+ return;
+ }
+ pf += adv;
+}
+
+ if (IS_ABSOLUTE_PATH(filename.c_str()))
+{
+ error_at(location, import path cannot be absolute path);
+ return;
+}
+
if (filename == unsafe)
{
this-import_unsafe(local_name, is_local_name_exported, location);
@@ -1003,7 +1056,15 @@ Gogo::add_type(const std::string name,
Named_object* no = this-current_bindings()-add_type(name, NULL, type,
location);
if (!this-in_global_scope() no-is_type())
-no-type_value()-set_in_function(this-functions_.back().function);
+{
+ Named_object* f = this-functions_.back().function;
+ unsigned int index;
+ if (f-is_function())
+ index = f-func_value()-new_local_type_index();
+ else
+ index = 0;
+ no-type_value()-set_in_function(f, index);
+}
}
// Add a named type.
@@ -1025,7 +1086,12 @@ Gogo::declare_type(const std::string na
if (!this-in_global_scope() no-is_type_declaration())
{
Named_object* f = this-functions_.back().function;
- no-type_declaration_value()-set_in_function(f);
+ unsigned int index;
+ if (f-is_function())
+ index = f-func_value()-new_local_type_index();
+ else
+ index = 0;
+ no-type_declaration_value()-set_in_function(f, index);
}
return no;
}
@@ -2989,9 +3055,10 @@ Gogo::convert_named_types_in_bindings(Bi
Function::Function(Function_type* type, Function* enclosing, Block* block,
Location location)
: type_(type), enclosing_(enclosing), results_(NULL),
-closure_var_(NULL), block_(block), location_(location), fndecl_(NULL),
-defer_stack_(NULL), results_are_named_(false), calls_recover_(false),
-is_recover_thunk_(false), has_recover_thunk_(false)
+closure_var_(NULL), block_(block), location_(location), labels_(),
+local_type_count_(0), fndecl_(NULL), defer_stack_(NULL),
+results_are_named_(false), calls_recover_(false), is_recover_thunk_(false),
+has_recover_thunk_(false)
{
}
@@ -4599,9 +4666,10 @@ Named_object::set_type_value(Named_type*
go_assert(this-classification_ ==
Re: [4.7 PATCH] Use automake no-dist everywhere
On Thu, Sep 20, 2012 at 09:12:37AM -0700, Ian Lance Taylor wrote: On Thu, Sep 20, 2012 at 6:33 AM, Jakub Jelinek ja...@redhat.com wrote: This is the 4.7 version. Not 100% sure about libgo, Ian, are you regularly syncing upstream libgo even into 4.7 branch, or only to trunk? I.e. are you find with this kind of change for libgo, or do you want to do such a change upstream, or do you need make dist/distcheck upstream and will take care of regenerating stuff with automake 1.11.6 or later? I am regularly syncing libgo patch fixes into both mainline and the 4.7 branch, only not right now because the 4.7 branch is closed (unless I'm out of date). If you want to commit this to the 4.7 branch now while it is closed, go ahead, and I will catch up. Normally I think it's preferable to make the change upstream first. Ok, I'll leave libgo out from the patch and let you handle that on the 4.7 branch then. It needs to be resolved before 4.7.3 release in a few months (and on trunk before 4.8.0 release). Note that at this point the rejection reason was http://git.savannah.gnu.org/cgit/automake.git/commit/?id=784b3e6ccc7c72a1c95c340cbbe8897d6b689d76 i.e. chmod -R a-w $(distdir); chmod a+w $(distdir) line in the Makefile.in instead of chmod -R a-w $(distdir); chmod u+w $(distdir) But as this is not the first issue in the make dist* stuff, if you can, just disable it altogether ;). Jakub
Go patch committed: Keep up with main compiler
This patch to the Go frontend is really from Martin Jambor. It adjusts the Go frontend for changes in the main body of the compiler. This code in the Go frontend is slated to move out of gcc/go/gofrontend into gcc/go, hopefully sooner rather than later. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r fb054e3636c2 go/gogo-tree.cc --- a/go/gogo-tree.cc Thu Sep 20 09:28:23 2012 -0700 +++ b/go/gogo-tree.cc Thu Sep 20 10:02:17 2012 -0700 @@ -476,7 +476,6 @@ DECL_SAVED_TREE(fndecl) = init_stmt_list; - current_function_decl = fndecl; if (DECL_STRUCT_FUNCTION(fndecl) == NULL) push_struct_function(fndecl); else @@ -487,7 +486,6 @@ cgraph_add_new_function(fndecl, false); - current_function_decl = NULL_TREE; pop_cfun(); } @@ -864,17 +862,13 @@ // means that we need an fndecl. if (init_fndecl == NULL_TREE) init_fndecl = this-initialization_function_decl(); - current_function_decl = init_fndecl; if (DECL_STRUCT_FUNCTION(init_fndecl) == NULL) push_struct_function(init_fndecl); else push_cfun(DECL_STRUCT_FUNCTION(init_fndecl)); - tree var_decl = is_sink ? NULL_TREE : vec[i]; var_init_tree = no-var_value()-get_init_block(this, NULL, var_decl); - - current_function_decl = NULL_TREE; pop_cfun(); } @@ -1126,15 +1120,12 @@ cfun-function_end_locus = func-block()-end_location().gcc_location(); - current_function_decl = decl; - func-build_tree(gogo, this); gimplify_function_tree(decl); cgraph_finalize_function(decl, true); - current_function_decl = NULL_TREE; pop_cfun(); } }
Re: Scheduler: Allow breaking dependencies by modifying patterns
On Fri, Aug 3, 2012 at 5:05 AM, Bernd Schmidt ber...@codesourcery.com wrote: This patch allows us to change rn++ rm=[rn] into rm=[rn + 4] rn++ Opportunities to do this are discovered by a mini-pass over the instructions after generating dependencies and before scheduling a block. At that point we have all the information required to ensure that a candidate dep between two instructions is only used to show the register dependence, and to ensure that every insn with a memory reference is only subject to at most one dep causing a pattern change. The dep_t structure is extended to hold an optional pointer to a replacement description, which holds information about what to change when a dependency is broken. The time when this replacement is applied differs depending on whether the changed insn is the DEP_CON (in which case the pattern is changed whenever the broken dependency becomes the last one), or the DEP_PRO, in which case we make the change when the corresponding DEP_CON has been scheduled. This ensures that the ready list always contains insns with the correct pattern. A few additional bits are needed in the dep structure: one to hold information about whether a dependency occurs multiple times, and one to distinguish dependencies that are purely for register values from those with other meanings (e.g. memory references). Also, sched-rgn was changed to use a new bit, DEP_POSTPONED, rather than HARD_DEP to indicate that we don't want to schedule an insn in the current block. A possible future extension would be to also allow autoinc addressing modes as the increment insn. Bootstrapped and tested on x86_64-linux, and also tested on c6x-elf (quite a number of changes were necessary to make it work there). It was originally written for a mips target and tested there in the context of a 4.6 tree. I've also run spec2000 on x86_64, with no change that looked like anything other than noise. Ok? This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 -- H.J.
Re: [patch, mips] Fix for PR 54619, GCC aborting with -O -mips16
Steve Ellcey sell...@mips.com writes: On Wed, 2012-09-19 at 18:42 +0100, Richard Sandiford wrote: But the documentation says: This hook is never called with an invalid address. Since VOIDmode MEMs aren't valid, I think that should mean it's invalid to call this hook (and rtlanal.c:address_cost) with VOIDmode. I never got time to look at that though. (The culprit in the case I saw was tree-ssa-loop-ivopts.c. Sandra had some improvements in this area, so maybe they would fix this too.) Loading or storing BLKmode doesn't map to any instruction, so I don't think returning true for zero is any better than what we do now. Richard It looks like address_cost does get called with invalid addresses though Right, that's what I meant. The hook (and address_cost) are being passed VOIDmode, even though VOIDmode isn't a legitimate mode for a MEM. And that's a bug IMO. and I think that happens on other platforms then MIPS, it is just that MIPS is the only one where the invalid address causes a compile time failure. For example, if you compile my test program without -mips16 the compiler does not abort but address_cost is still called with a VOIDmode MEM. What do you think about my patch minus the initial check for offset == 0? That would avoid the compile time abort. If we didn't want to do that it seems like address_cost should include a check for valid addresses before it calls the hook. I am sure that would cause failures on many platforms and get some attention. address_cost already checks memory_address_addr_space_p, and returns a large value if it's false. We could avoid the assert by making memory_address_addr_space_p return false for VOIDmode, but an assert seems better (which I think is what you're suggesting). Returning 1000 for VOIDmode addresses -- as per the former option -- would certainly avoid the assert, but wouldn't be very helpful. I think tree-ssa-loop-ivopts is simply asking for the wrong thing, and needs to be changed. As I say, Sandra had some fixes in this area. Richard
Re: Top Level GCC change questions
On Sep 20, 2012, at 12:01 AM, Georg-Johann Lay g...@gcc.gnu.org wrote: Steve Ellcey schrieb: DJ Delorie wrote: Is there any automation for this or is it still up to each person checking in files to copy stuff over by hand? There is no automation, as neither project was willing to cede control to the other. In general, any patch applied to one repo should be (and may be) applied to the other, but at the moment it's up to each committer to actually do it. OK. I also noticed a change that is in the config directory in GCC but not in binutils: [...] There are also these two changes to configure[.ac] http://gcc.gnu.org/viewcvs?view=revisionrevision=190967 http://gcc.gnu.org/viewcvs?view=revisionrevision=190887 I filed a copyright assignment for the GCC project, so I don't know if it is appropriate to sync these changes with other FSF projects where I did not file a copyright assignment. If you have paper work for gcc, gcc can accept them. Once gcc accepts them, _anyone_ can move them from the gcc project to any other FSF project, provided the copyright is the same and the file is copyright FSF. If the copyright is different in owner or in license (exclusions, GPL 2/3 or anything else), the case is less trivial and ask about the more complex cases. You can double check, but I believe the files in question fit the trivial case. One reason why the FSF insists on paperwork is to give it the latitude to do operations like this.
Re: Use conditional casting with symtab_node
On 9/20/12, Michael Matz m...@suse.de wrote:
On Wed, 19 Sep 2012, Lawrence Crowl wrote:
On 9/19/12, Eric Botcazou ebotca...@adacore.com wrote:
The language syntax would bind the conditional into the
intializer, as in
if (varpool_node *vnode = (node-try_variable ()
vnode-finalized))
varpool_analyze_node (vnode);
which does not type-match.
So, if you want the type saftey and performance, the cascade
is really unavoidable.
Just write:
varpool_node *vnode;
if ((vnode = node-try_variable ()) vnode-finalized)
varpool_analyze_node (vnode);
This has been the standard style for the past 2 decades and
trading it for cascading if's is really a bad idea.
Assignments in if statements are known to cause confusion.
So? Make it:
varpool_node *vnode = node-try_variable ();
if (vnode vnode-finalized)
varpool_analyze_node (vnode);
The point of the change is to limit the scope of the variable
to the if statement, which prevents its unintended use later.
I'm not worried about this.
It is helpful to have the language and the usage in concurrence.
Okay, so unless someone objects, I'll move the variable out when
it introduces a cacade.
Why do you think cascading ifs is a bad idea?
Precedent. Confusion in case of dangling else (requiring more {},
and hence even more indentation). Ugly.
I generally take ugly as an indication that the function needs
refactoring.
--
Lawrence Crowl
Re: Top Level GCC change questions
Not in GCC: 2012-09-15 Jiong Wang jiw...@tilera.com * configure.ac (ENABLE_GOLD): support tilegx* * configure: rebuild I pulled this into gcc. Walter
Re: vector comparisons in C++
On Sat, 1 Sep 2012, Marc Glisse wrote:
I have some issues with the vector-compare-2.c torture test. It passes a
vector by value (argument and return type), which is likely to warn (although
for some reason it doesn't for me, with today's compiler). And it takes
-Wno-psabi through a .x file, but those are not read in c-c++-common, so I
put it in dg-options. I would have changed the function to use pointers, but
I don't know if it specifically wants to test passing by value...
Hello,
Pat Haugen just explained it to me: there was a default -w option in the
old location of the testcase. However, there isn't in the new one. I am
thus proposing the following, which restores the old behavior. Note that
-Wno-psabi is still needed as it is not implied by -w.
2012-09-20 Marc Glisse marc.gli...@inria.fr
PR c++/54427
* c-c++-common/torture/vector-compare-2.c: Add -w.
--
Marc GlisseIndex: c-c++-common/torture/vector-compare-2.c
===
--- c-c++-common/torture/vector-compare-2.c (revision 191585)
+++ c-c++-common/torture/vector-compare-2.c (working copy)
@@ -1,12 +1,12 @@
/* { dg-do run } */
-/* { dg-options -Wno-psabi } */
+/* { dg-options -Wno-psabi -w } */
#define vector(elcount, type) \
__attribute__((vector_size((elcount)*sizeof(type type
/* Check that constant folding in
these simple cases works. */
vector (4, int)
foo (vector (4, int) x)
{
return (x == x) + (x != x) + (x x)
+ (x x) + (x = x) + (x = x);
Re: RFA: Fix COND_EXEC handling of dead_or_set_regno_p
On 09/19/2012 09:25 PM, Joern Rennecke wrote: + /* If a COND_EXEC is not executed, the value survives. */ if (GET_CODE (pattern) == COND_EXEC) -pattern = COND_EXEC_CODE (pattern); +return 0; Ok. r~
[PATCH] Fix a bug that breaks go build
This patch fixes a bug is in tree-eh.c. IS_UNKNOWN_LOCATION is mistakenly used, thus the block info for a call stmt is cleared. Bootstrapped and gcc regression testing is on-going. Is it okay for trunk? Thanks, Dehao gcc/ChangeLog: tree-eh.c (lower_try_finally_dup_block): Use correct way to check unknown location. Index: tree-eh.c === --- tree-eh.c (revision 191494) +++ tree-eh.c (working copy) @@ -883,7 +883,7 @@ lower_try_finally_dup_block (gimple_seq seq, struc new_seq = copy_gimple_seq_and_replace_locals (seq); for (gsi = gsi_start (new_seq); !gsi_end_p (gsi); gsi_next (gsi)) -if (IS_UNKNOWN_LOCATION (gimple_location (gsi_stmt (gsi +if (gimple_location (gsi_stmt (gsi)) == UNKNOWN_LOCATION) gimple_set_location (gsi_stmt (gsi), loc); if (outer_state-tf)
[PATCH] PR c++/53551 - -Wunused-local-typedefs misses uses
Hello,
We don't record the use of a typedef when it's used through a
typename. So on the example of the patch, g++ complains that the 'type'
typedef is not used. Fixed thus.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* decl.c (make_typename_type): Record the use of typedefs.
gcc/testsuite/
* g++.dg/warn/Wunused-local-typedefs-2.C: New test.
---
gcc/cp/decl.c |4 +++-
.../g++.dg/warn/Wunused-local-typedefs-2.C | 20
2 files changed, 23 insertions(+), 1 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wunused-local-typedefs-2.C
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 6b5b986..09550be 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -3326,7 +3326,9 @@ make_typename_type (tree context, tree name, enum
tag_types tag_type,
if (DECL_ARTIFICIAL (t) || !(complain tf_keep_type_decl))
t = TREE_TYPE (t);
-
+
+ maybe_record_typedef_use (t);
+
return t;
}
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs-2.C
b/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs-2.C
new file mode 100644
index 000..073e253
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs-2.C
@@ -0,0 +1,20 @@
+// Origin PR c++/33255
+// { dg-options -Wunused } -- should trigger -Wunused-local-typedefs
+// { dg-do compile { target c++11 } }
+
+template typename C
+struct structure
+{
+typename C::type val;
+};
+
+int
+main()
+{
+ struct context
+ {
+ using type = int;
+ };
+
+ return structurecontext{42}.val;
+}
--
Dodji
Re: [PATCH] Combine location with block using block_locations
Sorry for breaking these tests. This problem is very hard to reproduce. However, I had a patch to fix another compile-time problem which may be related to this one. http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html After applying the patch, the PCH related bugs are not showing any more on my machines. Dehao On Thu, Sep 20, 2012 at 10:59 PM, Dehao Chen de...@google.com wrote: Hi, Paolo, I'll look into the ICE problems now. Thanks, Dehao On Thu, Sep 20, 2012 at 9:04 PM, Paolo Carlini paolo.carl...@oracle.com wrote: Hi, On 09/19/2012 09:59 PM, Dehao Chen wrote: This patch was commited as r191494. I'm afraid I can't help *much* with the debugging, but on my x86_64-linux machine and a very straightforward configuration (--enable-languages=c++ --disable-multilib) after r191494 I'm seeing the following libstdc++ regressions. FAIL: 17_intro/headers/c++1998/all.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_c++200x_compatibility.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/all_pedantic_errors.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++1998/stdc++_multiple_inclusion.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors) FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess errors) are all ICEs like the below. Apparently PCHs are required, I can't reproduce outside the testsuite, without the library PCHs. Does it make any sense to you? Please let me know if I can somehow help. Thanks, Paolo. /// In file included from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_ios.h:39:0, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/ios:45, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/istream:40, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/sstream:39, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/complex:47, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdc++.h:67, from /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/stdtr1c++.h:29, from /scratch/Gcc/svn-dirs/trunk/libstdc++-v3/include/precompiled/extc++.h:30: /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h: In member function 'virtual std::ctypechar::char_type std::ctypechar::do_widen(char) const': /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:1077:7: internal compiler error: Segmentation fault do_widen(char __c) const ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Patch, Fortran, committed] Fix issue in cpp.c's print_line
gfortran was using
loc = expand_location (src_loc);
and then looked at loc.sysp value to decide whether it was a system
header with extern C or a normal system header.
However, loc.sysp is a bool! There is another sysp which is an
integer. As in gcc/c-family/c-ppoutput.c, one has to use
in_system_header_at to access it.
Successfully build on x86-64-linux and committed as Rev. 191590.
Tobias
PS: The issue was found by Coverity's static scanner :-)
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 191588)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2012-09-20 Tobias Burnus bur...@net-b.de
+
+ PR fortran/54599
+ * cpp.c (print_line): Properly handle extern C.
+
2012-09-20 Martin Jambor mjam...@suse.cz
* trans-decl.c (gfc_get_extern_function_decl): Push NULL cfun. Do not
Index: gcc/fortran/cpp.c
===
--- gcc/fortran/cpp.c (Revision 191588)
+++ gcc/fortran/cpp.c (Arbeitskopie)
@@ -822,6 +822,7 @@ print_line (source_location src_loc, const char *s
size_t to_file_len;
unsigned char *to_file_quoted;
unsigned char *p;
+ int sysp;
loc = expand_location (src_loc);
to_file_len = strlen (loc.file);
@@ -838,9 +839,10 @@ print_line (source_location src_loc, const char *s
print.src_line == 0 ? 1 : print.src_line,
to_file_quoted, special_flags);
- if (loc.sysp == 2)
+ sysp = in_system_header_at (src_loc);
+ if (sysp == 2)
fputs ( 3 4, print.outf);
- else if (loc.sysp == 1)
+ else if (sysp == 1)
fputs ( 3, print.outf);
putc ('\n', print.outf);
Re: Use conditional casting with symtab_node
On Thu, Sep 20, 2012 at 1:53 PM, Lawrence Crowl cr...@googlers.com wrote:
Why do you think cascading ifs is a bad idea?
Precedent. Confusion in case of dangling else (requiring more {},
and hence even more indentation). Ugly.
I generally take ugly as an indication that the function needs
refactoring.
Hear! Hear! Hear!
Sadly, many functions in GCC (at least in cp/) are in that category :-(
-- Gaby
Re: Use conditional casting with symtab_node
On 9/20/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sep 20, 2012 Lawrence Crowl cr...@googlers.com wrote:
Why do you think cascading ifs is a bad idea?
Precedent. Confusion in case of dangling else (requiring
more {}, and hence even more indentation). Ugly.
I generally take ugly as an indication that the function needs
refactoring.
Hear! Hear! Hear!
Sadly, many functions in GCC (at least in cp/) are in that
category :-(
It is not just GCC. Most large codebases I've seen have had lots of
large functions. It takes persistent effort to beat back entropy.
I once chatted with a guy who worked on a project with a strict
requirement that every function fit on one screen, and that was
when screens were 24 lines. He said their bug rate was really low.
And the one function they made an exception for turned out the have
the worst bug in it.
--
Lawrence Crowl
Fix oversights in the gnat.dg testsuite
The dg directives need to be put in the .adb files, otherwise they are ignored
in the gnat.dg directory.
Tested on x86-64/Linux, applied on all active branches.
2012-09-20 Eric Botcazou ebotca...@adacore.com
* gnat.dg/opt20.ads: Move dg directive to...
* gnat.dg/opt20.adb: ...here.
* gnat.dg/addr1.ad[sb]: Likewise.
* gnat.dg/concat2.ad[sb]: Likewise.
* gnat.dg/array16.ad[sb]: Likewise.
* gnat.dg/atomic5.ad[sb]: Likewise.
* gnat.dg/discr29.ad[sb]: Likewise.
* gnat.dg/noreturn5.ad[sb]: Likewise.
* gnat.dg/vect8.ad[sb]: Likewise. Add dg-options.
* gnat.dg/discr23.ads: Remove dg directive.
* gnat.dg/nested_float_packed.ads: Likewise.
* gnat.dg/oconst6.ads: Move to...
* gnat.dg/specs/oconst6.ads: ...here.
--
Eric BotcazouIndex: gnat.dg/opt20.adb
===
--- gnat.dg/opt20.adb (revision 191365)
+++ gnat.dg/opt20.adb (working copy)
@@ -1,3 +1,6 @@
+-- { dg-do compile }
+-- { dg-options -O2 -gnatpn }
+
with Ada.Characters.Handling; use Ada.Characters.Handling;
package body Opt20 is
Index: gnat.dg/opt20.ads
===
--- gnat.dg/opt20.ads (revision 191365)
+++ gnat.dg/opt20.ads (working copy)
@@ -1,6 +1,3 @@
--- { dg-do compile }
--- { dg-options -O2 -gnatpn }
-
with Opt20_Pkg; use Opt20_Pkg;
package Opt20 is
Index: gnat.dg/addr1.adb
===
--- gnat.dg/addr1.adb (revision 191365)
+++ gnat.dg/addr1.adb (working copy)
@@ -1,3 +1,5 @@
+-- { dg-do compile }
+
with System;
package body addr1 is
task type T is
Index: gnat.dg/addr1.ads
===
--- gnat.dg/addr1.ads (revision 191365)
+++ gnat.dg/addr1.ads (working copy)
@@ -1,5 +1,3 @@
--- { dg-do compile }
-
package addr1 is
pragma Elaborate_Body;
end;
Index: gnat.dg/discr23.ads
===
--- gnat.dg/discr23.ads (revision 191365)
+++ gnat.dg/discr23.ads (working copy)
@@ -1,5 +1,3 @@
--- { dg-do compile }
-
package Discr23 is
procedure Dummy;
Index: gnat.dg/oconst6.ads
===
--- gnat.dg/oconst6.ads (revision 191365)
+++ gnat.dg/oconst6.ads (working copy)
@@ -1,18 +0,0 @@
--- { dg-do compile }
--- { dg-final { scan-assembler-not elabs } }
-
-package OCONST6 is
-
- type Sequence is array (1 .. 1) of Natural;
-
- type Message is record
- Data : Sequence;
- end record;
-
- for Message'Alignment use 1;
- pragma PACK (Message);
-
- ACK : Message := (Data = (others = 1));
-
-end;
-
Index: gnat.dg/concat2.adb
===
--- gnat.dg/concat2.adb (revision 191365)
+++ gnat.dg/concat2.adb (working copy)
@@ -1,3 +1,6 @@
+-- { dg-do compile }
+-- { dg-options -O }
+
with Text_IO; use Text_IO;
package body Concat2 is
@@ -15,4 +18,3 @@ package body Concat2 is
end;
end Concat2;
-
Index: gnat.dg/concat2.ads
===
--- gnat.dg/concat2.ads (revision 191365)
+++ gnat.dg/concat2.ads (working copy)
@@ -1,6 +1,3 @@
--- { dg-do compile }
--- { dg-options -O }
-
package Concat2 is
procedure Browse;
Index: gnat.dg/vect8.adb
===
--- gnat.dg/vect8.adb (revision 191365)
+++ gnat.dg/vect8.adb (working copy)
@@ -1,3 +1,6 @@
+-- { dg-do compile }
+-- { dg-options -w }
+
package body Vect8 is
function Foo (V : Vec) return Vec is
Index: gnat.dg/vect8.ads
===
--- gnat.dg/vect8.ads (revision 191365)
+++ gnat.dg/vect8.ads (working copy)
@@ -1,5 +1,3 @@
--- { dg-do compile }
-
package Vect8 is
type Vec is array (1 .. 2) of Long_Float;
Index: gnat.dg/array16.adb
===
--- gnat.dg/array16.adb (revision 191365)
+++ gnat.dg/array16.adb (working copy)
@@ -1,3 +1,6 @@
+-- { dg-do compile }
+-- { dg-options -O -gnatn -fdump-tree-optimized }
+
package body Array16 is
function F1 (A : access My_T1) return My_T1 is
@@ -20,3 +23,6 @@ package body Array16 is
end;
end Array16;
+
+-- { dg-final { scan-tree-dump-not secondary_stack optimized } }
+-- { dg-final { cleanup-tree-dump optimized } }
Index: gnat.dg/array16.ads
===
--- gnat.dg/array16.ads (revision 191365)
+++ gnat.dg/array16.ads (working copy)
@@ -1,6 +1,3 @@
--- { dg-do compile }
--- { dg-options -O -gnatn -fdump-tree-optimized }
-
with Array16_Pkg;
package Array16 is
@@ -26,6 +23,3 @@ package Array16 is
procedure Proc (A : access My_T1; B : access My_T2);
end Array16;
-
--- { dg-final { scan-tree-dump-not secondary_stack optimized } }
Re: [PATCH] Combine location with block using block_locations
On Thu, Sep 20, 2012 at 6:04 PM, Dominique Dhumieres domi...@lps.ens.fr wrote: A lot of failures in the test suite have appeared between revisions 191485 and 191494 see http://gcc.gnu.org/ml/gcc-regression/2012-09/msg00327.html ). I have looked at the failure of libgomp.fortran/reduction1.f90: [macbook] f90/bug% gfc -O3 -g -fopenmp /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90 /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90: In function 'MAIN__._omp_fn.0': /opt/gcc/work/libgomp/testsuite/libgomp.fortran/reduction1.f90:22:0: internal compiler error: in change_scope, at final.c:1543 !$omp reduction (+:i, ia, r, ra, d, da, c, ca) The backtrace is #0 fancy_abort (file=0x100a7b376 ../../work/gcc/final.c, line=1543, function=0x100b418b3 change_scope) at ../../work/gcc/diagnostic.c:1010 #1 0x00010045f9f9 in change_scope (orig_insn=value optimized out, s1=value optimized out, s2=value optimized out) at ../../work/gcc/final.c:1543 #2 0x000100463c40 in final_start_function (first=value optimized out, file=value optimized out, optimize_p=value optimized out) at ../../work/gcc/final.c:1613 #3 0x000100465761 in rest_of_handle_final () at ../../work/gcc/final.c:4291 #4 0x0001006486ea in execute_one_pass (pass=value optimized out) at ../../work/gcc/passes.c:2206 #5 0x000100648afd in execute_pass_list (pass=value optimized out) at ../../work/gcc/passes.c:2261 #6 0x000100648b0f in execute_pass_list (pass=value optimized out) at ../../work/gcc/passes.c:2262 #7 0x000100648b0f in execute_pass_list (pass=value optimized out) at ../../work/gcc/passes.c:2262 #8 0x000100365f4b in expand_function (node=value optimized out) at ../../work/gcc/cgraphunit.c:1609 #9 0x0001003680ba in compile () at ../../work/gcc/cgraphunit.c:1714 #10 0x00010036870f in finalize_compilation_unit () at ../../work/gcc/cgraphunit.c:2089 #11 0x0001005e0f27 in write_global_declarations () at ../../work/gcc/langhooks.c:323 #12 0x0001007047f1 in compile_file () at ../../work/gcc/toplev.c:560 #13 0x00010070663c in toplev_main (argc=value optimized out, argv=value optimized out) at ../../work/gcc/toplev.c:1863 #14 0x00010e14 in start () Could you have a look to this problem? This problem will be fixed by http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html Sorry for the inconvenience. Dehao TIA Dominique
[Patch, ARM, testsuite]
Hi,
GCC for ARM does not support compiling in Thumb1 mode and
float-abi=hard. But it does not fail unless the program being
compiled actually contains a function with parameters and/or a return
value.
This is a (minor) problem in the testsuite in some configurations.
For instance, if I run the testsuite forcing -mthumb (via site.exp)
for a GCC configured for float-abi=hard, and a test uses
/* { dg-require-effective-target arm_arch_v6_ok } */
/* { dg-add-options arm_arch_v6 } */
it won't be unresolved since effective-target arm_arch_v6_ok is successful.
The attached patch adds a dummy function body in the test such that it fails.
Another way of achieving the same result is by making sure that the
relevant tests use
arm_arch_v6_multilib
instead of
arm_arch_v6_ok
even if the test is not intended to be executed.
OK?
Christophe.
2012-09-21 Christophe Lyon christophe.l...@linaro.org
gcc/testsuite:
* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
Add function body to force error messages in some configurations.
* gcc.target/arm/v6-ok.c: New test.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index f597316..bc7d451 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2211,6 +2211,11 @@ foreach { armfunc armflag armdef } { v4 -march=armv4
-marm __ARM_ARCH_4__
#if !defined (DEF)
#error FOO
#endif
+ int
+ main (void)
+ {
+ return 0;
+ }
} FLAG ]
}
diff --git a/gcc/testsuite/gcc.target/arm/v6-ok.c
b/gcc/testsuite/gcc.target/arm/v6-ok.c
new file mode 100644
index 000..4eb1aed
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/v6-ok.c
@@ -0,0 +1,8 @@
+/* Check that compiling for armv6 is OK. This is useful to detect
+ configurations leading to thumb1 and float-abi=hard, which are not
+ supported currently. */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v6_ok } */
+/* { dg-add-options arm_arch_v6 } */
+
+int func(void) { return 0; }
Re: Scheduler: Allow breaking dependencies by modifying patterns
On 09/20/2012 07:42 PM, H.J. Lu wrote: On Fri, Aug 3, 2012 at 5:05 AM, Bernd Schmidt ber...@codesourcery.com wrote: This patch allows us to change rn++ rm=[rn] into rm=[rn + 4] rn++ This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 The jury is still out on that, but it did cause PR54643. This seems to be some kind of interaction with the new SCHED_PRESSURE_MODEL code. For now it seems best to just disable the new optimization if scheduling for pressure. It will still trigger during sched2. I've bootstrapped the following on x86_64-linux and verified that the arm build gets further (it now fails in libbacktrace). Committed. Bernd Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 191592) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2012-09-20 Bernd Schmidt ber...@codesourcery.com + + PR bootstrap/54643 + * haifa-sched.c (schedule_block): Skip find_modifiable_mems if using + SCHED_PRESSURE_MODEL. + 2012-09-20 Joern Rennecke joern.renne...@embecosm.com * rtlanal.c (dead_or_set_regno_p): Fix COND_EXEC handling. Index: gcc/haifa-sched.c === --- gcc/haifa-sched.c (revision 191582) +++ gcc/haifa-sched.c (working copy) @@ -5854,7 +5854,8 @@ schedule_block (basic_block *target_bb) rtx head = NEXT_INSN (prev_head); rtx tail = PREV_INSN (next_tail); - if ((current_sched_info-flags DONT_BREAK_DEPENDENCIES) == 0) + if ((current_sched_info-flags DONT_BREAK_DEPENDENCIES) == 0 + sched_pressure != SCHED_PRESSURE_MODEL) find_modifiable_mems (head, tail); /* We used to have code to avoid getting parameters moved from hard
Re: [PATCH] Combine location with block using block_locations
This problem will be fixed by http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html Sorry, but its not (see pr54645 c#3). Dominique
[Patch, ARM, testsuite] improve test for builtin_bswap16 for Thumb2
Hi,
The attached patch make sure we test builtin_bswap16 expansion in
Thumb2 mode in addition to the existing Thumb1 test (which may fail as
unsupported if the compiler is also using float-abi=hard).
The newly created test is the same as the existing one, except for the
forced architecture version.
Christophe.
2012-09-21 Christophe Lyon christophe.l...@linaro.org
gcc/testsuite:
* gcc.target/arm/builtin-bswap-1.c: Add comment.
* gcc.target/arm/builtin-bswap-v6t2.c: New test.
diff --git a/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
b/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
index 43195bd..fe95fb1 100644
--- a/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
+++ b/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
@@ -1,3 +1,4 @@
+/* Force testing on armv6 to check thumb1 mode. */
/* { dg-do compile } */
/* { dg-options -O2 } */
/* { dg-require-effective-target arm_arch_v6_ok } */
diff --git a/gcc/testsuite/gcc.target/arm/builtin-bswap-v6t2.c
b/gcc/testsuite/gcc.target/arm/builtin-bswap-v6t2.c
new file mode 100644
index 000..4ab3f85
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/builtin-bswap-v6t2.c
@@ -0,0 +1,82 @@
+/* Force testing on armv6t2 to check thumb2 mode. */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+/* { dg-require-effective-target arm_arch_v6t2_ok } */
+/* { dg-add-options arm_arch_v6t2 } */
+/* { dg-final { scan-assembler-not orr\[ \t\] } } */
+/* { dg-final { scan-assembler-times revsh\\t 1 { target { arm_nothumb } } }
} */
+/* { dg-final { scan-assembler-times revshne\\t 1 { target { arm_nothumb } }
} } */
+/* { dg-final { scan-assembler-times revsh\\t 2 { target { ! arm_nothumb } }
} } */
+/* { dg-final { scan-assembler-times rev16\\t 1 { target { arm_nothumb } } }
} */
+/* { dg-final { scan-assembler-times rev16ne\\t 1 { target { arm_nothumb } }
} } */
+/* { dg-final { scan-assembler-times rev16\\t 2 { target { ! arm_nothumb } }
} } */
+/* { dg-final { scan-assembler-times rev\\t 2 { target { arm_nothumb } } } }
*/
+/* { dg-final { scan-assembler-times revne\\t 2 { target { arm_nothumb } } }
} */
+/* { dg-final { scan-assembler-times rev\\t 4 { target { ! arm_nothumb } } }
} */
+
+/* revsh */
+short swaps16 (short x)
+{
+ return __builtin_bswap16 (x);
+}
+
+extern short foos16 (short);
+
+/* revshne */
+short swaps16_cond (short x, int y)
+{
+ short z = x;
+ if (y)
+z = __builtin_bswap16 (x);
+ return foos16 (z);
+}
+
+/* rev16 */
+unsigned short swapu16 (unsigned short x)
+{
+ return __builtin_bswap16 (x);
+}
+
+extern unsigned short foou16 (unsigned short);
+
+/* rev16ne */
+unsigned short swapu16_cond (unsigned short x, int y)
+{
+ unsigned short z = x;
+ if (y)
+z = __builtin_bswap16 (x);
+ return foou16 (z);
+}
+
+/* rev */
+int swaps32 (int x) {
+ return __builtin_bswap32 (x);
+}
+
+extern int foos32 (int);
+
+/* revne */
+int swaps32_cond (int x, int y)
+{
+ int z = x;
+ if (y)
+z = __builtin_bswap32 (x);
+ return foos32 (z);
+}
+
+/* rev */
+unsigned int swapu32 (unsigned int x)
+{
+ return __builtin_bswap32 (x);
+}
+
+extern unsigned int foou32 (unsigned int);
+
+/* revne */
+unsigned int swapsu2 (unsigned int x, int y)
+{
+ int z = x;
+ if (y)
+z = __builtin_bswap32 (x);
+ return foou32 (z);
+}
Re: [patch] Fix PR rtl-optimization/54290
This breaks bootstrap on ARM:
/home/rearnsha/gnusrc/gcc/gcc-fsf/gcc/reload1.c: In function `void
choose_reload_regs(insn_chain*)':
/home/rearnsha/gnusrc/gcc/gcc-fsf/gcc/reload1.c:6959:19: error: unused
variable `tem' [-Werror=unused-variable]
rtx check_reg, tem;
My bad... fixed thusly.
2012-09-20 Eric Botcazou ebotca...@adacore.com
* reload1.c (choose_reload_regs): Add missing #ifdef/#endif pair.
--
Eric BotcazouIndex: reload1.c
===
--- reload1.c (revision 191591)
+++ reload1.c (working copy)
@@ -6956,7 +6956,10 @@ choose_reload_regs (struct insn_chain *c
for (j = 0; j n_reloads; j++)
{
int r = reload_order[j];
- rtx check_reg, tem;
+ rtx check_reg;
+#ifdef SECONDARY_MEMORY_NEEDED
+ rtx tem;
+#endif
if (reload_inherited[r] rld[r].reg_rtx)
check_reg = rld[r].reg_rtx;
else if (reload_override_in[r]
Re: [Patch] PR54635: Add addr_space_t argument to mode_dependent_address_p
On Thu, 20 Sep 2012, Georg-Johann Lay wrote: Hans-Peter Nilsson wrote: Georg-Johann Lay wrote: mode_dependent_address_p is not sensitive to the address space of the passed address. Thus, add an addr_space_t parameter to the hook. Borderline obvious. :) (J/k; the added functionality seems obvious but the implementation may have non-obvious issues, though I saw none.) What specifically? Specifically none; nothing. (Not a typo for one. :) Being unsure about the component, I chose other. Is middle-end better? Since this is the back-end API, i think your other fits just as good or better. Just IMHO. AFAIK PR12345, PR 12345 and PR component/12345 entries are recognized and connected to bugzilla PRs? If you're sure it gets through to bugzilla, then I certainly don't care. brgds, H-P
Re: [PATCH] Combine location with block using block_locations
I can reproduce the problem now. After some investigation, this error should be a bug exposed by this patch. The root cause is, in expand_omp_taskreg, it calls move_sese_region_to_fn with gimple_block(entry_stmt) as the root of the block tree. However, there is an edge inside the region that has the root's sibling as its goto_block. As a result, the block get escaped when numbering the blocks. This bug does not expose before because he goto_block was set NULL. The block_location patch reserved the value for the goto_block, thus exposed he problem. I'll try to fix it in the next couple of days. Thanks, Dehao On Fri, Sep 21, 2012 at 6:07 AM, Dominique Dhumieres domi...@lps.ens.fr wrote: This problem will be fixed by http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01491.html Sorry, but its not (see pr54645 c#3). Dominique
[PATCH] rs6000: Fix nonsensical scc splitter pattern
This splitter is, erm, interesting. This patch fixes it. Bootstrapped and regression checked on powerpc64-linux. Okay to apply? Segher 2012-09-20 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.md (define_split for plus_eqsi): Fix output pattern. --- gcc/config/rs6000/rs6000.md |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index 9eb0a37..9f96270 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -11829,7 +11829,7 @@ (define_split (clobber (match_operand:SI 5 register_operand ))] ! gpc_reg_operand (operands[2], SImode) [(set (match_dup 5) (match_dup 2)) - (set (match_dup 2) (plus:SI (match_op_dup 1 [(match_dup 2) (match_dup 3)]) + (set (match_dup 0) (plus:SI (match_op_dup 1 [(match_dup 5) (match_dup 3)]) (match_dup 4)))]) (define_insn *plus_eqsi -- 1.7.7.6
[PATCH, doc] Separate sections in Chapter Plugins and LTO
Hi all, Currently the Chapter Plugins and LTO is all in one html page, the other chapters are separated into sections. So I separated them to make them easier reading. Is this patch OK? Regards, Jia 2012-09-21 Jia Liu pro...@gmail.com * gcc/doc/lto.texi: Separate sections. * gcc/doc/plugins.texi: Separate sections. 0001-doc-Separate-sections-in-plugins-and-lto.patch Description: Binary data
Re: [PATCH] rs6000: Fix nonsensical scc splitter pattern
On Thu, Sep 20, 2012 at 7:47 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: This splitter is, erm, interesting. This patch fixes it. Bootstrapped and regression checked on powerpc64-linux. Okay to apply? Segher 2012-09-20 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.md (define_split for plus_eqsi): Fix output pattern. Okay. Thanks, David
Re: [patch, mips] Fix for PR 54619, GCC aborting with -O -mips16
Re: I think tree-ssa-loop-ivopts is simply asking for the wrong thing, and needs to be changed. As I say, Sandra had some fixes in this area. This patch: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html Sadly, that patch has fallen off the bottom of my priority list (some legal wrangling halted all work on the Hexagon port that was the motivating example for it), and meanwhile it's become bit-rotten due to Bill Schmidt's work that touched on the ivopts code as well. If someone else would like to adopt this patch, please do! I agree that it is just plain dumb for ivopts to be trying to precompute address costs for modes that are not even valid. -Sandra
[PING] Re: VxWorks Patches Back from the Dead!
Ping? Just did a full pull and rebuild today and everything still works :) Robert Mason On 9/10/2012 3:46 PM, Bruce Korb wrote: Hi, On Mon, Sep 10, 2012 at 10:48 AM, rbmj r...@verizon.net wrote: On the other hand, I've read this on the website: Don't mix together changes made for different reasons. Send them individually. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts OTOH, this is a fairly cohesive set of patches. A single project. Even if, strictly speaking, each include fix is entirely separate from the others (by the design of fixincludes), I see them as a cohesive set that ought to be in a single commit. Fixes to fixes for fixincludes have been very infrequent. ... At the same time, it's a pain in the rear to worry about 12 different commits I'm into comforting one's derriere. Unless cosmic rays break everything again, that should be all. :) OK. I'll push it on your behalf once the other bits have been approved by their approvers. Cheers - Bruce
Re: [PATCH] Fix a bug that breaks go build
This patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649
The previous patch is incorrect and will cause regression to
g++.dg/debug/dwarf2/deallocator.C
A new patch is attached. It solved the bootstrap problem for go.
Basically, when we set the line number for stmts in the finally block,
we don't want to change its block info.
The new patch can bootstrap, and passed gcc regression tests.
Is it okay for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-09-20 Dehao Chen de...@google.com
PR go/54649
* tree-eh.c (lower_try_finally_dup_block): Set the correct block for
stmts in the duplicated EH block.
Index: gcc/tree-eh.c
===
--- gcc/tree-eh.c (revision 191586)
+++ gcc/tree-eh.c (working copy)
@@ -883,8 +883,15 @@ lower_try_finally_dup_block (gimple_seq seq, struc
new_seq = copy_gimple_seq_and_replace_locals (seq);
for (gsi = gsi_start (new_seq); !gsi_end_p (gsi); gsi_next (gsi))
-if (IS_UNKNOWN_LOCATION (gimple_location (gsi_stmt (gsi
- gimple_set_location (gsi_stmt (gsi), loc);
+{
+ gimple stmt = gsi_stmt (gsi);
+ if (IS_UNKNOWN_LOCATION (gimple_location (stmt)))
+ {
+ tree block = gimple_block (stmt);
+ gimple_set_location (stmt, loc);
+ gimple_set_block (stmt, block);
+ }
+}
if (outer_state-tf)
region = outer_state-tf-try_finally_expr;
[testsuite] gcc.target/arm: skip 5 tests for flag conflicts
This patch adds test directives to skip 5 tests in gcc.target/arm if the
flags specified for the test would be overridden by or conflict with
flags used for all tests, such as multilib flags.
Tested on arm-none-eabi with a variety of test flags. I'll wait a day
or two before checking it in to give ARM experts a chance to comment.
I plan to backport to the 4.7 branch soon after it's in trunk.
Janis
2012-09-20 Janis Johnson jani...@codesourcery.com
* gcc.target/arm/pr40887.c: Avoid conflicting flags.
* gcc.target/arm/pr51835.c: Likewise.
* gcc.target/arm/pr51915.c: Likewise.
* gcc.target/arm/pr52006.c: Likewise.
* gcc.target/arm/pr53187.c: Likewise.
Index: gcc.target/arm/pr40887.c
===
--- gcc.target/arm/pr40887.c(revision 191502)
+++ gcc.target/arm/pr40887.c(working copy)
@@ -1,3 +1,4 @@
+/* { dg-skip-if do not override -march { *-*-* } { -march=* } {
-march=armv5te } } */
/* { dg-options -O2 -march=armv5te } */
/* { dg-final { scan-assembler blx } } */
Index: gcc.target/arm/pr51835.c
===
--- gcc.target/arm/pr51835.c(revision 191502)
+++ gcc.target/arm/pr51835.c(working copy)
@@ -1,6 +1,8 @@
/* { dg-do compile } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-skip-if do not override -mfloat-abi { *-*-* } { -mfloat-abi=* } {
-mfloat-abi=hard } } */
+/* { dg-skip-if do not override -mfpu { *-*-* } { -mfpu=* } {
-mfpu=fpv4-sp-d16 } } */
/* { dg-options -O2 -mfloat-abi=hard -mfpu=fpv4-sp-d16 } */
-/* { dg-require-effective-target arm_thumb2_ok } */
int func1 (double d)
{
Index: gcc.target/arm/pr51915.c
===
--- gcc.target/arm/pr51915.c(revision 191502)
+++ gcc.target/arm/pr51915.c(working copy)
@@ -1,5 +1,7 @@
/* PR target/51915 */
/* { dg-do compile } */
+/* { dg-skip-if do not override -march { *-*-* } { -march=* } {
-march=armv7-a } } */
+/* { dg-skip-if do not override -mfloat-abi { *-*-* } { -mfloat-abi=* } {
-mfloat-abi=hard } } */
/* { dg-options -march=armv7-a -mfloat-abi=hard -O2 } */
struct S { int s1; void *s2; };
Index: gcc.target/arm/pr52006.c
===
--- gcc.target/arm/pr52006.c(revision 191502)
+++ gcc.target/arm/pr52006.c(working copy)
@@ -1,5 +1,7 @@
/* PR target/52006 */
/* { dg-do compile } */
+/* { dg-skip-if do not override -march= { *-*-* } { -march=* } {
-march=armv7-a } } */
+/* { dg-skip-if do not override -mfloat-abi { *-*-* } { -mfloat-abi=* } {
-mfloat-abi=hard } } */
/* { dg-options -march=armv7-a -mfloat-abi=hard -O2 -fPIC } */
unsigned long a;
Index: gcc.target/arm/pr53187.c
===
--- gcc.target/arm/pr53187.c(revision 191502)
+++ gcc.target/arm/pr53187.c(working copy)
@@ -1,5 +1,6 @@
/* PR target/53187 */
/* { dg-do compile } */
+/* { dg-skip-if do not override -march { *-*-* } { -march=* } {
-march=armv7-a } } */
/* { dg-options -march=armv7-a -mfloat-abi=hard -O2 } */
void bar (int);
Re: [PATCH] Combine location with block using block_locations
Hi, As expected, since this patch was checked in yesterday, there are 4 bugs exposed (1 fixed, 1 patch ready, 2 TBD): 1. http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01413.html Failed targets such as arm and mips. Fixed by r191510 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649 Failed Go bootstrap (I didn't test --enable-language=go). The problem is when we set the line number for stmts in the finally block (tree-eh.c), we don't want to change its block info. A fix was proposed: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01513.html 3. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645 All PCH related tests fail intermittently. (They didn't manifest when I was doing the test...) The cause of the problem is: when reading PCH data, the line_table is also read from PCH files. But the location_adhoc_data_map is not managed by GC, thus is not read in from PCH file (only a pointer is read in). I'll try to provide a patch to resolve the problem by the end of Friday. 4. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54650 Failed one regression test in libgomp (I didn't know that there are regression tests for libraries before...) This error should be a bug exposed by this patch. I'll try to provide a patch as soon as possible. Thanks, Dehao
[testsuite] fix to check_effective_target_arm_hard_vfp_ok
Tests in gcc.target/arm/aapcs check for floating-point arguments being
passed correctly, but the added flag -mfloat-abi=hard can be
overridden by another value in flags used for all tests (like multilib
flags), causing the tests to fail. The tests in that directory are all
gated on effective-target arm_hard_vfp_ok; this patch changes its code
to return 0 if the test will use a different value of -mfloat-abi.
Tested on arm-none-eabi with a variety of test flags. I'm hoping to
hear from ARM experts that this is OK; there are a handful of tests in
arm/aapcs that pass even with -mfloat-abi=softfp, so a better solution
might be to skip individual tests for that option.
Janis
2012-09-20 Janis Johnson jani...@codesourcery.com
* lib/target-supports.exp (check_effective_target_arm_hard_vfp_ok):
Return 0 if already specifying -mfloat-abi other than hard.
Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 191501)
+++ lib/target-supports.exp (working copy)
@@ -2053,7 +2053,8 @@
# options.
proc check_effective_target_arm_hard_vfp_ok { } {
-if { [check_effective_target_arm32] } {
+if { [check_effective_target_arm32]
+ ! [check-flags [list { *-*-* } { -mfloat-abi=* } {
-mfloat-abi=hard }]] } {
return [check_no_compiler_messages arm_hard_vfp_ok executable {
int main() { return 0;}
} -mfpu=vfp -mfloat-abi=hard]
Re: [PATCH] Fix a bug that breaks go build
On Thu, Sep 20, 2012 at 7:31 PM, Dehao Chen de...@google.com wrote: This patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54649 The previous patch is incorrect and will cause regression to g++.dg/debug/dwarf2/deallocator.C A new patch is attached. It solved the bootstrap problem for go. Basically, when we set the line number for stmts in the finally block, we don't want to change its block info. The new patch can bootstrap, and passed gcc regression tests. Is it okay for trunk? Thanks, Dehao gcc/ChangeLog: 2012-09-20 Dehao Chen de...@google.com PR go/54649 * tree-eh.c (lower_try_finally_dup_block): Set the correct block for stmts in the duplicated EH block. This is OK. Please also add the test case from http://gcc.gnu.org/ml/gcc/2012-09/msg00183.html to the compiler testsuite. Best would be to add a simplified version that does not #include string. But I see that there are test cases under testsuite/g++.dg that #include string, so I guess it is OK to do that in a g++ test. You can add the test case, however you decided to do, in a separate, later patch. Thanks. Ian
Ping: PATCH RFA: Print backtrace on ICE
Ping. The patch is the same, so I didn't attach it again. It may be found at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01174.html . I think I've replied to all comments. Ian -- Forwarded message -- From: Ian Lance Taylor i...@google.com Date: Mon, Sep 17, 2012 at 10:17 AM Subject: PATCH RFA: Print backtrace on ICE To: gcc-patches@gcc.gnu.org This patch to the diagnostic code uses the new backtrace library to print a backtrace on an ICE. For example, here is the output of a test case I took from a C++ PR: /home/iant/foo2.cc:6:6: internal compiler error: in cp_lexer_new_from_tokens, at cp/parser.c:638 0xec549f internal_error(char const*, ...) ../../trunk/gcc/diagnostic.c:1057 0xec3f53 fancy_abort(char const*, int, char const*) ../../trunk/gcc/diagnostic.c: 0x5ff78e cp_lexer_new_from_tokens ../../trunk/gcc/cp/parser.c:638 0x5ff78e cp_parser_push_lexer_for_tokens ../../trunk/gcc/cp/parser.c:3290 0x60ff40 cp_parser_late_parsing_for_member ../../trunk/gcc/cp/parser.c:21713 0x60ff40 cp_parser_class_specifier_1 ../../trunk/gcc/cp/parser.c:18207 0x60ff40 cp_parser_class_specifier ../../trunk/gcc/cp/parser.c:18231 0x60ff40 cp_parser_type_specifier ../../trunk/gcc/cp/parser.c:13390 0x61c83d cp_parser_decl_specifier_seq ../../trunk/gcc/cp/parser.c:10731 0x628317 cp_parser_single_declaration ../../trunk/gcc/cp/parser.c:21313 0x6289c0 cp_parser_template_declaration_after_export ../../trunk/gcc/cp/parser.c:21198 0x62de39 cp_parser_declaration ../../trunk/gcc/cp/parser.c:10183 0x62c487 cp_parser_declaration_seq_opt ../../trunk/gcc/cp/parser.c:10105 0x62c762 cp_parser_translation_unit ../../trunk/gcc/cp/parser.c:3757 0x62c762 c_parse_file() ../../trunk/gcc/cp/parser.c:27557 0x72e4e4 c_common_parse_file() ../../trunk/gcc/c-family/c-opts.c:1138 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Bootstrapped on x86_64-unknown-linux-gnu. I didn't bother to run the testsuite, since the code only changes when an ICE occurs anyhow. OK for mainline? Ian gcc/: 2012-09-17 Ian Lance Taylor i...@google.com * diagnostic.c: Include demangle.h and backtrace.h. (bt_stop): New static array. (bt_callback, bt_err_callback): New static functions. (diagnostic_action_after_output): Call backtrace_full for DK_ICE. * Makefile.in (BACKTRACE): New variable. (BACKTRACEINC, LIBBACKTRACE): New variables. (BACKTRACE_H): New variable. (LIBDEPS, LIBS): Add $(LIBBACKTRACE). (INCLUDES): Add $(BACKTRACEINC). (diagnostic.o): Depend upon $(DEMANGLE_H) and $(BACKTRACE_H). ./: 2012-09-17 Ian Lance Taylor i...@google.com * Makefile.def: Make all-gcc depend on all-libbacktrace. * Makefile.in: Rebuild.
