[PATCH, i386]: Some trivial cleanups
2017-05-06 Uros Bizjak
* config/i386/i386.c (ext_80387_constant_init): Do not explicitly
initialize to zero.
(init_regs): Remove declaration.
(function_arg_advance_32): Initialize error_p as boolean variable.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to mainline SVN.
Uros.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9c429de..0d27113 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2569,7 +2569,7 @@ enum x86_64_reg_class
/* Table of constants used by fldpi, fldln2, etc */
static REAL_VALUE_TYPE ext_80387_constants_table [5];
-static bool ext_80387_constants_init = 0;
+static bool ext_80387_constants_init;
static struct machine_function * ix86_init_machine_status (void);
@@ -8544,9 +8544,6 @@ ix86_asm_output_function_label (FILE *asm_out_file, const
char *fname,
}
}
-/* regclass.c */
-extern void init_regs (void);
-
/* Implementation of call abi switching target hook. Specific to FNDECL
the specific call register sets are set. See also
ix86_conditional_register_usage for more details. */
@@ -9665,7 +9662,7 @@ function_arg_advance_32 (CUMULATIVE_ARGS *cum,
machine_mode mode,
HOST_WIDE_INT words)
{
int res = 0;
- bool error_p = NULL;
+ bool error_p = false;
if (TARGET_IAMCU)
{
@@ -9710,13 +9707,13 @@ pass_in_reg:
case DFmode:
if (cum->float_in_sse == -1)
- error_p = 1;
+ error_p = true;
if (cum->float_in_sse < 2)
break;
/* FALLTHRU */
case SFmode:
if (cum->float_in_sse == -1)
- error_p = 1;
+ error_p = true;
if (cum->float_in_sse < 1)
break;
/* FALLTHRU */
@@ -9978,13 +9975,13 @@ pass_in_reg:
case DFmode:
if (cum->float_in_sse == -1)
- error_p = 1;
+ error_p = true;
if (cum->float_in_sse < 2)
break;
/* FALLTHRU */
case SFmode:
if (cum->float_in_sse == -1)
- error_p = 1;
+ error_p = true;
if (cum->float_in_sse < 1)
break;
/* FALLTHRU */
[patch, testsuite, PR80606] Remove default_packed lines from i386/avx-vtestp{d,s}*
Hi,
The test-cases i386/avx-vtestp{d,s}* contain lines guarded with target
default_packed, using absolute line numbers 150 and 164. The absolute
line numbers intend to refer to the position of the packed attribute in
unions ieee754_float and ieee754_double in m128-check.h, but they do not
match the actual lines.
The default_packed lines were introduced for netware support in 2009,
but netware support was removed in 2011.
The line numbers changes from:
...
149unsigned sign : 1;
150 } bits __attribute__((packed));
151 };
--
163unsigned sign : 1;
164 } bits __attribute__((packed));
165 };
...
to:
...
149unsigned long frac : 23;
150unsigned exp : 8;
151unsigned sign : 1;
--
163unsigned long frac0 : 20;
164unsigned exp : 11;
165unsigned sign : 1;
...
in Jan 2014 in r207150.
Apparently nobody noticed when the line numbers changed, so they are
effectively unmaintained.
This patch removes the unmaintained lines.
Tested on x86_64.
OK for trunk?
Thanks,
- Tom
Remove default_packed lines from i386/avx-vtestp{d,s}*
2017-05-05 Tom de Vries
PR testsuite/80606
* gcc.target/i386/avx-vtestpd-1.c: Remove default_packed lines.
* gcc.target/i386/avx-vtestpd-2.c: Same.
* gcc.target/i386/avx-vtestpd-256-1.c: Same.
* gcc.target/i386/avx-vtestpd-256-2.c: Same.
* gcc.target/i386/avx-vtestpd-256-3.c: Same.
* gcc.target/i386/avx-vtestpd-3.c: Same.
* gcc.target/i386/avx-vtestps-1.c: Same.
* gcc.target/i386/avx-vtestps-2.c: Same.
* gcc.target/i386/avx-vtestps-256-1.c: Same.
* gcc.target/i386/avx-vtestps-256-2.c: Same.
* gcc.target/i386/avx-vtestps-256-3.c: Same.
* gcc.target/i386/avx-vtestps-3.c: Same.
---
gcc/testsuite/gcc.target/i386/avx-vtestpd-1.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestpd-2.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestpd-256-1.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestpd-256-2.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestpd-256-3.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestpd-3.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestps-1.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestps-2.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestps-256-1.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestps-256-2.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestps-256-3.c | 2 --
gcc/testsuite/gcc.target/i386/avx-vtestps-3.c | 2 --
12 files changed, 24 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/avx-vtestpd-1.c b/gcc/testsuite/gcc.target/i386/avx-vtestpd-1.c
index 6b52d78..a00d3e6 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vtestpd-1.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vtestpd-1.c
@@ -1,8 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target avx } */
/* { dg-options "-O2 -mavx -DNEED_IEEE754_DOUBLE" } */
-/* { dg-warning "attribute ignored" "" { target default_packed } 164 } */
-/* { dg-message " from " "include chain" { target default_packed } 0 } */
#include "avx-check.h"
diff --git a/gcc/testsuite/gcc.target/i386/avx-vtestpd-2.c b/gcc/testsuite/gcc.target/i386/avx-vtestpd-2.c
index 57dfeeb..f7b6358 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vtestpd-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vtestpd-2.c
@@ -1,8 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target avx } */
/* { dg-options "-O2 -mavx -DNEED_IEEE754_DOUBLE" } */
-/* { dg-warning "attribute ignored" "" { target default_packed } 164 } */
-/* { dg-message " from " "include chain" { target default_packed } 0 } */
#include "avx-check.h"
diff --git a/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-1.c b/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-1.c
index 050f140..bed4456 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-1.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-1.c
@@ -1,8 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target avx } */
/* { dg-options "-O2 -mavx -DNEED_IEEE754_DOUBLE" } */
-/* { dg-warning "attribute ignored" "" { target default_packed } 164 } */
-/* { dg-message " from " "include chain" { target default_packed } 0 } */
#include "avx-check.h"
diff --git a/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-2.c b/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-2.c
index 0954f1d..d29ff79 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-2.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-2.c
@@ -1,8 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target avx } */
/* { dg-options "-O2 -mavx -DNEED_IEEE754_DOUBLE" } */
-/* { dg-warning "attribute ignored" "" { target default_packed } 164 } */
-/* { dg-message " from " "include chain" { target default_packed } 0 } */
#include "avx-check.h"
diff --git a/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-3.c b/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-3.c
index 8a6e32e..2f76257 100644
--- a/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-3.c
+++ b/gcc/testsuite/gcc.target/i386/avx-vtestpd-256-3.c
@@ -
Re: [PATCH 1/3] Remove support for obsolete x86 -malign-foo options
On Tue, Apr 18, 2017 at 8:30 PM, Denys Vlasenko wrote:
> 2017-04-18 Denys Vlasenko
>
> * config/i386/i386-common.c (ix86_handle_option): Remove support
> for obsolete -malign-loops, -malign-jumps and -malign-functions
> options.
> * config/i386/i386.opt: Likewise.
> Index: gcc/common/config/i386/i386-common.c
> ===
> --- gcc/common/config/i386/i386-common.c(revision 240663)
> +++ gcc/common/config/i386/i386-common.c(working copy)
> @@ -998,38 +998,6 @@ ix86_handle_option (struct gcc_options *opts,
> }
>return true;
>
> -
> - /* Comes from final.c -- no real reason to change it. */
> -#define MAX_CODE_ALIGN 16
> -
> -case OPT_malign_loops_:
> - warning_at (loc, 0, "-malign-loops is obsolete, use -falign-loops");
> - if (value > MAX_CODE_ALIGN)
> - error_at (loc, "-malign-loops=%d is not between 0 and %d",
> - value, MAX_CODE_ALIGN);
> - else
> - opts->x_align_loops = 1 << value;
> - return true;
> -
> -case OPT_malign_jumps_:
> - warning_at (loc, 0, "-malign-jumps is obsolete, use -falign-jumps");
> - if (value > MAX_CODE_ALIGN)
> - error_at (loc, "-malign-jumps=%d is not between 0 and %d",
> - value, MAX_CODE_ALIGN);
> - else
> - opts->x_align_jumps = 1 << value;
> - return true;
> -
> -case OPT_malign_functions_:
> - warning_at (loc, 0,
> - "-malign-functions is obsolete, use -falign-functions");
> - if (value > MAX_CODE_ALIGN)
> - error_at (loc, "-malign-functions=%d is not between 0 and %d",
> - value, MAX_CODE_ALIGN);
> - else
> - opts->x_align_functions = 1 << value;
> - return true;
> -
> case OPT_mbranch_cost_:
>if (value > 5)
> {
> Index: gcc/config/i386/i386.opt
> ===
> --- gcc/config/i386/i386.opt(revision 240663)
> +++ gcc/config/i386/i386.opt(working copy)
> @@ -205,18 +205,6 @@ malign-double
> Target Report Mask(ALIGN_DOUBLE) Save
> Align some doubles on dword boundary.
>
> -malign-functions=
> -Target RejectNegative Joined UInteger
> -Function starts are aligned to this power of 2.
> -
> -malign-jumps=
> -Target RejectNegative Joined UInteger
> -Jump targets are aligned to this power of 2.
> -
> -malign-loops=
> -Target RejectNegative Joined UInteger
> -Loop code aligned to this power of 2.
> -
> malign-stringops
> Target RejectNegative Report InverseMask(NO_ALIGN_STRINGOPS,
> ALIGN_STRINGOPS) Save
> Align destination of the string operations.
Instead of removing the above definitions, please rather redefine them
in a similar way -mcpu in i386.opt is obsoleted, e.g.:
malign-functions=
Target RejectNegative Joined Undocumented Alias(falign-functions=)
Warn(%<-malign-functions%> is obsolete, use %<-falign-functions%>)
This cleanup should be done a long time ago, the patch can be
committed independently of other patches in the series.
Uros.
Re: [patch, testsuite, PR80606] Remove default_packed lines from i386/avx-vtestp{d,s}*
On Sat, May 6, 2017 at 9:12 AM, Tom de Vries wrote:
> Hi,
>
> The test-cases i386/avx-vtestp{d,s}* contain lines guarded with target
> default_packed, using absolute line numbers 150 and 164. The absolute line
> numbers intend to refer to the position of the packed attribute in unions
> ieee754_float and ieee754_double in m128-check.h, but they do not match the
> actual lines.
>
> The default_packed lines were introduced for netware support in 2009, but
> netware support was removed in 2011.
>
> The line numbers changes from:
> ...
>149unsigned sign : 1;
>150 } bits __attribute__((packed));
>151 };
> --
>163unsigned sign : 1;
>164 } bits __attribute__((packed));
>165 };
> ...
>
> to:
> ...
>149unsigned long frac : 23;
>150unsigned exp : 8;
>151unsigned sign : 1;
> --
>163unsigned long frac0 : 20;
>164unsigned exp : 11;
>165unsigned sign : 1;
> ...
> in Jan 2014 in r207150.
>
> Apparently nobody noticed when the line numbers changed, so they are
> effectively unmaintained.
>
> This patch removes the unmaintained lines.
>
> Tested on x86_64.
>
> OK for trunk?
OK.
Thanks,
Uros.
[committed, testsuite] Replace absolute line numbers in g++.dg/{debug,goacc}
Hi,
this patch replaces absolute line numbers in g++.dg/{debug,goacc}.
Tested on x86_64.
Committed as obvious.
Thanks,
- Tom
Replace absolute line numbers in g++.dg/{debug,goacc}
2017-05-05 Tom de Vries
PR testsuite/80557
* g++.dg/debug/dwarf2/dwarf2-1.C: Replace absolute line numbers.
* g++.dg/debug/dwarf2/dwarf2-2.C: Same.
* g++.dg/debug/dwarf2/pr46123-2.C: Same.
* g++.dg/debug/dwarf2/typedef5.C: Same.
* g++.dg/goacc/data-1.C: Same.
---
gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C | 3 +--
gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C | 3 +--
gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C | 3 +--
gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C | 2 +-
gcc/testsuite/g++.dg/goacc/data-1.C | 15 ++-
5 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C
index d0176ba..ada9fef 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C
@@ -1,3 +1,4 @@
+/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } } */
// Copyright (C) 2006 Free Software Foundation, Inc.
// Contributed by Nathan Sidwell 6 Jan 2006
@@ -20,5 +21,3 @@ namespace N
}
N::Derived thing;
-
-/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } 1 } */
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C b/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C
index 23175c6..1386186 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C
@@ -1,3 +1,4 @@
+/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } } */
// PR debug/27057
// { dg-do compile }
// { dg-options "-gdwarf -feliminate-dwarf2-dups" }
@@ -15,5 +16,3 @@ void A::foo ()
{
using namespace N;
}
-
-/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } 1 } */
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C b/gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C
index b262034..71e2baf 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C
@@ -1,3 +1,4 @@
+/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } } */
// PR debug/46123
// { dg-do compile }
// { dg-options "-g -feliminate-dwarf2-dups" }
@@ -45,5 +46,3 @@ int main ()
return 1;
return 0;
}
-
-/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } 1 } */
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C b/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
index b541ae4..e7c5003 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
@@ -1,3 +1,4 @@
+/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } } */
// Origin: PR debug/46101
// { dg-options "-gdwarf-2 -feliminate-dwarf2-dups" }
// { dg-do compile }
@@ -9,4 +10,3 @@ typedef struct
A a;
-/* { dg-bogus "-feliminate-dwarf2-dups is broken for C\\+\\+, ignoring" "broken -feliminate-dwarf2-dups" { xfail *-*-* } 1 } */
diff --git a/gcc/testsuite/g++.dg/goacc/data-1.C b/gcc/testsuite/g++.dg/goacc/data-1.C
index 2b210dc..73de964 100644
--- a/gcc/testsuite/g++.dg/goacc/data-1.C
+++ b/gcc/testsuite/g++.dg/goacc/data-1.C
@@ -3,7 +3,11 @@ foo (int &a, int (&b)[100], int &n)
{
#pragma acc enter data copyin (a, b) async wait
#pragma acc enter data create (b[20:30]) async wait
-#pragma acc enter data (a) /* { dg-error "expected '#pragma acc' clause before '\\\(' token" } */
+
+#pragma acc enter data (a)
+ /* { dg-error "expected '#pragma acc' clause before '\\\(' token" "" { target *-*-* } .-1 } */
+ /* { dg-error "has no data movement clause" "" { target *-*-* } .-2 } */
+
#pragma acc enter data create (b(1:10)) /* { dg-error "expected '\\\)' before '\\\(' token" } */
#pragma acc exit data delete (a) if (0)
#pragma acc exit data copyout (b) if (a)
@@ -22,7 +26,11 @@ foo (T &a, T (&b)[100], T &n)
{
#pragma acc enter data copyin (a, b) async wait
#pragma acc enter data create (b[20:30]) async wait
-#pragma acc enter data (a) /* { dg-error "expected '#pragma acc' clause before '\\\(' token" } */
+
+#pragma acc enter data (a)
+ /* { dg-error "expected '#pragma acc' clause before '\\\(' token" "" { target *-*-* } .-1 } */
+ /* { dg-error "has no data movement clause" "" { target *-*-* } .-2 } */
+
#pragma acc enter data create (b(1:10)) /* { dg-error "expected '\\\)' before '\\\(' token" } */
#pragma acc exit data delete (a) if (0)
#pragma acc exit data copyout (b) if (a)
@@ -34,6 +42,3 @@ foo (T &a, T (&b)[100], T &n)
#pragma
[testsuite, committed] Replace absolute line numbers in gcc.target/aarch64
Hi,
this patch replaces absolute line numbers in gcc.target/aarch64.
Tested on aarch64.
Committed as obvious.
Thanks,
- Tom
Replace absolute line numbers in gcc.target/aarch64
2017-05-05 Tom de Vries
PR testsuite/80557
* gcc.target/aarch64/spellcheck_1.c: Replace absolute line numbers.
* gcc.target/aarch64/spellcheck_2.c: Same.
* gcc.target/aarch64/spellcheck_3.c: Same.
---
gcc/testsuite/gcc.target/aarch64/spellcheck_1.c | 6 +++---
gcc/testsuite/gcc.target/aarch64/spellcheck_2.c | 6 +++---
gcc/testsuite/gcc.target/aarch64/spellcheck_3.c | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c b/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
index 76e54e8..ccfe417 100644
--- a/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
@@ -3,7 +3,7 @@
__attribute__((target ("arch=armv8-a-typo"))) void
foo ()
{
+ /* { dg-message "valid arguments are: \[^\n\r]*; did you mean 'armv8-a'?" "" { target *-*-* } .-1 } */
+ /* { dg-error "unknown value 'armv8-a-typo' for 'arch' target attribute" "" { target *-*-* } .-2 } */
+ /* { dg-error "target attribute 'arch=armv8-a-typo' is invalid" "" { target *-*-* } .-3 } */
}
-/* { dg-message "valid arguments are: \[^\n\r]*; did you mean 'armv8-a'?" "" { target *-*-* } 5 } */
-/* { dg-error "unknown value 'armv8-a-typo' for 'arch' target attribute" "" { target *-*-* } 5 } */
-/* { dg-error "target attribute 'arch=armv8-a-typo' is invalid" "" { target *-*-* } 5 } */
diff --git a/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c b/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c
index 80d4795..42ba51a 100644
--- a/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/spellcheck_2.c
@@ -3,7 +3,7 @@
__attribute__((target ("cpu=cortex-a57-typo"))) void
foo ()
{
+ /* { dg-message "valid arguments are: \[^\n\r]*; did you mean 'cortex-a57?" "" { target *-*-* } .-1 } */
+ /* { dg-error "unknown value 'cortex-a57-typo' for 'cpu' target attribute" "" { target *-*-* } .-2 } */
+ /* { dg-error "target attribute 'cpu=cortex-a57-typo' is invalid" "" { target *-*-* } .-3 } */
}
-/* { dg-message "valid arguments are: \[^\n\r]*; did you mean 'cortex-a57?" "" { target *-*-* } 5 } */
-/* { dg-error "unknown value 'cortex-a57-typo' for 'cpu' target attribute" "" { target *-*-* } 5 } */
-/* { dg-error "target attribute 'cpu=cortex-a57-typo' is invalid" "" { target *-*-* } 5 } */
diff --git a/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c b/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c
index ab1940f..03d2bbf 100644
--- a/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c
+++ b/gcc/testsuite/gcc.target/aarch64/spellcheck_3.c
@@ -3,7 +3,7 @@
__attribute__((target ("tune=cortex-a57-typo"))) void
foo ()
{
+ /* { dg-message "valid arguments are: \[^\n\r]*; did you mean 'cortex-a57?" "" { target *-*-* } .-1 } */
+ /* { dg-error "unknown value 'cortex-a57-typo' for 'tune' target attribute" "" { target *-*-* } .-2 } */
+ /* { dg-error "target attribute 'tune=cortex-a57-typo' is invalid" "" { target *-*-* } .-3 } */
}
-/* { dg-message "valid arguments are: \[^\n\r]*; did you mean 'cortex-a57?" "" { target *-*-* } 5 } */
-/* { dg-error "unknown value 'cortex-a57-typo' for 'tune' target attribute" "" { target *-*-* } 5 } */
-/* { dg-error "target attribute 'tune=cortex-a57-typo' is invalid" "" { target *-*-* } 5 } */
[testsuite, committed] Replace absolute line numbers in gcc.target/arm
Hi,
this patch replaces absolute line numbers in gcc.target/arm.
Tested on arm.
Committed as obvious.
Thanks,
- Tom
Replace absolute line numbers in gcc.target/arm
2017-05-05 Tom de Vries
PR testsuite/80557
* gcc.target/arm/pr69180.c: Replace absolute line numbers.
---
gcc/testsuite/gcc.target/arm/pr69180.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/pr69180.c b/gcc/testsuite/gcc.target/arm/pr69180.c
index 998c734..a43d0fe 100644
--- a/gcc/testsuite/gcc.target/arm/pr69180.c
+++ b/gcc/testsuite/gcc.target/arm/pr69180.c
@@ -8,9 +8,10 @@
#pragma GCC target ("fpu=neon-fp-armv8")
#define __ARM_NEON_FP 0
+/* { dg-warning ".__ARM_NEON_FP. redefined" "" { target *-*-* } .-1 } */
+
#define __ARM_FP 0
-#define __ARM_FEATURE_LDREX 0
+/* { dg-warning ".__ARM_FP. redefined" "" { target *-*-* } .-1 } */
-/* { dg-warning ".__ARM_NEON_FP. redefined" "" { target *-*-* } 10 } */
-/* { dg-warning ".__ARM_FP. redefined" "" { target *-*-* } 11 } */
-/* { dg-warning ".__ARM_FEATURE_LDREX. redefined" "" { target *-*-* } 12 } */
+#define __ARM_FEATURE_LDREX 0
+/* { dg-warning ".__ARM_FEATURE_LDREX. redefined" "" { target *-*-* } .-1 } */
Re: [patch,avr,committed]: Remove flag_strict_overflow from avr.md
Richard Biener writes:
> On Fri, 5 May 2017, Richard Sandiford wrote:
>> Richard Biener writes:
>> > On Fri, 5 May 2017, Georg-Johann Lay wrote:
>> >> On 05.05.2017 13:04, Richard Biener wrote:
>> >> > On Fri, 5 May 2017, Georg-Johann Lay wrote:
>> >> >
>> >> > > Applied this addendum to r247495 which removed
>> >> > > flag_strict_overflow. There
>> >> > > were remains of the flag in avr.md which broke the avr build.
>> >> > >
>> >> > > Committed as r247632.
>> >> >
>> >> > Whoops - sorry for not grepping besides .[ch] files...
>> >> >
>> >> > But... these patterns very much look like premature optimization
>> >> > and/or bugs. combine is supposed to handle this via simplify_rtx.
>> >>
>> >> Well, for now the patch just restores avr BE to be able to be build.
>> >
>> > Sure.
>> >
>> >> > Also note that on RTL we generally assume overflow wraps as we lose
>> >> > signedness of operands. Not sure what 'compare' in your patterns
>> >> > will end up with.
>> >> >
>> >> > The only flag_wrapv checks in RTL otherwise are in simplify-rtx.c
>> >> > for ABS which seems to be a singed RTL op.
>> >>
>> >> Which is a bug, IMO. Letting undefined overflow propagate to RTL
>> >> renders some RTL as if it has undefined behaviour. Consequence is
>> >> that testing the MSB must no more use signed comparisons on
>> >> less-zero resp. greater-or-equal-to-zero.
>> >>
>> >> Cf. https://gcc.gnu.org/PR75964 for an example:
>> >>
>> >>
>> >> typedef __UINT8_TYPE__ uint8_t;
>> >>
>> >> uint8_t abs8 (uint8_t x)
>> >> {
>> >> if (x & 0x80)
>> >> x = -x;
>> >>
>> >> if (x & 0x80)
>> >> x = 0x7f;
>> >>
>> >> return x;
>> >> }
>> >>
>> >> The first comparison is performed by a signed test against 0 (which
>> >> is reasonable and the best code in that case) but then we conclude
>> >> that the second test is always false, which is BUG.
>> >>
>> >> IMO the culprit is to let slip undefined overflow to RTL.
>> >
>> > Yes. I thought in RTL overflow is always well-defined (but then
>> > as I said your patterns are equally bogus).
>>
>> Yeah, me too. I don't see how the simplify-rtx.c code can be right.
>>
>> Is the following OK, if it passes testing?
>
> Yes. Can you add the testcase?
OK, here's what I installed after testing on aarch64-linux-gnu and
x86_64-linux-gnu.
Thanks,
Richard
2017-05-06 Richard Sandiford
gcc/
PR rtl-optimization/75964
* simplify-rtx.c (simplify_const_relational_operation): Remove
invalid handling of comparisons of integer ABS.
gcc/testsuite/
PR rtl-optimization/75964
* gcc.dg/torture/pr75964.c: New test.
Index: gcc/simplify-rtx.c
===
--- gcc/simplify-rtx.c 2017-05-05 13:44:27.364724260 +0100
+++ gcc/simplify-rtx.c 2017-05-05 13:44:36.580195277 +0100
@@ -5316,34 +5316,14 @@ simplify_const_relational_operation (enu
{
case LT:
/* Optimize abs(x) < 0.0. */
- if (!HONOR_SNANS (mode)
- && (!INTEGRAL_MODE_P (mode)
- || (!flag_wrapv && !flag_trapv)))
- {
- if (INTEGRAL_MODE_P (mode)
- && (issue_strict_overflow_warning
- (WARN_STRICT_OVERFLOW_CONDITIONAL)))
- warning (OPT_Wstrict_overflow,
-("assuming signed overflow does not occur when "
- "assuming abs (x) < 0 is false"));
- return const0_rtx;
- }
+ if (!INTEGRAL_MODE_P (mode) && !HONOR_SNANS (mode))
+ return const0_rtx;
break;
case GE:
/* Optimize abs(x) >= 0.0. */
- if (!HONOR_NANS (mode)
- && (!INTEGRAL_MODE_P (mode)
- || (!flag_wrapv && !flag_trapv)))
- {
- if (INTEGRAL_MODE_P (mode)
- && (issue_strict_overflow_warning
- (WARN_STRICT_OVERFLOW_CONDITIONAL)))
- warning (OPT_Wstrict_overflow,
-("assuming signed overflow does not occur when "
- "assuming abs (x) >= 0 is true"));
- return const_true_rtx;
- }
+ if (!INTEGRAL_MODE_P (mode) && !HONOR_NANS (mode))
+ return const_true_rtx;
break;
case UNGE:
Index: gcc/testsuite/gcc.dg/torture/pr75964.c
===
--- /dev/null 2017-05-05 17:46:05.071578834 +0100
+++ gcc/testsuite/gcc.dg/torture/pr75964.c 2017-05-06 08:35:54.794072285
+0100
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+
+typedef __UINT8_TYPE__ uint8_t;
+
+uint8_t __attribute__ ((noinline, noclone))
+abs8 (uint8_t x)
+{
+ if (x & 0x80)
+x = -x;
+
+ if (x & 0x80)
+x = 0x7f;
+
+ return x;
+}
+
+int
+main (void)
+{
+ if (abs8 (0) != 0
+ || abs8 (1) != 1
+ || abs8 (127) != 127
+ || abs8 (128) != 127
+ || abs8 (129) != 127
+ || abs8 (255) != 1)
+__bui
[testsuite, committed] Replace absolute line numbers in gcc.target/spu
Hi,
this patch replaces absolute line numbers in gcc.target/spu.
Tested on spu.
Committed as obvious.
Thanks,
- Tom
Replace absolute line numbers in gcc.target/spu
2017-05-05 Tom de Vries
PR testsuite/80557
* gcc.target/spu/Wmain.c: Replace absolute line numbers.
* gcc.target/spu/intrinsics-1.c: Same.
---
gcc/testsuite/gcc.target/spu/Wmain.c| 2 +-
gcc/testsuite/gcc.target/spu/intrinsics-1.c | 11 ---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.target/spu/Wmain.c b/gcc/testsuite/gcc.target/spu/Wmain.c
index b6bfe41..d80e182 100644
--- a/gcc/testsuite/gcc.target/spu/Wmain.c
+++ b/gcc/testsuite/gcc.target/spu/Wmain.c
@@ -2,6 +2,6 @@
/* { dg-options "-Wmain -mstdmain" } */
int main (void *wrong)/* { dg-warning "first argument of 'main' should be 'int'" } */
+ /* { dg-warning "'main' takes only zero or two arguments" "" { target *-*-* } .-1 } */
{
- /* { dg-warning "'main' takes only zero or two arguments" "" { target *-*-* } 4 } */
}
diff --git a/gcc/testsuite/gcc.target/spu/intrinsics-1.c b/gcc/testsuite/gcc.target/spu/intrinsics-1.c
index 2720889..b8974f6 100644
--- a/gcc/testsuite/gcc.target/spu/intrinsics-1.c
+++ b/gcc/testsuite/gcc.target/spu/intrinsics-1.c
@@ -10,10 +10,15 @@ void f(void)
int *a1;
_Complex double b;
gt = spu_cmpgt(a, N); /* { dg-error "parameter list" } */
+
gt = spu_cmpgt(a, a1); /* { dg-error "integer from pointer without a cast" } */
+ /* { dg-message "note: expected 'int'" "" { target *-*-* } .-1 } */
+
gt = spu_cmpgt(a, b); /* { dg-error "parameter list" } */
+
gt = spu_cmpgt(a, a);
- a = spu_cmpgt(a, a); /* { dg-message "note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts" } */
-/* { dg-message "note: expected 'int'" "" { target *-*-* } 13 } */
-/* { dg-error "incompatible types when assigning" "" { target *-*-* } 16 } */
+
+ a = spu_cmpgt(a, a);
+ /* { dg-message "note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts" "" { target *-*-* } .-1 } */
+ /* { dg-error "incompatible types when assigning" "" { target *-*-* } .-2 } */
}
[testsuite, committed] Replace absolute line numbers in gcc.target/powerpc
Hi,
this patch replaces absolute line numbers in gcc.target/powerpc.
Tested on ppc.
Committed as obvious.
Thanks,
- Tom
Replace absolute line numbers in gcc.target/powerpc
2017-05-05 Tom de Vries
PR testsuite/80557
* gcc.target/powerpc/altivec-macros.c: Replace absolute line numbers.
* gcc.target/powerpc/altivec-types-1.c: Same.
---
gcc/testsuite/gcc.target/powerpc/altivec-macros.c | 31 --
gcc/testsuite/gcc.target/powerpc/altivec-types-1.c | 8 --
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-macros.c b/gcc/testsuite/gcc.target/powerpc/altivec-macros.c
index c07eaa3..91bf120 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-macros.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-macros.c
@@ -23,42 +23,45 @@ _Pragma ("__vector")
#undef __vector
#define __vector __new_vector
+/* { dg-message "location of the previous" "prev __vector defn" { target *-*-* } .-1 } */
#undef __pixel
#define __pixel __new_pixel
+/* { dg-message "location of the previous" "prev __pixel defn" { target *-*-* } .-1 } */
#undef __bool
#define __bool __new_bool
+/* { dg-message "location of the previous" "prev __bool defn"{ target *-*-* } .-1 } */
#undef vector
#define vector new_vector
+/* { dg-message "location of the previous" "prev vector defn"{ target *-*-* } .-1 } */
#undef pixel
#define pixel new_pixel
+/* { dg-message "location of the previous" "prev pixel defn" { target *-*-* } .-1 } */
#undef bool
#define bool new_bool
+/* { dg-message "location of the previous" "prev bool defn" { target *-*-* } .-1 } */
/* Re-definition of "unconditional" macros. */
/* Warnings should be generated as usual. */
#define __vector __newer_vector
+/* { dg-warning "redefined" "__vector redefined" { target *-*-* } .-1 } */
+
#define __pixel __newer_pixel
+/* { dg-warning "redefined" "__pixel redefined" { target *-*-* } .-1 } */
+
#define __bool __newer_bool
+/* { dg-warning "redefined" "__bool redefined"{ target *-*-* } .-1 } */
+
#define vector newer_vector
+/* { dg-warning "redefined" "vector redefined"{ target *-*-* } .-1 } */
+
#define pixel newer_pixel
-#define bool newer_bool
+/* { dg-warning "redefined" "pixel redefined" { target *-*-* } .-1 } */
-/* { dg-warning "redefined" "__vector redefined" { target *-*-* } 45 } */
-/* { dg-warning "redefined" "__pixel redefined" { target *-*-* } 46 } */
-/* { dg-warning "redefined" "__bool redefined"{ target *-*-* } 47 } */
-/* { dg-warning "redefined" "vector redefined"{ target *-*-* } 48 } */
-/* { dg-warning "redefined" "pixel redefined" { target *-*-* } 49 } */
-/* { dg-warning "redefined" "bool redefined" { target *-*-* } 50 } */
-
-/* { dg-message "location of the previous" "prev __vector defn" { target *-*-* } 25 } */
-/* { dg-message "location of the previous" "prev __pixel defn" { target *-*-* } 28 } */
-/* { dg-message "location of the previous" "prev __bool defn"{ target *-*-* } 31 } */
-/* { dg-message "location of the previous" "prev vector defn"{ target *-*-* } 34 } */
-/* { dg-message "location of the previous" "prev pixel defn" { target *-*-* } 37 } */
-/* { dg-message "location of the previous" "prev bool defn" { target *-*-* } 40 } */
+#define bool newer_bool
+/* { dg-warning "redefined" "bool redefined" { target *-*-* } .-1 } */
diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c b/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c
index bcce2a3..b26f16e 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-types-1.c
@@ -76,10 +76,16 @@ __vector __bool unsigned int vbui; /* { dg-error "" } */
__vector __bool signed int vbsi; /* { dg-error "" } */
__vector __bool unsigned vbuj; /* { dg-error "" } */
__vector __bool signed vbsj; /* { dg-error "" } */
+
__vector signed float vsf; /* { dg-error "" } */
+/* { dg-message "note: previous" "prev vsf" { target *-*-* } .-1 } */
+
__vector unsigned float vuf; /* { dg-error "" } */
__vector short float vsf; /* { dg-error "" } */
+
__vector signed double vsd; /* { dg-error "" } */
+/* { dg-message "note: previous" "prev vsd" { target *-*-* } .-1 } */
+
__vector unsigned double vud; /* { dg-error "" } */
__vector short double vsd; /* { dg-error "" } */
__vector __bool float vbf; /* { dg-error "" } */
@@ -87,5 +93,3 @@ __vector __bool double vbd; /* { dg-error "" } */
__vector __bool short float blf; /* { dg-error "" } */
__vector __bool short double vlbd; /* { dg-error "" } */
-/* { dg-message "note: previous" "prev vsf" { target *-*-* } 79 } */
-/* { dg-message "note: previous" "prev vsd" { target *-*-* } 82 } */
[testsuite, committed] Add absolute line number comment in gcc.target/avr/progmem-error-1.cpp
Hi,
this patchs adds an absolute line number comment in
gcc.target/avr/progmem-error-1.cpp.
Committed as obvious.
Thanks,
- Tom
Add absolute line number comment in gcc.target/avr/progmem-error-1.cpp
2017-05-05 Tom de Vries
* gcc.target/avr/progmem-error-1.cpp: Add abolute line number comment.
---
gcc/testsuite/gcc.target/avr/progmem-error-1.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/avr/progmem-error-1.cpp b/gcc/testsuite/gcc.target/avr/progmem-error-1.cpp
index 934b93c..b1676c1 100644
--- a/gcc/testsuite/gcc.target/avr/progmem-error-1.cpp
+++ b/gcc/testsuite/gcc.target/avr/progmem-error-1.cpp
@@ -2,4 +2,7 @@
#include "progmem.h"
-char str[] PROGMEM = "Hallo"; /* { dg-error "must be const" "" { target avr-*-* } 1 } */
+char str[] PROGMEM = "Hallo";
+/* This is the line number of the PROGMEM definition in progmem.h. Keep it
+ absolute. */
+/* { dg-error "must be const" "" { target avr-*-* } 1 } */
Re: [PATCH, GCC/ARM, Stage 1] PR71607: Fix ICE when loading constant
On 04/20/2017 11:54 AM, Prakhar Bahuguna wrote:
diff --git a/gcc/testsuite/gcc.target/arm/tls-disable-literal-pool.c
b/gcc/testsuite/gcc.target/arm/tls-disable-literal-pool.c
new file mode 100644
index 000..fe14a6b132c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/tls-disable-literal-pool.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target tls } */
+/* { dg-require-effective-target arm_cortex_m } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-options "-mslow-flash-data" } */
+
+__thread int x = 0;
+
+int
+bar ()
+{
+ return x;
+}
+
+/* { dg-error "accessing thread-local storage is not currently supported with -mpure-code or
-mslow-flash-data" "" { target *-*-* } 12 } */
Absolute line numbers make the testsuite harder to maintain, and in this
case it's not necessary.
Please put the dg-error:
- on the same line as the return, and remove the line number, or
- on the line after the return, and use relative line number .-1
Thanks,
- Tom
Re: [PATCH] c++ parser: fix-it hints for wrong usage of 'friend' and 'auto'
On 2 May, Martin Sebor wrote:
> On 04/29/2017 04:23 PM, Volker Reichelt wrote:
>> Hi,
>>
>> the following patch adds fix-it hints to the C++ parser for two wrongly
>> used keywords detected in cp_parser_decl_specifier_seq.
>>
>> Bootstrapped and regtested on x86_64-pc-linux-gnu.
>>
>> OK for trunk?
>>
>> Regards,
>> Volker
>>
>>
>> 2017-04-29 Volker Reichelt
>>
>> * parser.c (cp_parser_decl_specifier_seq): Add fix-it hints for
>> friend outside class and obsolete auto as storage-class-specifier.
>>
>> Index: gcc/cp/parser.c
>> ===
>> --- gcc/cp/parser.c 2017-04-28
>> +++ gcc/cp/parser.c 2017-04-28
>> @@ -13213,7 +13213,9 @@
>> case RID_FRIEND:
>>if (!at_class_scope_p ())
>> {
>> - error_at (token->location, "% used outside of class");
>> + gcc_rich_location richloc (token->location);
>> + richloc.add_fixit_remove ();
>> + error_at_rich_loc (&richloc, "% used outside of class");
>>cp_lexer_purge_token (parser->lexer);
>> }
>>else
>> @@ -13277,8 +13279,11 @@
>>
>>/* Complain about `auto' as a storage specifier, if
>> we're complaining about C++0x compatibility. */
>> - warning_at (token->location, OPT_Wc__11_compat, "%"
>> - " changes meaning in C++11; please remove it");
>> + gcc_rich_location richloc (token->location);
>> + richloc.add_fixit_remove ();
>> + warning_at_rich_loc (&richloc, OPT_Wc__11_compat,
>> + "% changes meaning in C++11; "
>> + "please remove it");
>
> What caught my eye here is the "please remove it" part :) Maybe
> it's me but it seems a little too forceful for a warning (despite
> the please). I would find a more conventional phrasing like
> "suggest to remove it" to be more suitable.
>
> That said, I wonder if removing the auto is actually the best
> suggestion. Wouldn't it more in line with where C++ is headed
> to suggest to remove the type and keep the auto?
>
> Martin
I think you missed that we are in C++98 mode here. Dropping the 'auto'
is the only viable choice to stay in C++98 mode and gain C++11
compatibility.
With that in mind, I don't think that the wording "please remove it"
is bad. The user is in C++98 mode and wants to know about C++11
compatibility (as OPT_Wc__11_compat is selected). So the compiler
gives her/him clear advice what to do.
For me "suggest to remove it" sounde too weak (more like "if you run
into problems in C++11, you could try to drop the 'auto' here").
Other solutions like "'auto' needs to be removed here to gain C++11
compatibility" sound a bit clumsy to me.
Regards,
Volker
New Spanish PO file for 'gcc' (version 7.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-7.1.0.es.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH 1/N] Introduce dump_flags_t type and use it instead of int type.
On Fri, May 05, 2017 at 01:38:21PM +0200, Richard Biener wrote: > On Fri, May 5, 2017 at 12:41 PM, Martin Liška wrote: > > Hello. > > > > There's first patch that just defines dump_flags_t as uint64_t and changes > > all > > corresponding interfaces that do use it. There's a problematic impact that > > all targets have to include dumpfile.h just right after coretypes.h. That > > makes > > the patch harder to properly test. I tried couple of cross-compilers and it > > works. > > > > Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. > > I've been also testing i686-linux-gnu bootstrap and x86_64-linux-gnu > > targets. > > > > Thoughts? > > So usually we get away with defining pervasive types in coretypes.h instead. > > Now I see how that can be not what we want if dump_flags_t becomes a > "class". Well, at least if it has too many (inline) methods. > > How many of our files end up including dumpfile.h? There's > > /* Most host source files will require the following headers. */ > #if !defined (GENERATOR_FILE) && !defined (USED_FOR_TARGET) > #include "machmode.h" > #include "signop.h" > #include "wide-int.h" > > at the end of coretypes.h so it might be possible to stuff dumpfile.h there. > > Or create a dump-flags.h header just containing the flag bits. I suppose > most files need it because they include some interfaces that have > dump_flags_t, not because they do dumping (they'd include dumpflags.h > already), right? well, if a header uses dumpflags_t and a forward declaration won't do it should include it right? but continueing the coretypes.h hacks may be expedient. > Anyway, I think the patch is a good thing (how do we make sure we > don't "regress", aka people using 'int', not knowing about dump_flag_t?). does it make sense to define it as a struct whose only member is a uint64_t? That way you'd have to explicitly pull out the field wherever you want to pass it to something taking an int. That would require defining a bunch of operator &/| etc. However we could also move from there to a set of bitfields for most of the flags and usually not need to explicitly extract the bit we want. Trev
[PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading
This is the 2nd of 3-5 patches to address pr78496.
Jump threading will examine ASSERT_EXPRs as it walks the IL and record
information from those ASSERT_EXPRs into the available expression and
const/copies tables where they're later used to simplify conditionals.
We're missing a couple things though.
First an ASSERT_EXPR with an EQ test creates an equality we can enter
into the const/copy tables. We were failing to do that. This is most
interesting when the RHS of the condition in the ASSERT_EXPR is a
constant, obviously. This has a secondary benefit of doing less work to
get better optimization.
Second, some ASSERT_EXPRs may start off as a relational test such as x
<= 0, but after range extraction and propagation they could be
simplified into an equality comparison. We already do this with
conditionals and generalizing that code to handle ASSERT_EXPRs is pretty
easy. This gives us more chances to extract simple equivalences from
the condition in ASSERT_EXPRs.
This patch fixes those 2 problems. I don't think it directly helps
pr78496 right now as we're unable to pick up the newly exposed jump
threads until VRP2. But that's a short term limitation that I've
already addressed locally :-)
Bootstrapped, regression tested and installed on the trunk.
jeff
ps. An astute observer might note that improving the effectiveness of
VRP jump threading seems counterproductive since I've stated I want to
remove VRP jump threading. These improvements don't significantly
change how I was planning to do that or the infrastructure we're going
to rely upon to make that change. All that changes is where we get the
information from -- ASSERT_EXPRs vs querying a new API that generates
the same information as needed.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b0c253b09ae..0f78f2a2ed1 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2017-05-06 Jeff Law
+
+ PR tree-optimization/78496
+ * tree-vrp.c (simplify_assert_expr_using_ranges): New function.
+ (simplify_stmt_using_ranges): Call it.
+ (vrp_dom_walker::before_dom_children): Extract equivalences
+ from an ASSERT_EXPR with an equality comparison against a
+ constant.
+
2017-05-06 Richard Sandiford
* lra-constraints.c (lra_copy_reg_equiv): New function.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index fca5b87e798..42782a6d17c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2017-05-06 Jeff Law
+
+ PR tree-optimization/78496
+ * gcc.dg/tree-ssa/ssa-thread-16.c: New test.
+ * gcc.dg/tree-ssa/ssa-thread-17.c: New test.
+
2017-05-06 Richard Sandiford
* gcc.target/aarch64/spill_1.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
new file mode 100644
index 000..78c349ca14d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
+
+/* We should thread the if (exp == 2) conditional on the
+ the path from inside the if (x) THEN arm. It is the only
+ jump threading opportunity in this code. */
+
+/* { dg-final { scan-tree-dump-times "Threaded" 1 "vrp1" } } */
+
+
+extern void abort (void) __attribute__ ((__nothrow__, __leaf__))
+ __attribute__ ((__noreturn__));
+
+int x;
+
+
+int code;
+void
+do_jump (int exp)
+{
+ switch (code)
+{
+case 4:
+ if ((exp) == 1)
+ goto normal;
+ if (x)
+ {
+ if (exp != 0)
+ abort ();
+ }
+ if ((exp) == 2)
+ goto normal;
+case 3:
+ abort ();
+}
+ normal:
+ ;
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
new file mode 100644
index 000..692658fbb4b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
+
+/* We should simplify one ASSERT_EXPR from a relational
+ into an equality test. */
+/* { dg-final { scan-tree-dump-times "Folded
into:\[^\r\n\]*ASSERT_EXPR\*\[^\r\n\]* == 1" 1 "vrp1" } } */
+
+/* And simplification of the ASSERT_EXPR leads to a jump threading
opportunity. */
+/* { dg-final { scan-tree-dump-times "Threaded" 1 "vrp1" } } */
+
+extern void abort (void) __attribute__ ((__nothrow__, __leaf__))
+ __attribute__ ((__noreturn__));
+
+union gimple_statement_d;
+typedef union gimple_statement_d *gimple;
+
+
+
+union gimple_statement_d
+{
+ unsigned num_ops;
+};
+
+void
+gimple_assign_set_rhs_with_ops_1 (int code, gimple stmt, unsigned new_rhs_ops)
+{
+
+ stmt->num_ops = new_rhs_ops + 1;
+ if (stmt->num_ops <= 1)
+abort ();
+ if (new_rhs_ops > 1)
+if (stmt->num_ops <= 2)
+ abort ();
+ if (new_rhs_ops > 2)
+ abort ();
+}
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index cf
[PING][patch] have "would be stringified in traditional C" warning in libcpp/macro.c be controlled by -Wtraditional
Pinging this: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01325.html
On 3/24/17, Eric Gallager wrote:
> It seemed odd to me that gcc was issuing a warning about compatibility
> with traditional C that I couldn't turn off by pushing/popping
> -Wtraditional over the problem area, so I made the attached (minor)
> patch to fix it. Survives bootstrap, but the only testing I've done
> with it has been compiling the one file that was giving me issues
> previously, which I'd need to reduce further to turn it into a proper
> test case.
>
> Thanks,
> Eric Gallager
>
> libcpp/ChangeLog:
>
> 2017-03-24 Eric Gallager
>
> * macro.c (check_trad_stringification): Have warning be controlled by
> -Wtraditional.
>
So I did the reducing I mentioned above and now have a testcase for
it; it was pretty similar to the one from here:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01319.html
so I combined them into a single testcase and have attached the
combined version. I can confirm that the testcase passes with my patch
applied.
/* { dg-do compile } */
#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wtraditional"
unsigned long bad = 1UL; /* { dg-warning "suffix" } */
/* The extra space before the pragma on this next line avoids a warning: */
#pragma GCC diagnostic pop
unsigned long ok_again = 2UL; /* { dg-bogus "suffix" } */
/* Redundant with the previous pop, but just shows that it fails to stop the
* following warning: */
#pragma GCC diagnostic ignored "-Wtraditional"
/* { dg-bogus "would be stringified" .+1 } */
#define UNW_DEC_PROLOGUE(fmt, body, rlen, arg) \
do { \
unw_rlen = rlen; \
*(int *)arg = body; \
printf("%s:%s(rlen=%lu)\n", \
fmt, (body ? "body" : "prologue"), (unsigned long)rlen); \
} while (0)
Re: [PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading
> +simplify_assert_expr_using_ranges (gimple *stmt)
> +{
> + return false;
I assume you didn't mean to leave that in?
Trev
Re: [PATCH, ARM] Add a new target hook to compute the frame layout
On 05/05/17 16:59, Richard Earnshaw (lists) wrote:
> On 05/09/16 17:43, Bernd Edlinger wrote:
>> Hi Richard,
>>
>> what do you think of this patch, is it OK (with the suggested wording)?
>>
>
> Bernd,
>
> Apologies, this seems to have fallen through a crack.
>
> I'm happy with this. Does it still apply?
>
Yes, only in a few places the context lines changed slightly.
So I attached a refreshed patch for your reference.
> If so, I suggest applying it after a 24-hour cooling off period for any
> final comments.
>
Fine, then I will apply it on monday evening, unless someone objects.
Thanks
Bernd.
> R.
>
>>
>> Thanks
>> Bernd.
>>
>> On 08/05/16 16:06, Richard Earnshaw (lists) wrote:
>>> On 05/08/16 13:49, Bernd Edlinger wrote:
On 08/05/16 11:29, Richard Earnshaw (lists) wrote:
> On 04/08/16 22:16, Bernd Edlinger wrote:
>> Hi,
>>
>> this patch introduces a new target hook that allows the target's
>> INITIAL_ELIMINATION_OFFSET function to use cached values instead of
>> re-computing the frame layout every time.
>>
>> I have updated the documentation a bit and hope it is clearer this time.
>>
>> It still needs a review by ARM port maintainers.
>>
>> If the ARM port maintainers find this patch useful, that would be fine.
>>
>
> I need to look into this more, but my first thought was that the
> documentation is confusing, or there is a real problem in this patch.
>
Thanks for your quick response.
The documentation is actually the most difficult part for me.
> As I understand it the frame has to be re-laid out each time the
> contents of the frame changes (an extra register becomes live or another
> spill slot is needed). So saying that it is laid out once can't be
> right if (as I read it initially) you mean 'once per function' since I
> think it needs to be 'once for each time the frame contents changes'.
>
> Of course, things might be a bit different with LRA compared with
> reload, but I strongly suspect this is never going to be an 'exactly
> once per function' operation.
>
Right. It will be done 2 or 3 times for each function.
LRA and reload behave identical in that respect.
But each time reload changes something in the input data the
INITIAL_EMIMINATION_OFFSET is called several times, and the results
have to be consistent in each iteration.
The frame layout function has no way to know if the frame layout
is expected to change or not.
Many targets use reload_completed as an indication when the frame layout
may not change at all, but that is only an approximation.
> Can you clarify your meaning in the documentation please?
>
I meant 'once' in the sense of 'once for each time the frame contents
change'.
Thus I'd change that sentence to:
"This target hook allows the target to compute the frame layout once for
each time the frame contents change and make use of the cached frame
layout in @code{INITIAL_ELIMINATION_OFFSET} instead of re-computing it
on every invocation. This is particularly useful for targets that have
an expensive frame layout function. Implementing this callback is
optional."
>>>
>>> Thanks, that's pretty much what I expected would be the case.
>>>
>>> Could I suggest:
>>>
>>> This target hook is called once each time the frame layout needs to be
>>> recalculated. The calculations can be cached by the target and can then
>>> be used by @code{INITIAL_ELIMINATION_OFFSET} instead of re-computing the
>>> layout on every invocation of that hook. This is particularly useful
>>> for targets that have an expensive frame layout function. Implementing
>>> this callback is optional.
>>>
>>> R.
>>>
Thanks
Bernd.
> R.
>
>>
>> Thanks
>> Bernd.
>>
>> On 06/21/16 23:29, Jeff Law wrote:
>>> On 06/16/2016 08:47 AM, Bernd Edlinger wrote:
Hi!
By the design of the target hook INITIAL_ELIMINATION_OFFSET
it is necessary to call this function several times with
different register combinations.
Most targets use a cached data structure that describes the
exact frame layout of the current function.
It is safe to skip the computation when reload_completed = true,
and most targets do that already.
However while reload is doing its work, it is not clear when to
do the computation and when not. This results in unnecessary
work. Computing the frame layout can be a simple function or an
arbitrarily complex one, that walks all instructions of the current
function for instance, which is more or less the common case.
This patch adds a new optional target hook that can be used
by the target to factor th
Re: [PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading
On 05/06/2017 09:38 AM, Trevor Saunders wrote:
+simplify_assert_expr_using_ranges (gimple *stmt)
+{
+ return false;
I assume you didn't mean to leave that in?
No I didn't. I used to to extract the testcases. Ugh.
jeff
Re: [PATCH v4 0/12] [i386] Improve 64-bit Microsoft to System V ABI pro/epilogues
On 05/05/2017 03:56 AM, Daniel Santos wrote: On 05/02/2017 05:40 AM, Kai Tietz wrote: Right, and Wine people will tell, if something doesn't work for them. So ok for me too. Kai Well, I haven't re-run these tests in a few months, but I got 272 failed wine tests with gcc 7.1 and 234 with my patch set rebased onto 7.1. So it looks like I'll be trying to diagnose these failures this weekend. Those are bad numbers. I had forgotten to filter out the testlist.o files. Below are my most recent numbers running Wine 2.7: gcc-5.4.0 CFLAGS="-march=native -O2 -g": 74 gcc-7.1.0 CFLAGS="-march=native -O2 -g": 74 gcc-7.1.0 CFLAGS="-march=nocona -mtune=generic -O2 -g": 79 gcc-7.1.0 CFLAGS="-march=native -O2 -g -mcall-ms2sysv-xlogues" (patched): 31 I'm building out a clean test environment on another machine to try to rule out clutter issues (and video driver issues) on my workstation. Daniel
[PATCH] PR80280: Fix quoting of candidate functions
Hi,
the following patch fixes some wrong quoting that was introduced by
Martin's patch for PR translation/80280, see
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=247607
Consider the following testcase:
struct A {};
bool b = !A();
On trunk we currently get the following diagnostic:
bug.cc:2:10: error: no match for 'operator!' (operand type is 'A')
bool b = !A();
^~~~
bug.cc:2:10: note: 'candidate: operator!(bool) '
bug.cc:2:10: note: no known conversion for argument 1 from 'A' to 'bool'
Note, that not only the candidate function, but also the surrounding
text is quoted in the second-to-last line.
With the patch, this line reads:
bug.cc:2:10: note: candidate: 'operator!(bool)'
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK for trunk?
Regards,
Volker
2017-05-06 Volker Reichelt
PR translation/80280
* call.c (print_z_candidate): Fix quoting.
Index: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 247720)
+++ gcc/cp/call.c (working copy)
@@ -3457,16 +3457,16 @@
{
cloc = loc;
if (candidate->num_convs == 3)
- inform (cloc, "%<%s%D(%T, %T, %T) %>", msg, fn,
+ inform (cloc, "%s%<%D(%T, %T, %T)%> ", msg, fn,
candidate->convs[0]->type,
candidate->convs[1]->type,
candidate->convs[2]->type);
else if (candidate->num_convs == 2)
- inform (cloc, "%<%s%D(%T, %T) %>", msg, fn,
+ inform (cloc, "%s%<%D(%T, %T)%> ", msg, fn,
candidate->convs[0]->type,
candidate->convs[1]->type);
else
- inform (cloc, "%<%s%D(%T) %>", msg, fn,
+ inform (cloc, "%s%<%D(%T)%> ", msg, fn,
candidate->convs[0]->type);
}
else if (TYPE_P (fn))
===
Re: [PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading
On Sat, May 6, 2017 at 8:03 AM, Jeff Law wrote:
> This is the 2nd of 3-5 patches to address pr78496.
>
> Jump threading will examine ASSERT_EXPRs as it walks the IL and record
> information from those ASSERT_EXPRs into the available expression and
> const/copies tables where they're later used to simplify conditionals.
>
> We're missing a couple things though.
>
> First an ASSERT_EXPR with an EQ test creates an equality we can enter into
> the const/copy tables. We were failing to do that. This is most
> interesting when the RHS of the condition in the ASSERT_EXPR is a constant,
> obviously. This has a secondary benefit of doing less work to get better
> optimization.
>
> Second, some ASSERT_EXPRs may start off as a relational test such as x <= 0,
> but after range extraction and propagation they could be simplified into an
> equality comparison. We already do this with conditionals and generalizing
> that code to handle ASSERT_EXPRs is pretty easy. This gives us more chances
> to extract simple equivalences from the condition in ASSERT_EXPRs.
>
> This patch fixes those 2 problems. I don't think it directly helps pr78496
> right now as we're unable to pick up the newly exposed jump threads until
> VRP2. But that's a short term limitation that I've already addressed
> locally :-)
>
> Bootstrapped, regression tested and installed on the trunk.
After this patch on aarch64-linux-gnu I get a bootstrap failure while
linking lto1/cc1/cc1plus/go1 in stage2:
godump.o: In function `go_define(unsigned int, char const*)':
godump.c:(.text+0x36c): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.rodata'
godump.c:(.text+0x4b4): relocation truncated to fit:
R_AARCH64_ADR_PREL_LO21 against `.rodata'
collect2: error: ld returned 1 exit status
../../gcc/gcc/lto/Make-lang.in:81: recipe for target 'lto1' failed
make[3]: *** [lto1] Error 1
Thanks,
Andrew
>
> jeff
>
>
> ps. An astute observer might note that improving the effectiveness of VRP
> jump threading seems counterproductive since I've stated I want to remove
> VRP jump threading. These improvements don't significantly change how I was
> planning to do that or the infrastructure we're going to rely upon to make
> that change. All that changes is where we get the information from --
> ASSERT_EXPRs vs querying a new API that generates the same information as
> needed.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index b0c253b09ae..0f78f2a2ed1 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,12 @@
> +2017-05-06 Jeff Law
> +
> + PR tree-optimization/78496
> + * tree-vrp.c (simplify_assert_expr_using_ranges): New function.
> + (simplify_stmt_using_ranges): Call it.
> + (vrp_dom_walker::before_dom_children): Extract equivalences
> + from an ASSERT_EXPR with an equality comparison against a
> + constant.
> +
> 2017-05-06 Richard Sandiford
>
> * lra-constraints.c (lra_copy_reg_equiv): New function.
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index fca5b87e798..42782a6d17c 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,9 @@
> +2017-05-06 Jeff Law
> +
> + PR tree-optimization/78496
> + * gcc.dg/tree-ssa/ssa-thread-16.c: New test.
> + * gcc.dg/tree-ssa/ssa-thread-17.c: New test.
> +
> 2017-05-06 Richard Sandiford
>
> * gcc.target/aarch64/spill_1.c: New test.
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
> new file mode 100644
> index 000..78c349ca14d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
> @@ -0,0 +1,38 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
> +
> +/* We should thread the if (exp == 2) conditional on the
> + the path from inside the if (x) THEN arm. It is the only
> + jump threading opportunity in this code. */
> +
> +/* { dg-final { scan-tree-dump-times "Threaded" 1 "vrp1" } } */
> +
> +
> +extern void abort (void) __attribute__ ((__nothrow__, __leaf__))
> + __attribute__ ((__noreturn__));
> +
> +int x;
> +
> +
> +int code;
> +void
> +do_jump (int exp)
> +{
> + switch (code)
> +{
> +case 4:
> + if ((exp) == 1)
> + goto normal;
> + if (x)
> + {
> + if (exp != 0)
> + abort ();
> + }
> + if ((exp) == 2)
> + goto normal;
> +case 3:
> + abort ();
> +}
> + normal:
> + ;
> +}
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
> new file mode 100644
> index 000..692658fbb4b
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
> @@ -0,0 +1,36 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
> +
> +/* We should simplify one ASSERT_EXPR from a relational
> + into an equality test. */
> +/* { dg-final { scan-tree-dump-times "Folded
> into:\[^
Re: [PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading
On Sat, May 6, 2017 at 4:55 PM, Andrew Pinski wrote:
> On Sat, May 6, 2017 at 8:03 AM, Jeff Law wrote:
>> This is the 2nd of 3-5 patches to address pr78496.
>>
>> Jump threading will examine ASSERT_EXPRs as it walks the IL and record
>> information from those ASSERT_EXPRs into the available expression and
>> const/copies tables where they're later used to simplify conditionals.
>>
>> We're missing a couple things though.
>>
>> First an ASSERT_EXPR with an EQ test creates an equality we can enter into
>> the const/copy tables. We were failing to do that. This is most
>> interesting when the RHS of the condition in the ASSERT_EXPR is a constant,
>> obviously. This has a secondary benefit of doing less work to get better
>> optimization.
>>
>> Second, some ASSERT_EXPRs may start off as a relational test such as x <= 0,
>> but after range extraction and propagation they could be simplified into an
>> equality comparison. We already do this with conditionals and generalizing
>> that code to handle ASSERT_EXPRs is pretty easy. This gives us more chances
>> to extract simple equivalences from the condition in ASSERT_EXPRs.
>>
>> This patch fixes those 2 problems. I don't think it directly helps pr78496
>> right now as we're unable to pick up the newly exposed jump threads until
>> VRP2. But that's a short term limitation that I've already addressed
>> locally :-)
>>
>> Bootstrapped, regression tested and installed on the trunk.
>
>
> After this patch on aarch64-linux-gnu I get a bootstrap failure while
> linking lto1/cc1/cc1plus/go1 in stage2:
> godump.o: In function `go_define(unsigned int, char const*)':
> godump.c:(.text+0x36c): relocation truncated to fit:
> R_AARCH64_ADR_PREL_LO21 against `.rodata'
> godump.c:(.text+0x4b4): relocation truncated to fit:
> R_AARCH64_ADR_PREL_LO21 against `.rodata'
> collect2: error: ld returned 1 exit status
> ../../gcc/gcc/lto/Make-lang.in:81: recipe for target 'lto1' failed
> make[3]: *** [lto1] Error 1
I should mention this is even after the patch to
simplify_assert_expr_using_ranges .
Thanks,
Andrew
>
> Thanks,
> Andrew
>
>
>>
>> jeff
>>
>>
>> ps. An astute observer might note that improving the effectiveness of VRP
>> jump threading seems counterproductive since I've stated I want to remove
>> VRP jump threading. These improvements don't significantly change how I was
>> planning to do that or the infrastructure we're going to rely upon to make
>> that change. All that changes is where we get the information from --
>> ASSERT_EXPRs vs querying a new API that generates the same information as
>> needed.
>>
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index b0c253b09ae..0f78f2a2ed1 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,12 @@
>> +2017-05-06 Jeff Law
>> +
>> + PR tree-optimization/78496
>> + * tree-vrp.c (simplify_assert_expr_using_ranges): New function.
>> + (simplify_stmt_using_ranges): Call it.
>> + (vrp_dom_walker::before_dom_children): Extract equivalences
>> + from an ASSERT_EXPR with an equality comparison against a
>> + constant.
>> +
>> 2017-05-06 Richard Sandiford
>>
>> * lra-constraints.c (lra_copy_reg_equiv): New function.
>> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
>> index fca5b87e798..42782a6d17c 100644
>> --- a/gcc/testsuite/ChangeLog
>> +++ b/gcc/testsuite/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2017-05-06 Jeff Law
>> +
>> + PR tree-optimization/78496
>> + * gcc.dg/tree-ssa/ssa-thread-16.c: New test.
>> + * gcc.dg/tree-ssa/ssa-thread-17.c: New test.
>> +
>> 2017-05-06 Richard Sandiford
>>
>> * gcc.target/aarch64/spill_1.c: New test.
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
>> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
>> new file mode 100644
>> index 000..78c349ca14d
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-16.c
>> @@ -0,0 +1,38 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fdump-tree-vrp1-details" } */
>> +
>> +/* We should thread the if (exp == 2) conditional on the
>> + the path from inside the if (x) THEN arm. It is the only
>> + jump threading opportunity in this code. */
>> +
>> +/* { dg-final { scan-tree-dump-times "Threaded" 1 "vrp1" } } */
>> +
>> +
>> +extern void abort (void) __attribute__ ((__nothrow__, __leaf__))
>> + __attribute__ ((__noreturn__));
>> +
>> +int x;
>> +
>> +
>> +int code;
>> +void
>> +do_jump (int exp)
>> +{
>> + switch (code)
>> +{
>> +case 4:
>> + if ((exp) == 1)
>> + goto normal;
>> + if (x)
>> + {
>> + if (exp != 0)
>> + abort ();
>> + }
>> + if ((exp) == 2)
>> + goto normal;
>> +case 3:
>> + abort ();
>> +}
>> + normal:
>> + ;
>> +}
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
>> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-17.c
>> new file mode 100644
>> index 000..692658fbb4b
>> --- /dev/null
>>
