Re: [PATCH] Fix up cprop to canonicalize PLUS/MINUS with 2 CONSTANT_P arguments (PR rtl-optimization/57915)
On 01/31/14 22:52, Richard Biener wrote: On February 1, 2014 12:56:45 AM GMT+01:00, Steven Bosscher wrote: On Fri, Jan 31, 2014 at 10:28 PM, Jakub Jelinek wrote: Without this patch, cprop can propagate e.g. a SYMBOL_REF to former (mem (plus (reg) (const_int))) making it invalid RTL (as plus of CONSTANT_P arguments must be simplified or surrounded by CONST). But isn't this true for all non-unary operators? Is covering MINUS and PLUS enough? AND should be handled as well. I can't think of any others that might be used with symbol refs. But yes, in principle you are right. I think AND is necessary for certain variants of the Alpha. In theory a shift-add might be possible here, but I don't know if it happens in practice. jeff
Re: [PATCH] Fixing PR60000: A bug in the vectorizer.
On February 1, 2014 12:06:55 AM GMT+01:00, Cong Hou wrote:
>On Fri, Jan 31, 2014 at 5:06 AM, Jakub Jelinek
>wrote:
>>
>> On Fri, Jan 31, 2014 at 09:41:59AM +0100, Richard Biener wrote:
>> > Is that because si and pattern_def_si point to the same stmts?
>Then
>> > I'd prefer to do
>> >
>> > if (is_store)
>> >{
>> > ...
>> > pattern_def_seq = NULL;
>> >}
>> > else if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
>> >{
>> > pattern_def_seq = NULL;
>> > gsi_next (&si);
>> >}
>>
>> Yeah, I think stores can only appear at the end of patterns, so IMHO
>it should be
>> safe to just clear pattern_def_seq always in that case. Right now
>the code
>> has continue; separately for STMT_VINFO_GROUPED_ACCESS (stmt_info)
>and
>> for !STMT_VINFO_GROUPED_ACCESS (stmt_info) stores, but I guess you
>should
>> just move them at the end of if (is_store) and clear pattern_def_seq
>there
>> before the continue. Add gcc_assert (!transform_pattern_stmt); too?
>
>
>I agree. I have updated the patch accordingly. Bootstrapped and tested
>on x86_64. OK for the trunk?
Ok.
Thanks,
Richard.
>thanks,
>Cong
>
>
>
>
>diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>index 95a324c..cabcaf8 100644
>--- a/gcc/ChangeLog
>+++ b/gcc/ChangeLog
>@@ -1,3 +1,10 @@
>+2014-01-30 Cong Hou
>+
>+ PR tree-optimization/6
>+ * tree-vect-loop.c (vect_transform_loop): Set pattern_def_seq
>to NULL
>+ if the vectorized statement is a store. A store statement can
>only
>+ appear at the end of pattern statements.
>+
> 2014-01-27 Jakub Jelinek
>
>PR bootstrap/59934
>diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
>index fa61d5c..f2ce70f 100644
>--- a/gcc/testsuite/ChangeLog
>+++ b/gcc/testsuite/ChangeLog
>@@ -1,3 +1,8 @@
>+2014-01-30 Cong Hou
>+
>+ PR tree-optimization/6
>+ * g++.dg/vect/pr6.cc: New test.
>+
> 2014-01-27 Christian Bruel
>
>* gcc.target/sh/torture/strncmp.c: New tests.
>diff --git a/gcc/testsuite/g++.dg/vect/pr6.cc
>b/gcc/testsuite/g++.dg/vect/pr6.cc
>new file mode 100644
>index 000..fe39d6a
>--- /dev/null
>+++ b/gcc/testsuite/g++.dg/vect/pr6.cc
>@@ -0,0 +1,13 @@
>+/* { dg-do compile } */
>+/* { dg-additional-options "-fno-tree-vrp" } */
>+
>+void foo (bool* a, int* b)
>+{
>+ for (int i = 0; i < 1000; ++i)
>+{
>+ a[i] = i % 2;
>+ b[i] = i % 3;
>+}
>+}
>+
>+/* { dg-final { cleanup-tree-dump "vect" } } */
>diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
>index 69c8d21..0e162cb 100644
>--- a/gcc/tree-vect-loop.c
>+++ b/gcc/tree-vect-loop.c
>@@ -6053,7 +6053,6 @@ vect_transform_loop (loop_vec_info loop_vinfo)
> the chain. */
> gsi_next (&si);
> vect_remove_stores (GROUP_FIRST_ELEMENT (stmt_info));
>- continue;
>}
> else
>{
>@@ -6063,11 +6062,13 @@ vect_transform_loop (loop_vec_info loop_vinfo)
> unlink_stmt_vdef (store);
> gsi_remove (&si, true);
> release_defs (store);
>- continue;
>}
>- }
>
>- if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
>+ /* Stores can only appear at the end of pattern
>statements. */
>+ gcc_assert (!transform_pattern_stmt);
>+ pattern_def_seq = NULL;
>+ }
>+ else if (!transform_pattern_stmt && gsi_end_p
>(pattern_def_si))
>{
> pattern_def_seq = NULL;
> gsi_next (&si);
>
>
>
>
>
>>
>>
>> Jakub
Re: [PATCH] Fix up cprop to canonicalize PLUS/MINUS with 2 CONSTANT_P arguments (PR rtl-optimization/57915)
On February 1, 2014 12:56:45 AM GMT+01:00, Steven Bosscher wrote: >On Fri, Jan 31, 2014 at 10:28 PM, Jakub Jelinek wrote: > >> Without this patch, cprop can propagate e.g. a SYMBOL_REF to former >> (mem (plus (reg) (const_int))) >> making it invalid RTL (as plus of CONSTANT_P arguments must be >simplified >> or surrounded by CONST). > >But isn't this true for all non-unary operators? Is covering MINUS and >PLUS enough? AND should be handled as well. I can't think of any others that might be used with symbol refs. But yes, in principle you are right. Richard. >Ciao! >Steven
Re: [PATCH] Fix __builtin_setjmp handling (PR tree-optimization/60003)
On January 31, 2014 10:24:22 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As described in the PR, __builtin_setjmp_receiver isn't declared to
>returns_twice, and thus after dce cfun->calls_setjmp might be no longer
>true.
>At RTL __builtin_setjmp_receiver is handled as non-local label, so this
>patch just forces cfun->has_nonlocal_label already in GIMPLE, so that
>e.g. the inliner still sees stmt_can_make_nonlocal_goto.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
>2014-01-31 Jakub Jelinek
>
> PR tree-optimization/60003
> * gimple-low.c (lower_builtin_setjmp): Set cfun->has_nonlocal_label.
> * profile.c (branch_prob): Use gimple_call_builtin_p
> to check for BUILT_IN_SETJMP_RECEIVER.
> * tree-inline.c (copy_bb): Call notice_special_calls.
>
> * gcc.c-torture/execute/pr60003.c: New test.
>
>--- gcc/gimple-low.c.jj2014-01-29 12:43:25.0 +0100
>+++ gcc/gimple-low.c 2014-01-31 10:02:38.843026680 +0100
>@@ -709,6 +709,12 @@ lower_builtin_setjmp (gimple_stmt_iterat
> tree dest, t, arg;
> gimple g;
>
>+ /* __builtin_setjmp_{setup,receiver} aren't ECF_RETURNS_TWICE and
>for RTL
>+ these builtins are modelled as non-local label jumps to the label
>+ that is passed to these two builtins, so pretend we have a
>non-local
>+ label during GIMPLE passes too. See PR60003. */
>+ cfun->has_nonlocal_label = true;
>+
>/* NEXT_LABEL is the label __builtin_longjmp will jump to. Its address
>is
>passed to both __builtin_setjmp_setup and __builtin_setjmp_receiver.
>*/
> FORCED_LABEL (next_label) = 1;
>--- gcc/profile.c.jj 2014-01-29 12:43:25.0 +0100
>+++ gcc/profile.c 2014-01-31 10:18:00.450198256 +0100
>@@ -1104,7 +1104,6 @@ branch_prob (void)
> {
> gimple_stmt_iterator gsi;
> gimple first;
>-tree fndecl;
>
> gsi = gsi_start_nondebug_after_labels_bb (bb);
> gcc_checking_assert (!gsi_end_p (gsi));
>@@ -1114,10 +1113,7 @@ branch_prob (void)
>special and don't expect anything to be inserted before
>them. */
> if (is_gimple_call (first)
>-&& (((fndecl = gimple_call_fndecl (first)) != NULL
>- && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
>- && (DECL_FUNCTION_CODE (fndecl)
>- == BUILT_IN_SETJMP_RECEIVER))
>+&& (gimple_call_builtin_p (first, BUILT_IN_SETJMP_RECEIVER)
> || (gimple_call_flags (first) & ECF_RETURNS_TWICE)
> || (gimple_call_internal_p (first)
> && (gimple_call_internal_fn (first)
>--- gcc/tree-inline.c.jj 2014-01-29 12:43:24.0 +0100
>+++ gcc/tree-inline.c 2014-01-31 10:19:13.849815593 +0100
>@@ -1745,7 +1745,6 @@ copy_bb (copy_body_data *id, basic_block
> if (is_gimple_call (stmt))
> {
> struct cgraph_edge *edge;
>-int flags;
>
> switch (id->transform_call_graph_edges)
> {
>@@ -1868,11 +1867,7 @@ copy_bb (copy_body_data *id, basic_block
> }
> }
>
>-flags = gimple_call_flags (stmt);
>-if (flags & ECF_MAY_BE_ALLOCA)
>- cfun->calls_alloca = true;
>-if (flags & ECF_RETURNS_TWICE)
>- cfun->calls_setjmp = true;
>+notice_special_calls (stmt);
> }
>
> maybe_duplicate_eh_stmt_fn (cfun, stmt, id->src_cfun, orig_stmt,
>--- gcc/testsuite/gcc.c-torture/execute/pr60003.c.jj 2014-01-31
>10:05:15.095205547 +0100
>+++ gcc/testsuite/gcc.c-torture/execute/pr60003.c 2014-01-31
>10:04:59.0 +0100
>@@ -0,0 +1,48 @@
>+/* PR tree-optimization/60003 */
>+
>+extern void abort (void);
>+
>+unsigned long long jmp_buf[5];
>+
>+__attribute__((noinline, noclone)) void
>+baz (void)
>+{
>+ __builtin_longjmp (&jmp_buf, 1);
>+}
>+
>+void
>+bar (void)
>+{
>+ baz ();
>+}
>+
>+__attribute__((noinline, noclone)) int
>+foo (int x)
>+{
>+ int a = 0;
>+
>+ if (__builtin_setjmp (&jmp_buf) == 0)
>+{
>+ while (1)
>+ {
>+a = 1;
>+bar (); /* OK if baz () instead */
>+ }
>+}
>+ else
>+{
>+ if (a == 0)
>+ return 0;
>+ else
>+ return x;
>+}
>+}
>+
>+int
>+main ()
>+{
>+ if (foo (1) == 0)
>+abort ();
>+
>+ return 0;
>+}
>
> Jakub
[patch] Add missing generated file to contrib/gcc_update list.
The gcc_update file is missing an entry for gcc/config/aarch64/aarch64.md; this patch adds it. Ok for trunk? Thanks, - Brooks Index: contrib/ChangeLog === --- contrib/ChangeLog (revision 207012) +++ contrib/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2014-01-31 Brooks Moses + + * gcc_update (files_and_dependencies): Add aarch64-tune.md. + 2013-10-21 Mike Stump * gcc_update (configure): Update to handle svn 1.8.1. Index: contrib/gcc_update === --- contrib/gcc_update (revision 207012) +++ contrib/gcc_update (working copy) @@ -79,6 +79,7 @@ gcc/cstamp-h.in: gcc/configure.ac gcc/config.in: gcc/cstamp-h.in gcc/fixinc/fixincl.x: gcc/fixinc/fixincl.tpl gcc/fixinc/inclhack.def +gcc/config/aarch64/aarch64-tune.md: gcc/config/aarch64/aarch64-cores.def gcc/config/aarch64/gentune.sh gcc/config/arm/arm-tune.md: gcc/config/arm/arm-cores.def gcc/config/arm/gentune.sh gcc/config/arm/arm-tables.opt: gcc/config/arm/arm-arches.def gcc/config/arm/arm-cores.def gcc/config/arm/arm-fpus.def gcc/config/arm/genopt.sh gcc/config/avr/avr-tables.opt: gcc/config/avr/avr-mcus.def gcc/config/avr/genopt.sh
Re: [PATCH, rs6000] Support -maltivec=be in LE mode for vec_perm builtin
On Fri, Jan 31, 2014 at 6:36 PM, Bill Schmidt
wrote:
> Hi,
>
> One more patch in the set supporting -maltivec=be for the Altivec
> builtins, this one for vec_perm. Most of the work was done already in
> rs6000.c:altivec_expand_vec_perm_le (). We can reuse this logic for the
> present work by generalizing the code to operate on vector types other
> than V16QImode.
>
> When -maltivec=be is specified for a little endian target, we call that
> routine to expand the builtin rather than generating the vperm pattern
> directly. The pattern is then matched by
> *altivec_vperm_{,_uns}_internal to generate the actual vperm
> instruction.
>
> There are two new test cases that verify correct vec_perm behavior for
> BE, LE, and LE with -maltivec=be. Because vec_perm now works the same
> for BE and LE without -maltivec=be, one existing test needs modification
> to avoid the previous workaround for endianness.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions. Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> gcc:
>
> 2014-01-31 Bill Schmidt
>
> * config/rs6000/rs6000.c (altivec_expand_vec_perm_le): Generalize
> for vector types other than V16QImode.
> * config/rs6000/altivec.md (altivec_vperm_): Change to a
> define_expand, and call altivec_expand_vec_perm_le when producing
> code with little endian element order.
> (*altivec_vperm__internal): New insn having previous
> behavior of altivec_vperm_.
> (altivec_vperm__uns): Change to a define_expand, and call
> altivec_expand_vec_perm_le when producing code with little endian
> element order.
> (*altivec_vperm__uns_internal): New insn having previous
> behavior of altivec_vperm__uns.
>
> gcc/testsuite:
>
> 2014-01-31 Bill Schmidt
>
> * gcc.dg/vmx/3b-15.c: Remove special handling for little endian.
> * gcc.dg/vmx/perm.c: New.
> * gcc.dg/vmx/perm-be-order.c: New.
Okay.
Thanks, David
Re: [PATCH] Fix up cprop to canonicalize PLUS/MINUS with 2 CONSTANT_P arguments (PR rtl-optimization/57915)
On Fri, Jan 31, 2014 at 10:28 PM, Jakub Jelinek wrote: > Without this patch, cprop can propagate e.g. a SYMBOL_REF to former > (mem (plus (reg) (const_int))) > making it invalid RTL (as plus of CONSTANT_P arguments must be simplified > or surrounded by CONST). But isn't this true for all non-unary operators? Is covering MINUS and PLUS enough? Ciao! Steven
Re: [PATCH, rs6000] Handle -maltivec=be on little endian for vec_sums
On Thu, Jan 30, 2014 at 9:42 PM, Bill Schmidt
wrote:
> Hi,
>
> This patch adds logic for -maltivec=be with a little endian target when
> generating code for the vec_sums builtin. This implements the vsumsws
> instruction, which adds the four elements in the first input vector
> operand to element 3 of the second input vector operand, placing the
> result in element 3 of the destination vector operand.
>
> For little endian, element 3 is the leftmost (most significant) word in
> the vector register, while the instruction treats element 3 as the
> rightmost (least significant) word. Since there is not a vector
> shift-immediate or rotate-immediate instruction in VMX, we use a splat
> instruction to get LE element 3 (BE element 0) into BE element 3 of a
> scratch register for input to the vsumsws instruction. Similarly, the
> result of the vsumsws instruction is then splatted from BE element 3
> into BE element 0 (LE element 3) where it is expected to be by any
> builtin that consumes that value. The destination register is reused
> for this purpose.
>
> As with other patches in this series, an altivec_vsumsws_direct pattern
> is added for uses of vsumsws internal to GCC.
>
> Two new test cases are added that demonstrate how the vec_vsums builtin
> is expected to behave for BE, LE, and LE with -maltivec=be.
>
> Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
> regressions. Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> gcc:
>
> 2014-01-30 Bill Schmidt
>
> * config/rs6000/altivec.md (UNSPEC_VSUMSWS_DIRECT): New unspec.
> (altivec_vsumsws): Add handling for -maltivec=be with a little
> endian target.
> (altivec_vsumsws_direct): New.
> (reduc_splus_): Call gen_altivec_vsumsws_direct instead of
> gen_altivec_vsumsws.
>
> gcc/testsuite:
>
> 2014-01-30 Bill Schmidt
>
> * gcc.dg/vmx/vsums.c: New.
> * gcc.dg/vmx/vsums-be-order.c: New.
Okay.
Thanks, David
Re: wide-int, ipa
On Jan 9, 2014, at 7:20 AM, Richard Biener wrote:
> @@ -968,7 +968,7 @@ get_polymorphic_call_info (tree fndecl,
>{
> base_pointer = TREE_OPERAND (base, 0);
> context->offset
> -+= offset2 + mem_ref_offset (base).low * BITS_PER_UNIT;
> + += offset2 + mem_ref_offset (base).ulow () *
> BITS_PER_UNIT;
> context->outer_type = NULL;
>}
> /* We found base object. In this case the outer_type
Fixed, thanks for the catch. This is what I checked in:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 206599)
+++ ipa-devirt.c(working copy)
@@ -1023,7 +1023,7 @@ get_polymorphic_call_info (tree fndecl,
{
base_pointer = TREE_OPERAND (base, 0);
context->offset
- += offset2 + mem_ref_offset (base).ulow () * BITS_PER_UNIT;
+ += offset2 + mem_ref_offset (base).to_short_addr () *
BITS_PER_UNIT;
context->outer_type = NULL;
}
/* We found base object. In this case the outer_type
Re: [google gcc-4_8] gcov-tools: minor fix for broken build for arm
Thanks for catching this, and the fix.
OK for google branch.
-Rong
On Fri, Jan 31, 2014 at 2:46 PM, Hán Shěn (沈涵) wrote:
> Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
> not defined, which leads to redefinition of cs_all, this is observed
> on google/gcc-4_8 branch.
>
> Patch below, tested on chromeos for arm and x86_64 arch.
>
> Ok for google/gcc-4_8 branch?
>
> diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
> index 76f6104..bbce3a6 100644
> --- a/libgcc/libgcov-driver.c
> +++ b/libgcc/libgcov-driver.c
> @@ -559,10 +559,6 @@ gcov_exit_merge_summary (const struct gcov_info
> *gi_ptr, struct gcov_summary *pr
> {
>struct gcov_ctr_summary *cs_prg, *cs_tprg, *cs_all;
>unsigned t_ix;
> -#if !GCOV_LOCKED
> - /* summary for all instances of program. */
> - struct gcov_ctr_summary *cs_all;
> -#endif
>
>/* Merge the summaries. */
>for (t_ix = 0; t_ix < GCOV_COUNTERS_SUMMABLE; t_ix++)
>
>
> Han
[PATCH, rs6000] Support -maltivec=be in LE mode for vec_perm builtin
Hi,
One more patch in the set supporting -maltivec=be for the Altivec
builtins, this one for vec_perm. Most of the work was done already in
rs6000.c:altivec_expand_vec_perm_le (). We can reuse this logic for the
present work by generalizing the code to operate on vector types other
than V16QImode.
When -maltivec=be is specified for a little endian target, we call that
routine to expand the builtin rather than generating the vperm pattern
directly. The pattern is then matched by
*altivec_vperm_{,_uns}_internal to generate the actual vperm
instruction.
There are two new test cases that verify correct vec_perm behavior for
BE, LE, and LE with -maltivec=be. Because vec_perm now works the same
for BE and LE without -maltivec=be, one existing test needs modification
to avoid the previous workaround for endianness.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Is this ok for trunk?
Thanks,
Bill
gcc:
2014-01-31 Bill Schmidt
* config/rs6000/rs6000.c (altivec_expand_vec_perm_le): Generalize
for vector types other than V16QImode.
* config/rs6000/altivec.md (altivec_vperm_): Change to a
define_expand, and call altivec_expand_vec_perm_le when producing
code with little endian element order.
(*altivec_vperm__internal): New insn having previous
behavior of altivec_vperm_.
(altivec_vperm__uns): Change to a define_expand, and call
altivec_expand_vec_perm_le when producing code with little endian
element order.
(*altivec_vperm__uns_internal): New insn having previous
behavior of altivec_vperm__uns.
gcc/testsuite:
2014-01-31 Bill Schmidt
* gcc.dg/vmx/3b-15.c: Remove special handling for little endian.
* gcc.dg/vmx/perm.c: New.
* gcc.dg/vmx/perm-be-order.c: New.
Index: gcc/testsuite/gcc.dg/vmx/perm-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/perm-be-order.c(revision 0)
+++ gcc/testsuite/gcc.dg/vmx/perm-be-order.c(revision 0)
@@ -0,0 +1,74 @@
+/* { dg-options "-maltivec=be -mabi=altivec -std=gnu99 -mno-vsx" } */
+
+#include "harness.h"
+
+static void test()
+{
+ /* Input vectors. */
+ vector unsigned char vuca = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
+ vector unsigned char vucb =
{16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31};
+ vector signed char vsca =
{-16,-15,-14,-13,-12,-11,-10,-9,-8,-7,-6,-5,-4,-3,-2,-1};
+ vector signed char vscb = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
+ vector unsigned short vusa = {0,1,2,3,4,5,6,7};
+ vector unsigned short vusb = {8,9,10,11,12,13,14,15};
+ vector signed short vssa = {-8,-7,-6,-5,-4,-3,-2,-1};
+ vector signed short vssb = {0,1,2,3,4,5,6,7};
+ vector unsigned int vuia = {0,1,2,3};
+ vector unsigned int vuib = {4,5,6,7};
+ vector signed int vsia = {-4,-3,-2,-1};
+ vector signed int vsib = {0,1,2,3};
+ vector float vfa = {-4.0,-3.0,-2.0,-1.0};
+ vector float vfb = {0.0,1.0,2.0,3.0};
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ vector unsigned char vucp = {15,16,14,17,13,18,12,19,11,20,10,21,9,22,8,23};
+ vector unsigned char vscp = {15,16,14,17,13,18,12,19,11,20,10,21,9,22,8,23};
+ vector unsigned char vusp = {15,14,17,16,13,12,19,18,11,10,21,20,9,8,23,22};
+ vector unsigned char vssp = {15,14,17,16,13,12,19,18,11,10,21,20,9,8,23,22};
+ vector unsigned char vuip = {15,14,13,12,19,18,17,16,11,10,9,8,23,22,21,20};
+ vector unsigned char vsip = {15,14,13,12,19,18,17,16,11,10,9,8,23,22,21,20};
+ vector unsigned char vfp = {15,14,13,12,19,18,17,16,11,10,9,8,23,22,21,20};
+#else
+ vector unsigned char vucp = {0,31,1,30,2,29,3,28,4,27,5,26,6,25,7,24};
+ vector unsigned char vscp = {0,31,1,30,2,29,3,28,4,27,5,26,6,25,7,24};
+ vector unsigned char vusp = {0,1,30,31,2,3,28,29,4,5,26,27,6,7,24,25};
+ vector unsigned char vssp = {0,1,30,31,2,3,28,29,4,5,26,27,6,7,24,25};
+ vector unsigned char vuip = {0,1,2,3,28,29,30,31,4,5,6,7,24,25,26,27};
+ vector unsigned char vsip = {0,1,2,3,28,29,30,31,4,5,6,7,24,25,26,27};
+ vector unsigned char vfp = {0,1,2,3,28,29,30,31,4,5,6,7,24,25,26,27};
+#endif
+
+ /* Result vectors. */
+ vector unsigned char vuc;
+ vector signed char vsc;
+ vector unsigned short vus;
+ vector signed short vss;
+ vector unsigned int vui;
+ vector signed int vsi;
+ vector float vf;
+
+ /* Expected result vectors. */
+ vector unsigned char vucr = {0,31,1,30,2,29,3,28,4,27,5,26,6,25,7,24};
+ vector signed char vscr =
{-16,15,-15,14,-14,13,-13,12,-12,11,-11,10,-10,9,-9,8};
+ vector unsigned short vusr = {0,15,1,14,2,13,3,12};
+ vector signed short vssr = {-8,7,-7,6,-6,5,-5,4};
+ vector unsigned int vuir = {0,7,1,6};
+ vector signed int vsir = {-4,3,-3,2};
+ vector float vfr = {-4.0,3.0,-3.0,2.0};
+
+ vuc = vec_perm (vuca, vucb, vucp);
+ vsc = vec_perm (vsca, vscb, vscp);
+ vus = vec_perm (vusa, vusb, vusp);
+ vss = vec_perm (vssa, vssb, vssp);
+ vui = vec_perm (vuia, vuib
Re: [PATCH] Fixing PR60000: A bug in the vectorizer.
On Fri, Jan 31, 2014 at 5:06 AM, Jakub Jelinek wrote:
>
> On Fri, Jan 31, 2014 at 09:41:59AM +0100, Richard Biener wrote:
> > Is that because si and pattern_def_si point to the same stmts? Then
> > I'd prefer to do
> >
> > if (is_store)
> >{
> > ...
> > pattern_def_seq = NULL;
> >}
> > else if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
> >{
> > pattern_def_seq = NULL;
> > gsi_next (&si);
> >}
>
> Yeah, I think stores can only appear at the end of patterns, so IMHO it
> should be
> safe to just clear pattern_def_seq always in that case. Right now the code
> has continue; separately for STMT_VINFO_GROUPED_ACCESS (stmt_info) and
> for !STMT_VINFO_GROUPED_ACCESS (stmt_info) stores, but I guess you should
> just move them at the end of if (is_store) and clear pattern_def_seq there
> before the continue. Add gcc_assert (!transform_pattern_stmt); too?
I agree. I have updated the patch accordingly. Bootstrapped and tested
on x86_64. OK for the trunk?
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 95a324c..cabcaf8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2014-01-30 Cong Hou
+
+ PR tree-optimization/6
+ * tree-vect-loop.c (vect_transform_loop): Set pattern_def_seq to NULL
+ if the vectorized statement is a store. A store statement can only
+ appear at the end of pattern statements.
+
2014-01-27 Jakub Jelinek
PR bootstrap/59934
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index fa61d5c..f2ce70f 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-01-30 Cong Hou
+
+ PR tree-optimization/6
+ * g++.dg/vect/pr6.cc: New test.
+
2014-01-27 Christian Bruel
* gcc.target/sh/torture/strncmp.c: New tests.
diff --git a/gcc/testsuite/g++.dg/vect/pr6.cc
b/gcc/testsuite/g++.dg/vect/pr6.cc
new file mode 100644
index 000..fe39d6a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vect/pr6.cc
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fno-tree-vrp" } */
+
+void foo (bool* a, int* b)
+{
+ for (int i = 0; i < 1000; ++i)
+{
+ a[i] = i % 2;
+ b[i] = i % 3;
+}
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 69c8d21..0e162cb 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -6053,7 +6053,6 @@ vect_transform_loop (loop_vec_info loop_vinfo)
the chain. */
gsi_next (&si);
vect_remove_stores (GROUP_FIRST_ELEMENT (stmt_info));
- continue;
}
else
{
@@ -6063,11 +6062,13 @@ vect_transform_loop (loop_vec_info loop_vinfo)
unlink_stmt_vdef (store);
gsi_remove (&si, true);
release_defs (store);
- continue;
}
- }
- if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
+ /* Stores can only appear at the end of pattern statements. */
+ gcc_assert (!transform_pattern_stmt);
+ pattern_def_seq = NULL;
+ }
+ else if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
{
pattern_def_seq = NULL;
gsi_next (&si);
>
>
> Jakub
[google gcc-4_8] gcov-tools: minor fix for broken build for arm
Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
not defined, which leads to redefinition of cs_all, this is observed
on google/gcc-4_8 branch.
Patch below, tested on chromeos for arm and x86_64 arch.
Ok for google/gcc-4_8 branch?
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index 76f6104..bbce3a6 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -559,10 +559,6 @@ gcov_exit_merge_summary (const struct gcov_info
*gi_ptr, struct gcov_summary *pr
{
struct gcov_ctr_summary *cs_prg, *cs_tprg, *cs_all;
unsigned t_ix;
-#if !GCOV_LOCKED
- /* summary for all instances of program. */
- struct gcov_ctr_summary *cs_all;
-#endif
/* Merge the summaries. */
for (t_ix = 0; t_ix < GCOV_COUNTERS_SUMMABLE; t_ix++)
Han
Re: [C++ Patch] PR 51219
On 01/28/2014 01:37 PM, Paolo Carlini wrote: ... by the way, I don't understand why we are appending the constructor at all for the unnamed bit-field?!? Eg, what about the below? I agree, it doesn't seem necessary; output_constructor deals fine with a sparse CONSTRUCTOR. This patch is OK. Jason
Re: [PATCH] Fix PCH on AArch64 (PR pch/60010)
On Fri, Jan 31, 2014 at 2:09 PM, Kyle McMartin wrote: > On Fri, Jan 31, 2014 at 02:03:25PM -0800, Andrew Pinski wrote: >> > 2014-01-31 Kyle McMartin >> > >> > PR pch/60010 >> > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64. >> >> >> If this gets merged before my ILP32 changes, I will make sure I >> include a fix for ILP32 also. >> > > Ah, good thinking. I was wondering if it would require a test of > __LP64__ as well, but didn't think to look if AArch32 ABI was using > __aarch64__ && !LP64 or __aarch32__ or something. Well aarch32 uses __arm__ (the old arm toolchain in fact) but I am talking about the ILP32 ABI for AARCH64. Thanks, Andrew > > Thanks Andrew! > > regards, Kyle
Re: [PATCH] Fix PCH on AArch64 (PR pch/60010)
On Fri, Jan 31, 2014 at 02:03:25PM -0800, Andrew Pinski wrote: > > 2014-01-31 Kyle McMartin > > > > PR pch/60010 > > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64. > > > If this gets merged before my ILP32 changes, I will make sure I > include a fix for ILP32 also. > Ah, good thinking. I was wondering if it would require a test of __LP64__ as well, but didn't think to look if AArch32 ABI was using __aarch64__ && !LP64 or __aarch32__ or something. Thanks Andrew! regards, Kyle
[jit] Add libgccjit++.h, a C++ wrapper to the API
Committed to branch dmalcolm/jit:
The libgccjit C API is relatively low-level and thus should be easy to
maintain a stable ABI for, and to wrap from many different languages.
However, it's rather verbose.
This commit adds an example of a C++ wrapper, which makes use of methods,
overloading, and inheritance, giving a much more terse API.
It's all done as small inline functions wrapped around the raw C pointers,
within one header, so it shouldn't need to be built as a separate library,
hence this shouldn't add an ABI (I hope), just an API.
As an example, I ported test-quadratic.c to it (as a new file:
test-quadratic.cc), and was able to considerably reduce the line-count
whilst fitting within a 80-column limit:
# line, word, byte counts:
$ wc \
gcc/testsuite/jit.dg/test-quadratic.c \
gcc/testsuite/jit.dg/test-quadratic.cc
487 1066 12748 gcc/testsuite/jit.dg/test-quadratic.c
369 911 9985 gcc/testsuite/jit.dg/test-quadratic.cc
856 1977 22733 total
Caveat: I haven't yet managed to get DejaGnu to run this as part of
the test suite; I've been building/running it manually for now.
gcc/jit/
* libgccjit++.h: New file - a C++ wrapper for the libgccjit.h API.
* TODO.rst ("Test Suite"): New section, adding note about C++
tests.
gcc/testsuite/
* jit.dg/test-quadratic.cc: New file - a translation of
test-quadratic.c to the libgccjit++.h C++ API.
---
gcc/jit/ChangeLog.jit | 7 +
gcc/jit/TODO.rst | 4 +
gcc/jit/libgccjit++.h | 829 +
gcc/testsuite/ChangeLog.jit| 5 +
gcc/testsuite/jit.dg/test-quadratic.cc | 369 +++
5 files changed, 1214 insertions(+)
create mode 100644 gcc/jit/libgccjit++.h
create mode 100644 gcc/testsuite/jit.dg/test-quadratic.cc
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 4babb1e..0dd95f2 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,12 @@
2014-01-31 David Malcolm
+ * libgccjit++.h: New file - a C++ wrapper for the libgccjit.h API.
+
+ * TODO.rst ("Test Suite"): New section, adding note about C++
+ tests.
+
+2014-01-31 David Malcolm
+
* libgccjit.h (gcc_jit_context_new_rvalue_from_int): Give the type
parameter a more descriptive name.
(gcc_jit_context_zero): Likewise.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 5b6e0f7..0572b78 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -133,6 +133,10 @@ Initial Release
* gcc_jit_loop_end: verify that loops are validly nested?
+Test suite
+==
+* get DejaGnu to build and run C++ testcases
+
Future milestones
=
* try porting llvmpipe to gcc
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
new file mode 100644
index 000..8636dd1
--- /dev/null
+++ b/gcc/jit/libgccjit++.h
@@ -0,0 +1,829 @@
+/* A C++ API for libgccjit, purely as inline wrapper functions. */
+
+#ifndef LIBGCCJIT_PLUS_PLUS_H
+#define LIBGCCJIT_PLUS_PLUS_H
+
+#include "libgccjit.h"
+
+#include
+
+/
+ C++ API
+ /
+
+namespace gccjit
+{
+ class context;
+ class location;
+ class field;
+ class type;
+ class param;
+ class function;
+ class label;
+ class rvalue;
+ class lvalue;
+
+ class context
+ {
+ public:
+static context acquire ();
+context ();
+context (gcc_jit_context *ctxt);
+
+location
+new_location (const char *filename,
+ int line,
+ int column);
+
+type get_type (enum gcc_jit_types kind);
+
+field new_field (type type_, const char *name);
+field new_field (location loc, type type_, const char *name);
+
+type new_struct_type (const char *name,
+ std::vector fields);
+type new_struct_type (location loc,
+ const char *name,
+ std::vector fields);
+
+param new_param (type type_,
+const char *name);
+param new_param (location loc,
+type type_,
+const char *name);
+
+function new_function (enum gcc_jit_function_kind kind,
+ type return_type,
+ const char *name,
+ std::vector params,
+ int is_variadic);
+function new_function (location loc,
+ enum gcc_jit_function_kind kind,
+ type return_type,
+ const char *name,
+ std::vector params,
+ int is_variadic);
+
+rvalue new_rvalue (type numeric_type,
+ int value);
+rvalue zero (type numeric_type);
+rvalue one (type numeric_type);
+rvalue new_rvalue (type numeric_type,
+
Re: PR ipa/59831 (ipa-cp devirt issues)
Hi,
here is even better testcase (in a sense that my patch does not solve the wrong
code issue)
Compile with ./xgcc -B ./ -O3 ~/t.C -S -fno-partial-inlining
-fno-early-inlining -fdump-ipa-all -fdump-tree-all -fipa-cp -fno-ipa-sra
Here the sequence is bit different. Here we have contstruction table store
done within destructor that
sets it accoridng to the second parameter. We hover still produce PASSTHROUGH
function for it and
we end up propagating the wrong type.
Honza
#include
class A {
public:
unsigned length;
};
class B {};
class MultiTermDocs : public virtual B {
protected:
A readerTermDocs;
A subReaders;
virtual B *m_fn1(int *) {}
virtual inline ~MultiTermDocs();
void wrap(void)
{
m_fn1(NULL);
}
};
class C : MultiTermDocs {
B *m_fn1(int *);
};
MultiTermDocs::~MultiTermDocs() {
wrap ();
if (&readerTermDocs) {
B *a;
for (unsigned i = 0; i < subReaders.length; i++)
(a != 0);
}
}
Re: [PATCH] Fix PCH on AArch64 (PR pch/60010)
On Fri, Jan 31, 2014 at 11:59 AM, Kyle McMartin wrote: > Hi, > > Similar to other architectures, failing to set TRY_EMPTY_VM_SPACE > results in a Segmentation Fault and ICE in cc1plus when using > precompiled headers and randomize_va_space is set. This patch fixes the > issue, and now I can reliably build packages which use pch (wxGTK and > openjdk in particular would fail every time. wxGTK has survived 30 build > attempts without failure now.) > > (The exact value is unimportant, as long as it's in an unused area. I > suspect that the fallback buffer_size code path hasn't been fixed up > since the exec-shield days and could use a re-think now that mmap > randomization is upstream. I've been trying to debug exactly why it > fails for all architctures, so we can remove this, but haven't had much > luck yet.) > > This is similar to pch/45979, pch/14940, target/25343. > > Bootstrapped and tested on aarch64-linux-gnu. > > regards, Kyle > > 2014-01-31 Kyle McMartin > > PR pch/60010 > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64. If this gets merged before my ILP32 changes, I will make sure I include a fix for ILP32 also. Thanks, Andrew > > --- a/gcc/config/host-linux.c > +++ b/gcc/config/host-linux.c > @@ -86,6 +86,8 @@ > # define TRY_EMPTY_VM_SPACE0x6000 > #elif defined(__mc68000__) > # define TRY_EMPTY_VM_SPACE0x4000 > +#elif defined(__aarch64__) > +# define TRY_EMPTY_VM_SPACE0x10 > #elif defined(__ARM_EABI__) > # define TRY_EMPTY_VM_SPACE 0x6000 > #elif defined(__mips__) && defined(__LP64__)
[PATCH] Fix up cprop to canonicalize PLUS/MINUS with 2 CONSTANT_P arguments (PR rtl-optimization/57915)
Hi!
Without this patch, cprop can propagate e.g. a SYMBOL_REF to former
(mem (plus (reg) (const_int)))
making it invalid RTL (as plus of CONSTANT_P arguments must be simplified
or surrounded by CONST).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2014-01-31 Jakub Jelinek
PR rtl-optimization/57915
* recog.c (simplify_while_replacing): For PLUS/MINUS
with both operands CONSTANT_P where one operand is equal
to TO call simplify_gen_binary.
* gcc.target/i386/pr57915.c: New test.
--- gcc/recog.c.jj 2014-01-23 10:53:05.0 +0100
+++ gcc/recog.c 2014-01-31 16:08:06.371826412 +0100
@@ -590,6 +590,14 @@ simplify_while_replacing (rtx *loc, rtx
validate_change (object, loc,
simplify_gen_binary
(PLUS, GET_MODE (x), XEXP (x, 0), XEXP (x, 1)), 1);
+ /* Canonicalize addition of two constants, that must be either
+simplified into a constant or (const (plus (...) (...))). */
+ else if (CONSTANT_P (XEXP (x, 0))
+ && CONSTANT_P (XEXP (x, 1))
+ && (XEXP (x, 0) == to || XEXP (x, 1) == to))
+ validate_change (object, loc,
+simplify_gen_binary
+(PLUS, GET_MODE (x), XEXP (x, 0), XEXP (x, 1)), 1);
break;
case MINUS:
if (CONST_SCALAR_INT_P (XEXP (x, 1)))
@@ -599,6 +607,14 @@ simplify_while_replacing (rtx *loc, rtx
simplify_gen_unary (NEG,
GET_MODE (x), XEXP (x, 1),
GET_MODE (x))), 1);
+ /* Canonicalize subtraction of two constants, that must be either
+simplified into a constant or (const (minus (...) (...))). */
+ else if (CONSTANT_P (XEXP (x, 0))
+ && CONSTANT_P (XEXP (x, 1))
+ && (XEXP (x, 0) == to || XEXP (x, 1) == to))
+ validate_change (object, loc,
+simplify_gen_binary
+(MINUS, GET_MODE (x), XEXP (x, 0), XEXP (x, 1)), 1);
break;
case ZERO_EXTEND:
case SIGN_EXTEND:
--- gcc/testsuite/gcc.target/i386/pr57915.c.jj 2014-01-31 16:10:47.436942155
+0100
+++ gcc/testsuite/gcc.target/i386/pr57915.c 2014-01-31 16:10:21.0
+0100
@@ -0,0 +1,33 @@
+/* PR rtl-optimization/57915 */
+/* { dg-do compile } */
+/* { dg-options "-Os" } */
+
+extern struct T { char a[8]; char b[16]; } t;
+int c;
+void foo (void);
+
+extern inline char *
+baz (char *x, const char *y)
+{
+ const char *e = y;
+ unsigned long f, g;
+ asm ("" : "+c" (f), "+D" (e) : "a" ('\0'), "X" (*e));
+ g = e - 1 - y;
+ __builtin_memcpy (x, y, g);
+ x[g] = '\0';
+ return x;
+}
+
+void
+bar (void)
+{
+ char d[16];
+ baz (d, t.b);
+
+ for (;;)
+{
+ foo ();
+ if (c)
+ baz (d, t.b);
+}
+}
Jakub
[PATCH] Fix __builtin_setjmp handling (PR tree-optimization/60003)
Hi!
As described in the PR, __builtin_setjmp_receiver isn't declared to
returns_twice, and thus after dce cfun->calls_setjmp might be no longer true.
At RTL __builtin_setjmp_receiver is handled as non-local label, so this
patch just forces cfun->has_nonlocal_label already in GIMPLE, so that
e.g. the inliner still sees stmt_can_make_nonlocal_goto.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-01-31 Jakub Jelinek
PR tree-optimization/60003
* gimple-low.c (lower_builtin_setjmp): Set cfun->has_nonlocal_label.
* profile.c (branch_prob): Use gimple_call_builtin_p
to check for BUILT_IN_SETJMP_RECEIVER.
* tree-inline.c (copy_bb): Call notice_special_calls.
* gcc.c-torture/execute/pr60003.c: New test.
--- gcc/gimple-low.c.jj 2014-01-29 12:43:25.0 +0100
+++ gcc/gimple-low.c2014-01-31 10:02:38.843026680 +0100
@@ -709,6 +709,12 @@ lower_builtin_setjmp (gimple_stmt_iterat
tree dest, t, arg;
gimple g;
+ /* __builtin_setjmp_{setup,receiver} aren't ECF_RETURNS_TWICE and for RTL
+ these builtins are modelled as non-local label jumps to the label
+ that is passed to these two builtins, so pretend we have a non-local
+ label during GIMPLE passes too. See PR60003. */
+ cfun->has_nonlocal_label = true;
+
/* NEXT_LABEL is the label __builtin_longjmp will jump to. Its address is
passed to both __builtin_setjmp_setup and __builtin_setjmp_receiver. */
FORCED_LABEL (next_label) = 1;
--- gcc/profile.c.jj2014-01-29 12:43:25.0 +0100
+++ gcc/profile.c 2014-01-31 10:18:00.450198256 +0100
@@ -1104,7 +1104,6 @@ branch_prob (void)
{
gimple_stmt_iterator gsi;
gimple first;
- tree fndecl;
gsi = gsi_start_nondebug_after_labels_bb (bb);
gcc_checking_assert (!gsi_end_p (gsi));
@@ -1114,10 +1113,7 @@ branch_prob (void)
special and don't expect anything to be inserted before
them. */
if (is_gimple_call (first)
- && (((fndecl = gimple_call_fndecl (first)) != NULL
- && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL
- && (DECL_FUNCTION_CODE (fndecl)
- == BUILT_IN_SETJMP_RECEIVER))
+ && (gimple_call_builtin_p (first, BUILT_IN_SETJMP_RECEIVER)
|| (gimple_call_flags (first) & ECF_RETURNS_TWICE)
|| (gimple_call_internal_p (first)
&& (gimple_call_internal_fn (first)
--- gcc/tree-inline.c.jj2014-01-29 12:43:24.0 +0100
+++ gcc/tree-inline.c 2014-01-31 10:19:13.849815593 +0100
@@ -1745,7 +1745,6 @@ copy_bb (copy_body_data *id, basic_block
if (is_gimple_call (stmt))
{
struct cgraph_edge *edge;
- int flags;
switch (id->transform_call_graph_edges)
{
@@ -1868,11 +1867,7 @@ copy_bb (copy_body_data *id, basic_block
}
}
- flags = gimple_call_flags (stmt);
- if (flags & ECF_MAY_BE_ALLOCA)
- cfun->calls_alloca = true;
- if (flags & ECF_RETURNS_TWICE)
- cfun->calls_setjmp = true;
+ notice_special_calls (stmt);
}
maybe_duplicate_eh_stmt_fn (cfun, stmt, id->src_cfun, orig_stmt,
--- gcc/testsuite/gcc.c-torture/execute/pr60003.c.jj2014-01-31
10:05:15.095205547 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr60003.c 2014-01-31
10:04:59.0 +0100
@@ -0,0 +1,48 @@
+/* PR tree-optimization/60003 */
+
+extern void abort (void);
+
+unsigned long long jmp_buf[5];
+
+__attribute__((noinline, noclone)) void
+baz (void)
+{
+ __builtin_longjmp (&jmp_buf, 1);
+}
+
+void
+bar (void)
+{
+ baz ();
+}
+
+__attribute__((noinline, noclone)) int
+foo (int x)
+{
+ int a = 0;
+
+ if (__builtin_setjmp (&jmp_buf) == 0)
+{
+ while (1)
+ {
+ a = 1;
+ bar (); /* OK if baz () instead */
+ }
+}
+ else
+{
+ if (a == 0)
+ return 0;
+ else
+ return x;
+}
+}
+
+int
+main ()
+{
+ if (foo (1) == 0)
+abort ();
+
+ return 0;
+}
Jakub
Re: [C++ Patch] PR 58672
Hi, > On 31/gen/2014, at 18:32, Jason Merrill wrote: > > Oops, sorry I was slow to claim this PR... No problem, nice to see the bug going completely away! Well, you may want to have a look to my pending work on c++/51219 ;) http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01693.html http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01808.html Thanks, Paolo.
Re: PR ipa/59831 (ipa-cp devirt issues)
Hi,
this is variant of testcase that produces wrong code on Mainline.
$ ./xgcc -B ./ -O3 ~/t.C -S -fno-partial-inlining -fno-early-inlining
-fdump-ipa-all ; g++ t.s; ./a.out
Aborted
The bug is that we determine wrong type on call of ~MultiTermDocs within ~C (it
is determined as C, while it really should be C in construction).
Quite amusingly gcc-4.8 also determine the wrong type but does devirtualize
correctly. Martin,
any idea why?
#include
class A {
public:
unsigned length;
};
class B {};
class MultiTermDocs : public virtual B {
protected:
A readerTermDocs;
A subReaders;
virtual B *m_fn1(int *) {}
inline virtual ~MultiTermDocs();
void wrap(void)
{
m_fn1(NULL);
}
};
class C : MultiTermDocs {
B *m_fn1(int *);
};
MultiTermDocs::~MultiTermDocs() {
wrap ();
if (&readerTermDocs) {
B *a;
for (unsigned i = 0; i < subReaders.length; i++)
(a != 0);
}
}
[PATCH] Fix PCH on AArch64 (PR pch/60010)
Hi, Similar to other architectures, failing to set TRY_EMPTY_VM_SPACE results in a Segmentation Fault and ICE in cc1plus when using precompiled headers and randomize_va_space is set. This patch fixes the issue, and now I can reliably build packages which use pch (wxGTK and openjdk in particular would fail every time. wxGTK has survived 30 build attempts without failure now.) (The exact value is unimportant, as long as it's in an unused area. I suspect that the fallback buffer_size code path hasn't been fixed up since the exec-shield days and could use a re-think now that mmap randomization is upstream. I've been trying to debug exactly why it fails for all architctures, so we can remove this, but haven't had much luck yet.) This is similar to pch/45979, pch/14940, target/25343. Bootstrapped and tested on aarch64-linux-gnu. regards, Kyle 2014-01-31 Kyle McMartin PR pch/60010 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64. --- a/gcc/config/host-linux.c +++ b/gcc/config/host-linux.c @@ -86,6 +86,8 @@ # define TRY_EMPTY_VM_SPACE0x6000 #elif defined(__mc68000__) # define TRY_EMPTY_VM_SPACE0x4000 +#elif defined(__aarch64__) +# define TRY_EMPTY_VM_SPACE0x10 #elif defined(__ARM_EABI__) # define TRY_EMPTY_VM_SPACE 0x6000 #elif defined(__mips__) && defined(__LP64__)
Fix pr/60004
It seems that lower_try_finally_switch was not properly updated for the
addition of EH_ELSE. We tried to lower the finally construct before we
actually handled the EH_ELSE construct specially.
I examined the other lower_try_finally_* alternatives and they all seem to do
the right thing.
Testing in progress; I'll commit if things go well.
r~
diff --git a/gcc/testsuite/g++.dg/tm/pr60004.C
b/gcc/testsuite/g++.dg/tm/pr60004.C
new file mode 100644
index 000..b8c2c0e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tm/pr60004.C
@@ -0,0 +1,10 @@
+// { dg-do compile }
+// { dg-options "-fgnu-tm" }
+
+int a;
+int f() {
+__transaction_atomic {
+if (a == 5)
+return 1;
+}
+}
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 0c8282e..e9c714c 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -1388,9 +1388,6 @@ lower_try_finally_switch (struct leh_state *state, struct
leh_tf_state *tf)
x = gimple_seq_last_stmt (finally);
finally_loc = x ? gimple_location (x) : tf_loc;
- /* Lower the finally block itself. */
- lower_eh_constructs_1 (state, &finally);
-
/* Prepare for switch statement generation. */
nlabels = tf->dest_array.length ();
return_index = nlabels;
@@ -1476,6 +1473,7 @@ lower_try_finally_switch (struct leh_state *state, struct
leh_tf_state *tf)
x = gimple_build_label (finally_label);
gimple_seq_add_stmt (&tf->top_p_seq, x);
+ lower_eh_constructs_1 (state, &finally);
gimple_seq_add_seq (&tf->top_p_seq, finally);
/* Redirect each incoming goto edge. */
C++ PATCH to mark_decl_instantiated
In the discussion of PR 59469, Honza said that the C++ front end should
be setting forced_by_abi on explicitly instantiated decls. This patch
does that, though unfortunately it does not seem to be sufficient to fix
the bug.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2c704f89487f0df704afe4d953f5a336b10214ca
Author: Jason Merrill
Date: Fri Jan 31 13:02:14 2014 -0500
PR c++/59469
* pt.c (mark_decl_instantiated): Call mark_needed.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ae5995b..7967db8 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -17967,6 +17967,7 @@ mark_decl_instantiated (tree result, int extern_p)
else
{
mark_definable (result);
+ mark_needed (result);
/* Always make artificials weak. */
if (DECL_ARTIFICIAL (result) && flag_weak)
comdat_linkage (result);
Re: [C++ patch] for c++/37140
OK, thanks. Jason
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 10:12 AM, Joseph S. Myers
wrote:
> On Fri, 31 Jan 2014, Andrew Pinski wrote:
>
>> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
>> > Hi,
>> >
>> > For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
>> > This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
>> > Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
>> > -mlong-double-64 and -mlong-double-80 negate each other so that the
>> > last one on command line wins. It os OK since we don't support
>> > -mlong-double-xxx in target attribute. I added some testcases to verify
>> > it works correctly. OK for trunk?
>>
>> I don't see any where in the documentation that explains the
>> difference between -mlong-double-128 and -m128bit-long-double. Can
>> you please add that -mlong-double-128 causes soft-floating point.
I will update it together with -m128bit-long-double clarification.
>> Also what about the interactions between these two options.
They have nothing to do with each other. -m128bit-long-double
controls the storage size of __float80 amd -mlong-double-XXX
controls the size of long double, 64, 80 and 128 bits.
>
> Yes, I think the invoke.texi documentation for each of these options needs
> to cross-reference the other one of the options and explain the difference
> explicitly.
>
> I would add: to confirm, does __float80 remain available on 64-bit Android
Yes, it does. There is a testcase for it:
[hjl@gnu-6 testsuite]$ cat gcc.target/i386/long-double-80-5.c
/* { dg-do compile } */
/* { dg-options "-O2 -mlong-double-64" } */
__float80
foo (__float80 x)
{
return x * x;
}
/* { dg-final { scan-assembler "fldt" } } */
[hjl@gnu-6 testsuite]$
> and provide access to XFmode there? (If not, the documentation of
> __float80 needs updating.)
>
> If in future we implement TS 18661-3 in GCC, it will be necessary to work
> out in cases such as this whether _Float64x should have the representation
> of __float80 or __float128 (I'd guess __float80 would be better).
>
--
H.J.
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
On Fri, 31 Jan 2014, Richard Biener wrote:
> Still I think this is odd behavior - as you are matching x86_64-*linux
> you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know
On Ubuntu those are in /usr/include/x86_64-linux-gnu/gnu/ (and I suppose
the 32-bit one is /usr/include/i386-linux-gnu/gnu/ but haven't checked).
--
Joseph S. Myers
jos...@codesourcery.com
Re: [C++ RFC/Patch] PR 58561
On 01/29/2014 12:49 PM, Paolo Carlini wrote: By the way, this recycling of TEMPLATE_TYPE_PARM + name seems weird to me too, I noticed it a couple of times already (I think it shows in an open diagnostic issue too). I think the alternative would an additional TREE_CODE and a lot of uses of it wherever now we just say TEMPLATE_TYPE_PARM (eg, in pt.c). Maybe it's worth it, maybe not, I don't know if Jason *actually* tried the idea in his local trees. I didn't. We represent auto as a TEMPLATE_TYPE_PARM because auto deduction works like template deduction, and if we wanted to call it something else we would need to replace it with a TEMPLATE_TYPE_PARM in order to do deduction, plus check for auto when checking whether a type is dependent. So, doable, but kind of a pain. Jason
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, 31 Jan 2014, Andrew Pinski wrote: > On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote: > > Hi, > > > > For 64-bit Android, long double is 128-bit IEEE-754 floating point type. > > This patch adds -mlong-double-128 to i386 and makes it default for 64-bit > > Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128, > > -mlong-double-64 and -mlong-double-80 negate each other so that the > > last one on command line wins. It os OK since we don't support > > -mlong-double-xxx in target attribute. I added some testcases to verify > > it works correctly. OK for trunk? > > I don't see any where in the documentation that explains the > difference between -mlong-double-128 and -m128bit-long-double. Can > you please add that -mlong-double-128 causes soft-floating point. > Also what about the interactions between these two options. Yes, I think the invoke.texi documentation for each of these options needs to cross-reference the other one of the options and explain the difference explicitly. I would add: to confirm, does __float80 remain available on 64-bit Android and provide access to XFmode there? (If not, the documentation of __float80 needs updating.) If in future we implement TS 18661-3 in GCC, it will be necessary to work out in cases such as this whether _Float64x should have the representation of __float80 or __float128 (I'd guess __float80 would be better). -- Joseph S. Myers jos...@codesourcery.com
Re: PR ipa/59831 (ipa-cp devirt issues)
> I've tested your patch a little bit and hit the gcc_assert above:
>
> markus@x4 tmp % cat test.ii
> class A {
> public:
> unsigned length;
> };
> class B {};
> class MultiTermDocs : public virtual B {
> protected:
> A readerTermDocs;
> A subReaders;
> virtual B *m_fn1(int *);
> virtual ~MultiTermDocs();
> };
> class C : MultiTermDocs {
> B *m_fn1(int *);
> };
> MultiTermDocs::~MultiTermDocs() {
> if (&readerTermDocs) {
> B *a;
> for (unsigned i = 0; i < subReaders.length; i++)
> (a != 0);
> }
> }
>
> B *C::m_fn1(int *) { return 0; }
Thanks! It is the case where we see a construction vtable store. There is no
BINFO for that, so we need to give up trying to analyze the type.
We will need to improve our representation to handle this eventually, but
that is definitely not stage3 material.
I actualy wondered about this and tried to construct a testcase that did not
trigger for some reason and concluded that I probably don't care when it does
not fire for firefox. Your testing (and reduced testcaes) are very useful.
I will drop the abort and add your testcase before comitting the patch.
I wonder if we can reproduce this as wrong code bug for gcc-4.8. Basically
virtual calls in the destructors of the virtual base should get devirtualized
the wrong way.
Honza
>
> markus@x4 tmp % g++ -O2 test.ii
> test.ii: In destructor ‘virtual C::~C()’:
> test.ii:24:32: internal compiler error: in vtable_pointer_value_to_binfo, at
> ipa-devirt.c:1082
> B *C::m_fn1(int *) { return 0; }
> ^
> 0x9ca774 vtable_pointer_value_to_binfo(tree_node*)
> ../../gcc/gcc/ipa-devirt.c:1082
> 0x9e22b9 extr_type_from_vtbl_ptr_store
> ../../gcc/gcc/ipa-prop.c:606
> 0x9e22b9 check_stmt_for_type_change
> ../../gcc/gcc/ipa-prop.c:648
> 0xc18343 walk_aliased_vdefs_1
> ../../gcc/gcc/tree-ssa-alias.c:2472
> 0xc1846d walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*,
> tree_node*, void*), void*, bitmap_head**)
> ../../gcc/gcc/tree-ssa-alias.c:2491
> 0x9e1cba detect_type_change
> ../../gcc/gcc/ipa-prop.c:702
> 0x9e8b63 compute_complex_assign_jump_func
> ../../gcc/gcc/ipa-prop.c:1089
> 0x9e8b63 ipa_compute_jump_functions_for_edge
> ../../gcc/gcc/ipa-prop.c:1635
> 0x9eb882 ipa_compute_jump_functions
> ../../gcc/gcc/ipa-prop.c:1675
> 0x9eb882 ipa_analyze_node(cgraph_node*)
> ../../gcc/gcc/ipa-prop.c:2212
> 0x103ea7f ipcp_generate_summary
> ../../gcc/gcc/ipa-cp.c:3709
> 0xaa4906 execute_ipa_summary_passes(ipa_opt_pass_d*)
> ../../gcc/gcc/passes.c:2027
> 0x833dbb ipa_passes
> ../../gcc/gcc/cgraphunit.c:2070
> 0x833dbb compile()
> ../../gcc/gcc/cgraphunit.c:2174
> 0x834304 finalize_compilation_unit()
> ../../gcc/gcc/cgraphunit.c:2329
> 0x62efce cp_write_global_declarations()
> ../../gcc/gcc/cp/decl2.c:4447
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
>
>
> --
> Markus
Re: [PATCH] Add location_t printer to gdbinit.in
On Jan 31, 2014, at 2:40 AM, Marek Polacek wrote: > Often enough I need to print expanded_location of location_t. > It'd be convenient to have this macro in gdbinit.in. > > Ok? Looks good to me…
Re: [C++ Patch] PR 58672
Oops, sorry I was slow to claim this PR... Jason
C++ PATCH for c++/58672 (ICE with invalid thread_local)
In this testcase, an error caused us to decide that a variable needs
initialization but not a TLS init function. We should handle that
gracefully.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit cc60625316aa72c2142bd90a30e3756358caac23
Author: Jason Merrill
Date: Fri Jan 31 11:36:54 2014 -0500
PR c++/58672
* decl2.c (handle_tls_init): Handle null init fn.
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 2216591..35707a0 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4036,6 +4036,8 @@ handle_tls_init (void)
if (TREE_PUBLIC (var))
{
tree single_init_fn = get_tls_init_fn (var);
+ if (single_init_fn == NULL_TREE)
+ continue;
cgraph_node *alias
= cgraph_same_body_alias (cgraph_get_create_node (fn),
single_init_fn, fn);
diff --git a/gcc/testsuite/g++.dg/tls/thread_local-ice2.C b/gcc/testsuite/g++.dg/tls/thread_local-ice2.C
new file mode 100644
index 000..53bc297
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tls/thread_local-ice2.C
@@ -0,0 +1,11 @@
+// PR c++/58672
+// { dg-options "-std=c++11" }
+// { dg-require-effective-target tls }
+
+struct A
+{
+ A(int);
+ i;// { dg-error "" }
+};
+
+thread_local A a(0);
[C++ Patch] PR 58672
Hi,
I think we can pretty easily fix the remaining minor issue in the
thread_local meta-bug: the ICE happens because, after the error, we end
up calling cgraph_same_body_alias from handle_tls_init with a null
second argument (returned by get_tls_init_fn), thus
cgraph_create_function_alias crashes immediately on the line (the whole
function doesn't make sense for null alias):
gcc_assert (TREE_CODE (alias) == FUNCTION_DECL);
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-01-31 Paolo Carlini
PR c++/58672
* decl2.c (handle_tls_init): Don't call cgraph_same_body_alias
with a null second argument.
/testsuite
2014-01-31 Paolo Carlini
PR c++/58672
* g++.dg/tls/thread_local9.C: New.
Index: cp/decl2.c
===
--- cp/decl2.c (revision 207361)
+++ cp/decl2.c (working copy)
@@ -4036,10 +4036,13 @@ handle_tls_init (void)
if (TREE_PUBLIC (var))
{
tree single_init_fn = get_tls_init_fn (var);
- cgraph_node *alias
- = cgraph_same_body_alias (cgraph_get_create_node (fn),
- single_init_fn, fn);
- gcc_assert (alias != NULL);
+ if (single_init_fn)
+ {
+ cgraph_node *alias
+ = cgraph_same_body_alias (cgraph_get_create_node (fn),
+ single_init_fn, fn);
+ gcc_assert (alias != NULL);
+ }
}
#endif
}
Index: testsuite/g++.dg/tls/thread_local9.C
===
--- testsuite/g++.dg/tls/thread_local9.C(revision 0)
+++ testsuite/g++.dg/tls/thread_local9.C(working copy)
@@ -0,0 +1,11 @@
+// PR c++/58672
+// { dg-options "-std=c++11" }
+// { dg-require-effective-target tls }
+
+struct A
+{
+ A(int);
+ i; // { dg-error "does not name a type" }
+};
+
+thread_local A a(0);
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 9:04 AM, Uros Bizjak wrote: > On Fri, Jan 31, 2014 at 5:58 PM, Andrew Pinski wrote: >> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote: >>> Hi, >>> >>> For 64-bit Android, long double is 128-bit IEEE-754 floating point type. >>> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit >>> Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128, >>> -mlong-double-64 and -mlong-double-80 negate each other so that the >>> last one on command line wins. It os OK since we don't support >>> -mlong-double-xxx in target attribute. I added some testcases to verify >>> it works correctly. OK for trunk? >> >> I don't see any where in the documentation that explains the >> difference between -mlong-double-128 and -m128bit-long-double. Can >> you please add that -mlong-double-128 causes soft-floating point. >> Also what about the interactions between these two options. > > The -m128bit-long-double has no effect on TFmode. The names are > similar by coincidence, but it is a good idea to mention the > difference in the documentation. > I will come up with something after -mlong-double-128 is checked in. Thanks. -- H.J.
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 8:52 AM, Uros Bizjak wrote: > On Fri, Jan 31, 2014 at 2:59 PM, H.J. Lu wrote: > >> For 64-bit Android, long double is 128-bit IEEE-754 floating point type. >> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit >> Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128, >> -mlong-double-64 and -mlong-double-80 negate each other so that the >> last one on command line wins. It os OK since we don't support >> -mlong-double-xxx in target attribute. I added some testcases to verify >> it works correctly. OK for trunk? >> >> Thanks. >> >> >> H.J. >> --- >> gcc/ >> >> 2014-01-30 H.J. Lu >> >> * config/i386/i386.c (flag_opts): Add -mlong-double-128. >> (ix86_option_override_internal): Default long double to 64-bit for >> 32-bit Bionic and to 128-bit for 64-bit Bionic. >> >> * config/i386/i386.h (LONG_DOUBLE_TYPE_SIZE): Use 128 if >> TARGET_LONG_DOUBLE_128 is true. >> (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. >> >> * config/i386/i386.opt (mlong-double-80): Negate -mlong-double-64. >> (mlong-double-64): Negate -mlong-double-128. >> (mlong-double-128): New option. >> >> * config/i386/i386-c.c (ix86_target_macros): Define >> __LONG_DOUBLE_128__ for TARGET_LONG_DOUBLE_128. >> >> * doc/invoke.texi: Document -mlong-double-128. >> >> gcc/testsuite/ >> >> 2014-01-30 H.J. Lu >> >> * gcc.target/i386/long-double-64-1.c: Verify __multf3 isn't used. >> * gcc.target/i386/long-double-64-4.c: Likewise. >> * gcc.target/i386/long-double-80-1.c: Likewise. >> * gcc.target/i386/long-double-80-2.c: Likewise. >> * gcc.target/i386/long-double-80-3.c: Likewise. >> * gcc.target/i386/long-double-80-4.c: Likewise. >> * gcc.target/i386/long-double-80-5.c: Likewise. >> * gcc.target/i386/long-double-64-2.c: Limit to ia32. Verify >> __multf3 isn't used. >> * gcc.target/i386/long-double-64-3.c: Likewise. >> * gcc.target/i386/long-double-128-1.c: New test. >> * gcc.target/i386/long-double-128-2.c: Likewise. >> * gcc.target/i386/long-double-128-3.c: Likewise. >> * gcc.target/i386/long-double-128-4.c: Likewise. >> * gcc.target/i386/long-double-128-5.c: Likewise. >> * gcc.target/i386/long-double-128-6.c: Likewise. >> * gcc.target/i386/long-double-128-7.c: Likewise. >> * gcc.target/i386/long-double-128-8.c: Likewise. >> * gcc.target/i386/long-double-128-9.c: Likewise. >> * gcc.target/i386/long-double-64-5.c: Likewise. >> * gcc.target/i386/long-double-64-6.c: Likewise. >> * gcc.target/i386/long-double-64-7.c: Likewise. >> * gcc.target/i386/long-double-64-8.c: Likewise. >> * gcc.target/i386/long-double-64-9.c: Likewise. >> * gcc.target/i386/long-double-80-10.c: Likewise. >> * gcc.target/i386/long-double-80-8.c: Likewise. >> * gcc.target/i386/long-double-80-9.c: Likewise. > > OK for mainline as far as x86 is concerned, but please check if you > also need Android maintainer approval. > Hi Maxim, Can you take a look at this? BTW, 64-bit Android psABI is on hjl/android branch at https://github.com/hjl-tools/x86-64-psABI Thanks. -- H.J.
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 5:58 PM, Andrew Pinski wrote: > On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote: >> Hi, >> >> For 64-bit Android, long double is 128-bit IEEE-754 floating point type. >> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit >> Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128, >> -mlong-double-64 and -mlong-double-80 negate each other so that the >> last one on command line wins. It os OK since we don't support >> -mlong-double-xxx in target attribute. I added some testcases to verify >> it works correctly. OK for trunk? > > I don't see any where in the documentation that explains the > difference between -mlong-double-128 and -m128bit-long-double. Can > you please add that -mlong-double-128 causes soft-floating point. > Also what about the interactions between these two options. The -m128bit-long-double has no effect on TFmode. The names are similar by coincidence, but it is a good idea to mention the difference in the documentation. Uros.
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
> Hi,
>
> For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
> Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
> -mlong-double-64 and -mlong-double-80 negate each other so that the
> last one on command line wins. It os OK since we don't support
> -mlong-double-xxx in target attribute. I added some testcases to verify
> it works correctly. OK for trunk?
I don't see any where in the documentation that explains the
difference between -mlong-double-128 and -m128bit-long-double. Can
you please add that -mlong-double-128 causes soft-floating point.
Also what about the interactions between these two options.
Thanks,
Andrew
>
> Thanks.
>
>
> H.J.
> ---
> gcc/
>
> 2014-01-30 H.J. Lu
>
> * config/i386/i386.c (flag_opts): Add -mlong-double-128.
> (ix86_option_override_internal): Default long double to 64-bit for
> 32-bit Bionic and to 128-bit for 64-bit Bionic.
>
> * config/i386/i386.h (LONG_DOUBLE_TYPE_SIZE): Use 128 if
> TARGET_LONG_DOUBLE_128 is true.
> (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise.
>
> * config/i386/i386.opt (mlong-double-80): Negate -mlong-double-64.
> (mlong-double-64): Negate -mlong-double-128.
> (mlong-double-128): New option.
>
> * config/i386/i386-c.c (ix86_target_macros): Define
> __LONG_DOUBLE_128__ for TARGET_LONG_DOUBLE_128.
>
> * doc/invoke.texi: Document -mlong-double-128.
>
> gcc/testsuite/
>
> 2014-01-30 H.J. Lu
>
> * gcc.target/i386/long-double-64-1.c: Verify __multf3 isn't used.
> * gcc.target/i386/long-double-64-4.c: Likewise.
> * gcc.target/i386/long-double-80-1.c: Likewise.
> * gcc.target/i386/long-double-80-2.c: Likewise.
> * gcc.target/i386/long-double-80-3.c: Likewise.
> * gcc.target/i386/long-double-80-4.c: Likewise.
> * gcc.target/i386/long-double-80-5.c: Likewise.
> * gcc.target/i386/long-double-64-2.c: Limit to ia32. Verify
> __multf3 isn't used.
> * gcc.target/i386/long-double-64-3.c: Likewise.
> * gcc.target/i386/long-double-128-1.c: New test.
> * gcc.target/i386/long-double-128-2.c: Likewise.
> * gcc.target/i386/long-double-128-3.c: Likewise.
> * gcc.target/i386/long-double-128-4.c: Likewise.
> * gcc.target/i386/long-double-128-5.c: Likewise.
> * gcc.target/i386/long-double-128-6.c: Likewise.
> * gcc.target/i386/long-double-128-7.c: Likewise.
> * gcc.target/i386/long-double-128-8.c: Likewise.
> * gcc.target/i386/long-double-128-9.c: Likewise.
> * gcc.target/i386/long-double-64-5.c: Likewise.
> * gcc.target/i386/long-double-64-6.c: Likewise.
> * gcc.target/i386/long-double-64-7.c: Likewise.
> * gcc.target/i386/long-double-64-8.c: Likewise.
> * gcc.target/i386/long-double-64-9.c: Likewise.
> * gcc.target/i386/long-double-80-10.c: Likewise.
> * gcc.target/i386/long-double-80-8.c: Likewise.
> * gcc.target/i386/long-double-80-9.c: Likewise.
> diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
> index ee83de6..0c50720 100644
> --- a/gcc/config/i386/i386-c.c
> +++ b/gcc/config/i386/i386-c.c
> @@ -513,6 +513,9 @@ ix86_target_macros (void)
>if (TARGET_LONG_DOUBLE_64)
> cpp_define (parse_in, "__LONG_DOUBLE_64__");
>
> + if (TARGET_LONG_DOUBLE_128)
> +cpp_define (parse_in, "__LONG_DOUBLE_128__");
> +
>cpp_define_formatted (parse_in, "__ATOMIC_HLE_ACQUIRE=%d",
> IX86_HLE_ACQUIRE);
>cpp_define_formatted (parse_in, "__ATOMIC_HLE_RELEASE=%d",
> IX86_HLE_RELEASE);
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 1e65743..3a01b6e 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2628,6 +2628,7 @@ ix86_target_string (HOST_WIDE_INT isa, int flags, const
> char *arch,
>static struct ix86_target_opts flag_opts[] =
>{
> { "-m128bit-long-double", MASK_128BIT_LONG_DOUBLE },
> +{ "-mlong-double-128", MASK_LONG_DOUBLE_128 },
> { "-mlong-double-64", MASK_LONG_DOUBLE_64 },
> { "-m80387", MASK_80387 },
> { "-maccumulate-outgoing-args",MASK_ACCUMULATE_OUTGOING_ARGS },
> @@ -4195,10 +4196,18 @@ ix86_option_override_internal (bool main_args_p,
>else if (opts_set->x_target_flags & MASK_RECIP)
> opts->x_recip_mask &= ~(RECIP_MASK_ALL & ~opts->x_recip_mask_explicit);
>
> - /* Default long double to 64-bit for Bionic. */
> + /* Default long double to 64-bit for 32-bit Bionic and to __float128
> + for 64-bit Bionic. */
>if (TARGET_HAS_BIONIC
> - && !(opts_set->x_target_flags & MASK_LONG_DOUBLE_64))
> -opts->x_target_flags |= MASK_LONG_DOUBLE_64;
> + && !(opts_set->x_target_flags
> + & (MASK_LONG_DOU
RE: Issue with _Cilk_for
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Friday, January 31, 2014 11:26 AM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Issue with _Cilk_for
>
> On Fri, Jan 31, 2014 at 04:18:28PM +, Iyer, Balaji V wrote:
> > I tried to do this. The thing is, you had me model like this:
> >
> > #pragma omp parallel for
> > _Cilk_for (...)
> > {
> > Body
> > }
> >
> > Now, the compiler will do something like this:
> >
> > #pragma OMP parallel
> > {
> > #pragma Omp for
> > {
> > _Cilk_for (...)
> > Body
> > }
> > }
> >
> > Now, if by the time it starts to look at evaluating/breaking up the
> > _Cilk-for's parts, we are already at the scope inside #pragma omp
> > parallel. If I try to pop here, it has some scope issues with #pragma
> > omp parallel. This requires a lot of rewrite of existing OMP code to
> > port it for _Cilk_for. This can be done but will take significant
> > time which I don't think I have since we are close to end of stage3.
>
> It really doesn't require lots of rewriting, after all, OpenMP handles the C++
> iterators very similarly.
>
> > We can look into what you want, but in the meantime, can you accept
> > this patch with the way I have modelled so that the feature can make
> > it into 4.9?
>
> No. In GCC we do not rush in bad changes just because there is time
> pressure. As Cilk+ is new in GCC 4.9, if you adjust things properly in say
> 2-3
> weeks frame, we might still make an exception and allow it in during stage4,
> otherwise it will have to wait for 5.0.
Hi Jakub,
I am not asking to rush anything. Personally, I won't submit anything
if I don't think it is a correct solution, especially for something this big
into a system that is used by a large population. On the top level, I don't
understand why it matters where the #pragma omp parallel is placed. Can you
please explain me that? I agree it feels weird when you think about from OMP
standpoint, but so what? It is just used in the internal representation for
_Cilk_for so that I can use the OMP routines to create child functions and
transplant the correct parts of code to it. _Cilk_for behaves very differently
compared to OMP for. It is almost like apple and orange when it comes to
functionality. To my best knowledge, there is no additional scoping or overhead
instructions inserted when I put #prgma omp parallel around the body.
I am just asking this to get the whole picture. Please don't think this as an
argument/flame.
Thanks,
Balaji V. Iyer.
>
> Jakub
Re: PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
On Fri, Jan 31, 2014 at 2:59 PM, H.J. Lu wrote: > For 64-bit Android, long double is 128-bit IEEE-754 floating point type. > This patch adds -mlong-double-128 to i386 and makes it default for 64-bit > Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128, > -mlong-double-64 and -mlong-double-80 negate each other so that the > last one on command line wins. It os OK since we don't support > -mlong-double-xxx in target attribute. I added some testcases to verify > it works correctly. OK for trunk? > > Thanks. > > > H.J. > --- > gcc/ > > 2014-01-30 H.J. Lu > > * config/i386/i386.c (flag_opts): Add -mlong-double-128. > (ix86_option_override_internal): Default long double to 64-bit for > 32-bit Bionic and to 128-bit for 64-bit Bionic. > > * config/i386/i386.h (LONG_DOUBLE_TYPE_SIZE): Use 128 if > TARGET_LONG_DOUBLE_128 is true. > (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise. > > * config/i386/i386.opt (mlong-double-80): Negate -mlong-double-64. > (mlong-double-64): Negate -mlong-double-128. > (mlong-double-128): New option. > > * config/i386/i386-c.c (ix86_target_macros): Define > __LONG_DOUBLE_128__ for TARGET_LONG_DOUBLE_128. > > * doc/invoke.texi: Document -mlong-double-128. > > gcc/testsuite/ > > 2014-01-30 H.J. Lu > > * gcc.target/i386/long-double-64-1.c: Verify __multf3 isn't used. > * gcc.target/i386/long-double-64-4.c: Likewise. > * gcc.target/i386/long-double-80-1.c: Likewise. > * gcc.target/i386/long-double-80-2.c: Likewise. > * gcc.target/i386/long-double-80-3.c: Likewise. > * gcc.target/i386/long-double-80-4.c: Likewise. > * gcc.target/i386/long-double-80-5.c: Likewise. > * gcc.target/i386/long-double-64-2.c: Limit to ia32. Verify > __multf3 isn't used. > * gcc.target/i386/long-double-64-3.c: Likewise. > * gcc.target/i386/long-double-128-1.c: New test. > * gcc.target/i386/long-double-128-2.c: Likewise. > * gcc.target/i386/long-double-128-3.c: Likewise. > * gcc.target/i386/long-double-128-4.c: Likewise. > * gcc.target/i386/long-double-128-5.c: Likewise. > * gcc.target/i386/long-double-128-6.c: Likewise. > * gcc.target/i386/long-double-128-7.c: Likewise. > * gcc.target/i386/long-double-128-8.c: Likewise. > * gcc.target/i386/long-double-128-9.c: Likewise. > * gcc.target/i386/long-double-64-5.c: Likewise. > * gcc.target/i386/long-double-64-6.c: Likewise. > * gcc.target/i386/long-double-64-7.c: Likewise. > * gcc.target/i386/long-double-64-8.c: Likewise. > * gcc.target/i386/long-double-64-9.c: Likewise. > * gcc.target/i386/long-double-80-10.c: Likewise. > * gcc.target/i386/long-double-80-8.c: Likewise. > * gcc.target/i386/long-double-80-9.c: Likewise. OK for mainline as far as x86 is concerned, but please check if you also need Android maintainer approval. Thanks, Uros.
Re: Issue with _Cilk_for
On Fri, Jan 31, 2014 at 04:18:28PM +, Iyer, Balaji V wrote:
> I tried to do this. The thing is, you had me model like this:
>
> #pragma omp parallel for
> _Cilk_for (...)
> {
> Body
> }
>
> Now, the compiler will do something like this:
>
> #pragma OMP parallel
> {
> #pragma Omp for
> {
> _Cilk_for (...)
> Body
> }
> }
>
> Now, if by the time it starts to look at evaluating/breaking up the
> _Cilk-for's parts, we are already at the scope inside #pragma omp
> parallel. If I try to pop here, it has some scope issues with #pragma omp
> parallel. This requires a lot of rewrite of existing OMP code to port it
> for _Cilk_for. This can be done but will take significant time which I
> don't think I have since we are close to end of stage3.
It really doesn't require lots of rewriting, after all, OpenMP handles
the C++ iterators very similarly.
> We can look into what you want, but in the meantime, can you accept this
> patch with the way I have modelled so that the feature can make it into
> 4.9?
No. In GCC we do not rush in bad changes just because there is time
pressure. As Cilk+ is new in GCC 4.9, if you adjust things properly in
say 2-3 weeks frame, we might still make an exception and allow it in
during stage4, otherwise it will have to wait for 5.0.
Jakub
C++ PATCH for c++/55800 (undefined symbol with thread_local)
Here we were leaving DECL_EXTERNAL set on the TLS init alias, so it
wasn't getting emitted properly.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit e0343cda07dc6b8139eeb7c3a5f25891d48a6300
Author: Jason Merrill
Date: Fri Jan 31 10:54:49 2014 -0500
PR c++/55800
* decl2.c (get_tls_init_fn): Copy DECL_EXTERNAL from the variable.
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index b2103c8..2216591 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -2949,7 +2949,7 @@ get_tls_init_fn (tree var)
TREE_PUBLIC (fn) = TREE_PUBLIC (var);
DECL_ARTIFICIAL (fn) = true;
DECL_COMDAT (fn) = DECL_COMDAT (var);
- DECL_EXTERNAL (fn) = true;
+ DECL_EXTERNAL (fn) = DECL_EXTERNAL (var);
if (DECL_ONE_ONLY (var))
make_decl_one_only (fn, cxx_comdat_group (fn));
if (TREE_PUBLIC (var))
diff --git a/gcc/testsuite/g++.dg/tls/thread_local8.C b/gcc/testsuite/g++.dg/tls/thread_local8.C
new file mode 100644
index 000..206e7b3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tls/thread_local8.C
@@ -0,0 +1,11 @@
+// PR c++/55800
+// { dg-options "-std=c++11" }
+// { dg-require-alias "" }
+// { dg-final { scan-assembler "_ZTH12foo_instance" { target tls_native } } }
+
+struct foo
+{
+ foo();
+};
+
+thread_local foo foo_instance;
RE: Issue with _Cilk_for
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, January 31, 2014 11:04 AM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Issue with _Cilk_for
>
> On Fri, Jan 31, 2014 at 04:42:57PM +0100, Jakub Jelinek wrote:
> > Can you explain why you emit anything in between the parallel and
> _Cilk_for?
> > I don't see why it should be needed.
> > Depending on what the Cilk+ standard allows you to do (can array.begin
> > () be evaluated multiple times or not, and if not, can you invoke say
> > a copy constructor on it), you should just emit an EXPR_STMT that
> > initializes an artificial scalar (say get_temp_regvar created) to
> > (array.end () - array.begin ()) before you add the parallel, or, if
> > array.begin () can't be evaluated multiple times, then construct some
> > temporary before the parallel with array.begin () as initializer and
> > then do the subtraction between array.end () and that temporary.
> >
> > Then the parallel, with _Cilk_for immediately in it and just another
> > temporary scalar as loop iterator there, and only inside of _Cilk_for
> > declare the iterator var and construct (if it has been declared in
> > _Cilk_for, otherwise just initialize it) to, depending on what Cilk+
> > requires, either to array.begin () and then operator+ it to the
> > corresponding value, or construct already to array.begin () + scalariv.
>
> Actually, small correction, the iterator variable likely should be constructed
> before the parallel and just marked as firstprivate on the parallel, then you
> even don't need any special temporary.
>
> So for:
>
> _Cilk_for (vector::iterator iter = array.begin(); iter != array.end();
> iter++)
> {
> if (*iter == 6)
> *iter = 13;
> }
>
> emit basically:
> {
> Iterator iter;
> Iterator::Iterator(&iter, array.begin());
> ptrdiff_t tmpcount = Iterator::operator-(array.end(), &iter);
> ptrdiff_t tmpiv;
> ptrdiff_t tmplast = 0;
> #pragma omp parallel firstprivate(iter, tmpcount, tmplast) private(tmpiv)
> {
> _Cilk_for(tmpiv = 0; tmpiv < tmpcount; tmpiv++)
> {
> Iterator::operator+(&iter, tmpiv - tmplast);
> tmplast = tmpiv;
> {
> if (*iter == 6)
> *iter = 13;
> }
> }
> }
> }
>
I tried to do this. The thing is, you had me model like this:
#pragma omp parallel for
_Cilk_for (...)
{
Body
}
Now, the compiler will do something like this:
#pragma OMP parallel
{
#pragma Omp for
{
_Cilk_for (...)
Body
}
}
Now, if by the time it starts to look at evaluating/breaking up the _Cilk-for's
parts, we are already at the scope inside #pragma omp parallel. If I try to pop
here, it has some scope issues with #pragma omp parallel. This requires a lot
of rewrite of existing OMP code to port it for _Cilk_for. This can be done but
will take significant time which I don't think I have since we are close to end
of stage3.
But, if I had the parallel around the body, then the body is transplanted into
the child function and everything I need for _Cilk-for is done. Yes, it does
not make sense for an OMP expert. I am nowhere close to being an expert and
even I had a hard time to wrap my head around this.
We can look into what you want, but in the meantime, can you accept this patch
with the way I have modelled so that the feature can make it into 4.9?
Thanks,
Balaji V. Iyer.
> Jakub
Re: [C++ Patch] PR 59082
OK. Jason
Re: Issue with _Cilk_for
On Fri, Jan 31, 2014 at 04:42:57PM +0100, Jakub Jelinek wrote:
> Can you explain why you emit anything in between the parallel and _Cilk_for?
> I don't see why it should be needed.
> Depending on what the Cilk+ standard allows you to do (can array.begin ()
> be evaluated multiple times or not, and if not, can you invoke say a copy
> constructor on it), you should just emit an EXPR_STMT that initializes
> an artificial scalar (say get_temp_regvar created) to
> (array.end () - array.begin ()) before you add the parallel, or,
> if array.begin () can't be evaluated multiple times, then construct some
> temporary before the parallel with array.begin () as initializer
> and then do the subtraction between array.end () and that temporary.
>
> Then the parallel, with _Cilk_for immediately in it and just another
> temporary scalar as loop iterator there, and only inside of _Cilk_for
> declare the iterator var and construct (if it has been declared in _Cilk_for,
> otherwise
> just initialize it) to, depending on what Cilk+ requires, either to
> array.begin () and then operator+ it to the corresponding value, or
> construct already to array.begin () + scalariv.
Actually, small correction, the iterator variable likely should be
constructed before the parallel and just marked as firstprivate on the
parallel, then you even don't need any special temporary.
So for:
_Cilk_for (vector::iterator iter = array.begin(); iter != array.end();
iter++)
{
if (*iter == 6)
*iter = 13;
}
emit basically:
{
Iterator iter;
Iterator::Iterator(&iter, array.begin());
ptrdiff_t tmpcount = Iterator::operator-(array.end(), &iter);
ptrdiff_t tmpiv;
ptrdiff_t tmplast = 0;
#pragma omp parallel firstprivate(iter, tmpcount, tmplast) private(tmpiv)
{
_Cilk_for(tmpiv = 0; tmpiv < tmpcount; tmpiv++)
{
Iterator::operator+(&iter, tmpiv - tmplast);
tmplast = tmpiv;
{
if (*iter == 6)
*iter = 13;
}
}
}
}
Jakub
[Ada] Warn on barrier functions that depend on global data
This patch adds a warning to a barrier function in an entry body, when the
barrier mentions data that is not private to the protected object, and subject
to external modification by unsynchronized actions, which can lead to hard-to-
diagnose race conditions.
Compiling entry_with_global_barrier.adb must yield
entry_with_global_barrier.adb:39:49:
warning: potentially unsynchronized barrier
entry_with_global_barrier.adb:39:49:
warning: "Global_Flag" should be private component of type
with Ada.Text_IO; use Ada.Text_IO;
procedure Entry_with_global_barrier is
Global_Flag : Boolean := False;
protected Triggered_from_Outside is
entry Block_until_External_Condition;
private
Some_Flag : Boolean := False;
end Triggered_from_Outside;
protected body Triggered_from_Outside is
entry Block_until_External_Condition when Global_Flag is
begin
Put_Line ("Barrier opened");
end Block_until_External_Condition;
end Triggered_from_Outside;
task Block;
task body Block is
begin
Triggered_from_Outside.Block_until_External_Condition;
Put_Line ("Block task terminates");
end Block;
begin
Global_Flag := True;
Put_Line ("Main task waits for termination");
end Entry_with_global_barrier;
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-01-31 Ed Schonberg
* exp_ch9.adb (Expand_Entry_Barrier): Warn if the barrier
depends on data that is not private to the protected object,
and potentially modifiable in unsynchronized fashion.
Index: exp_ch9.adb
===
--- exp_ch9.adb (revision 207351)
+++ exp_ch9.adb (working copy)
@@ -6180,10 +6180,60 @@
Condition (Entry_Body_Formal_Part (N));
Prot : constant Entity_Id := Scope (Ent);
Spec_Decl : constant Node_Id := Parent (Prot);
- Func : Node_Id;
+ Func : Entity_Id;
B_F : Node_Id;
Body_Decl : Node_Id;
+ function Is_Global_Entity (N : Node_Id) return Traverse_Result;
+ -- Check whether entity in Barrier is external to protected type.
+ -- If so, barrier may not be properly synchronized.
+
+ --
+ -- Is_Global_Entity --
+ --
+
+ function Is_Global_Entity (N : Node_Id) return Traverse_Result is
+ E : Entity_Id;
+ S : Entity_Id;
+ begin
+ if Is_Entity_Name (N) and then Present (Entity (N)) then
+E := Entity (N);
+S := Scope (E);
+
+if Ekind (E) = E_Variable then
+ if Scope (E) = Func then
+ null;
+
+ -- A protected call from a barrier to another object is ok
+
+ elsif Ekind (Etype (E)) = E_Protected_Type then
+ null;
+
+ -- If the variable is within the package body we consider
+ -- this safe. This is a common (if dubious) idiom.
+
+ elsif S = Scope (Prot)
+ and then (Ekind (S) = E_Package
+ or else Ekind (S) = E_Generic_Package)
+ and then Nkind (Parent (E)) = N_Object_Declaration
+ and then Nkind (Parent (Parent (E))) = N_Package_Body
+ then
+ null;
+
+ else
+ Error_Msg_N ("potentially unsynchronized barrier ?", N);
+ Error_Msg_N ("!& should be private component of type?", N);
+ end if;
+end if;
+ end if;
+
+ return OK;
+ end Is_Global_Entity;
+
+ procedure Check_Unprotected_Barrier is
+ new Traverse_Proc (Is_Global_Entity);
+ -- Start of processing for Expand_Entry_Barrier
+
begin
if No_Run_Time_Mode then
Error_Msg_CRT ("entry barrier", N);
@@ -6268,8 +6318,11 @@
end if;
-- It is not a boolean variable or literal, so check the restriction
+ -- and otherwise emit warning if barrier contains global entities and
+ -- is thus potentially unsynchronized.
Check_Restriction (Simple_Barriers, Cond);
+ Check_Unprotected_Barrier (Cond);
end Expand_Entry_Barrier;
--
[Ada] Unchecked_Deallocation fails to free a class-wide object
This patch corrects the treatment of a deallocation call where the designated
type is class-wide and also acts as a generic actual in an instantiation, to
perform a runtime check when trying to determine the controlled-ness of the
deallocated object.
-- Source --
-- deallocator.ads
package Deallocator is
procedure Execute;
end Deallocator;
-- deallocator.adb
with Ada.Unchecked_Deallocation;
package body Deallocator is
type Typ is tagged limited null record;
type Any_Typ_Ptr is access all Typ'Class;
generic
type Item_Typ (<>) is limited private;
package Gen is
type Item_Ptr is access all Item_Typ;
procedure Deallocate (Ptr : in out Item_Ptr);
end Gen;
package body Gen is
procedure Free is
new Ada.Unchecked_Deallocation (Item_Typ, Item_Ptr);
procedure Deallocate (Ptr : in out Item_Ptr) is
begin
Free (Ptr);
end Deallocate;
end Gen;
package Inst is new Gen (Typ'Class);
procedure Execute is
Obj : Any_Typ_Ptr := new Typ;
begin
Inst.Deallocate (Inst.Item_Ptr (Obj));
end Execute;
end Deallocator;
-- main.adb
with Deallocator;
procedure Main is
begin
Deallocator.Execute;
end Main;
-
-- Compilation --
-
$ gnatmake -q main.adb
$ ./main
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-01-31 Hristian Kirtchev
* exp_util.adb (Build_Allocate_Deallocate_Proc): Rewrite
the logic that generates a runtime check to determine the
controlled status of the object about to be allocated or
deallocated. Class-wide types now always use a runtime check
even if they appear as generic actuals.
(Find_Object): Detect
a special case that involves interface class-wide types because
the object appears as a complex expression.
Index: exp_util.adb
===
--- exp_util.adb(revision 207349)
+++ exp_util.adb(working copy)
@@ -511,14 +511,33 @@
Expr := E;
loop
-if Nkind_In (Expr, N_Qualified_Expression,
- N_Unchecked_Type_Conversion)
-then
+if Nkind (Expr) = N_Explicit_Dereference then
+ Expr := Prefix (Expr);
+
+elsif Nkind (Expr) = N_Qualified_Expression then
Expr := Expression (Expr);
-elsif Nkind (Expr) = N_Explicit_Dereference then
- Expr := Prefix (Expr);
+elsif Nkind (Expr) = N_Unchecked_Type_Conversion then
+ -- When interface class-wide types are involved in allocation,
+ -- the expander introduces several levels of address arithmetic
+ -- to perform dispatch table displacement. In this scenario the
+ -- object appears as:
+ --
+ --Tag_Ptr (Base_Address ('Address))
+ --
+ -- Detect this case and utilize the whole expression as the
+ -- "object" since it now points to the proper dispatch table.
+
+ if Is_RTE (Etype (Expr), RE_Tag_Ptr) then
+ exit;
+
+ -- Continue to strip the object
+
+ else
+ Expr := Expression (Expr);
+ end if;
+
else
exit;
end if;
@@ -790,102 +809,106 @@
-- h) Is_Controlled
- -- Generate a run-time check to determine whether a class-wide object
- -- is truly controlled.
-
if Needs_Finalization (Desig_Typ) then
-if Is_Class_Wide_Type (Desig_Typ)
- or else Is_Generic_Actual_Type (Desig_Typ)
-then
- declare
- Flag_Id : constant Entity_Id := Make_Temporary (Loc, 'F');
- Flag_Expr : Node_Id;
- Param : Node_Id;
- Temp : Node_Id;
+declare
+ Flag_Id : constant Entity_Id := Make_Temporary (Loc, 'F');
+ Flag_Expr : Node_Id;
+ Param : Node_Id;
+ Temp : Node_Id;
- begin
- if Is_Allocate then
- Temp := Find_Object (Expression (Expr));
- else
- Temp := Expr;
- end if;
+begin
+ if Is_Allocate then
+ Temp := Find_Object (Expression (Expr));
+ else
+ Temp := Expr;
+ end if;
- -- Processing for generic actuals
+ -- Processing for allocations where the expression is a subtype
+ -- indication.
- if Is_Generic_Actual_Type (Desig_Typ) then
- Flag_Expr :=
- New_Reference_To (Boolean_Literals
- (Needs_Fina
Re: Issue with _Cilk_for
On Wed, Jan 29, 2014 at 10:58:55PM +, Iyer, Balaji V wrote:
> This is the testcase I am using:
>
> _Cilk_for (vector::iterator iter = array.begin(); iter != array.end();
> iter++)
> {
>if (*iter == 6)
> *iter = 13;
> }
> ==
> try
> {
> #pragma omp parallel schedule(cilk-for,0)
> if(__gnu_cxx::operator- > ((const struct
> __normal_iterator &) (const struct __normal_iterator *) &TARGET_EXPR
> ::end (&array)>, (const struct __normal_iterator &)
> (const struct __normal_iterator *) &iter))
> {
> {
> {
> struct iterator iter;
> difference_type D.28409;
> difference_type D.28410;
>
> struct iterator iter;
> < (void) (iter = TARGET_EXPR ::begin (&array)>)
> >;
> difference_type D.28409;
> difference_type D.28410;
>grainsize = 0 if(__gnu_cxx::operator- std::vector > ((const struct __normal_iterator &) (const struct
> __normal_iterator *) &TARGET_EXPR ::end (&array)>,
> (const struct __normal_iterator &) (const struct __normal_iterator *) &iter))
> {
> < (void) (D.28410 = 0) >
> _Cilk_for (D.28409 = 0; D.28409 != < __gnu_cxx::operator- > ((const struct
> __normal_iterator &) (const struct __normal_iterator *) &TARGET_EXPR
> ::end (&array)>, (const struct __normal_iterator &)
> (const struct __normal_iterator *) &iter)>>; D.28409 = D.28409 + 1)
Can you explain why you emit anything in between the parallel and _Cilk_for?
I don't see why it should be needed.
Depending on what the Cilk+ standard allows you to do (can array.begin ()
be evaluated multiple times or not, and if not, can you invoke say a copy
constructor on it), you should just emit an EXPR_STMT that initializes
an artificial scalar (say get_temp_regvar created) to
(array.end () - array.begin ()) before you add the parallel, or,
if array.begin () can't be evaluated multiple times, then construct some
temporary before the parallel with array.begin () as initializer
and then do the subtraction between array.end () and that temporary.
Then the parallel, with _Cilk_for immediately in it and just another
temporary scalar as loop iterator there, and only inside of _Cilk_for
declare the iterator var and construct (if it has been declared in _Cilk_for,
otherwise
just initialize it) to, depending on what Cilk+ requires, either to
array.begin () and then operator+ it to the corresponding value, or
construct already to array.begin () + scalariv.
Jakub
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
> As I said, you can't "properly" check it at the point you are checking. > Which is why I complain - you're not checking this properly! This is understood. There is a choice to be made, between an early check (which will benefit our casual users) catching this particular special case, and a later check. I argued for an earlier check, because it was a particular annoying and particularly un-user-friendly error, and wrote the check in a way to minimize the number of false negatives. But, as you say, it is not possible to write a perfect check at that early point. FX
[Ada] Add restrictions to the use of s-tposen
The package s-tposen is used to implement protected objects (with one entry) in the ravenscar profile. In fact, only a subset of the ravenscar profile is required to trigger the use of this package (instead of s-tpoben). This patch adds a restriction to the triggering conditions, in order to simplify the implementation and the interface of s-tposen. No functional change. Tested on x86_64-pc-linux-gnu, committed on trunk 2014-01-31 Tristan Gingold * exp_util.adb (Corresponding_Runtime_Package): Restrict the use of System_Tasking_Protected_Objects_Single_Entry. * exp_ch9.adb (Build_Simple_Entry_Call): Remove Mode parameter of Protected_Single_Entry_Call. (Expand_N_Timed_Entry_Call): Remove single_entry case. * exp_disp.adb (Make_Disp_Asynchronous_Select_Body): Remove single_entry case. (Make_Disp_Timed_Select_Body): Likewise. * rtsfind.ads (RE_Timed_Protected_Single_Entry_Call): Remove. * s-tposen.adb (Send_Program_Error, PO_Do_Or_Queue): Remove Self_Id parameter. (Wakeup_Entry_Caller): Remove Self_ID and New_State parameters. (Wait_For_Completion_With_Timeout): Remove. (Protected_Single_Entry_Call): Remove Mode parameter (always Simple_Call). (Service_Entry): Remove Self_Id constant (not used anymore). (Timed_Protected_Single_Entry_Call): Remove. * s-tposen.ads (Timed_Protected_Single_Entry_Call): Remove. (Protected_Single_Entry_Call): Remove Mode parameter. Index: exp_util.adb === --- exp_util.adb(revision 207348) +++ exp_util.adb(working copy) @@ -1646,6 +1646,7 @@ then if Abort_Allowed or else Restriction_Active (No_Entry_Queue) = False + or else Restriction_Active (No_Select_Statements) = False or else Number_Entries (Typ) > 1 or else (Has_Attach_Handler (Typ) and then not Restricted_Profile) Index: exp_ch9.adb === --- exp_ch9.adb (revision 207348) +++ exp_ch9.adb (working copy) @@ -4682,12 +4682,10 @@ -- family index expressions are evaluated before the entry -- parameters. - if Abort_Allowed - or else Restriction_Active (No_Entry_Queue) = False - or else not Is_Protected_Type (Conctyp) - or else Number_Entries (Conctyp) > 1 - or else (Has_Attach_Handler (Conctyp) - and then not Restricted_Profile) + if not Is_Protected_Type (Conctyp) + or else + Corresponding_Runtime_Package (Conctyp) = + System_Tasking_Protected_Objects_Entries then X := Make_Defining_Identifier (Loc, Name_uX); @@ -4902,8 +4900,7 @@ when System_Tasking_Protected_Objects_Single_Entry => -- Protected_Single_Entry_Call ( -- Object => po._object'Access, - -- Uninterpreted_Data => P'Address; - -- Mode => Simple_Call); + -- Uninterpreted_Data => P'Address); Call := Make_Procedure_Call_Statement (Loc, @@ -4914,8 +4911,7 @@ Make_Attribute_Reference (Loc, Attribute_Name => Name_Unchecked_Access, Prefix => Parm1), -Parm3, -New_Reference_To (RTE (RE_Simple_Call), Loc))); +Parm3)); when others => raise Program_Error; @@ -12481,24 +12477,6 @@ (RTE (RE_Timed_Protected_Entry_Call), Loc), Parameter_Associations => Params)); - when System_Tasking_Protected_Objects_Single_Entry => - Param := First (Params); - while Present (Param) -and then not - Is_RTE (Etype (Param), RE_Protected_Entry_Index) - loop - Next (Param); - end loop; - - Remove (Param); - - Rewrite (Call, -Make_Procedure_Call_Statement (Loc, - Name => -New_Reference_To - (RTE (RE_Timed_Protected_Single_Entry_Call), Loc), - Parameter_Associations => Params)); - when others => raise Program_Error; end case; Index: rtsfind.ads === --- rtsfind.ads (revision 207348) +++ rtsfind.ads (working copy) @@ -1750,7 +1750,6 @@ RE_Exceptional_Complete_Single_Entry_Body, RE_Protected_Count_Entry, -- Protected_Objects.
[Ada] Fix problem with misclassification of references
This patch fixes a problem in the compiler of confusing references
with modifications in the xref listing. This is now fixed properly.
The following program
1. procedure TooManyXrefs is
2.type r is record
3. a : integer;
4.end record;
5.type v is array (1 .. 10) of r;
6.vv : v;
7. begin
8.vv (3).a := 2;
9.TooManyXrefs.vv (3).a := 2;
10. end TooManyXrefs;
Should generate only three references to vv:
6a4 vv{5A9} 8m4 9m17
i.e. the definition and the two references, previously it generated
five references.
Tested on x86_64-pc-linux-gnu, committed on trunk
2014-01-31 Robert Dewar
* exp_ch2.adb: New calling sequence for Is_LHS.
* frontend.adb: Add call to Process_Deferred_References.
* lib-xref.ads, lib-xref.adb (Process_Deferred_References): New.
(Deferred_References): New table.
* sem_ch8.adb (Find_Direct_Name): Make deferred reference table
entries.
(Find_Expanded_Name): Ditto.
* sem_res.adb: New calling sequence for Is_LHS.
* sem_util.ads, sem_util.adb (Is_LHS): New calling sequence.
* sem_warn.adb: Call Process_Deferred_References before issuing
warnings.
Index: frontend.adb
===
--- frontend.adb(revision 207348)
+++ frontend.adb(working copy)
@@ -36,6 +36,7 @@
with Inline; use Inline;
with Lib; use Lib;
with Lib.Load; use Lib.Load;
+with Lib.Xref; use Lib.Xref;
with Live; use Live;
with Namet;use Namet;
with Nlists; use Nlists;
@@ -392,6 +393,7 @@
-- Output waiting warning messages
+ Lib.Xref.Process_Deferred_References;
Sem_Warn.Output_Non_Modified_In_Out_Warnings;
Sem_Warn.Output_Unreferenced_Messages;
Sem_Warn.Check_Unused_Withs;
Index: sem_util.adb
===
--- sem_util.adb(revision 207348)
+++ sem_util.adb(working copy)
@@ -5587,7 +5587,8 @@
-- we exclude overloaded calls, since we don't know enough to be sure
-- of giving the right answer in this case.
- if Is_Entity_Name (Name (Call))
+ if Nkind_In (Call, N_Function_Call, N_Procedure_Call_Statement)
+and then Is_Entity_Name (Name (Call))
and then Present (Entity (Name (Call)))
and then Is_Overloadable (Entity (Name (Call)))
and then not Is_Overloaded (Name (Call))
@@ -9982,14 +9983,18 @@
-- We seem to have a lot of overlapping functions that do similar things
-- (testing for left hand sides or lvalues???).
- function Is_LHS (N : Node_Id) return Boolean is
+ function Is_LHS (N : Node_Id) return Is_LHS_Result is
P : constant Node_Id := Parent (N);
begin
-- Return True if we are the left hand side of an assignment statement
if Nkind (P) = N_Assignment_Statement then
- return Name (P) = N;
+ if Name (P) = N then
+return Yes;
+ else
+return No;
+ end if;
-- Case of prefix of indexed or selected component or slice
@@ -10002,23 +10007,16 @@
-- what we really have is N.all.Q (or N.all(Q .. R)). In either
-- case this makes N.all a left hand side but not N itself.
- -- Here follows a worrisome kludge. If Etype (N) is not set, which
- -- for sure happens in the call from Find_Direct_Name, that means we
- -- don't know if N is of an access type, so we can't give an accurate
- -- answer. For now, we assume we do not have an access type, which
- -- means for example that P.Q.R := X will look like a modification
- -- of P, even if P.Q eventually turns out to be an access type. The
- -- consequence is at least that in some cases we incorrectly identify
- -- a reference as a modification. It is not clear if there are any
- -- other bad consequences. ???
+ -- If we don't know the type yet, this is the case where we return
+ -- Unknown, since the answer depends on the type which is unknown.
if No (Etype (N)) then
-return False;
+return Unknown;
-- We have an Etype set, so we can check it
elsif Is_Access_Type (Etype (N)) then
-return False;
+return No;
-- OK, not access type case, so just test whole expression
@@ -10029,7 +10027,7 @@
-- All other cases are not left hand sides
else
- return False;
+ return No;
end if;
end Is_LHS;
Index: sem_util.ads
===
--- sem_util.ads(revision 207348)
+++ sem_util.ads(working copy)
@@ -1164,8 +1164,15 @@
-- AI05-0139-2: Check whether Typ is one of the predefined interfaces in
-- Ada.Iterator_Interfaces, or i
C++ PATCH for c++/57043 (wrong partial ordering)
We need to loosen the check for an exact match when we're doing partial
ordering, because dealing with dependent types means we can't
instantiate things like typenames to see what they end up being. And
it's not necessary because when we've gotten to partial ordering, we
already know that both candidates are viable.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 99cdae90e846894d63ff11e45ac47a9d1172483b
Author: Jason Merrill
Date: Thu Jan 30 23:29:54 2014 -0500
PR c++/57043
* pt.c (fn_type_unification): Don't do DEDUCE_EXACT check
during partial ordering.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 981e2e0..ae5995b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -15740,8 +15740,11 @@ fn_type_unification (tree fn,
/* If we're looking for an exact match, check that what we got
is indeed an exact match. It might not be if some template
- parameters are used in non-deduced contexts. */
- if (strict == DEDUCE_EXACT)
+ parameters are used in non-deduced contexts. But don't check
+ for an exact match if we have dependent template arguments;
+ in that case we're doing partial ordering, and we already know
+ that we have two candidates that will provide the actual type. */
+ if (strict == DEDUCE_EXACT && !any_dependent_template_arguments_p (targs))
{
tree substed = TREE_TYPE (decl);
unsigned int i;
diff --git a/gcc/testsuite/g++.dg/template/partial15.C b/gcc/testsuite/g++.dg/template/partial15.C
new file mode 100644
index 000..357bb05
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/partial15.C
@@ -0,0 +1,19 @@
+// PR c++/57043
+// { dg-do link }
+
+template struct complex { };
+
+template
+complex
+pow(const complex& x, const complex& y) { return complex(); }
+
+template
+struct promote_2 { typedef T type; };
+
+template
+complex::type>
+pow(const complex& x, const complex& y);
+
+complex (*powcc)(const complex&, const complex&) = pow;
+
+int main() {}
C++ PATCH for c++/59646 (ICE with volatile initializer_list)
We were failing to set TARGET_EXPR_LIST_INIT_P on a TARGET_EXPR created
from aggregate initialization, which is needed to avoid calling the copy
constructor when using that TARGET_EXPR to initialize the element of the
underlying array of the initializer_list.
We also should avoid building a CONSTRUCTOR with an error_mark_node
inside it.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit a4cdb0d20f4f81b8c265ff5d10f676d09c48edd1
Author: Jason Merrill
Date: Fri Jan 31 09:39:13 2014 -0500
PR c++/59646
* call.c (convert_like_real) [ck_aggr]: Set TARGET_EXPR_LIST_INIT_P.
[ck_list]: Check for error_mark_node.
(build_aggr_conv): Set LOOKUP_NO_NARROWING and check_narrowing.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 71f95db..d4e8a28 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -886,6 +886,8 @@ build_aggr_conv (tree type, tree ctor, int flags, tsubst_flags_t complain)
if (ctor == error_mark_node)
return NULL;
+ flags |= LOOKUP_NO_NARROWING;
+
for (; field; field = next_initializable_field (DECL_CHAIN (field)))
{
tree ftype = TREE_TYPE (field);
@@ -926,6 +928,7 @@ build_aggr_conv (tree type, tree ctor, int flags, tsubst_flags_t complain)
c->type = type;
c->rank = cr_exact;
c->user_conv_p = true;
+ c->check_narrowing = true;
c->u.next = NULL;
return c;
}
@@ -6111,6 +6114,8 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
to avoid the error about taking the address of a temporary. */
array = cp_build_addr_expr (array, complain);
array = cp_convert (build_pointer_type (elttype), array, complain);
+ if (array == error_mark_node)
+ return error_mark_node;
/* Build up the initializer_list object. */
totype = complete_type (totype);
@@ -6135,8 +6140,11 @@ convert_like_real (conversion *convs, tree expr, tree fn, int argnum,
return fold_if_not_in_template (expr);
}
expr = reshape_init (totype, expr, complain);
- return get_target_expr_sfinae (digest_init (totype, expr, complain),
+ expr = get_target_expr_sfinae (digest_init (totype, expr, complain),
complain);
+ if (expr != error_mark_node)
+ TARGET_EXPR_LIST_INIT_P (expr) = true;
+ return expr;
default:
break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist79.C b/gcc/testsuite/g++.dg/cpp0x/initlist79.C
new file mode 100644
index 000..5a1914d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist79.C
@@ -0,0 +1,8 @@
+// PR c++/59646
+// { dg-require-effective-target c++11 }
+
+#include
+
+struct A {};
+
+std::initializer_list x = {{}};
RE: [PING] [PATCH] _Cilk_for for C and C++
Hello Everyone,
Did anyone get a chance to look at this patch (link to patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01612.html)? I tried to do as
Jakub mentioned but it hits a road-block when it comes to iterators due to
variable scoping issues.
This patch does not disrupt any other parts of the code and all the
code here are wrapped inside a check for for Cilk Plus enabling. It also passes
all the tests and does not disrupt any existing failing or passing ones for
both 32 and 64 bit modes in my x86_64 machine.
It is the last feature to make Cilk Plus feature-complete. Is the patch OK for
trunk?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Wednesday, January 29, 2014 10:54 AM
> To: Jakub Jelinek
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: RE: [PING] [PATCH] _Cilk_for for C and C++
>
> Hi Jakub,
>
> > -Original Message-
> > From: Jakub Jelinek [mailto:ja...@redhat.com]
> > Sent: Wednesday, January 29, 2014 6:31 AM
> > To: Iyer, Balaji V
> > Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez';
> > 'gcc-patches@gcc.gnu.org'; 'r...@redhat.com'
> > Subject: Re: [PING] [PATCH] _Cilk_for for C and C++
> >
> > On Tue, Jan 28, 2014 at 04:55:38PM +, Iyer, Balaji V wrote:
> > > I thought about it a bit more, and the main issue here is that we
> > > need access to the _Cilk_for loop's components both inside the child
> > > function and the parent function.
> >
> > I guess for the C++ iterators, if in the _Cilk_for model you need to
> > provide number of iterations before parallelization, it really depends
> > on what the standard allows and what you want to do exactly.
>
> Yes, I need the value before the parallelization context hits. This is why in
> my
> last patch I had the parallel around the body and omp for around the _Cilk-
> for statement.
>
>
> > If you need to provide the iteration count before spawning the threads
> > and the standard allows you that, then just lower it in the C++ FE
> > already so that you do:
> > vector::iterator temp = array.begin ();
> > sizetype tempcount = (array.end () - temp); before the parallel, and then
> > #pragma omp parallel firstprivate(temp, tempcount)
> > _Cilk_for (sizetype temp2 = 0; temp2 < tempcount; temp2++)
> > {
> > vector::iterator ii = temp + temp2;
> >
> > }
>
> This is kind of what I did (atlest tried to accomplish what you mentioned
> above). I can look into doing this, but is it possible for you to accept the
> patch
> as-is and we will look into fixing it in the future?
>
> Thanks,
>
> Balaji V. Iyer.
>
> > or similar. The C++ FE needs to lower the C++ iterators anyway, the
> > middle- end can really only work with integral or pointer iterators,
> > and it depends on how exactly the Cilk+ standard defines _Cilk_for
> > with iterators (what methods must be implemented on the iterators and
> > what methods and in what order should be called).
> >
> > Jakub
Re: PR ipa/59831 (ipa-cp devirt issues)
On 2014.01.31 at 07:22 +0100, Jan Hubicka wrote:
> +tree
> +vtable_pointer_value_to_binfo (tree t)
> +{
> + /* We expect &MEM[(void *)&virtual_table + 16B].
> + We obtain object's BINFO from the context of the virtual table.
> + This one contains pointer to virtual table represented via
> + POINTER_PLUS_EXPR. Verify that this pointer match to what
> + we propagated through.
> +
> + In the case of virtual inheritance, the virtual tables may
> + be nested, i.e. the offset may be different from 16 and we may
> + need to dive into the type representation. */
> + if (t && TREE_CODE (t) == ADDR_EXPR
> + && TREE_CODE (TREE_OPERAND (t, 0)) == MEM_REF
> + && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 0)) == ADDR_EXPR
> + && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 1)) == INTEGER_CST
> + && (TREE_CODE (TREE_OPERAND (TREE_OPERAND (TREE_OPERAND (t, 0), 0), 0))
> + == VAR_DECL)
> + && DECL_VIRTUAL_P (TREE_OPERAND (TREE_OPERAND
> + (TREE_OPERAND (t, 0), 0), 0)))
> +{
> + tree vtable = TREE_OPERAND (TREE_OPERAND (TREE_OPERAND (t, 0), 0), 0);
> + tree offset = TREE_OPERAND (TREE_OPERAND (t, 0), 1);
> + tree binfo = TYPE_BINFO (DECL_CONTEXT (vtable));
> +
> + binfo = subbinfo_with_vtable_at_offset (binfo, offset, vtable);
> + gcc_assert (binfo);
> + return binfo;
> +}
> + return NULL;
> +}
I've tested your patch a little bit and hit the gcc_assert above:
markus@x4 tmp % cat test.ii
class A {
public:
unsigned length;
};
class B {};
class MultiTermDocs : public virtual B {
protected:
A readerTermDocs;
A subReaders;
virtual B *m_fn1(int *);
virtual ~MultiTermDocs();
};
class C : MultiTermDocs {
B *m_fn1(int *);
};
MultiTermDocs::~MultiTermDocs() {
if (&readerTermDocs) {
B *a;
for (unsigned i = 0; i < subReaders.length; i++)
(a != 0);
}
}
B *C::m_fn1(int *) { return 0; }
markus@x4 tmp % g++ -O2 test.ii
test.ii: In destructor ‘virtual C::~C()’:
test.ii:24:32: internal compiler error: in vtable_pointer_value_to_binfo, at
ipa-devirt.c:1082
B *C::m_fn1(int *) { return 0; }
^
0x9ca774 vtable_pointer_value_to_binfo(tree_node*)
../../gcc/gcc/ipa-devirt.c:1082
0x9e22b9 extr_type_from_vtbl_ptr_store
../../gcc/gcc/ipa-prop.c:606
0x9e22b9 check_stmt_for_type_change
../../gcc/gcc/ipa-prop.c:648
0xc18343 walk_aliased_vdefs_1
../../gcc/gcc/tree-ssa-alias.c:2472
0xc1846d walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*, tree_node*,
void*), void*, bitmap_head**)
../../gcc/gcc/tree-ssa-alias.c:2491
0x9e1cba detect_type_change
../../gcc/gcc/ipa-prop.c:702
0x9e8b63 compute_complex_assign_jump_func
../../gcc/gcc/ipa-prop.c:1089
0x9e8b63 ipa_compute_jump_functions_for_edge
../../gcc/gcc/ipa-prop.c:1635
0x9eb882 ipa_compute_jump_functions
../../gcc/gcc/ipa-prop.c:1675
0x9eb882 ipa_analyze_node(cgraph_node*)
../../gcc/gcc/ipa-prop.c:2212
0x103ea7f ipcp_generate_summary
../../gcc/gcc/ipa-cp.c:3709
0xaa4906 execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc/gcc/passes.c:2027
0x833dbb ipa_passes
../../gcc/gcc/cgraphunit.c:2070
0x833dbb compile()
../../gcc/gcc/cgraphunit.c:2174
0x834304 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2329
0x62efce cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4447
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
--
Markus
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
On Fri, Jan 31, 2014 at 3:45 PM, FX wrote: >> I've just seen that an explicit --enable-multilib is a way to do that. > > Yes, I was writing that as a reply when I received your email. (Also, it's > written in the configure error message.) Yeah - you know, that message is quite long and somehow I didn't read it carefully. I suspect that will happen to others, too, so we'll get some extra complaints from that ;) >> Btw, doing the configure check exactly after all-stage1-gcc should be >> an early enough and a serialization point, no? There you can do the >> check even for when cross-compiling. > > Well, you've already built a whole stage, so it's not so early, is it? Well, building the stage1 compiler is probably the fastest thing nowadays (it didn't yet build the target libraries for stage1 with the stage1, unoptimized and checking-enabled compiler - which is where it would fail in the odd way which is what you want to improve). As I said, you can't "properly" check it at the point you are checking. Which is why I complain - you're not checking this properly! Anyway, I've fixed the "bug" on our side with --enable-multilib. Richard. > > FX
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
> I've just seen that an explicit --enable-multilib is a way to do that. Yes, I was writing that as a reply when I received your email. (Also, it’s written in the configure error message.) > Btw, doing the configure check exactly after all-stage1-gcc should be > an early enough and a serialization point, no? There you can do the > check even for when cross-compiling. Well, you’ve already built a whole stage, so it’s not so early, is it? FX
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
On Fri, Jan 31, 2014 at 3:40 PM, Richard Biener
wrote:
> On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener
> wrote:
>> On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
The patch is okay, but if other architecture maintainers could add
similar checks for their ports (SPARC and PPC, I guess), it would be nice.
>>>
>>> Thanks, committed as rev. 205975
>>>
>>> Adding other systems to the list of checks will be easy, once the
>>> maintainers confirm that they want to opt in into it.
>>
>> In our default build environment for package building GCC no longer builds
>> because of this:
>>
>> [ 152s]
>> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/
>> ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc.a when
>> sea
>> rching for -lgcc
>> [ 152s]
>> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/
>> ld: cannot find -lgcc
>> [ 152s]
>> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
>> skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc_s.so
>> when searching for -lgcc_s
>> [ 152s]
>> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
>> cannot find -lgcc_s
>> [ 152s] collect2: error: ld returned 1 exit status
>> [ 152s] configure: error: I suspect your system does not have 32-bit
>> developement libraries (libc and headers). If you have them, rerun
>> configure with --enable-multilib. If you do not have them, and want to
>> build a 64-bit-only compiler, rerun configure with --disable-multilib.
>>
>> the issue is that while we do have 32bit glibc support installed but not all
>> required files for the host compiler to produce 32bit executables - which
>> isn't needed - the compiler we bootstrap will have all the support for this.
>>
>> In fact, a x86_64 multilib GCC can be just bootstrapped fine with a
>> non-multilib x86_64 compiler which you also disallow with the above check.
>>
>> I don't see how you can do this configure check in its current form early,
>> before you've built the stage1 compiler.
>>
>> So - please consider reverting this patch or at least provide a way to
>> override the check.
>
> I've just seen that an explicit --enable-multilib is a way to do that.
>
> Still I think this is odd behavior - as you are matching x86_64-*linux
> you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know
> of any distribution where you can have the header package installed
> without the corresponding libraries.
Btw, doing the configure check exactly after all-stage1-gcc should be
an early enough and a serialization point, no? There you can do the
check even for when cross-compiling.
Richard.
> Richard.
>
>> Thanks,
>> Richard.
>>
>>
>>
>>> FX
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener
wrote:
> On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
>>> The patch is okay, but if other architecture maintainers could add
>>> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
>>
>> Thanks, committed as rev. 205975
>>
>> Adding other systems to the list of checks will be easy, once the
>> maintainers confirm that they want to opt in into it.
>
> In our default build environment for package building GCC no longer builds
> because of this:
>
> [ 152s]
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/
> ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc.a when
> sea
> rching for -lgcc
> [ 152s]
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/
> ld: cannot find -lgcc
> [ 152s]
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc_s.so
> when searching for -lgcc_s
> [ 152s]
> /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld:
> cannot find -lgcc_s
> [ 152s] collect2: error: ld returned 1 exit status
> [ 152s] configure: error: I suspect your system does not have 32-bit
> developement libraries (libc and headers). If you have them, rerun
> configure with --enable-multilib. If you do not have them, and want to
> build a 64-bit-only compiler, rerun configure with --disable-multilib.
>
> the issue is that while we do have 32bit glibc support installed but not all
> required files for the host compiler to produce 32bit executables - which
> isn't needed - the compiler we bootstrap will have all the support for this.
>
> In fact, a x86_64 multilib GCC can be just bootstrapped fine with a
> non-multilib x86_64 compiler which you also disallow with the above check.
>
> I don't see how you can do this configure check in its current form early,
> before you've built the stage1 compiler.
>
> So - please consider reverting this patch or at least provide a way to
> override the check.
I've just seen that an explicit --enable-multilib is a way to do that.
Still I think this is odd behavior - as you are matching x86_64-*linux
you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know
of any distribution where you can have the header package installed
without the corresponding libraries.
Richard.
> Thanks,
> Richard.
>
>
>
>> FX
Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets
On Fri, Dec 13, 2013 at 10:47 PM, FX wrote: >> The patch is okay, but if other architecture maintainers could add >> similar checks for their ports (SPARC and PPC, I guess), it would be nice. > > Thanks, committed as rev. 205975 > > Adding other systems to the list of checks will be easy, once the maintainers > confirm that they want to opt in into it. In our default build environment for package building GCC no longer builds because of this: [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc.a when sea rching for -lgcc [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ ld: cannot find -lgcc [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.8/libgcc_s.so when searching for -lgcc_s [ 152s] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc_s [ 152s] collect2: error: ld returned 1 exit status [ 152s] configure: error: I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib. the issue is that while we do have 32bit glibc support installed but not all required files for the host compiler to produce 32bit executables - which isn't needed - the compiler we bootstrap will have all the support for this. In fact, a x86_64 multilib GCC can be just bootstrapped fine with a non-multilib x86_64 compiler which you also disallow with the above check. I don't see how you can do this configure check in its current form early, before you've built the stage1 compiler. So - please consider reverting this patch or at least provide a way to override the check. Thanks, Richard. > FX
Re: [C++ patch] for c++/37140
2014-01-28 Jason Merrill :
> On 01/27/2014 04:28 PM, Fabien Chêne wrote:
>>
>> + if (DECL_DEPENDENT_P (decl) && USING_DECL_TYPENAME_P (decl))
>> +{
>> + /* We have found a type introduced by a using
>> +declaration at class scope that refers to a dependent
>> +type.
>> +
>> +using typename :: [opt] nested-name-specifier unqualified-id ;
>> + */
>> + decl = make_typename_type (TREE_TYPE (decl),
>> +DECL_NAME (decl),
>> +typename_type, tf_error);
>> + if (decl != error_mark_node)
>> + decl = TYPE_NAME (decl);
>> +
>> + return decl;
>> +}
>> +
>> while (TREE_CODE (decl) == USING_DECL && !DECL_DEPENDENT_P (decl))
>> decl = USING_DECL_DECLS (decl);
>
>
> Shouldn't the new code be after the while loop?
Actually, as a non-dependent USING_DECL may refer to a dependent one,
that would make sense.
I have failed however to find a testcase where the code above does not
work, probably because as in the example below, a non-dependent
USING_DECL refering to a dependent one implicitly requires the base
class to be parsed before, so that the instanciation can be performed.
Thus, the typename_type is already created.
template struct B
{
typedef char type;
};
template struct C : B
{
using typename B::type;
};
struct D : C
{
using C::type;
type z;
};
Anyway, your suggestion makes sense to me, and I have successfully
tested the attached patch on x86_64 linux.
2014-01-31 Fabien Chêne
PR c++/37140
* parser.c (cp_parser_nonclass_name): Call strip_using_decl and
move the code handling dependent USING_DECLs...
* name-lookup.c (strip_using_decl): ...Here.
2014-01-31 Fabien Chêne
PR c++/37140
* g++.dg/template/using27.C: New.
* g++.dg/template/using28.C: New.
* g++.dg/template/using29.C: New.
--
Fabien
Index: gcc/testsuite/g++.dg/template/using27.C
===
--- gcc/testsuite/g++.dg/template/using27.C (revision 0)
+++ gcc/testsuite/g++.dg/template/using27.C (revision 0)
@@ -0,0 +1,33 @@
+// PR c++/37140
+
+struct X
+{
+ typedef int nested_type;
+};
+
+template
+struct A
+{
+ typedef X type;
+};
+
+template
+struct B : A
+{
+ using typename A::type;
+ typename type::nested_type x;
+};
+
+template
+struct C : B
+{
+ using typename B::type;
+ typename type::nested_type y;
+};
+
+struct D : C
+{
+ using C::type;
+ type::nested_type z;
+};
+
Index: gcc/testsuite/g++.dg/template/using29.C
===
--- gcc/testsuite/g++.dg/template/using29.C (revision 0)
+++ gcc/testsuite/g++.dg/template/using29.C (revision 0)
@@ -0,0 +1,21 @@
+// PR c++/58047
+
+template
+struct print_arg { };
+
+struct const_holder {
+ static const int CONSTANT = 42;
+};
+
+template
+struct identity {
+ typedef T type;
+};
+
+template
+struct test_case : public identity {
+ using typename identity::type;
+ print_arg printer;
+};
+
+template struct test_case;
Index: gcc/testsuite/g++.dg/template/using28.C
===
--- gcc/testsuite/g++.dg/template/using28.C (revision 0)
+++ gcc/testsuite/g++.dg/template/using28.C (revision 0)
@@ -0,0 +1,17 @@
+// PR c++/37140
+
+struct C
+{
+ static const int block_size = 1;
+};
+
+template struct A {
+ typedef C type;
+};
+
+template struct B : public A {
+ using typename A::type;
+ static const int block_size = type::block_size;
+};
+
+template class B;
Index: gcc/cp/name-lookup.c
===
--- gcc/cp/name-lookup.c (revision 207035)
+++ gcc/cp/name-lookup.c (working copy)
@@ -406,7 +406,8 @@ pop_bindings_and_leave_scope (void)
leave_scope ();
}
-/* Strip non dependent using declarations. */
+/* Strip non dependent using declarations. If DECL is dependent,
+ surreptitiously create a typename_type and return it. */
tree
strip_using_decl (tree decl)
@@ -416,6 +417,23 @@ strip_using_decl (tree decl)
while (TREE_CODE (decl) == USING_DECL && !DECL_DEPENDENT_P (decl))
decl = USING_DECL_DECLS (decl);
+
+ if (TREE_CODE (decl) == USING_DECL && DECL_DEPENDENT_P (decl)
+ && USING_DECL_TYPENAME_P (decl))
+{
+ /* We have found a type introduced by a using
+ declaration at class scope that refers to a dependent
+ type.
+
+ using typename :: [opt] nested-name-specifier unqualified-id ;
+ */
+ decl = make_typename_type (TREE_TYPE (decl),
+ DECL_NAME (decl),
+ typename_type, tf_error);
+ if (decl != error_mark_node)
+ decl = TYPE_NAME (decl);
+}
+
return decl;
}
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 207035)
+++ gcc/cp/parser.c (working copy)
@@ -14824,25 +14824,7 @@ cp_parser_nonclass_name (cp_parser* pars
/* Look up
Re: [PATCH] Don't run tsan tests if a trivial test doesn't work
On Fri, Jan 31, 2014 at 02:57:14PM +0100, Richard Biener wrote: > Ok (you remove one target selector - was that spurious) Yes, tsan is supported on x86_64-linux only anyway, so tsan_init fails everywhere else. Jakub
PATCH: Add -mlong-double-128 and make it default for 64-bit Bionic
Hi,
For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
-mlong-double-64 and -mlong-double-80 negate each other so that the
last one on command line wins. It os OK since we don't support
-mlong-double-xxx in target attribute. I added some testcases to verify
it works correctly. OK for trunk?
Thanks.
H.J.
---
gcc/
2014-01-30 H.J. Lu
* config/i386/i386.c (flag_opts): Add -mlong-double-128.
(ix86_option_override_internal): Default long double to 64-bit for
32-bit Bionic and to 128-bit for 64-bit Bionic.
* config/i386/i386.h (LONG_DOUBLE_TYPE_SIZE): Use 128 if
TARGET_LONG_DOUBLE_128 is true.
(LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Likewise.
* config/i386/i386.opt (mlong-double-80): Negate -mlong-double-64.
(mlong-double-64): Negate -mlong-double-128.
(mlong-double-128): New option.
* config/i386/i386-c.c (ix86_target_macros): Define
__LONG_DOUBLE_128__ for TARGET_LONG_DOUBLE_128.
* doc/invoke.texi: Document -mlong-double-128.
gcc/testsuite/
2014-01-30 H.J. Lu
* gcc.target/i386/long-double-64-1.c: Verify __multf3 isn't used.
* gcc.target/i386/long-double-64-4.c: Likewise.
* gcc.target/i386/long-double-80-1.c: Likewise.
* gcc.target/i386/long-double-80-2.c: Likewise.
* gcc.target/i386/long-double-80-3.c: Likewise.
* gcc.target/i386/long-double-80-4.c: Likewise.
* gcc.target/i386/long-double-80-5.c: Likewise.
* gcc.target/i386/long-double-64-2.c: Limit to ia32. Verify
__multf3 isn't used.
* gcc.target/i386/long-double-64-3.c: Likewise.
* gcc.target/i386/long-double-128-1.c: New test.
* gcc.target/i386/long-double-128-2.c: Likewise.
* gcc.target/i386/long-double-128-3.c: Likewise.
* gcc.target/i386/long-double-128-4.c: Likewise.
* gcc.target/i386/long-double-128-5.c: Likewise.
* gcc.target/i386/long-double-128-6.c: Likewise.
* gcc.target/i386/long-double-128-7.c: Likewise.
* gcc.target/i386/long-double-128-8.c: Likewise.
* gcc.target/i386/long-double-128-9.c: Likewise.
* gcc.target/i386/long-double-64-5.c: Likewise.
* gcc.target/i386/long-double-64-6.c: Likewise.
* gcc.target/i386/long-double-64-7.c: Likewise.
* gcc.target/i386/long-double-64-8.c: Likewise.
* gcc.target/i386/long-double-64-9.c: Likewise.
* gcc.target/i386/long-double-80-10.c: Likewise.
* gcc.target/i386/long-double-80-8.c: Likewise.
* gcc.target/i386/long-double-80-9.c: Likewise.
diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
index ee83de6..0c50720 100644
--- a/gcc/config/i386/i386-c.c
+++ b/gcc/config/i386/i386-c.c
@@ -513,6 +513,9 @@ ix86_target_macros (void)
if (TARGET_LONG_DOUBLE_64)
cpp_define (parse_in, "__LONG_DOUBLE_64__");
+ if (TARGET_LONG_DOUBLE_128)
+cpp_define (parse_in, "__LONG_DOUBLE_128__");
+
cpp_define_formatted (parse_in, "__ATOMIC_HLE_ACQUIRE=%d", IX86_HLE_ACQUIRE);
cpp_define_formatted (parse_in, "__ATOMIC_HLE_RELEASE=%d", IX86_HLE_RELEASE);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 1e65743..3a01b6e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2628,6 +2628,7 @@ ix86_target_string (HOST_WIDE_INT isa, int flags, const
char *arch,
static struct ix86_target_opts flag_opts[] =
{
{ "-m128bit-long-double", MASK_128BIT_LONG_DOUBLE },
+{ "-mlong-double-128", MASK_LONG_DOUBLE_128 },
{ "-mlong-double-64", MASK_LONG_DOUBLE_64 },
{ "-m80387", MASK_80387 },
{ "-maccumulate-outgoing-args",MASK_ACCUMULATE_OUTGOING_ARGS },
@@ -4195,10 +4196,18 @@ ix86_option_override_internal (bool main_args_p,
else if (opts_set->x_target_flags & MASK_RECIP)
opts->x_recip_mask &= ~(RECIP_MASK_ALL & ~opts->x_recip_mask_explicit);
- /* Default long double to 64-bit for Bionic. */
+ /* Default long double to 64-bit for 32-bit Bionic and to __float128
+ for 64-bit Bionic. */
if (TARGET_HAS_BIONIC
- && !(opts_set->x_target_flags & MASK_LONG_DOUBLE_64))
-opts->x_target_flags |= MASK_LONG_DOUBLE_64;
+ && !(opts_set->x_target_flags
+ & (MASK_LONG_DOUBLE_64 | MASK_LONG_DOUBLE_128)))
+opts->x_target_flags |= (TARGET_64BIT
+? MASK_LONG_DOUBLE_128
+: MASK_LONG_DOUBLE_64);
+
+ /* Only one of them can be active. */
+ gcc_assert ((opts->x_target_flags & MASK_LONG_DOUBLE_64) == 0
+ || (opts->x_target_flags & MASK_LONG_DOUBLE_128) == 0);
/* Save the initial options in case the user does function specific
options. */
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index bfb6d
Re: [PATCH] Don't run tsan tests if a trivial test doesn't work
On Fri, 31 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 31, 2014 at 12:34:46PM +0100, Jakub Jelinek wrote:
> > Apparently tsan doesn't work e.g. under setarch x86_64 -R, at which point
> > all tests fail. This patch just disables the tests in that case.
> >
> > Tested on x86_64-linux both under setarch x86_64 -R and without, committed
> > to trunk as obvious.
> >
> > Of course it would be nicer if libtsan actually supported that (and didn't
> > rely on PIEs etc.), but I don't see that as a priority for upstream :(.
> >
> > 2014-01-31 Jakub Jelinek
> >
> > * lib/tsan-dg.exp (tsan_init): Try to run a trivial program,
> > if it fails don't run any tsan tests.
>
> As discussed on IRC, some people would like to have tsan tests at least
> as compile tests if they can't be reliably executed.
>
> So, this patch implements that by tweaking dg-do-what default.
>
> Ok for trunk?
Ok (you remove one target selector - was that spurious)
Thanks,
Richard.
> 2014-01-31 Jakub Jelinek
>
> PR sanitizer/59410
> * lib/tsan-dg.exp (tsan_init): Instead of not running any
> tsan tests if trivial testcase doesn't run, set dg-do-what-default
> to compile.
> (tsan_finish): Restore dg-do-what-default.
> * g++.dg/tsan/atomic_free.C: Remove dg-do line.
> * g++.dg/tsan/fd_close_norace2.C: Likewise.
> * g++.dg/tsan/default_options.C: Likewise.
> * g++.dg/tsan/aligned_vs_unaligned_race.C: Likewise.
> * g++.dg/tsan/atomic_free2.C: Likewise.
> * g++.dg/tsan/cond_race.C: Likewise.
> * g++.dg/tsan/fd_close_norace.C: Likewise.
> * g++.dg/tsan/benign_race.C: Likewise.
> * c-c++-common/tsan/fd_pipe_race.c: Likewise.
> * c-c++-common/tsan/simple_race.c: Likewise.
> * c-c++-common/tsan/mutexset1.c: Likewise.
> * c-c++-common/tsan/thread_leak2.c: Likewise.
> * c-c++-common/tsan/tls_race.c: Likewise.
> * c-c++-common/tsan/write_in_reader_lock.c: Likewise.
> * c-c++-common/tsan/race_on_barrier2.c: Likewise.
> * c-c++-common/tsan/free_race2.c: Likewise.
> * c-c++-common/tsan/thread_leak.c: Likewise.
> * c-c++-common/tsan/thread_leak1.c: Likewise.
> * c-c++-common/tsan/race_on_barrier.c: Likewise.
> * c-c++-common/tsan/free_race.c: Likewise.
> * c-c++-common/tsan/sleep_sync.c: Likewise.
> * c-c++-common/tsan/tiny_race.c: Likewise.
> * c-c++-common/tsan/race_on_mutex2.c: Likewise.
> * c-c++-common/tsan/atomic_stack.c: Likewise.
> * c-c++-common/tsan/race_on_mutex.c: Likewise. Adjust line numbers
> in dg-output regexps.
> * c-c++-common/tsan/simple_stack.c: Likewise.
>
> --- gcc/testsuite/lib/tsan-dg.exp.jj 2014-01-31 12:30:09.0 +0100
> +++ gcc/testsuite/lib/tsan-dg.exp 2014-01-31 13:21:26.350586160 +0100
> @@ -69,6 +69,8 @@ proc tsan_init { args } {
> global ALWAYS_CXXFLAGS
> global TOOL_OPTIONS
> global tsan_saved_TEST_ALWAYS_FLAGS
> +global dg-do-what-default
> +global tsan_saved_dg-do-what-default
>
> set link_flags ""
> if ![is_remote host] {
> @@ -79,6 +81,9 @@ proc tsan_init { args } {
> }
> }
>
> +if [info exists dg-do-what-default] {
> + set tsan_saved-dg-do-what-default dg-do-what-default
> +}
> if [info exists TEST_ALWAYS_FLAGS] {
> set tsan_saved_TEST_ALWAYS_FLAGS $TEST_ALWAYS_FLAGS
> }
> @@ -96,8 +101,11 @@ proc tsan_init { args } {
> if [check_runtime_nocache tsan_works {
> int main () { return 0; }
> } "-fPIE -pie -fsanitize=thread -g"] {
> - return 1
> + set dg-do-what-default run
> + } else {
> + set dg-do-what-default compile
> }
> + return 1
> }
> return 0
> }
> @@ -109,10 +117,17 @@ proc tsan_init { args } {
> proc tsan_finish { args } {
> global TEST_ALWAYS_FLAGS
> global tsan_saved_TEST_ALWAYS_FLAGS
> +global dg-do-what-default
> +global tsan_saved_dg-do-what-default
>
> if [info exists tsan_saved_TEST_ALWAYS_FLAGS] {
> set TEST_ALWAYS_FLAGS $tsan_saved_TEST_ALWAYS_FLAGS
> } else {
> unset TEST_ALWAYS_FLAGS
> }
> +if [info exists tsan_saved-dg-do-what-default] {
> + set dg-do-what-default tsan_saved-dg-do-what-default
> +} else {
> + unset dg-do-what-default
> +}
> }
> --- gcc/testsuite/g++.dg/tsan/atomic_free.C.jj2013-12-12
> 14:28:31.0 +0100
> +++ gcc/testsuite/g++.dg/tsan/atomic_free.C 2014-01-31 13:15:25.110473518
> +0100
> @@ -1,4 +1,3 @@
> -/* { dg-do run } */
> /* { dg-shouldfail "tsan" } */
>
> #include
> --- gcc/testsuite/g++.dg/tsan/fd_close_norace2.C.jj 2013-12-12
> 14:28:31.0 +0100
> +++ gcc/testsuite/g++.dg/tsan/fd_close_norace2.C 2014-01-31
> 13:15:30.882443238 +0100
> @@ -1,5 +1,3 @@
> -/* { dg-do run } */
> -
> #include
> #include
> #include
> --- gcc/testsuite/g++.dg/tsan/default_options.C.jj2013-12-12
> 14:28:31.00
Re: [PATCH] TILE-Gx: add release note on tilegx big endian support in wwwdocs
On Thu, 30 Jan 2014, Walter Lee wrote: > Here is a release note item for big endian support on tilegx. Ok to > commit once that change is approved? Yes. If you like, you could also mention the new command-line options or if there is anything around configuration options. And as maintainer of the port and you don't need approval for documentation or web page changes like this. Gerald
Re: [PATCH] Fixing PR60000: A bug in the vectorizer.
On Fri, Jan 31, 2014 at 09:41:59AM +0100, Richard Biener wrote:
> Is that because si and pattern_def_si point to the same stmts? Then
> I'd prefer to do
>
> if (is_store)
>{
> ...
> pattern_def_seq = NULL;
>}
> else if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
>{
> pattern_def_seq = NULL;
> gsi_next (&si);
>}
Yeah, I think stores can only appear at the end of patterns, so IMHO it should
be
safe to just clear pattern_def_seq always in that case. Right now the code
has continue; separately for STMT_VINFO_GROUPED_ACCESS (stmt_info) and
for !STMT_VINFO_GROUPED_ACCESS (stmt_info) stores, but I guess you should
just move them at the end of if (is_store) and clear pattern_def_seq there
before the continue. Add gcc_assert (!transform_pattern_stmt); too?
Jakub
Re: [PATCH] Don't run tsan tests if a trivial test doesn't work
On Fri, Jan 31, 2014 at 12:34:46PM +0100, Jakub Jelinek wrote:
> Apparently tsan doesn't work e.g. under setarch x86_64 -R, at which point
> all tests fail. This patch just disables the tests in that case.
>
> Tested on x86_64-linux both under setarch x86_64 -R and without, committed
> to trunk as obvious.
>
> Of course it would be nicer if libtsan actually supported that (and didn't
> rely on PIEs etc.), but I don't see that as a priority for upstream :(.
>
> 2014-01-31 Jakub Jelinek
>
> * lib/tsan-dg.exp (tsan_init): Try to run a trivial program,
> if it fails don't run any tsan tests.
As discussed on IRC, some people would like to have tsan tests at least
as compile tests if they can't be reliably executed.
So, this patch implements that by tweaking dg-do-what default.
Ok for trunk?
2014-01-31 Jakub Jelinek
PR sanitizer/59410
* lib/tsan-dg.exp (tsan_init): Instead of not running any
tsan tests if trivial testcase doesn't run, set dg-do-what-default
to compile.
(tsan_finish): Restore dg-do-what-default.
* g++.dg/tsan/atomic_free.C: Remove dg-do line.
* g++.dg/tsan/fd_close_norace2.C: Likewise.
* g++.dg/tsan/default_options.C: Likewise.
* g++.dg/tsan/aligned_vs_unaligned_race.C: Likewise.
* g++.dg/tsan/atomic_free2.C: Likewise.
* g++.dg/tsan/cond_race.C: Likewise.
* g++.dg/tsan/fd_close_norace.C: Likewise.
* g++.dg/tsan/benign_race.C: Likewise.
* c-c++-common/tsan/fd_pipe_race.c: Likewise.
* c-c++-common/tsan/simple_race.c: Likewise.
* c-c++-common/tsan/mutexset1.c: Likewise.
* c-c++-common/tsan/thread_leak2.c: Likewise.
* c-c++-common/tsan/tls_race.c: Likewise.
* c-c++-common/tsan/write_in_reader_lock.c: Likewise.
* c-c++-common/tsan/race_on_barrier2.c: Likewise.
* c-c++-common/tsan/free_race2.c: Likewise.
* c-c++-common/tsan/thread_leak.c: Likewise.
* c-c++-common/tsan/thread_leak1.c: Likewise.
* c-c++-common/tsan/race_on_barrier.c: Likewise.
* c-c++-common/tsan/free_race.c: Likewise.
* c-c++-common/tsan/sleep_sync.c: Likewise.
* c-c++-common/tsan/tiny_race.c: Likewise.
* c-c++-common/tsan/race_on_mutex2.c: Likewise.
* c-c++-common/tsan/atomic_stack.c: Likewise.
* c-c++-common/tsan/race_on_mutex.c: Likewise. Adjust line numbers
in dg-output regexps.
* c-c++-common/tsan/simple_stack.c: Likewise.
--- gcc/testsuite/lib/tsan-dg.exp.jj2014-01-31 12:30:09.0 +0100
+++ gcc/testsuite/lib/tsan-dg.exp 2014-01-31 13:21:26.350586160 +0100
@@ -69,6 +69,8 @@ proc tsan_init { args } {
global ALWAYS_CXXFLAGS
global TOOL_OPTIONS
global tsan_saved_TEST_ALWAYS_FLAGS
+global dg-do-what-default
+global tsan_saved_dg-do-what-default
set link_flags ""
if ![is_remote host] {
@@ -79,6 +81,9 @@ proc tsan_init { args } {
}
}
+if [info exists dg-do-what-default] {
+ set tsan_saved-dg-do-what-default dg-do-what-default
+}
if [info exists TEST_ALWAYS_FLAGS] {
set tsan_saved_TEST_ALWAYS_FLAGS $TEST_ALWAYS_FLAGS
}
@@ -96,8 +101,11 @@ proc tsan_init { args } {
if [check_runtime_nocache tsan_works {
int main () { return 0; }
} "-fPIE -pie -fsanitize=thread -g"] {
- return 1
+ set dg-do-what-default run
+ } else {
+ set dg-do-what-default compile
}
+ return 1
}
return 0
}
@@ -109,10 +117,17 @@ proc tsan_init { args } {
proc tsan_finish { args } {
global TEST_ALWAYS_FLAGS
global tsan_saved_TEST_ALWAYS_FLAGS
+global dg-do-what-default
+global tsan_saved_dg-do-what-default
if [info exists tsan_saved_TEST_ALWAYS_FLAGS] {
set TEST_ALWAYS_FLAGS $tsan_saved_TEST_ALWAYS_FLAGS
} else {
unset TEST_ALWAYS_FLAGS
}
+if [info exists tsan_saved-dg-do-what-default] {
+ set dg-do-what-default tsan_saved-dg-do-what-default
+} else {
+ unset dg-do-what-default
+}
}
--- gcc/testsuite/g++.dg/tsan/atomic_free.C.jj 2013-12-12 14:28:31.0
+0100
+++ gcc/testsuite/g++.dg/tsan/atomic_free.C 2014-01-31 13:15:25.110473518
+0100
@@ -1,4 +1,3 @@
-/* { dg-do run } */
/* { dg-shouldfail "tsan" } */
#include
--- gcc/testsuite/g++.dg/tsan/fd_close_norace2.C.jj 2013-12-12
14:28:31.0 +0100
+++ gcc/testsuite/g++.dg/tsan/fd_close_norace2.C2014-01-31
13:15:30.882443238 +0100
@@ -1,5 +1,3 @@
-/* { dg-do run } */
-
#include
#include
#include
--- gcc/testsuite/g++.dg/tsan/default_options.C.jj 2013-12-12
14:28:31.0 +0100
+++ gcc/testsuite/g++.dg/tsan/default_options.C 2014-01-31 13:15:29.373451426
+0100
@@ -1,4 +1,3 @@
-/* { dg-do run } */
/* { dg-shouldfail "tsan" } */
#include
--- gcc/testsuite/g++.dg/tsan/aligned_vs_unaligned_race.C.jj2013-12-12
14:28:31.
Re: [PATCH][testsuite] Avoid division by zero.
On Fri, Jan 31, 2014 at 1:32 PM, Ilya Tocar wrote:
>> >> We won't get zero from exponential function, so expecting zero result
>> >> is flawed anyway.
>> >>
>> >> If we would like to introduce universal epsilon comparisons into the
>> >> testsuite, then please read [1]. Being overly pedantic, the definition
>> >> should be "|(v[i] - u.a[i]) / v[i]|", as stated in [2].
>> >>
>> >> [1]
>> >> http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
>> >> [2] http://en.wikipedia.org/wiki/Relative_error
>> >>
>> >
>> > We get zero from testing zero-masking. Currently we produce 0/0 = NaN.
>> > Comparison with NaN is always false, so tests pass. But I think that
>> > this should be fixed to avoid division by zero. As for being more
>> > pedantic about comparison, I doubt that its useful, when we use
>> > 0.0001 as eps.
>>
>> In this case, please add simple check for zero, with the above
>> comment. We don't test exp function, but masking.
>>
>
> Something like this?
Yes, this is OK, with a small comment fix.
> gcc/testsuite/gcc.target/i386/m512-check.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.target/i386/m512-check.h
> b/gcc/testsuite/gcc.target/i386/m512-check.h
> index 3209039..a96a103 100644
> --- a/gcc/testsuite/gcc.target/i386/m512-check.h
> +++ b/gcc/testsuite/gcc.target/i386/m512-check.h
> @@ -58,6 +58,16 @@ check_rough_##UINON_TYPE (UINON_TYPE u, const VALUE_TYPE
> *v, \
> \
>for (i = 0; i < ARRAY_SIZE (u.a); i++) \
> { \
> + /* We will always have v[i] == 0 == u.a[i] for some i, \
We can have ...
Thanks,
Uros.
[ping] Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build
ping, adding build maintainers Am 10.01.2014 12:06, schrieb Matthias Klose: > Am 10.01.2014 10:49, schrieb Zhenqiang Chen: >> On 10 January 2014 17:23, Matthias Klose wrote: >>> Am 10.01.2014 09:23, schrieb Zhenqiang Chen: Hi, MULTIARCH_DIRNAME was removed @r196649 since the dir info had been combined in MULTILIB_OSDIRNAMES. But MULTIARCH_DIRNAME was re-added @r201164. With this change, the final multiarch_dir is combined as "aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to multiarch build fail if the sysroot is in correct multiarch layout. Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we remove it as the patch? >>> >>> see the thread "[patch] set MULTIARCH_DIRNAME for multilib architectures" >>> from >>> June 2013. I think it is necessary to have the default defined. >>> Yesterday's >>> build looks ok for me, looking at default and include paths, so maybe I >>> don't >>> yet understand the issue. >> >> In our build, we configure eglbc with >> rtlddir=/lib >> libdir=/usr/lib/aarch64-linux-gnu >> slibdir=/lib/aarch64-linux-gnu >> >> And we configure gcc with "--disable-multilib --enable-multiarch", >> But when building gcc libraries, configure FAIL since it can not find >> the C libraries. And I try >> ./xgcc --print-multiarch >> the output is "aarch64-linux-gnu:aarch64-linux-gnu" >> >> Any comments? > >> >> Thanks! >> -Zhenqiang >> >> >> >>> I think aarch64 is the only architecture which introduces MULTILIB_* macros >>> without actually building any multilib, just to set the default library >>> name to >>> lib64. So maybe this has some side effects. > > sorry, I have a local patch applied after the lib64 change, which I forgot to > forward. > > * Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if > MULTILIB_OSDIRNAMES is not defined. > > --- a/src/gcc/Makefile.in > +++ b/src/gcc/Makefile.in > @@ -1837,7 +1837,7 @@ > "$(MULTILIB_EXCLUSIONS)" \ > "$(MULTILIB_OSDIRNAMES)" \ > "$(MULTILIB_REQUIRED)" \ > - "$(MULTIARCH_DIRNAME)" \ > + "$(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME))" \ > "$(MULTILIB_REUSE)" \ > "@enable_multilib@" \ > > tmp-mlib.h; \ > > applied/tested since July 2013 on the Debian/Ubuntu distro builds. It doesn't > affect the non-multiarch case. > > Ok for the trunk? > > Matthias >
Re: [PATCH][testsuite] Avoid division by zero.
> >> We won't get zero from exponential function, so expecting zero result
> >> is flawed anyway.
> >>
> >> If we would like to introduce universal epsilon comparisons into the
> >> testsuite, then please read [1]. Being overly pedantic, the definition
> >> should be "|(v[i] - u.a[i]) / v[i]|", as stated in [2].
> >>
> >> [1]
> >> http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
> >> [2] http://en.wikipedia.org/wiki/Relative_error
> >>
> >
> > We get zero from testing zero-masking. Currently we produce 0/0 = NaN.
> > Comparison with NaN is always false, so tests pass. But I think that
> > this should be fixed to avoid division by zero. As for being more
> > pedantic about comparison, I doubt that its useful, when we use
> > 0.0001 as eps.
>
> In this case, please add simple check for zero, with the above
> comment. We don't test exp function, but masking.
>
Something like this?
---
gcc/testsuite/gcc.target/i386/m512-check.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/gcc/testsuite/gcc.target/i386/m512-check.h
b/gcc/testsuite/gcc.target/i386/m512-check.h
index 3209039..a96a103 100644
--- a/gcc/testsuite/gcc.target/i386/m512-check.h
+++ b/gcc/testsuite/gcc.target/i386/m512-check.h
@@ -58,6 +58,16 @@ check_rough_##UINON_TYPE (UINON_TYPE u, const VALUE_TYPE *v,
\
\
for (i = 0; i < ARRAY_SIZE (u.a); i++) \
{ \
+ /* We will always have v[i] == 0 == u.a[i] for some i, \
+ when we test zero-masking. */\
+ if (v[i] == 0.0 && u.a[i] == 0.0)\
+ continue; \
+ if (v[i] == 0.0 && u.a[i] != 0.0)\
+ { \
+ err++;\
+ PRINTF ("%i: " FMT " != " FMT "\n", \
+ i, v[i], u.a[i]); \
+ } \
VALUE_TYPE rel_err = (u.a[i] - v[i]) / v[i]; \
if (((rel_err < 0) ? -rel_err : rel_err) > eps) \
{ \
--
1.8.3.1
[C++ Patch] PR 59082
Hi,
in this ICE on invalid regression we emit a sensible error message about
the duplicate base and then we ICE when we process the function, because
TYPE_VFIELD (type) is null in build_vfield_ref. My changes just check
for the offending situation and return early from build_base_path
(fold_build_pointer_plus would crash for an error_mark_node).
Tested x86_64-linux.
Thanks,
Paolo.
/cp
2014-01-31 Paolo Carlini
PR c++/59082
* class.c (build_vfield_ref): Early return error_mark_node if
TYPE_VFIELD (type) is null.
(build_base_path): Check return value of build_vfield_ref.
/testsuite
2014-01-31 Paolo Carlini
PR c++/59082
* g++.dg/inherit/crash4.C: New.
Index: cp/class.c
===
--- cp/class.c (revision 207336)
+++ cp/class.c (working copy)
@@ -431,6 +431,9 @@ build_base_path (enum tree_code code,
v_offset = build_vfield_ref (cp_build_indirect_ref (expr, RO_NULL,
complain),
TREE_TYPE (TREE_TYPE (expr)));
+
+ if (v_offset == error_mark_node)
+ return error_mark_node;
v_offset = fold_build_pointer_plus (v_offset, BINFO_VPTR_FIELD
(v_binfo));
v_offset = build1 (NOP_EXPR,
@@ -625,7 +628,9 @@ build_vfield_ref (tree datum, tree type)
{
tree vfield, vcontext;
- if (datum == error_mark_node)
+ if (datum == error_mark_node
+ /* Can happen in case of duplicate base types (c++/59082). */
+ || !TYPE_VFIELD (type))
return error_mark_node;
/* First, convert to the requested type. */
Index: testsuite/g++.dg/inherit/crash4.C
===
--- testsuite/g++.dg/inherit/crash4.C (revision 0)
+++ testsuite/g++.dg/inherit/crash4.C (working copy)
@@ -0,0 +1,10 @@
+// PR c++/59082
+
+struct A {};
+
+struct B : virtual A, A {}; // { dg-error "duplicate base type" }
+
+A foo(const B &b)
+{
+ return b;
+}
Re: [PATCH] Don't COND_EXEC frame related instructions (PR target/59923)
Jakub Jelinek writes: > --- gcc/ifcvt.c.jj2014-01-09 08:20:55.0 +0100 > +++ gcc/ifcvt.c 2014-01-29 17:16:29.912259159 +0100 > @@ -338,6 +338,10 @@ cond_exec_process_insns (ce_if_block *ce > >gcc_assert (NONJUMP_INSN_P (insn) || CALL_P (insn)); > > + /* dwarf2out can't coope with conditional unwind info. */ > + if (reload_completed && RTX_FRAME_RELATED_P (insn)) > + return FALSE; Sorry for the nitpick, but s/coope/cope/. Thanks, Richard
Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi Jakub! Thank you for review and quick answer. The above are OpenACC specific clauses, so they should have OACC_LIST_*? I just followed Thomas's style recomendations: If we're adding new names for implementing OpenACC things, maybe we should also name these OMP_*, to keep things simple to read in the code that uses them. And I agree with him. + case OMP_LIST_DEVICE: type = "DEVICE"; break; This one is in OpenMP 4.0 too (though, I didn't get to OpenMP 4.0 / fortran support yet), so this should be OMP_LIST_DEVICE. As far as I know, OpenMP device clause requires integer-expression, not variable-list, so, I think, we can use OMP_LIST_DEVICE to represent OpenACC device clause. -- Thanks, Ilmir.
[PATCH] Don't run tsan tests if a trivial test doesn't work
Hi!
Apparently tsan doesn't work e.g. under setarch x86_64 -R, at which point
all tests fail. This patch just disables the tests in that case.
Tested on x86_64-linux both under setarch x86_64 -R and without, committed
to trunk as obvious.
Of course it would be nicer if libtsan actually supported that (and didn't
rely on PIEs etc.), but I don't see that as a priority for upstream :(.
2014-01-31 Jakub Jelinek
* lib/tsan-dg.exp (tsan_init): Try to run a trivial program,
if it fails don't run any tsan tests.
--- gcc/testsuite/lib/tsan-dg.exp.jj2014-01-03 11:40:40.0 +0100
+++ gcc/testsuite/lib/tsan-dg.exp 2014-01-31 12:15:06.659406282 +0100
@@ -93,7 +93,11 @@ proc tsan_init { args } {
}
}
if { $link_flags != "" } {
- return 1
+ if [check_runtime_nocache tsan_works {
+ int main () { return 0; }
+ } "-fPIE -pie -fsanitize=thread -g"] {
+ return 1
+ }
}
return 0
}
Jakub
Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
On Fri, Jan 31, 2014 at 03:10:59PM +0400, Ilmir Usmanov wrote:
> @@ -1182,6 +1281,26 @@ show_omp_node (int level, gfc_code *c)
> {
> switch (list_type)
> {
> + case OMP_LIST_COPY: type = "COPY"; break;
> + case OMP_LIST_OACC_COPYIN: type = "COPYIN"; break;
> + case OMP_LIST_COPYOUT: type = "COPYOUT"; break;
> + case OMP_LIST_CREATE: type = "CREATE"; break;
> + case OMP_LIST_DELETE: type = "DELETE"; break;
> + case OMP_LIST_PRESENT: type = "PRESENT"; break;
> + case OMP_LIST_PRESENT_OR_COPY:
> +type = "PRESENT_OR_COPY"; break;
> + case OMP_LIST_PRESENT_OR_COPYIN:
> +type = "PRESENT_OR_COPYIN"; break;
> + case OMP_LIST_PRESENT_OR_COPYOUT:
> +type = "PRESENT_OR_COPYOUT"; break;
> + case OMP_LIST_PRESENT_OR_CREATE:
> +type = "PRESENT_OR_CREATE"; break;
> + case OMP_LIST_DEVICEPTR: type = "DEVICEPTR"; break;
> + case OMP_LIST_USE_DEVICE: type = "USE_DEVICE"; break;
> + case OMP_LIST_DEVICE_RESIDENT: type = "USE_DEVICE"; break;
> + case OMP_LIST_HOST: type = "HOST"; break;
The above are OpenACC specific clauses, so they should have OACC_LIST_*?
> + case OMP_LIST_DEVICE: type = "DEVICE"; break;
This one is in OpenMP 4.0 too (though, I didn't get to OpenMP 4.0 / fortran
support yet), so this should be OMP_LIST_DEVICE.
> + case OMP_LIST_CACHE: type = ""; break;
Again, this is OpenACC specific.
Jakub
Re: [PATCH 6/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
OpenACC 1.0 support -- documentation.
gcc/doc/
* generic.texi: Document OACC_KERNELS, OACC_DATA, OACC_HOST_DATA,
OACC_DECLARE, OACC_UPDATE, OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_WAIT,
OACC_CACHE.
>From 2550374183627d221f8881d14939ea7b0045bfba Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date: Fri, 31 Jan 2014 13:30:18 +0400
Subject: [PATCH 6/6] OpenACC GENERIC docs
---
gcc/doc/generic.texi | 40
1 file changed, 40 insertions(+)
diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi
index a56715b..8153a6e 100644
--- a/gcc/doc/generic.texi
+++ b/gcc/doc/generic.texi
@@ -2052,6 +2052,14 @@ edge. Rethrowing the exception is represented using @code{RESX_EXPR}.
@node OpenMP
@subsection OpenMP
@tindex OACC_PARALLEL
+@tindex OACC_KERNELS
+@tindex OACC_DATA
+@tindex OACC_HOST_DATA
+@tindex OACC_UPDATE
+@tindex OACC_ENTER_DATA
+@tindex OACC_EXIT_DATA
+@tindex OACC_WAIT
+@tindex OACC_CACHE
@tindex OMP_PARALLEL
@tindex OMP_FOR
@tindex OMP_SECTIONS
@@ -2073,6 +2081,38 @@ clauses used by the OpenMP API @w{@uref{http://www.openmp.org/}}.
Represents @code{#pragma acc parallel [clause1 @dots{} clauseN]}.
+@item OACC_KERNELS
+
+Represents @code{#pragma acc kernels [clause1 @dots{} clauseN]}.
+
+@item OACC_DATA
+
+Represents @code{#pragma acc data [clause1 @dots{} clauseN]}.
+
+@item OACC_HOST_DATA
+
+Represents @code{#pragma acc host_data [clause1 @dots{} clauseN]}.
+
+@item OACC_UPDATE
+
+Represents @code{#pragma acc update [clause1 @dots{} clauseN]}.
+
+@item OACC_ENTER_DATA
+
+Represents @code{#pragma acc enter data [clause1 @dots{} clauseN]}.
+
+@item OACC_EXIT_DATA
+
+Represents @code{#pragma acc exit data [clause1 @dots{} clauseN]}.
+
+@item OACC_WAIT
+
+Represents @code{#pragma acc wait [(num @dots{})]}.
+
+@item OACC_CACHE
+
+Represents @code{#pragma acc cache (var @dots{})}.
+
@item OMP_PARALLEL
Represents @code{#pragma omp parallel [clause1 @dots{} clauseN]}. It
--
1.8.3.2
Re: [PATCH 5/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
OpenACC 1.0 fortran FE support -- tests.
gcc/testsuite/gfortran.dg/goacc/
* goacc.exp: New test directory.
* branch.f95: New test.
* continuation-free-form.f95: Likewise.
* data-clauses.f95: Likewise.
* data-tree.f95: Likewise.
* declare-1.f95: Likewise.
* declare.f95: Likewise.
* directive-names.f95: Likewise.
* enter-exit-data.f95: Likewise.
* host_data-tree.f95: Likewise.
* if.f95: Likewise.
* kernels-tree.f95: Likewise.
* list.f95: Likewise.
* parallel-kernels-clauses.f95: Likewise.
* parallel-kernels-regions.f95: Likewise.
* parallel-tree.f95: Likewise.
* pure-elemental-procedures.f95: Likewise.
* reduction.f95: Likewise.
* sentinel-free-form.f95: Likewise.
* several-directives.f95: Likewise.
* sie.f95: Likewise.
>From 9850a2e343e506fa06edf1518414ac71eed60d48 Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date: Fri, 31 Jan 2014 13:29:44 +0400
Subject: [PATCH 5/6] OpenACC fortran tests
---
gcc/testsuite/gfortran.dg/goacc/branch.f95 | 55 +
.../gfortran.dg/goacc/continuation-free-form.f95 | 24 ++
gcc/testsuite/gfortran.dg/goacc/data-clauses.f95 | 261 +
gcc/testsuite/gfortran.dg/goacc/data-tree.f95 | 33 +++
gcc/testsuite/gfortran.dg/goacc/declare-1.f95 | 13 +
.../gfortran.dg/goacc/directive-names.f95 | 20 ++
.../gfortran.dg/goacc/enter-exit-data.f95 | 89 +++
gcc/testsuite/gfortran.dg/goacc/goacc.exp | 36 +++
gcc/testsuite/gfortran.dg/goacc/host_data-tree.f95 | 13 +
gcc/testsuite/gfortran.dg/goacc/if.f95 | 53 +
gcc/testsuite/gfortran.dg/goacc/kernels-tree.f95 | 34 +++
gcc/testsuite/gfortran.dg/goacc/list.f95 | 111 +
.../gfortran.dg/goacc/parallel-kernels-clauses.f95 | 96
.../gfortran.dg/goacc/parallel-kernels-regions.f95 | 57 +
gcc/testsuite/gfortran.dg/goacc/parallel-tree.f95 | 42
.../goacc/pure-elemental-procedures.f95| 46
gcc/testsuite/gfortran.dg/goacc/reduction.f95 | 138 +++
.../gfortran.dg/goacc/sentinel-free-form.f95 | 22 ++
.../gfortran.dg/goacc/several-directives.f95 | 7 +
gcc/testsuite/gfortran.dg/goacc/sie.f95| 252
20 files changed, 1402 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/goacc/branch.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/continuation-free-form.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/data-clauses.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/data-tree.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/declare-1.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/directive-names.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/enter-exit-data.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/goacc.exp
create mode 100644 gcc/testsuite/gfortran.dg/goacc/host_data-tree.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/if.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/kernels-tree.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/list.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/parallel-kernels-clauses.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/parallel-kernels-regions.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/parallel-tree.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/pure-elemental-procedures.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/reduction.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/sentinel-free-form.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/several-directives.f95
create mode 100644 gcc/testsuite/gfortran.dg/goacc/sie.f95
diff --git a/gcc/testsuite/gfortran.dg/goacc/branch.f95 b/gcc/testsuite/gfortran.dg/goacc/branch.f95
new file mode 100644
index 000..e470ce2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/branch.f95
@@ -0,0 +1,55 @@
+! { dg-do compile }
+! { dg-options "-fopenacc" }
+
+program test
+ implicit none
+
+ integer :: i
+
+ if (.true.) then
+ !$acc parallel
+ end if ! { dg-error "Unexpected" }
+ !$acc end parallel
+ end if
+
+ if (.true.) then
+ !$acc kernels
+ end if ! { dg-error "Unexpected" }
+ !$acc end kernels
+ end if
+
+ !$acc parallel
+ if (.true.) then
+ !$acc end parallel ! { dg-error "Unexpected" }
+ end if
+ !$acc end parallel
+
+ !$acc kernels
+ if (.true.) then
+ !$acc end kernels ! { dg-error "Unexpected" }
+ end if
+ !$acc end kernels
+
+ !$acc parallel
+ if (.true.) then
+ end if
+ !$acc end parallel
+
+ !$acc kernels
+ if (.true.) then
+ end if
+ !$acc end kernels
+
+ if (.true.) then
+ !$acc parallel
+ !$acc end parallel
+ end if
+
+ if (.true.) then
+ !$acc kernels
+ !$acc end kernels
+ end if
+10 i = 0
+
+
+end program test
\ No newline at end of file
diff --git a/gcc/testsuite/gfortran.dg/goacc/continuation-free-form.f95 b/gcc/testsuite/gfortran.dg/goacc/continuation-free-form.f95
new file mode 100644
Re: [PATCH 4/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
OpenACC 1.0 support -- GENERIC nodes and gimplify stubs.
gcc/
* gimplify.c (is_gimple_stmt): Stub OpenACC directives and clauses.
(gimplify_scan_omp_clauses, gimplify_adjust_omp_clauses): Likewise.
(gimplify_expr): Likewise.
* omp-low.c (scan_sharing_clauses): Likewise.
(gimple_code_is_oacc): New helper function.
(scan_sharing_clauses): Use it.
* tree-core.h
(OMP_CLAUSE_ASYNC, OMP_CLAUSE_NUM_GANGS, OMP_CLAUSE_NUM_WORKERS,
OMP_CLAUSE_VECTOR_LENGTH, OMP_CLAUSE_GANG, OMP_CLAUSE_WORKER,
OMP_CLAUSE_VECTOR, OMP_CLAUSE_INDEPENDENT,
OMP_CLAUSE_USE_DEVICE, OMP_CLAUSE_HOST, OMP_CLAUSE_DEVICE_RESIDENT,
OMP_CLAUSE_OACC_DEVICE, OMP_CLAUSE_DEFAULT, OMP_CLAUSE_WAIT): New
clauses.
* tree-pretty-print.c (dump_omp_clause): Print OpenACC clause.
(dump_generic_node): Print OpenACC directives and its clauses.
* tree.c (omp_clause_num_ops): Add OpenACC clauses.
(omp_clause_code_name): Likewise.
(walk_tree_1): Likewise.
* tree.def (OACC_KERNELS): New tree node.
(OACC_DATA, OACC_HOST_DATA, OACC_DECLARE, OACC_UPDATE): Likewise.
(OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_WAIT, OACC_CACHE): Likewise.
* tree.h (OACC_BODY): New macros.
(OACC_KERNELS_BODY, OACC_KERNELS_CLAUSES, OACC_CLAUSE_NUM_GANGS_EXPR,
OMP_CLAUSE_NUM_WORKERS_EXPR, OMP_CLAUSE_VECTOR_LENGTH_EXPR,
OMP_CLAUSE_VECTOR_EXPR, OMP_CLAUSE_WORKER_EXPR, OMP_CLAUSE_GANG_EXPR,
OMP_CLAUSE_ASYNC_EXPR,
OMP_WAIT_EXPR, OACC_DATA_BODY, OACC_DATA_CLAUSES,
OACC_DECLARE_CLAUSES,
OACC_UPDATE_CLAUSES, OACC_WAIT_CLAUSES, OACC_CACHE_CLAUSES,
OACC_HOST_DATA_BODY, OACC_HOST_DATA_CLAUSES): Likewise.
>From 3383f24ea09611525311e3e2147672421c31f9cb Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date: Fri, 31 Jan 2014 13:28:47 +0400
Subject: [PATCH 4/6] OpenACC GENERIC nodes
---
gcc/gimplify.c | 53 +
gcc/omp-low.c | 96 +---
gcc/tree-core.h | 61 +---
gcc/tree-pretty-print.c | 103
gcc/tree.c | 44 -
gcc/tree.def| 50 +++
gcc/tree.h | 53 +
7 files changed, 438 insertions(+), 22 deletions(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index d20f07f..34fd8ca 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4333,6 +4333,15 @@ is_gimple_stmt (tree t)
case ASM_EXPR:
case STATEMENT_LIST:
case OACC_PARALLEL:
+case OACC_KERNELS:
+case OACC_DATA:
+case OACC_CACHE:
+case OACC_WAIT:
+case OACC_HOST_DATA:
+case OACC_DECLARE:
+case OACC_UPDATE:
+case OACC_ENTER_DATA:
+case OACC_EXIT_DATA:
case OMP_PARALLEL:
case OMP_FOR:
case OMP_SIMD:
@@ -6157,6 +6166,20 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
remove = true;
break;
+ case OMP_CLAUSE_HOST:
+ case OMP_CLAUSE_OACC_DEVICE:
+ case OMP_CLAUSE_DEVICE_RESIDENT:
+ case OMP_CLAUSE_USE_DEVICE:
+ case OMP_CLAUSE_ASYNC:
+ case OMP_CLAUSE_GANG:
+ case OMP_CLAUSE_WAIT:
+ case OMP_NO_CLAUSE_CACHE:
+ case OMP_CLAUSE_INDEPENDENT:
+ case OMP_CLAUSE_WORKER:
+ case OMP_CLAUSE_VECTOR:
+ case OMP_CLAUSE_NUM_GANGS:
+ case OMP_CLAUSE_NUM_WORKERS:
+ case OMP_CLAUSE_VECTOR_LENGTH:
case OMP_CLAUSE_NOWAIT:
case OMP_CLAUSE_ORDERED:
case OMP_CLAUSE_UNTIED:
@@ -6476,6 +6499,23 @@ gimplify_adjust_omp_clauses (tree *list_p)
}
break;
+ case OMP_CLAUSE_HOST:
+ case OMP_CLAUSE_OACC_DEVICE:
+ case OMP_CLAUSE_DEVICE_RESIDENT:
+ case OMP_CLAUSE_USE_DEVICE:
+ case OMP_CLAUSE_ASYNC:
+ case OMP_CLAUSE_GANG:
+ case OMP_CLAUSE_WAIT:
+ case OMP_NO_CLAUSE_CACHE:
+ case OMP_CLAUSE_INDEPENDENT:
+ case OMP_CLAUSE_WORKER:
+ case OMP_CLAUSE_VECTOR:
+ case OMP_CLAUSE_NUM_GANGS:
+ case OMP_CLAUSE_NUM_WORKERS:
+ case OMP_CLAUSE_VECTOR_LENGTH:
+sorry ("Clause not supported yet");
+break;
+
case OMP_CLAUSE_REDUCTION:
case OMP_CLAUSE_COPYIN:
case OMP_CLAUSE_COPYPRIVATE:
@@ -7988,6 +8028,19 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
ret = GS_ALL_DONE;
break;
+ case OACC_KERNELS:
+ case OACC_DATA:
+ case OACC_CACHE:
+ case OACC_WAIT:
+ case OACC_HOST_DATA:
+ case OACC_DECLARE:
+ case OACC_UPDATE:
+ case OACC_ENTER_DATA:
+ case OACC_EXIT_DATA:
+sorry ("directive not yet implemented");
+ret = GS_ALL_DONE;
+break;
+
case OMP_PARALLEL:
gimplify_omp_parallel (expr_p, pre_p);
ret = GS_ALL_DONE;
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 4bbe6d6..88de870 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -1491,6 +1491,18 @@ fixup_child_record_type (omp_context *ctx)
TREE_TYPE (ctx->receiver_decl) = build_pointer_type (type);
}
+static bool
+gimple_code_is_oacc (const_gimple g)
+{
+ switch (gimple_code (g))
+{
+case GIMPLE_OACC_PARALLEL:
+ return true;
+default:
+ return fa
Re: [PATCH 3/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
OpenACC 1.0 fortran FE support -- translation to GENERIC.
* trans-decl.c
(gfc_generate_function_code): Insert OACC_DECLARE GENERIC node.
* trans-openmp.c (gfc_convert_expr_to_tree): New helper function.
(gfc_trans_omp_array_reduction): Support also OpenACC. Add parameter.
(gfc_trans_omp_reduction_list): Update.
(gfc_trans_oacc_construct): New transform function.
(gfc_trans_omp_map_clause_list): Likewise.
(gfc_trans_oacc_executable_directive): Likewise.
(gfc_trans_oacc_combined_directive, gfc_trans_oacc_declare): Likewise.
(gfc_trans_oacc_directive): Use them.
(gfc_trans_oacc_loop): Stub.
(gfc_trans_omp_clauses): Transform OpenACC clauses.
* trans-stmt.h (gfc_trans_oacc_directive): New function prototype.
(gfc_trans_oacc_declare): Likewise.
* trans.c (trans_code): Transform also OpenACC directives.
>From c7fcfb4e2aaeb1833dad4d5e370da330bb1a3760 Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date: Fri, 31 Jan 2014 13:27:24 +0400
Subject: [PATCH 3/6] OpenACC fortran front-end -- part 3
---
gcc/fortran/trans-decl.c | 7 +
gcc/fortran/trans-openmp.c | 367 +
gcc/fortran/trans-stmt.h | 4 +
gcc/fortran/trans.c| 15 ++
4 files changed, 393 insertions(+)
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index bb02f43..69f33dd 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5602,6 +5602,13 @@ gfc_generate_function_code (gfc_namespace * ns)
if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS) && !sym->attr.is_bind_c)
add_argument_checking (&body, sym);
+ /* Generate !$ACC DECLARE directive. */
+ if (ns->declare_clauses)
+{
+ tmp = gfc_trans_oacc_declare(&body, ns);
+ gfc_add_expr_to_block(&body, tmp);
+}
+
tmp = gfc_trans_code (ns->code);
gfc_add_expr_to_block (&body, tmp);
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 41020a8..a9d1bbc 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -767,6 +767,40 @@ gfc_trans_omp_reduction_list (gfc_namelist *namelist, tree list,
}
static tree
+gfc_trans_omp_map_clause_list (enum omp_clause_map_kind kind,
+ gfc_namelist *namelist, tree list)
+{
+ for (; namelist != NULL; namelist = namelist->next)
+if (namelist->sym->attr.referenced)
+ {
+tree t = gfc_trans_omp_variable (namelist->sym);
+if (t != error_mark_node)
+ {
+tree node = build_omp_clause (input_location, OMP_CLAUSE_MAP);
+OMP_CLAUSE_DECL (node) = t;
+OMP_CLAUSE_MAP_KIND (node) = kind;
+list = gfc_trans_add_clause (node, list);
+ }
+ }
+ return list;
+}
+
+static inline tree
+gfc_convert_expr_to_tree (stmtblock_t *block, gfc_expr *expr)
+{
+ gfc_se se;
+ tree result;
+
+ gfc_init_se (&se, NULL );
+ gfc_conv_expr (&se, expr);
+ gfc_add_block_to_block (block, &se.pre);
+ result = gfc_evaluate_now (se.expr, block);
+ gfc_add_block_to_block (block, &se.post);
+
+ return result;
+}
+
+static tree
gfc_trans_omp_clauses (stmtblock_t *block, gfc_omp_clauses *clauses,
locus where)
{
@@ -834,6 +868,51 @@ gfc_trans_omp_clauses (stmtblock_t *block, gfc_omp_clauses *clauses,
where);
continue;
}
+ if (list >= OMP_LIST_DATA_CLAUSE_FIRST
+ && list <= OMP_LIST_DATA_CLAUSE_LAST)
+{
+ enum omp_clause_map_kind kind;
+ switch (list)
+{
+case OMP_LIST_COPY:
+ kind = OMP_CLAUSE_MAP_FORCE_TOFROM;
+ break;
+case OMP_LIST_OACC_COPYIN:
+ kind = OMP_CLAUSE_MAP_FORCE_TO;
+ break;
+case OMP_LIST_COPYOUT:
+ kind = OMP_CLAUSE_MAP_FORCE_FROM;
+ break;
+case OMP_LIST_CREATE:
+ kind = OMP_CLAUSE_MAP_FORCE_ALLOC;
+ break;
+case OMP_LIST_DELETE:
+ kind = OMP_CLAUSE_MAP_FORCE_DEALLOC;
+ break;
+case OMP_LIST_PRESENT:
+ kind = OMP_CLAUSE_MAP_FORCE_PRESENT;
+ break;
+case OMP_LIST_PRESENT_OR_COPY:
+ kind = OMP_CLAUSE_MAP_TOFROM;
+ break;
+case OMP_LIST_PRESENT_OR_COPYIN:
+ kind = OMP_CLAUSE_MAP_TO;
+ break;
+case OMP_LIST_PRESENT_OR_COPYOUT:
+ kind = OMP_CLAUSE_MAP_FROM;
+ break;
+case OMP_LIST_PRESENT_OR_CREATE:
+ kind = OMP_CLAUSE_MAP_ALLOC;
+ break;
+case OMP_LIST_DEVICEPTR:
+ kind = OMP_CLAUSE_MAP_FORCE_DEVICEPTR;
+ break;
+default:
+ gcc_unreachable ();
+}
+ omp_clauses = gfc_trans_omp_map_clause_list (kind, n, omp_clauses);
+ continue;
+}
switch (list)
{
case OMP_LIST_PRIVATE:
@@ -853,6 +932,21 @@ gfc_tr
Re: [PATCH 2/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
OpenACC 1.0 fortran FE support -- matching and resolving.
* openmp.c (gfc_free_omp_clauses): Remove also OpenACC clauses.
(gfc_free_exprlist): New function to clear expression list.
(match_oacc_exprlist): New function to match expression list.
(match_oacc_clause_gang): New function to match OpenACC 2.0 gang
clauses.
(OMP_CLAUSE_ASYNC, OMP_CLAUSE_NUM_GANGS,
OMP_CLAUSE_NUM_WORKERS, OMP_CLAUSE_VECTOR_LENGTH,
OMP_CLAUSE_COPY, OMP_CLAUSE_OACC_COPYIN,
OMP_CLAUSE_COPYOUT, OMP_CLAUSE_CREATE, OMP_CLAUSE_PRESENT,
OMP_CLAUSE_PRESENT_OR_COPY, OMP_CLAUSE_PRESENT_OR_COPYIN,
OMP_CLAUSE_PRESENT_OR_COPYOUT, OMP_CLAUSE_PRESENT_OR_CREATE,
OMP_CLAUSE_DEVICEPTR, OMP_CLAUSE_GANG, OMP_CLAUSE_WORKER,
OMP_CLAUSE_VECTOR, OMP_CLAUSE_SEQ, OMP_CLAUSE_INDEPENDENT,
OMP_CLAUSE_USE_DEVICE, OMP_CLAUSE_HOST, OMP_CLAUSE_DEVICE_RESIDENT,
OMP_CLAUSE_DEVICE, OMP_CLAUSE_DEFAULT, OMP_CLAUSE_WAIT,
OMP_CLAUSE_DELETE, OMP_CLAUSE_AUTO, OMP_CLAUSE_TILE): New clauses.
(OACC_PARALLEL_CLAUSES, OACC_KERNELS_CLAUSES, OACC_DATA_CLAUSES,
OACC_LOOP_CLAUSES, OACC_PARALLEL_LOOP_CLAUSES,
OACC_KERNELS_LOOP_CLAUSES, OACC_HOST_DATA_CLAUSES,
OACC_DECLARE_CLAUSES,
OACC_UPDATE_CLAUSES, OACC_ENTER_DATA_CLAUSES,
OACC_EXIT_DATA_CLAUSES): New defines.
>From 64b05eeeadf25fca4f92f083cc11aaad1a7a692a Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date: Fri, 31 Jan 2014 13:26:13 +0400
Subject: [PATCH 2/6] OpenACC fortran front-end -- part 2
---
gcc/fortran/openmp.c | 942 ++-
1 file changed, 940 insertions(+), 2 deletions(-)
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index dff3ab1..d4e3ebd 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -69,11 +69,36 @@ gfc_free_omp_clauses (gfc_omp_clauses *c)
gfc_free_expr (c->final_expr);
gfc_free_expr (c->num_threads);
gfc_free_expr (c->chunk_size);
+ gfc_free_expr (c->async_expr);
+ gfc_free_expr (c->gang_expr);
+ gfc_free_expr (c->worker_expr);
+ gfc_free_expr (c->vector_expr);
+ gfc_free_expr (c->num_gangs_expr);
+ gfc_free_expr (c->num_workers_expr);
+ gfc_free_expr (c->vector_length_expr);
+ gfc_free_expr (c->non_clause_wait_expr);
+
for (i = 0; i < OMP_LIST_NUM; i++)
gfc_free_namelist (c->lists[i]);
+
+ gfc_free_exprlist (c->waitlist);
+
free (c);
}
+/* Free expression list. */
+void
+gfc_free_exprlist (gfc_exprlist *list)
+{
+ gfc_exprlist *n;
+
+ for (; list; list = n)
+{
+ n = list->next;
+ free (list);
+}
+}
+
/* Match a variable/common block list and construct a namelist from it. */
static match
@@ -169,6 +194,87 @@ cleanup:
return MATCH_ERROR;
}
+static match
+match_oacc_exprlist (const char *str, gfc_exprlist **list, bool allow_asterisk)
+{
+ gfc_exprlist *head, *tail, *p;
+ locus old_loc;
+ gfc_expr *expr;
+ match m;
+
+ head = tail = NULL;
+
+ old_loc = gfc_current_locus;
+
+ m = gfc_match (str);
+ if (m != MATCH_YES)
+return m;
+
+ for (;;)
+{
+ m = gfc_match_expr (&expr);
+ if (m == MATCH_YES || allow_asterisk)
+{
+ p = gfc_get_exprlist ();
+ if (head == NULL)
+head = tail = p;
+ else
+{
+ tail->next = p;
+ tail = tail->next;
+}
+ if (m == MATCH_YES)
+tail->expr = expr;
+ else if (gfc_match (" *") != MATCH_YES)
+goto syntax;
+ goto next_item;
+}
+ if (m == MATCH_ERROR)
+goto cleanup;
+ goto syntax;
+
+next_item:
+ if (gfc_match_char (')') == MATCH_YES)
+break;
+ if (gfc_match_char (',') != MATCH_YES)
+goto syntax;
+}
+
+ while (*list)
+list = &(*list)->next;
+
+ *list = head;
+ return MATCH_YES;
+
+syntax:
+ gfc_error ("Syntax error in OpenACC expression list at %C");
+
+cleanup:
+ gfc_free_exprlist (head);
+ gfc_current_locus = old_loc;
+ return MATCH_ERROR;
+}
+
+static match
+match_oacc_clause_gang (gfc_omp_clauses *cp)
+{
+ if (gfc_match_char ('(') != MATCH_YES)
+return MATCH_NO;
+ if (gfc_match (" num :") == MATCH_YES)
+{
+ cp->gang_static = false;
+ return gfc_match (" %e )", &cp->gang_expr);
+}
+ if (gfc_match (" static :") == MATCH_YES)
+{
+ cp->gang_static = true;
+ if (gfc_match (" * )") != MATCH_YES)
+return gfc_match (" %e )", &cp->gang_expr);
+ return MATCH_YES;
+}
+ return gfc_match (" %e )", &cp->gang_expr);
+}
+
#define OMP_CLAUSE_PRIVATE (1 << 0)
#define OMP_CLAUSE_FIRSTPRIVATE (1 << 1)
#define OMP_CLAUSE_LASTPRIVATE (1 << 2)
@@ -186,11 +292,40 @@ cleanup:
#define OMP_CLAUSE_FINAL (1 << 14)
#define OMP_CLAUSE_MERGEABLE (1 << 15)
+/* OpenACC 2.0 clauses. */
+#define OMP_CLAUSE_ASYNC(1 << 16)
+#define OMP_CLAUSE_NUM_GANGS(1 << 17)
+#define OMP_CLAUSE_NUM_WORKERS (1 << 18)
+#define OMP_CLAUSE_VECTOR_LENGTH(1 << 19)
+#define OMP_CLA
Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end
OpenACC 1.0 support to fortran FE -- core.
gcc/fortran/
* dump-parse-tree.c
(show_omp_node): Dump also OpenACC executable statements.
(show_code_node): Call it.
* gfortran.h
(ST_OACC_PARALLEL_LOOP, ST_OACC_END_PARALLEL_LOOP, ST_OACC_PARALLEL,
ST_OACC_END_PARALLEL, ST_OACC_KERNELS, ST_OACC_END_KERNELS,
ST_OACC_DATA, ST_OACC_END_DATA, ST_OACC_HOST_DATA,
ST_OACC_END_HOST_DATA, ST_OACC_LOOP, ST_OACC_DECLARE, ST_OACC_UPDATE,
ST_OACC_WAIT, ST_OACC_CACHE, ST_OACC_KERNELS_LOOP,
ST_OACC_END_KERNELS_LOOP, ST_OACC_ENTER_DATA,
ST_OACC_EXIT_DATA): New statements.
(gfc_exprlist): New structure to hold list of expressions.
(OMP_LIST_COPY, OMP_LIST_DATA_CLAUSE_FIRST,
OMP_LIST_OACC_COPYIN, OMP_LIST_COPYOUT, OMP_LIST_CREATE,
OMP_LIST_DELETE,
OMP_LIST_PRESENT, OMP_LIST_PRESENT_OR_COPY,
OMP_LIST_PRESENT_OR_COPYIN, OMP_LIST_PRESENT_OR_COPYOUT,
OMP_LIST_PRESENT_OR_CREATE, OMP_LIST_DEVICEPTR,
OMP_LIST_DATA_CLAUSE_LAST, OMP_LIST_USE_DEVICE,
OMP_LIST_DEVICE_RESIDENT, OMP_LIST_HOST, OMP_LIST_DEVICE,
OMP_LIST_CACHE): New types of list, allowed in clauses.
(gfc_omp_clauses): Add OpenACC clauses.
(gfc_namespace): Add OpenACC declare directive clauses.
(EXEC_OACC_KERNELS_LOOP, EXEC_OACC_PARALLEL_LOOP, EXEC_OACC_PARALLEL,
EXEC_OACC_KERNELS, EXEC_OACC_DATA, EXEC_OACC_HOST_DATA, EXEC_OACC_LOOP,
EXEC_OACC_UPDATE, EXEC_OACC_WAIT, EXEC_OACC_CACHE,
EXEC_OACC_ENTER_DATA,
EXEC_OACC_EXIT_DATA): New executable statements.
(gfc_free_exprlist): New function declaration.
(gfc_resolve_oacc_directive): Likewise.
(gfc_resolve_oacc_parallel_loop_blocks): Likewise.
(gfc_resolve_oacc_blocks): Likewise.
* match.c (match_exit_cycle): Add support of OpenACC regions and loops.
* match.h (gfc_match_oacc_cache): New function declaration.
(gfc_match_oacc_wait, gfc_match_oacc_update): Likewise.
(gfc_match_oacc_declare, gfc_match_oacc_loop): Likewise.
(gfc_match_oacc_host_data, gfc_match_oacc_data): Likewise.
(gfc_match_oacc_kernels, gfc_match_oacc_kernels_loop): Likewise.
(gfc_match_oacc_parallel, gfc_match_oacc_parallel_loop): Likewise.
(gfc_match_oacc_enter_data, gfc_match_oacc_exit_data): Likewise.
* parse.c (decode_oacc_directive): New function.
(verify_token_free, verify_token_fixed): New helper functions.
(next_free, next_fixed): Decode !$ACC sentinel.
(case_executable): Add ST_OACC_UPDATE, ST_OACC_WAIT, ST_OACC_CACHE,
ST_OACC_ENTER_DATA and ST_OACC_EXIT_DATA directives.
(case_exec_markers): Add ST_OACC_PARALLEL_LOOP, ST_OACC_PARALLEL,
ST_OACC_KERNELS, ST_OACC_DATA, ST_OACC_HOST_DATA, ST_OACC_LOOP and
ST_OACC_KERNELS_LOOP directives.
(push_state): Initialize OpenACC declare clauses.
(gfc_ascii_statement): Dump names of OpenACC directives.
(verify_st_order): Verify OpenACC declare directive as declarative.
(parse_spec): Push clauses to state stack when declare directive is
parsed.
(parse_oacc_structured_block, parse_oacc_loop): New functions.
(parse_executable): Call them.
(parse_progunit): Move declare clauses from state stack to namespace.
* parse.h (gfc_state_data): Add declare directive's clauses.
* resolve.c (gfc_resolve_blocks): Resolve OpenACC directives.
(resolve_code): Likewise.
* scanner.c (openacc_flag, openacc_locus): New static variables.
(skip_oacc_attribute, skip_omp_attribute): New helper functions.
(skip_free_comments, skip_fixed_comments): Don't skip !$ACC sentinel.
(gfc_next_char_literal): Support OpenACC directives.
* st.c (gfc_free_statement): Free also OpenACC directives.
>From f8f10537d2555e596bdd1655990150d45ef08f9b Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov
Date: Fri, 31 Jan 2014 13:25:42 +0400
Subject: [PATCH 1/6] OpenACC fortran front-end -- part 1
---
gcc/fortran/dump-parse-tree.c | 135 +-
gcc/fortran/gfortran.h| 59 ++
gcc/fortran/match.c | 27 +++
gcc/fortran/match.h | 15 ++
gcc/fortran/parse.c | 425 ++
gcc/fortran/parse.h | 1 +
gcc/fortran/resolve.c | 36
gcc/fortran/scanner.c | 376 ++---
gcc/fortran/st.c | 12 ++
9 files changed, 980 insertions(+), 106 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index b1343bc..9ef9db4 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1031,9 +1031,22 @@ show_omp_node (int level, gfc_code *c)
{
gfc_omp_clauses *omp_clauses = NULL;
const char *name = NULL;
+ bool is_oacc = false;
switch (c->op)
{
+case EXEC_OACC_PARALLEL_LOOP: name = "PARALLEL LOOP"; is_oacc = true; break;
+case EXEC_OACC_PARALLEL: name = "PARALLEL"; is_oacc = true; break;
+case EXEC_OACC_KERNELS_LOOP: name = "KERNELS LOOP"; is_oacc = true; break;
+case EXEC_OACC_KERNELS: name =
Re: [PATCH] [GOMP4] OpenACC 1.0+ support in fortran front-end
Hi Thomas! I fixed these patches: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01520.html . Instead of adding new OACC_* data structures and macros for OpenACC clauses these patches reuse existing OMP_* functionality and extends it. But OpenACC-specific constructs and directives still named as OACC_*. Thomas, as I noticed you privately, I can't use OpenMP 4.0 map clause to represent OpenACC data clauses in front-end, so old form of them still there. Successfully bootstrapped with no new regressions on x86_64-unknown-linux-gnu. OK for gomp-4_0-branch? -- Ilmir.
[PATCH] Add location_t printer to gdbinit.in
Often enough I need to print expanded_location of location_t. It'd be convenient to have this macro in gdbinit.in. Ok? 2014-01-31 Marek Polacek * gdbinit.in (pel): Define. diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in index c388f8a..25c530a 100644 --- a/gcc/gdbinit.in +++ b/gcc/gdbinit.in @@ -190,6 +190,15 @@ document pbm Dump the bitmap that is in $ as a comma-separated list of numbers. end +define pel +output expand_location ($) +echo \n +end + +document pel +Print expanded location of $. +end + # Define some macros helpful to gdb when it is expanding macros. macro define __FILE__ "gdb" macro define __LINE__ 1 Marek
Re: [PATCH][testsuite] Avoid division by zero.
On Fri, Jan 31, 2014 at 11:00 AM, Ilya Tocar wrote:
>> > This patch removes possible division by zero.
>> > Make check passes. Ok for trunk?
>> >
>> > 2014-01-30 Ilya Tocar
>> >
>> > * gcc.target/i386/m512-check.h: Use correct rounding values.
>> >
>> > ---
>> > gcc/testsuite/gcc.target/i386/m512-check.h | 3 ++-
>> > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/gcc/testsuite/gcc.target/i386/m512-check.h
>> > b/gcc/testsuite/gcc.target/i386/m512-check.h
>> > index 3209039..8441784 100644
>> > --- a/gcc/testsuite/gcc.target/i386/m512-check.h
>> > +++ b/gcc/testsuite/gcc.target/i386/m512-check.h
>> > @@ -58,7 +58,8 @@ check_rough_##UINON_TYPE (UINON_TYPE u, const VALUE_TYPE
>> > *v, \
>> > \
>> >for (i = 0; i < ARRAY_SIZE (u.a); i++) \
>> > { \
>> > - VALUE_TYPE rel_err = (u.a[i] - v[i]) / v[i]; \
>> > + VALUE_TYPE rel_err; \
>> > + rel_err = v[i] != 0 ? (u.a[i] - v[i]) / v[i] : u.a[i]; \
>> >if (((rel_err < 0) ? -rel_err : rel_err) > eps) \
>> > { \
>> > err++;\
>>
>> We won't get zero from exponential function, so expecting zero result
>> is flawed anyway.
>>
>> If we would like to introduce universal epsilon comparisons into the
>> testsuite, then please read [1]. Being overly pedantic, the definition
>> should be "|(v[i] - u.a[i]) / v[i]|", as stated in [2].
>>
>> [1]
>> http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
>> [2] http://en.wikipedia.org/wiki/Relative_error
>>
>
> We get zero from testing zero-masking. Currently we produce 0/0 = NaN.
> Comparison with NaN is always false, so tests pass. But I think that
> this should be fixed to avoid division by zero. As for being more
> pedantic about comparison, I doubt that its useful, when we use
> 0.0001 as eps.
In this case, please add simple check for zero, with the above
comment. We don't test exp function, but masking.
Uros.
[PATCH] Reset INSN_DELETED_P when reusing insns in the selective scheduler
Hello,
While testing PR 58960 on ia64, I've enabled selective scheduling for
bootstrap and found two small issues. One is the other instance of PR
57662 and another one is a miscompile that happens because we emit an insn
with INSN_DELETED_P flag set; the insn then obviously does not get output
in the assembly file. The reason for this is that we've cached this insn
in the transformation cache and reused it after it was deleted from the
insn stream. The patch resetting the flag qualifies as obvious, but I've
discussed it additionally with Alexander, and will be committing it
shortly. (The bootstrap fail is actually a regression, also I don't see
how to make a (small) test case.)
Steven, we've been adding insns through add_insn_after and since you've
touched the code last, I wanted to ask you two things. First, do you want
an assert there that we do not add INSN_DELETED_P insns (like we have for
the "after" parameter in add_insn_after_nobb?) I have added one and it
didn't fail on the x86-64 bootstrap, which is no wonder since this one is
directly used by reorg and sel-sched only. Second, the comment for
add_insn_after about the BB parameter does not apply -- the code
immediately does
3871 void
3872 add_insn_after (rtx insn, rtx after, basic_block bb)
3873 {
3874 add_insn_after_nobb (insn, after);
3875 if (!BARRIER_P (after)
3876 && !BARRIER_P (insn)
3877 && (bb = BLOCK_FOR_INSN (after)))
so the bb parameter gets overwritten. Should that be fixed in line with
add_insn_before code?
Yours,
Andrey
2013-01-31 Andrey Belevantsev
* sel-sched-ir.c (sel_gen_insn_from_expr_after): Reset INSN_DELETED_P on
the insn being emitted.
Index: sel-sched-ir.c
===
*** sel-sched-ir.c (revision 207299)
--- sel-sched-ir.c (working copy)
*** sel_gen_insn_from_expr_after (expr_t exp
*** 1398,1403
--- 1398,1408
emit_expr = set_insn_init (expr, vinsn ? vinsn : EXPR_VINSN (expr),
seqno);
insn = EXPR_INSN_RTX (emit_expr);
+
+ /* The insn may come from the transformation cache, which may hold already
+ deleted insns, so mark it as not deleted. */
+ INSN_DELETED_P (insn) = 0;
+
add_insn_after (insn, after, BLOCK_FOR_INSN (insn));
flags = INSN_INIT_TODO_SSID;
Re: [PATCH][testsuite] Avoid division by zero.
On 30 Jan 19:24, Uros Bizjak wrote:
> On Thu, Jan 30, 2014 at 5:41 PM, Ilya Tocar wrote:
>
> > This patch removes possible division by zero.
> > Make check passes. Ok for trunk?
> >
> > 2014-01-30 Ilya Tocar
> >
> > * gcc.target/i386/m512-check.h: Use correct rounding values.
> >
> > ---
> > gcc/testsuite/gcc.target/i386/m512-check.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/i386/m512-check.h
> > b/gcc/testsuite/gcc.target/i386/m512-check.h
> > index 3209039..8441784 100644
> > --- a/gcc/testsuite/gcc.target/i386/m512-check.h
> > +++ b/gcc/testsuite/gcc.target/i386/m512-check.h
> > @@ -58,7 +58,8 @@ check_rough_##UINON_TYPE (UINON_TYPE u, const VALUE_TYPE
> > *v, \
> > \
> >for (i = 0; i < ARRAY_SIZE (u.a); i++) \
> > { \
> > - VALUE_TYPE rel_err = (u.a[i] - v[i]) / v[i]; \
> > + VALUE_TYPE rel_err; \
> > + rel_err = v[i] != 0 ? (u.a[i] - v[i]) / v[i] : u.a[i]; \
> >if (((rel_err < 0) ? -rel_err : rel_err) > eps) \
> > { \
> > err++;\
>
> We won't get zero from exponential function, so expecting zero result
> is flawed anyway.
>
> If we would like to introduce universal epsilon comparisons into the
> testsuite, then please read [1]. Being overly pedantic, the definition
> should be "|(v[i] - u.a[i]) / v[i]|", as stated in [2].
>
> [1]
> http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
> [2] http://en.wikipedia.org/wiki/Relative_error
>
We get zero from testing zero-masking. Currently we produce 0/0 = NaN.
Comparison with NaN is always false, so tests pass. But I think that
this should be fixed to avoid division by zero. As for being more
pedantic about comparison, I doubt that its useful, when we use
0.0001 as eps.
Re: [PATCH] Vector mode addresses
On Thu, Jan 30, 2014 at 9:47 PM, Jakub Jelinek wrote: > On Thu, Jan 30, 2014 at 08:27:47PM +, Paulo Matos wrote: >> Yes, it looks strange but it was the way we came up with to >> implement an instruction that loads from a pair of addresses. >> >> From what I wrote previously to Richard. >> "We have an instruction that loads two 32 bit values into a lower >> and upper parts of a 64bit register using a base register and a 64 >> bit register used as a double index. >> So, >> r1 <- [r0, r2] >> means: >> low(r1) = [r0 + low(r2)] >> high(r1) = [r0 + high(r2)]" > > That sounds like gather instruction e.g. i?86 AVX2/AVX512F has. > I don't like using vector mode for the address though, i?86 uses UNSPECs and > IMNSHO you should too. Or express it as vec_concat of two MEM loads > where address of each one will be the base + vec_select of the vector > register. Yeah, I don't like it either. It opens a whole can of worms I think. Richard. > Jakub
Re: [PATCH] Fixing PR60000: A bug in the vectorizer.
On Thu, 30 Jan 2014, Cong Hou wrote:
> Hi
>
> PR6 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6) is caused by
> GCC vectorizer. The bug appears when handling vectorization patterns. When
> a pattern statement has additional new statements stored in pattern_def_seq
> in vect_transform_loop(), those statements are vectorized before the
> pattern statement. Once all those statements are handled, pattern_def_seq
> is set to NULL. However, if the pattern statement is a store,
> pattern_def_seq will not be set to NULL. In consequence, the next pattern
> statement will not have the correct pattern_def_seq
Is that because si and pattern_def_si point to the same stmts? Then
I'd prefer to do
if (is_store)
{
...
pattern_def_seq = NULL;
}
else if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
{
pattern_def_seq = NULL;
gsi_next (&si);
}
Richard.
>
> This bug can be fixed by nullifying pattern_def_seq before checking if the
> vectorized statement is a store. The patch is pasted below. Bootstrapped
> and tested on x86_64.
>
>
> thanks,
> Cong
>
>
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 95a324c..9df0d34 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2014-01-30 Cong Hou
> +
> + PR tree-optimization/6
> + * tree-vect-loop.c (vect_transform_loop): Set pattern_def_seq to
> NULL
> + before checking if the vectorized statement is a store. A store
> + statement can be a pattern one.
> +
> 2014-01-27 Jakub Jelinek
>
> PR bootstrap/59934
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index fa61d5c..f2ce70f 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2014-01-30 Cong Hou
> +
> + PR tree-optimization/6
> + * g++.dg/vect/pr6.cc: New test.
> +
> 2014-01-27 Christian Bruel
>
> * gcc.target/sh/torture/strncmp.c: New tests.
> diff --git a/gcc/testsuite/g++.dg/vect/pr6.cc
> b/gcc/testsuite/g++.dg/vect/pr6.cc
> new file mode 100644
> index 000..8a8bd22
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/vect/pr6.cc
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-fno-tree-vrp" } */
> +
> +void foo (bool* a, int* b)
> +{
> + for (int i = 0; i < 1000; ++i)
> +{
> + a[i] = i % 2;
> + b[i] = i % 3;
> +}
> +}
> +
> +/* { dg-final { cleanup-tree-dump "vect" } } */
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index 69c8d21..8c8bece 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -6044,6 +6044,10 @@ vect_transform_loop (loop_vec_info loop_vinfo)
>
> grouped_store = false;
> is_store = vect_transform_stmt (stmt, &si, &grouped_store, NULL,
> NULL);
> +
> + if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
> + pattern_def_seq = NULL;
> +
>if (is_store)
> {
> if (STMT_VINFO_GROUPED_ACCESS (stmt_info))
> @@ -6068,10 +6072,7 @@ vect_transform_loop (loop_vec_info loop_vinfo)
> }
>
> if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
> - {
> - pattern_def_seq = NULL;
> - gsi_next (&si);
> - }
> + gsi_next (&si);
> } /* stmts in BB */
> } /* BBs in loop */
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH] Don't COND_EXEC frame related instructions (PR target/59923)
On Thu, 30 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on arm, because ifcvt decides to conditionalize
> a frame related instruction that restores a call saved register and adjusts
> stack pointer (== CFA) in order to merge shrink-wrapped and
> non-shrink-wrapped basic blocks. I don't see a way how to conditionalize
> DW_CFA_restore in DWARF[234] unwind info, and while for the CFA adjustment
> one perhaps could emit conditional expression, not sure if the condition
> register is easily expressible in unwind info and whether it won't be
> clobbered by later instructions.
>
> So, this patch just refuses to put COND_EXEC on frame related instructions.
>
> Kyrill has kindly bootstrapped/regtested this on arm, ok for trunk?
Sounds reasonable to me.
Thanks,
Richard.
> 2014-01-30 Jakub Jelinek
>
> PR target/59923
> * ifcvt.c (cond_exec_process_insns): Don't conditionalize
> frame related instructions.
>
> * gcc.target/arm/pr59923.c: New test.
>
> --- gcc/ifcvt.c.jj2014-01-09 08:20:55.0 +0100
> +++ gcc/ifcvt.c 2014-01-29 17:16:29.912259159 +0100
> @@ -338,6 +338,10 @@ cond_exec_process_insns (ce_if_block *ce
>
>gcc_assert (NONJUMP_INSN_P (insn) || CALL_P (insn));
>
> + /* dwarf2out can't coope with conditional unwind info. */
> + if (reload_completed && RTX_FRAME_RELATED_P (insn))
> + return FALSE;
> +
>/* Remove USE insns that get in the way. */
>if (reload_completed && GET_CODE (PATTERN (insn)) == USE)
> {
> --- gcc/testsuite/gcc.target/arm/pr59923.c.jj 2014-01-29 17:39:32.355116229
> +0100
> +++ gcc/testsuite/gcc.target/arm/pr59923.c2014-01-29 17:39:10.0
> +0100
> @@ -0,0 +1,24 @@
> +/* PR target/59923 */
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_thumb2_ok } */
> +/* { dg-options "-O2 -mcpu=cortex-a15 -fno-strict-aliasing -mthumb -g" } */
> +
> +struct S
> +{
> + void *s;
> + struct T { unsigned short a; unsigned char b[4], c[4]; } *t;
> +} s;
> +void bar (void *);
> +
> +void
> +foo (struct S *x, int *y)
> +{
> + if (*y > 0)
> +return;
> + else if (x->t->b[0] == 0x43 && x->t->b[1] == 0x6d && x->t->c[0] == 1)
> +x->s = &s;
> + else
> +*y = 16384;
> + if (*y > 0)
> +bar (x);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH] Fix PR59993
On Thu, 30 Jan 2014, Marc Glisse wrote: > On Thu, 30 Jan 2014, Richard Biener wrote: > > >/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */ > >ptr = gimple_assign_rhs1 (stmt); > >off1 = gimple_assign_rhs2 (stmt); > > ! if (TREE_CODE (ptr) != SSA_NAME > > ! || !has_single_use (ptr)) > > return false; > >def_stmt = SSA_NAME_DEF_STMT (ptr); > >if (!is_gimple_assign (def_stmt) > > ! || gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR > > ! || !can_propagate_from (def_stmt)) > > return false; > >ptr = gimple_assign_rhs1 (def_stmt); > >off2 = gimple_assign_rhs2 (def_stmt); > > Hello, > > we have 2 helpers get_prop_source_stmt and defcodefor_name in > tree-ssa-forwprop.c, but you don't seem to like them. Do they have a > particular drawback or is it just easier to rewrite the code than to remember > how to use those? I am asking so I know whether I can / should use them in my > future patches. I don't like them too much - get_prop_source_stmt possibly causes quadratic compile-time complexity and defcodefor_name is just ugly ;) To get rid of get_prop_source_stmt I'd like to move towards keeping a simple SSA value lattice in forwprop so one can get at the constant or SSA name a SSA name is a copy of in O(1) (similar to the copyprop lattice). defcodefor_name ... well, I hope to get started on a meta-description to tree / GIMPLE pattern matching machinery (and build our folders upon that) soon. Richard.
Re: [PATCH] Fix PR59990
On Thu, 30 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 30, 2014 at 07:25:03PM +0100, Richard Biener wrote:
> > *** 8886,8891
> > --- 8892,8932
> > || TREE_ADDRESSABLE (desttype))
> > return NULL_TREE;
> >
> > + /* Make sure we are not copying using a floating-point mode or
> > + a type whose size possibly does not match its precision. */
> > + if (FLOAT_MODE_P (TYPE_MODE (desttype))
> > + || TREE_CODE (desttype) == BOOLEAN_TYPE
> > + || TREE_CODE (desttype) == ENUMERAL_TYPE)
> > + {
> > + /* A more suitable int_mode_for_mode would return a vector
> > +integer mode for a vector float mode or a integer complex
> > +mode for a float complex mode if there isn't a regular
> > +integer mode covering the mode of desttype. */
> > + enum machine_mode mode = int_mode_for_mode (TYPE_MODE (desttype));
> > + if (mode == BLKmode)
> > + desttype = NULL_TREE;
> > + else
> > + desttype = build_nonstandard_integer_type (GET_MODE_BITSIZE (mode),
> > + 1);
> > + }
>
> As I said in the PR, I think you want to do the build_aligned_type
> just in case e.g. the floating point type is more aligned than the integer
> or vice versa.
I think that calls were misguided - we don't use the types alignment
as-is, in fact we rely on pointer alignment for the source and destination
addresses and then only for !STRICT_ALIGNMENT targets make
mis-aligned accesses by lowering the types alignment. If you
apply custom alignment to a type that will override the pointer/decl
alignment forcefully thus IMHO those type align adjustments were
simply wrong.
Richard.
> > - {
> > - tree srcitype
> > - = lang_hooks.types.type_for_mode (TYPE_MODE (srctype),
> > - TYPE_UNSIGNED (srctype));
> > - srctype = build_aligned_type (srcitype, TYPE_ALIGN (srctype));
> > - }
> > -
>
> Jakub
