Re: [PATCH] Allow inlining always_inline functions into no_sanitize_address ones with -fsanitize=address
On Thu, 31 Jan 2019, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, we refuse to inline with -fsanitize=address
> no_sanitize_address functions into functions without that attribute,
> which is good and has been requested in PR59600.
> We also refuse to inline functions without that attribute into
> no_sanitize_address functions, which is ok if it is optimization matter
> only, we will just address sanitize the callee and not the caller.
> But if such callee has always_inline attribute, this causes errors, and
> e.g. means one can't use target intrinsics in functions with
> no_sanitize_address attribute, as we refuse to inline any of those.
>
> The following patch allows inlining always_inline functions in that
> situation, the end result is that both the caller and callee which becomes
> one function will not be sanitized (still errors if always_inline,
> no_sanitize_address is being inlined into normal function, that is just user
> error).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
> 2019-01-30 Jakub Jelinek
>
> PR sanitizer/89124
> * ipa-inline.c (sanitize_attrs_match_for_inline_p): Allow inlining
> always_inline callees into no_sanitize_address callers.
>
> * c-c++-common/asan/pr89124.c: New test.
>
> --- gcc/ipa-inline.c.jj 2019-01-10 11:43:08.956466913 +0100
> +++ gcc/ipa-inline.c 2019-01-30 22:21:57.319026848 +0100
> @@ -264,6 +264,12 @@ sanitize_attrs_match_for_inline_p (const
>if (!caller || !callee)
> return true;
>
> + /* Allow inlining always_inline functions into no_sanitize_address
> + functions. */
> + if (!sanitize_flags_p (SANITIZE_ADDRESS, caller)
> + && lookup_attribute ("always_inline", DECL_ATTRIBUTES (callee)))
> +return true;
> +
>return ((sanitize_flags_p (SANITIZE_ADDRESS, caller)
> == sanitize_flags_p (SANITIZE_ADDRESS, callee))
> && (sanitize_flags_p (SANITIZE_POINTER_COMPARE, caller)
> --- gcc/testsuite/c-c++-common/asan/pr89124.c.jj 2019-01-30
> 22:23:27.018546142 +0100
> +++ gcc/testsuite/c-c++-common/asan/pr89124.c 2019-01-30 22:23:05.568900221
> +0100
> @@ -0,0 +1,14 @@
> +/* PR sanitizer/89124 */
> +/* { dg-do compile } */
> +
> +static int inline __attribute__ ((always_inline))
> +foo (int x)
> +{
> + return x + 1;
> +}
> +
> +__attribute__ ((no_sanitize_address)) int
> +bar (int x)
> +{
> + return foo (x);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
[PATCH] Fix PR89135
I am testing the following patch to fix PR89135.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-01-31 Richard Biener
PR tree-optimization/89135
* tree-ssa-phiprop.c (pass_phiprop::execute): Skip blocks
with abnormal preds.
* gcc.dg/torture/pr89135.c: New testcase.
Index: gcc/tree-ssa-phiprop.c
===
--- gcc/tree-ssa-phiprop.c (revision 268415)
+++ gcc/tree-ssa-phiprop.c (working copy)
@@ -495,8 +495,14 @@ pass_phiprop::execute (function *fun)
bbs = get_all_dominated_blocks (CDI_DOMINATORS,
single_succ (ENTRY_BLOCK_PTR_FOR_FN (fun)));
FOR_EACH_VEC_ELT (bbs, i, bb)
-for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
- did_something |= propagate_with_phi (bb, gsi.phi (), phivn, n);
+{
+ /* Since we're going to move dereferences across predecessor
+ edges avoid blocks with abnormal predecessors. */
+ if (bb_has_abnormal_pred (bb))
+ continue;
+ for (gsi = gsi_start_phis (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+ did_something |= propagate_with_phi (bb, gsi.phi (), phivn, n);
+}
if (did_something)
gsi_commit_edge_inserts ();
Index: gcc/testsuite/gcc.dg/torture/pr89135.c
===
--- gcc/testsuite/gcc.dg/torture/pr89135.c (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr89135.c (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+
+typedef __INTPTR_TYPE__ intptr_t;
+intptr_t a, b, c, d;
+int foo (void) { return 0; }
+int baz (void);
+
+void
+bar (void)
+{
+ intptr_t g = (intptr_t) &&h;
+ void *i = &&j, *k = &&l;
+j:
+ if (baz ())
+{
+ intptr_t **n = (intptr_t **) &a;
+l:
+ b = 0;
+ for (; b >= 0;)
+ goto *k;
+h:
+ **n = 0;
+ for (;;)
+ {
+ intptr_t *o = &c;
+ g = foo ();
+ *o = g;
+ if (c)
+ goto *d;
+ }
+}
+ goto *i;
+}
Re: [PATCH] doc: showcase a "union of vectors" pattern (PR 88698)
On Wed, Jan 30, 2019 at 3:42 PM Alexander Monakov wrote:
>
> On Mon, 21 Jan 2019, Alexander Monakov wrote:
>
> > Ah, I see now. I agree transparent_union ought to work, but today both GCC
> > and Clang will reject such attempt; I've filed PR 88955 for the GCC issue.
> >
> > So unfortunately such code would still need a cast or an unnamed temporary,
> > which may be relatively obvious to the reader.
>
> In the end it may be preferable to have it anyway, so here's a revised version
> with an extra line in the example for passing arguments via compound literals.
>
> Checked with 'make html', OK to apply?
OK unless somebody objects within a reasonable time frame.
Richard.
> PR c/88698
> * doc/extend.texi (Vector Extensions): Add an example of using vector
> types together with x86 intrinsics.
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 95d22ac1e3c..34a76927b12 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -10632,6 +10632,47 @@ v4si g = __builtin_convertvector (f, v4si); /* g is
> @{1,-2,3,7@} */
> v4si h = __builtin_convertvector (c, v4si); /* h is @{1,5,0,10@} */
> @end smallexample
>
> +@cindex vector types, using with x86 intrinsics
> +Sometimes it is desirable to write code using a mix of generic vector
> +operations (for clarity) and machine-specific vector intrinsics (to
> +access vector instructions that are not exposed via generic built-ins).
> +On x86, intrinsic functions for integer vectors typically use the same
> +vector type @code{__m128i} irrespective of how they interpret the vector,
> +making it necessary to cast their arguments and return values from/to
> +other vector types. In C, you can make use of a @code{union} type:
> +@c In C++ such type punning via a union is not allowed by the language
> +@smallexample
> +#include
> +
> +typedef unsigned char u8x16 __attribute__ ((vector_size (16)));
> +typedef unsigned int u32x4 __attribute__ ((vector_size (16)));
> +
> +typedef union @{
> +__m128i mm;
> +u8x16 u8;
> +u32x4 u32;
> +@} v128;
> +@end smallexample
> +
> +@noindent
> +for variables that can be used with both built-in operators and x86
> +intrinsics:
> +
> +@smallexample
> +v128 x, y = @{ 0 @};
> +memcpy (&x, ptr, sizeof x);
> +y.u8 += 0x80;
> +x.mm = _mm_adds_epu8 (x.mm, y.mm);
> +x.u32 &= 0xff;
> +
> +/* Instead of a variable, a compound literal may be used to pass the
> + return value of an intrinsic call to a function expecting the union: */
> +v128 foo (v128);
> +x = foo ((v128) @{_mm_adds_epu8 (x.mm, y.mm)@});
> +@c This could be done implicitly with __attribute__((transparent_union)),
> +@c but GCC does not accept it for unions of vector types (PR 88955).
> +@end smallexample
> +
> @node Offsetof
> @section Support for @code{offsetof}
> @findex __builtin_offsetof
Re: [PATCH] Fix bogus fix-it for FLT_MAX (PR c/89122)
On Thu, Jan 31, 2019 at 12:09 AM David Malcolm wrote:
>
> PR c/89122 reports that we emit a bogus fix-it hint for the case where
> the code uses FLT_MAX, but has included rather than :
>
> x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did you
> mean 'INT_MAX'?
> 3 | float f = FLT_MAX;
> | ^~~
> | INT_MAX
>
> This patch adds some knowledge of (and ) to
> known-headers.cc, fixing the issue:
>
> x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function)
> 3 | float f = FLT_MAX;
> | ^~~
> x.c:2:1: note: 'FLT_MAX' is defined in header ''; did you forget
> to '#include '?
> 1 | #include
> +++ |+#include
> 2 |
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> Is this OK for trunk in stage 4? (presumably very low risk)
What does it not say for
int i = FLT_MAX;
? Hopefully it doesn't suggest to include float.h but suggests
to include limits.h and INT_MAX?
> gcc/c-family/ChangeLog:
> PR c/89122
> * known-headers.cc (get_stdlib_header_for_name): Add
> {FLT|DBL|LDBL}_{MAX|MIN} to "hints" array.
>
> gcc/testsuite/ChangeLog:
> PR c/89122
> * g++.dg/spellcheck-stdlib.C (test_FLT_MAX): New test.
> * gcc.dg/spellcheck-stdlib.c (test_FLT_MAX): New test.
> ---
> gcc/c-family/known-headers.cc| 8
> gcc/testsuite/g++.dg/spellcheck-stdlib.C | 5 +
> gcc/testsuite/gcc.dg/spellcheck-stdlib.c | 5 +
> 3 files changed, 18 insertions(+)
>
> diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
> index e3dcf73..c222f30 100644
> --- a/gcc/c-family/known-headers.cc
> +++ b/gcc/c-family/known-headers.cc
> @@ -84,6 +84,14 @@ get_stdlib_header_for_name (const char *name, enum stdlib
> lib)
> {"ULONG_MAX", {"", ""} },
> {"USHRT_MAX", {"", ""} },
>
> +/* and . */
> +{"DBL_MAX", {"", ""} },
> +{"DBL_MIN", {"", ""} },
> +{"FLT_MAX", {"", ""} },
> +{"FLT_MIN", {"", ""} },
> +{"LDBL_MAX", {"", ""} },
> +{"LDBL_MIN", {"", ""} },
> +
> /* and . */
> {"va_list", {"", ""} },
>
> diff --git a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> index 11a4e3e..31e91fe 100644
> --- a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> +++ b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> @@ -77,6 +77,11 @@ int test_INT_MAX (void)
>// { dg-message "'INT_MAX' is defined in header ''; did you
> forget to '#include '?" "" { target *-*-* } INT_MAX_line }
> }
>
> +/* Missing . */
> +float test_FLT_MAX = FLT_MAX; // { dg-line FLT_MAX_line }
> +// { dg-error "'FLT_MAX' was not declared" "" { target *-*-* } FLT_MAX_line }
> +// { dg-message "'FLT_MAX' is defined in header ''; did you forget
> to '#include '?" "" { target *-*-* } FLT_MAX_line }
> +
> /* Missing . */
>
> void test_cstring (char *dest, char *src)
> diff --git a/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
> b/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
> index 7474c9a..1ae3b5e 100644
> --- a/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
> +++ b/gcc/testsuite/gcc.dg/spellcheck-stdlib.c
> @@ -62,3 +62,8 @@ int test_INT_MAX (void)
>/* { dg-bogus "__INT_MAX__" "" { target *-*-* } INT_MAX_line } */
>/* { dg-message "'INT_MAX' is defined in header ''; did you
> forget to '#include '?" "" { target *-*-* } INT_MAX_line } */
> }
> +
> +/* Missing . */
> +float test_FLT_MAX = FLT_MAX; /* { dg-line FLT_MAX_line } */
> +/* { dg-error "'FLT_MAX' undeclared" "" { target *-*-* } FLT_MAX_line } */
> +/* { dg-message "'FLT_MAX' is defined in header ''; did you forget
> to '#include '?" "" { target *-*-* } FLT_MAX_line } */
> --
> 1.8.5.3
>
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On Thu, Jan 31, 2019 at 8:40 AM Aldy Hernandez wrote: > > Hi folks. > > The problem here is that Wprintf* uses the evrp_range_analyzer engine, > and doesn't understand that the x_5 != 256 conditional below should make > the RANGE [0, 255], not [0, 256]. > > [local count: 1063004407]: ># RANGE [0, 256] NONZERO 511 ># x_10 = PHI <0(2), x_5(3)> >snprintf (&temp, 4, "%%%02X", x_10); ># RANGE [1, 256] NONZERO 511 >x_5 = x_10 + 1; >if (x_5 != 256) > goto ; [98.99%] >else > goto ; [1.01%] > > This PR is handled quite easily in the ranger work, but alas there is > nothing for this release. Therefore, I'd like to dedicate as little > time as possible to this PR this time around. > > Various possible solutions are discussed in the PR. I think an easy way > is to lean on loop analysis to refine the PHI result. It turns out the > evrp engine already does this if SCEV data is available. > > As Richard mentioned in the PR, we should avoid code differences > dependent on -W* flags. I have put the loop init code in the pass > itself, but am open to moving it outside, perhaps early in the gate > function ??. > > I also took the liberty of calling loop_optimizer_init() with the > smallest subset of LOOPS_NORMAL which could still fix the problem > (LOOPS_HAVE_PREHEADERS). This avoids unnecessary changes to the CFG. > But really, I'm just guessing here. LOOPS_NORMAL would also work, > albeit creating forwarder blocks. > > Tested on x86-64 Linux. > > What do you think? As far as I understand fold_return_value is true/false independent of -W* flags (but dependent on -fprintf-return-value or so). This means that your patch avoids the risk of CFG changes dependent on -W* flags. This means you could safely use LOOPS_NORMAL (I'm not sure SCEV is happy with just pre-headers, unfortunately its exact requirements are not documented... - at least I see unconditional dereferences of loop->latch which rules out LOOPS_NO_CFG_MANIPULATION, likewise loop_preheader_edge is mentioned). That said, LOOPS_HAVE_PREHEADERS probably works well enough for both SCEV and niter analysis. Thus, the patch is OK if you adjust the comment a bit, it's perfectly safe to init loops conditional on optimization and running in the gate isn't wanted. I'm also not sure why this should go away with on-demand info -- working in the EVRP DOM walker exactly provides on-demand info (just the DOM style one relies on SCEV / niter analysis for any backedge work). Richard. > > Aldy
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
Hi Gerard, Thanks I'll make the suggested changes. About the duplication, we can avoid it if we have a "general" section for all Arm ports first and then subsections for Arm and AArch64 specific things. I'm not sure how the maintainers feel about such a re-organization though. Any opinions guys? Thanks, Tamar From: Gerald Pfeifer Sent: Thursday, January 31, 2019 12:29 AM To: Tamar Christina Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw; Marcus Shawcroft; Ramana Radhakrishnan; ni...@redhat.com; Kyrylo Tkachov Subject: Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags. On Wed, 23 Jan 2019, Tamar Christina wrote: > This patch adds the documentation for Stack clash protection and > Armv8.3-a support to changes.html for GCC 9. Some additional notes, all minor, for consideration before you commit. +The probing interval/guard size can be set by using +--param stack-clash-protection-guard-size=12|16. +The value of this parameter must be in bytes represented as a power of two. +The only two supported values for this parameter are 12 and 16 being +4Kb (2^12) and 64Kb (2^16) respectively. This one keeps making me think every time I read it. What do you think of changing the second and third sentences to "The two supported values for this paramter are 12 (for a 4KiB size, 2^12) and 16 (for a 64KiB size, 2^16)." or something like that? Shorter and about the same contents? (Note, uppercase B or we'd refer to bits.) +The Armv8.3-A complex number instructions are now supported via intrinsics +when the option -march=armv8.3-a or equivalent is specified. +For the half-precision floating-point variants of these instructions use the +architecture extension flag +fp16, e.g. +-march=armv8.3-a+fp16. + +The intrinsics are defined by the ACLE specification. Note that these two visual paragraphs in HTML source will be merged into just one unless you add ... around the two. Just pointing it out. + +The Armv8.3-A complex number instructions are now supported via intrinsics +when the option -march=armv8.3-a or equivalent is specified. +For the half-precision floating-point variants of these instructions use the +architecture extension flag +fp16, e.g. +-march=armv8.3-a+fp16. + +The intrinsics are defined by the ACLE specification. + I guess this duplication is hard to avoid between Arm and AArch64? Gerald
Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.
On Thu, 31 Jan 2019, 10:09 Tamar Christina Hi Gerard, > > Thanks I'll make the suggested changes. > > About the duplication, we can avoid it if we have a "general" section for > all Arm ports first and then subsections for Arm and AArch64 specific > things. > > I'm not sure how the maintainers feel about such a re-organization though. > Works for me R > > Any opinions guys? > > Thanks, > Tamar > > > From: Gerald Pfeifer > Sent: Thursday, January 31, 2019 12:29 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw; > Marcus Shawcroft; Ramana Radhakrishnan; ni...@redhat.com; Kyrylo Tkachov > Subject: Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new > features and flags. > > On Wed, 23 Jan 2019, Tamar Christina wrote: > > This patch adds the documentation for Stack clash protection and > > Armv8.3-a support to changes.html for GCC 9. > > Some additional notes, all minor, for consideration before you commit. > > +The probing interval/guard size can be set by using > +--param stack-clash-protection-guard-size=12|16. > +The value of this parameter must be in bytes represented as a power > of two. > +The only two supported values for this parameter are 12 and 16 being > +4Kb (2^12) and 64Kb (2^16) respectively. > > This one keeps making me think every time I read it. What do you > think of changing the second and third sentences to > > "The two supported values for this paramter are 12 (for a 4KiB size, > 2^12) and 16 (for a 64KiB size, 2^16)." > > or something like that? Shorter and about the same contents? (Note, > uppercase B or we'd refer to bits.) > > +The Armv8.3-A complex number instructions are now supported via > intrinsics > +when the option -march=armv8.3-a or equivalent is > specified. > +For the half-precision floating-point variants of these instructions > use the > +architecture extension flag +fp16, e.g. > +-march=armv8.3-a+fp16. > + > +The intrinsics are defined by the ACLE specification. > > Note that these two visual paragraphs in HTML source will be merged into > just one unless you add ... around the two. Just pointing it out. > > + > +The Armv8.3-A complex number instructions are now supported via > intrinsics > +when the option -march=armv8.3-a or equivalent is > specified. > +For the half-precision floating-point variants of these instructions > use the > +architecture extension flag +fp16, e.g. > +-march=armv8.3-a+fp16. > + > +The intrinsics are defined by the ACLE specification. > + > > I guess this duplication is hard to avoid between Arm and AArch64? > > Gerald >
[PATCH, i386]: Fix PR 89071, AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
Hello!
Attached patch (partially) avoids emitting XOR dependency breaking
insn by removing SSE reg dependency in the AVX instructions
themselves.
2019-01-31 Uroš Bizjak
PR target/89071
* config/i386/i386.md (*extendsfdf2): Split out reg->reg
alternative to avoid partial SSE register stall for TARGET_AVX.
(truncdfsf2): Ditto.
(sse4_1_round2): Ditto.
Bootstrapped on x86_64-linux-gnu {,-m32}, regression test in progress.
Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index d085e88bc61d..744f155fca6f 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -4370,9 +4370,9 @@
})
(define_insn "*extendsfdf2"
- [(set (match_operand:DF 0 "nonimm_ssenomem_operand" "=f,m,v")
+ [(set (match_operand:DF 0 "nonimm_ssenomem_operand" "=f,m,v,v")
(float_extend:DF
- (match_operand:SF 1 "nonimmediate_operand" "fm,f,vm")))]
+ (match_operand:SF 1 "nonimmediate_operand" "fm,f,v,m")))]
"TARGET_80387 || (TARGET_SSE2 && TARGET_SSE_MATH)"
{
switch (which_alternative)
@@ -4382,15 +4382,17 @@
return output_387_reg_move (insn, operands);
case 2:
+ return "%vcvtss2sd\t{%d1, %0|%0, %d1}";
+case 3:
return "%vcvtss2sd\t{%1, %d0|%d0, %1}";
default:
gcc_unreachable ();
}
}
- [(set_attr "type" "fmov,fmov,ssecvt")
- (set_attr "prefix" "orig,orig,maybe_vex")
- (set_attr "mode" "SF,XF,DF")
+ [(set_attr "type" "fmov,fmov,ssecvt,ssecvt")
+ (set_attr "prefix" "orig,orig,maybe_vex,maybe_vex")
+ (set_attr "mode" "SF,XF,DF,DF")
(set (attr "enabled")
(if_then_else
(match_test ("TARGET_SSE2 && TARGET_SSE_MATH"))
@@ -4481,7 +4483,7 @@
"TARGET_SSE_PARTIAL_REG_DEPENDENCY && epilogue_completed
&& optimize_function_for_speed_p (cfun)
&& (!REG_P (operands[1])
- || REGNO (operands[0]) != REGNO (operands[1]))
+ || (!TARGET_AVX && REGNO (operands[0]) != REGNO (operands[1])))
&& (!EXT_REX_SSE_REG_P (operands[0])
|| TARGET_AVX512VL)"
[(set (match_dup 0)
@@ -4534,9 +4536,9 @@
;; Conversion from DFmode to SFmode.
(define_insn "truncdfsf2"
- [(set (match_operand:SF 0 "nonimm_ssenomem_operand" "=m,f,v")
+ [(set (match_operand:SF 0 "nonimm_ssenomem_operand" "=m,f,v,v")
(float_truncate:SF
- (match_operand:DF 1 "register_ssemem_operand" "f,f,vm")))]
+ (match_operand:DF 1 "register_ssemem_operand" "f,f,v,m")))]
"TARGET_80387 || (TARGET_SSE2 && TARGET_SSE_MATH)"
{
switch (which_alternative)
@@ -4546,13 +4548,15 @@
return output_387_reg_move (insn, operands);
case 2:
+ return "%vcvtsd2ss\t{%d1, %0|%0, %d1}";
+case 3:
return "%vcvtsd2ss\t{%1, %d0|%d0, %1}";
default:
gcc_unreachable ();
}
}
- [(set_attr "type" "fmov,fmov,ssecvt")
+ [(set_attr "type" "fmov,fmov,ssecvt,ssecvt")
(set_attr "mode" "SF")
(set (attr "enabled")
(if_then_else
@@ -4639,7 +4643,7 @@
"TARGET_SSE_PARTIAL_REG_DEPENDENCY && epilogue_completed
&& optimize_function_for_speed_p (cfun)
&& (!REG_P (operands[1])
- || REGNO (operands[0]) != REGNO (operands[1]))
+ || (!TARGET_AVX && REGNO (operands[0]) != REGNO (operands[1])))
&& (!EXT_REX_SSE_REG_P (operands[0])
|| TARGET_AVX512VL)"
[(set (match_dup 0)
@@ -16171,19 +16175,20 @@
(define_insn "sse4_1_round2"
- [(set (match_operand:MODEF 0 "register_operand" "=x,v")
- (unspec:MODEF [(match_operand:MODEF 1 "nonimmediate_operand" "xm,vm")
- (match_operand:SI 2 "const_0_to_15_operand" "n,n")]
+ [(set (match_operand:MODEF 0 "register_operand" "=x,x,v")
+ (unspec:MODEF [(match_operand:MODEF 1 "nonimmediate_operand" "x,m,vm")
+ (match_operand:SI 2 "const_0_to_15_operand" "n,n,n")]
UNSPEC_ROUND))]
"TARGET_SSE4_1"
"@
+ %vround\t{%2, %d1, %0|%0, %d1, %2}
%vround\t{%2, %1, %d0|%d0, %1, %2}
vrndscale\t{%2, %1, %d0|%d0, %1, %2}"
[(set_attr "type" "ssecvt")
- (set_attr "prefix_extra" "1,*")
- (set_attr "length_immediate" "*,1")
- (set_attr "prefix" "maybe_vex,evex")
- (set_attr "isa" "noavx512f,avx512f")
+ (set_attr "prefix_extra" "1,1,*")
+ (set_attr "length_immediate" "*,*,1")
+ (set_attr "prefix" "maybe_vex,maybe_vex,evex")
+ (set_attr "isa" "noavx512f,noavx512f,avx512f")
(set_attr "mode" "")])
(define_insn "rintxf2"
[PATCH, og8] OpenACC: attach/detach array slices on dereferenced struct members
Hi,
This patch adds support for array slices on dereferenced struct
members, e.g.:
#pragma acc parallel copy(mystruct->a[0:n])
This works by making a new mapping pair for each struct pointer used in
the directive ("alloc(mystruct) firstprivate_pointer(mystruct)").
The C/C++ parsers permit chained dereferences
("mystruct->anotherstruct->bla[0:n]"). In this case, the current
implementation performs an attach/detach operation on the
final/innermost dereference only (so, "bla[0:n]" attaches to
the appropriate offset in "anotherstruct"). Other options might be to
explicitly disallow chained dereferences, or attach the whole chain
sequentially. The standard isn't helpful here (as of 2.6), but I think
that the chosen behaviour is reasonably consistent.
Arrays of structures aren't (yet?) supported
(either "copy(structarr[i].a[0:n])" or "copy(structarr[i]->a[0:n])"). I
added a basic test case for that.
Tested with offloading to nvptx, no regressions and the new tests pass.
I will apply shortly (to the og8 branch).
Thanks,
Julian
ChangeLog
gcc/c/
* c-typeck.c (handle_omp_array_sections_1): Handle chained dereferences.
(c_finish_omp_clauses): Likewise.
gcc/cp/
* semantics.c (handle_omp_array_sections_1): Handle array section on
dereferenced struct member.
(finish_omp_clauses): Don't error on multiple dereferenced struct
elements with the same base.
gcc/
* gimplify.c (gimplify_scan_omp_clauses): Handle array sections on
dereferenced struct members.
gcc/testsuite/
* c-c++-common/goacc/deep-copy-arrayofstruct.c: New test.
libgomp/
* testsuite/libgomp.oacc-c++/deep-copy-12.C: New test.
* testsuite/libgomp.oacc-c++/deep-copy-13.C: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-9.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-10.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-11.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-14.c: New test.
commit 56101feb78bc2e3344159f96b7d0ab9eaf4bd529
Author: Julian Brown
Date: Wed Jan 30 04:54:24 2019 -0800
[og8] Attach/detach array slices on dereferenced struct members
gcc/c/
* c-typeck.c (handle_omp_array_sections_1): Handle chained dereferences.
(c_finish_omp_clauses): Likewise.
gcc/cp/
* semantics.c (handle_omp_array_sections_1): Handle array section on
dereferenced struct member.
(finish_omp_clauses): Don't error on multiple dereferenced struct
elements with the same base.
gcc/
* gimplify.c (gimplify_scan_omp_clauses): Handle array sections on
dereferenced struct members.
gcc/testsuite/
* c-c++-common/goacc/deep-copy-arrayofstruct.c: New test.
libgomp/
* testsuite/libgomp.oacc-c++/deep-copy-12.C: New test.
* testsuite/libgomp.oacc-c++/deep-copy-13.C: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-9.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-10.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-11.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-14.c: New test.
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index d25e2d8c14c..7f021649216 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12445,9 +12445,16 @@ handle_omp_array_sections_1 (tree c, tree t, vec &types,
return error_mark_node;
}
t = TREE_OPERAND (t, 0);
+ if (ort == C_ORT_ACC && TREE_CODE (t) == MEM_REF)
+ {
+ if (maybe_ne (mem_ref_offset (t), 0))
+ error_at (OMP_CLAUSE_LOCATION (c),
+ "cannot dereference %qE in %qs clause", t,
+ omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
+ else
+ t = TREE_OPERAND (t, 0);
+ }
}
- if (TREE_CODE (t) == MEM_REF)
- t = TREE_OPERAND (t, 0);
}
if (!VAR_P (t) && TREE_CODE (t) != PARM_DECL)
{
@@ -13750,11 +13757,18 @@ c_finish_omp_clauses (tree clauses, enum c_omp_region_type ort)
break;
}
t = TREE_OPERAND (t, 0);
+ if (ort == C_ORT_ACC && TREE_CODE (t) == MEM_REF)
+ {
+ if (maybe_ne (mem_ref_offset (t), 0))
+ error_at (OMP_CLAUSE_LOCATION (c),
+ "cannot dereference %qE in %qs clause", t,
+ omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
+ else
+ t = TREE_OPERAND (t, 0);
+ }
}
if (remove)
break;
- if (TREE_CODE (t) == MEM_REF)
- t = TREE_OPERAND (t, 0);
if (VAR_P (t) || TREE_CODE (t) == PARM_DECL)
{
if (bitmap_bit_p (&map_field_head, DECL_UID (t)))
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 497fd39b10c..72c4dcec2b3 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -4557,6 +4557,8 @@ handle_omp_array_sections_1 (tree c, tree t, vec &types,
return error_mark_node;
}
t = TREE_OPERAND (t, 0);
+ i
[PATCH, RFC] Avoid the -D option which is not available install-sh
Hi,
I have an issue with the installation of gcc when configured with
--enable-languages=all
on an arm-target where install-sh is used, and make install fails at libphobos
as follows:
if test -f $file; then \
/home/ed/gnu/gcc-9-20190127-0/install-sh -c -m 644 -D $file
/home/ed/gnu/arm-linux-gnueabihf/lib/gcc/armv7l-unknown-linux-gnueabihf/9.0.1/include/d/$file
; \
else \
/home/ed/gnu/gcc-9-20190127-0/install-sh -c -m 644 -D
../../../../gcc-9-20190127-0/libphobos/libdruntime/$file \
/home/ed/gnu/arm-linux-gnueabihf/lib/gcc/armv7l-unknown-linux-gnueabihf/9.0.1/include/d/$file
; \
fi ; \
done
/home/ed/gnu/gcc-9-20190127-0/install-sh: invalid option: -D
/home/ed/gnu/gcc-9-20190127-0/install-sh: invalid option: -D
/home/ed/gnu/gcc-9-20190127-0/install-sh: invalid option: -D
...
I have fixed the installation with the attached patch, but when I regenerate
the automake
files using automake-1.15.1 and autoconf-2.69, I have an issue that apparently
the configure.ac must be out of sync, and the the generated files are missing
the option --runstatedir no matter what I do. At least on the source
RFC, because I am not sure what the --runstatedir option is, and if it is
intentional to remove,
and forgotten to re-generate, or if was intended to add, and forgotten to check
in the
configure.ac.
Attached patch which fixes the install issue, and removes the --runstatedir
configure option.
Is OK as is, or has anybody an idea how to fix this mess?
Thanks
Bernd.2019-01-31 Bernd Edlinger
* src/Makefile.am: Avoid the -D option which is not available
with the install-sh fallback. Use $(MKDIR_P) instead.
* libdruntime/Makefile.am: Likewise.
* configure: Regenerated.
* Makefile.in: Regenerated.
* src/Makefile.in: Regenerated.
* libdruntime/Makefile.in: Regenerated.
* testsuite/Makefile.in: Regenerated.
diff -ur libphobos/configure libphobos/configure
--- libphobos/configure 2019-01-27 23:33:11.0 +0100
+++ libphobos/configure 2019-01-31 09:17:08.788970961 +0100
@@ -782,7 +782,6 @@
docdir
oldincludedir
includedir
-runstatedir
localstatedir
sharedstatedir
sysconfdir
@@ -868,7 +867,6 @@
sysconfdir='${prefix}/etc'
sharedstatedir='${prefix}/com'
localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
includedir='${prefix}/include'
oldincludedir='/usr/include'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -1121,15 +1119,6 @@
| -silent | --silent | --silen | --sile | --sil)
silent=yes ;;
- -runstatedir | --runstatedir | --runstatedi | --runstated \
- | --runstate | --runstat | --runsta | --runst | --runs \
- | --run | --ru | --r)
-ac_prev=runstatedir ;;
- -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
- | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
- | --run=* | --ru=* | --r=*)
-runstatedir=$ac_optarg ;;
-
-sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
ac_prev=sbindir ;;
-sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1267,7 +1256,7 @@
for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \
datadir sysconfdir sharedstatedir localstatedir includedir \
oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
- libdir localedir mandir runstatedir
+ libdir localedir mandir
do
eval ac_val=\$$ac_var
# Remove trailing slashes.
@@ -1420,7 +1409,6 @@
--sysconfdir=DIRread-only single-machine data [PREFIX/etc]
--sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
--localstatedir=DIR modifiable single-machine data [PREFIX/var]
- --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
--libdir=DIRobject code libraries [EPREFIX/lib]
--includedir=DIRC header files [PREFIX/include]
--oldincludedir=DIR C header files for non-gcc [/usr/include]
@@ -11508,7 +11496,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11511 "configure"
+#line 11499 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -11614,7 +11602,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11617 "configure"
+#line 11605 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
diff -ur libphobos/libdruntime/Makefile.am libphobos/libdruntime/Makefile.am
--- libphobos/libdruntime/Makefile.am 2019-01-01 13:31:55.0 +0100
+++ libphobos/libdruntime/Makefile.am 2019-01-31 08:29:02.489565809 +0100
@@ -139,11 +139,12 @@
# Handles generated files as well
install-data-local:
+ $(MKDIR_P) $(DESTDIR)$(gdc_include_dir)
for file in $(ALL_DRUNTIME_INSTALL_DSOURCES); do \
if test -f $$file; then \
- $(INSTALL_HEADER) -D $$file $(DESTDIR)$(gdc_include_dir)/$$file ; \
+ $(INSTALL_HEADER) $$file $(DESTDIR)$(gdc_include_dir)/$$file ; \
else \
- $(INSTALL_HEADER) -D $(srcdir)/$$file \
+
[PATCH][libbacktrace] Fix .gnu_debugaltlink build-id check
Hi,
The 'debugaltlink_name_len =+ 1' bug reported in PR89136 exposes the fact that
the build-id is not verified for the .gnu_debugaltlink.
Fix both problems.
OK for trunk?
Thanks,
- Tom
[libbacktrace] Fix .gnu_debugaltlink build-id check
2019-01-31 Tom de Vries
PR libbacktrace/89136
* elf.c (elf_add): Read build-id if with_buildid_data. Fix
'debugaltlink_name_len =+ 1'.
---
libbacktrace/elf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index d933052200c..f3988ec02a0 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -2864,7 +2864,7 @@ elf_add (struct backtrace_state *state, const char
*filename, int descriptor,
/* Read the build ID if present. This could check for any
SHT_NOTE section with the right note name and type, but gdb
looks for a specific section name. */
- if (!debuginfo
+ if ((!debuginfo || with_buildid_data != NULL)
&& !buildid_view_valid
&& strcmp (name, ".note.gnu.build-id") == 0)
{
@@ -2938,7 +2938,7 @@ elf_add (struct backtrace_state *state, const char
*filename, int descriptor,
if (debugaltlink_name_len < shdr->sh_size)
{
/* Include terminating zero. */
- debugaltlink_name_len =+ 1;
+ debugaltlink_name_len += 1;
debugaltlink_buildid_data
= debugaltlink_data + debugaltlink_name_len;
Re: [PATCH][libbacktrace] Fix .gnu_debugaltlink build-id check
On Thu, Jan 31, 2019 at 12:40 PM Tom de Vries wrote:
>
> Hi,
>
> The 'debugaltlink_name_len =+ 1' bug reported in PR89136 exposes the fact that
> the build-id is not verified for the .gnu_debugaltlink.
>
> Fix both problems.
>
> OK for trunk?
OK.
Richard.
> Thanks,
> - Tom
>
> [libbacktrace] Fix .gnu_debugaltlink build-id check
>
> 2019-01-31 Tom de Vries
>
> PR libbacktrace/89136
> * elf.c (elf_add): Read build-id if with_buildid_data. Fix
> 'debugaltlink_name_len =+ 1'.
>
> ---
> libbacktrace/elf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index d933052200c..f3988ec02a0 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -2864,7 +2864,7 @@ elf_add (struct backtrace_state *state, const char
> *filename, int descriptor,
>/* Read the build ID if present. This could check for any
> SHT_NOTE section with the right note name and type, but gdb
> looks for a specific section name. */
> - if (!debuginfo
> + if ((!debuginfo || with_buildid_data != NULL)
> && !buildid_view_valid
> && strcmp (name, ".note.gnu.build-id") == 0)
> {
> @@ -2938,7 +2938,7 @@ elf_add (struct backtrace_state *state, const char
> *filename, int descriptor,
> if (debugaltlink_name_len < shdr->sh_size)
> {
> /* Include terminating zero. */
> - debugaltlink_name_len =+ 1;
> + debugaltlink_name_len += 1;
>
> debugaltlink_buildid_data
> = debugaltlink_data + debugaltlink_name_len;
Re: [PATCH, RFC] Avoid the -D option which is not available install-sh
Hi Bernd, > I have fixed the installation with the attached patch, but when I regenerate > the automake > files using automake-1.15.1 and autoconf-2.69, I have an issue that apparently > the configure.ac must be out of sync, and the the generated files are missing > the option --runstatedir no matter what I do. At least on the source > > RFC, because I am not sure what the --runstatedir option is, and if it is > intentional to remove, > and forgotten to re-generate, or if was intended to add, and forgotten to > check in the > configure.ac. > > Attached patch which fixes the install issue, and removes the --runstatedir > configure option. > Is OK as is, or has anybody an idea how to fix this mess? those configure files have been generated with some modified version of autoconf: --runstatedir isn't present in vanilla autoconf 2.69, but only in git autoconf. Since there are no uses of it I could find, please do regenerate with autoconf 2.69 (preferably self-built since distros tend to include random patches which only confuse future developers). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Handle timeout warnings in dg-extract-results
> On 29 Jan 2019, at 10:22, Christophe Lyon wrote: > > On Tue, 29 Jan 2019 at 11:12, Iain Sandoe wrote: >> >>> Did it work for you? >> >> So far it’s looking nice… (anything that makes the dg output more stable is >> Good in my book) >> >> … I am not sure (not checked thoroughly) but I think I saw one case in >> libgomp testing where it didn’t pick up the timeout, will poke some more at >> that if i see it again. > > If you still have the logs, you can run the script manually. So it seems that the only library testsuite that uses dg-extract-results is libstdc++v3. This explains why the script wasn’t applied to libgomp. It DTRT if applied manually. I guess an edit of the various library testsuite Makefile(s) to generate the original .sum file as a temp followed by dg-extract-results to the final file would work. Will try it when I have a few moments (unless you get to it first ;) ) Iain
Re: [PATCH] Handle timeout warnings in dg-extract-results
On Thu, 31 Jan 2019 at 13:30, Iain Sandoe wrote: > > > > On 29 Jan 2019, at 10:22, Christophe Lyon > > wrote: > > > > On Tue, 29 Jan 2019 at 11:12, Iain Sandoe wrote: > >> > > > >>> Did it work for you? > >> > >> So far it’s looking nice… (anything that makes the dg output more stable > >> is Good in my book) > >> > >> … I am not sure (not checked thoroughly) but I think I saw one case in > >> libgomp testing where it didn’t pick up the timeout, will poke some more > >> at that if i see it again. > > > > If you still have the logs, you can run the script manually. > > So it seems that the only library testsuite that uses dg-extract-results is > libstdc++v3. This explains why the script wasn’t applied to libgomp. It > DTRT if applied manually. Good news. I didn't imagine there were differences in the way results are extracted between our various tools/libs. > I guess an edit of the various library testsuite Makefile(s) to generate the > original .sum file as a temp followed by dg-extract-results to the final file > would work. Will try it when I have a few moments (unless you get to it > first ;) ) Please do, I don't plan to check libgomp. Thanks Christophe > > Iain >
Re: [PATCH] Fix bogus fix-it for FLT_MAX (PR c/89122)
On Thu, 2019-01-31 at 10:35 +0100, Richard Biener wrote:
> On Thu, Jan 31, 2019 at 12:09 AM David Malcolm
> wrote:
> >
> > PR c/89122 reports that we emit a bogus fix-it hint for the case
> > where
> > the code uses FLT_MAX, but has included rather than
> > :
> >
> > x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did
> > you
> > mean 'INT_MAX'?
> > 3 | float f = FLT_MAX;
> > | ^~~
> > | INT_MAX
> >
> > This patch adds some knowledge of (and ) to
> > known-headers.cc, fixing the issue:
> >
> > x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function)
> > 3 | float f = FLT_MAX;
> > | ^~~
> > x.c:2:1: note: 'FLT_MAX' is defined in header ''; did you
> > forget
> > to '#include '?
> > 1 | #include
> > +++ |+#include
> > 2 |
> >
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> >
> > Is this OK for trunk in stage 4? (presumably very low risk)
>
> What does it not say for
>
> int i = FLT_MAX;
>
> ? Hopefully it doesn't suggest to include float.h but suggests
> to include limits.h and INT_MAX?
The suggestions code (lookup_name_fuzzy) doesn't take types into
account, and has no knowledge of the "int-ness" of i. It's purely
looking for matches for names that it didn't recognize (albeit with an
enum to hint at whether it's looking for a type vs a function-like
thing vs "anything", but that wouldn't help here).
Trunk emits:
y.c:1:9: error: 'FLT_MAX' undeclared here (not in a function)
1 | int i = FLT_MAX;
| ^~~
With the patch it does indeed tell the user where FLT_MAX is:
y.c:1:9: error: 'FLT_MAX' undeclared here (not in a function)
1 | int i = FLT_MAX;
| ^~~
y.c:1:1: note: 'FLT_MAX' is defined in header ''; did you
forget to '#include '?
+++ |+#include
1 | int i = FLT_MAX;
This doesn't seem too bad to me (in that it's screaming "float" to the
user); if the user ignores that and blindly follows the suggestion,
they get:
y.c:2:9: warning: overflow in conversion from 'float' to 'int' changes
value from '3.40282347e+38f' to '2147483647' [-Woverflow]
2 | int i = FLT_MAX;
| ^~~
y.c:2:1: warning: overflow in constant expression [-Woverflow]
2 | int i = FLT_MAX;
| ^~~
It's not clear to me that we would want a fix-it hint for this case
(where the compiler knows about FLT_MAX) - maybe the user meant to
write that? Such a fix-it hint might look something like:
y.c:2:9: warning: overflow in conversion from 'float' to 'int' changes
value from '3.40282347e+38f' to '2147483647'; did you mean 'INT_MAX' [-
Woverflow]
2 | int i = FLT_MAX;
| ^~~
| INT_MAX
...or somesuch, but that's clearly too ambitious a patch for stage 4.
Would that be reasonable for the next stage 1?
In the meantime, is the original patch OK?
Thanks
Dave
> > gcc/c-family/ChangeLog:
> > PR c/89122
> > * known-headers.cc (get_stdlib_header_for_name): Add
> > {FLT|DBL|LDBL}_{MAX|MIN} to "hints" array.
> >
> > gcc/testsuite/ChangeLog:
> > PR c/89122
> > * g++.dg/spellcheck-stdlib.C (test_FLT_MAX): New test.
> > * gcc.dg/spellcheck-stdlib.c (test_FLT_MAX): New test.
> > ---
> > gcc/c-family/known-headers.cc| 8
> > gcc/testsuite/g++.dg/spellcheck-stdlib.C | 5 +
> > gcc/testsuite/gcc.dg/spellcheck-stdlib.c | 5 +
> > 3 files changed, 18 insertions(+)
> >
> > diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-
> > headers.cc
> > index e3dcf73..c222f30 100644
> > --- a/gcc/c-family/known-headers.cc
> > +++ b/gcc/c-family/known-headers.cc
> > @@ -84,6 +84,14 @@ get_stdlib_header_for_name (const char *name,
> > enum stdlib lib)
> > {"ULONG_MAX", {"", ""} },
> > {"USHRT_MAX", {"", ""} },
> >
> > +/* and . */
> > +{"DBL_MAX", {"", ""} },
> > +{"DBL_MIN", {"", ""} },
> > +{"FLT_MAX", {"", ""} },
> > +{"FLT_MIN", {"", ""} },
> > +{"LDBL_MAX", {"", ""} },
> > +{"LDBL_MIN", {"", ""} },
> > +
> > /* and . */
> > {"va_list", {"", ""} },
> >
> > diff --git a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> > b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> > index 11a4e3e..31e91fe 100644
> > --- a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> > +++ b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
> > @@ -77,6 +77,11 @@ int test_INT_MAX (void)
> >// { dg-message "'INT_MAX' is defined in header ''; did
> > you forget to '#include '?" "" { target *-*-* }
> > INT_MAX_line }
> > }
> >
> > +/* Missing . */
> > +float test_FLT_MAX = FLT_MAX; // { dg-line FLT_MAX_line }
> > +// { dg-error "'FLT_MAX' was not declared" "" { target *-*-* }
> > FLT_MAX_line }
> > +// { dg-message "'FLT_MAX' is defined in header ''; did
> > you forget to '#include '?" "" { target *-*-* }
> > FLT_MAX_line }
> > +
> > /* Missing . */
> >
> > void test_cstring (char *dest, char *src)
> > diff --git a/gcc/tests
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On 1/31/19 4:52 AM, Richard Biener wrote:
On Thu, Jan 31, 2019 at 8:40 AM Aldy Hernandez wrote:
Hi folks.
The problem here is that Wprintf* uses the evrp_range_analyzer engine,
and doesn't understand that the x_5 != 256 conditional below should make
the RANGE [0, 255], not [0, 256].
[local count: 1063004407]:
# RANGE [0, 256] NONZERO 511
# x_10 = PHI <0(2), x_5(3)>
snprintf (&temp, 4, "%%%02X", x_10);
# RANGE [1, 256] NONZERO 511
x_5 = x_10 + 1;
if (x_5 != 256)
goto ; [98.99%]
else
goto ; [1.01%]
This PR is handled quite easily in the ranger work, but alas there is
nothing for this release. Therefore, I'd like to dedicate as little
time as possible to this PR this time around.
Various possible solutions are discussed in the PR. I think an easy way
is to lean on loop analysis to refine the PHI result. It turns out the
evrp engine already does this if SCEV data is available.
As Richard mentioned in the PR, we should avoid code differences
dependent on -W* flags. I have put the loop init code in the pass
itself, but am open to moving it outside, perhaps early in the gate
function ??.
I also took the liberty of calling loop_optimizer_init() with the
smallest subset of LOOPS_NORMAL which could still fix the problem
(LOOPS_HAVE_PREHEADERS). This avoids unnecessary changes to the CFG.
But really, I'm just guessing here. LOOPS_NORMAL would also work,
albeit creating forwarder blocks.
Tested on x86-64 Linux.
What do you think?
As far as I understand fold_return_value is true/false independent
of -W* flags (but dependent on -fprintf-return-value or so). This means
that your patch avoids the risk of CFG changes dependent on
-W* flags. This means you could safely use LOOPS_NORMAL
But isn't my code inside of ::execute, which is still gated by
fold_return_value AND all the -W* flags:?
bool
pass_sprintf_length::gate (function *)
{
return ((warn_format_overflow > 0
|| warn_format_trunc > 0
|| flag_printf_return_value)
&& (optimize > 0) == fold_return_value);
}
Thus, I think we need to move the loop initialization somewhere else ??.
(I'm not sure SCEV is happy with just pre-headers, unfortunately
its exact requirements are not documented... - at least I see
unconditional dereferences of loop->latch which rules out
LOOPS_NO_CFG_MANIPULATION, likewise loop_preheader_edge
is mentioned).
That said, LOOPS_HAVE_PREHEADERS probably works well
enough for both SCEV and niter analysis.
Thus, the patch is OK if you adjust the comment a bit, it's
perfectly safe to init loops conditional on optimization and
running in the gate isn't wanted. I'm also not sure why
this should go away with on-demand info -- working in
the EVRP DOM walker exactly provides on-demand info
(just the DOM style one relies on SCEV / niter analysis
for any backedge work).
I believe there are backedge smarts in the ranger, at least for the
simple cases. But I'll change the comment about the on-demand code
curing everything, into some reminder to remove the SCEV stuff if/when
we have a more precise range mechanism. I'd hate for this loop
optimization requirement to survive past our need for it.
Aldy
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On Thu, Jan 31, 2019 at 09:30:13AM -0500, Aldy Hernandez wrote:
> > > (LOOPS_HAVE_PREHEADERS). This avoids unnecessary changes to the CFG.
> > > But really, I'm just guessing here. LOOPS_NORMAL would also work,
> > > albeit creating forwarder blocks.
> > >
> > > Tested on x86-64 Linux.
> > >
> > > What do you think?
> >
> > As far as I understand fold_return_value is true/false independent
> > of -W* flags (but dependent on -fprintf-return-value or so). This means
> > that your patch avoids the risk of CFG changes dependent on
> > -W* flags. This means you could safely use LOOPS_NORMAL
>
> But isn't my code inside of ::execute, which is still gated by
> fold_return_value AND all the -W* flags:?
>
> bool
> pass_sprintf_length::gate (function *)
> {
> return ((warn_format_overflow > 0
> || warn_format_trunc > 0
> || flag_printf_return_value)
> && (optimize > 0) == fold_return_value);
> }
>
> Thus, I think we need to move the loop initialization somewhere else ??.
Then perhaps turn the gate into just return (optimize > 0) == fold_return_value;
and in execute do what you're adding and guard the rest with the above
condition? As -fprintf-return-value is on by default for C-family, it shouldn't
change much.
+ adjust comment on the gate of course.
Jakub
[PATCH, committed] Fix SLSR portion of PR89008
Hi,
PR89008 observes that SLSR gets confused when provided with an expression of
the form X * 0.
The bug is currently latent on trunk, gcc 8, and gcc 7. This patch avoids
placing such
expressions in SLSR's candidate table, since they aren't of any use anyway.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Tested on
an older revision where the bug was observable and found to fix the problem.
Committed,
backports pending.
Thanks,
Bill
2018-01-31 Bill Schmidt
PR tree-optimization/89008
* gimple-ssa-strength-reduction.c (slsr_process_mul): Don't
process anything of the form X * 0.
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa-strength-reduction.c (revision 268411)
+++ gcc/gimple-ssa-strength-reduction.c (working copy)
@@ -1268,7 +1268,7 @@ slsr_process_mul (gimple *gs, tree rhs1, tree rhs2
c->next_interp = c2->cand_num;
c2->first_interp = c->cand_num;
}
- else if (TREE_CODE (rhs2) == INTEGER_CST)
+ else if (TREE_CODE (rhs2) == INTEGER_CST && !integer_zerop (rhs2))
{
/* Record an interpretation for the multiply-immediate. */
c = create_mul_imm_cand (gs, rhs1, rhs2, speed);
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On Wed, Jan 30, 2019 at 05:37:13PM -0500, Jason Merrill wrote:
> On 1/30/19 4:15 PM, Marek Polacek wrote:
> > On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
> > > On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> > > > On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek
> > > > wrote:
> > > > >
> > > > > My recent patch for 88815 and 78244 caused 89083, a P1 9 regression,
> > > > > which
> > > > > happens to be the same problem as 80864 and its many dupes, something
> > > > > I'd
> > > > > been meaning to fix for a long time.
> > > > >
> > > > > Basically, the problem is repeated reshaping of a constructor, once
> > > > > when
> > > > > parsing, and then again when substituting. With the recent fix, we
> > > > > call
> > > > > reshape_init + digest_init in finish_compound_literal even in a
> > > > > template
> > > > > if the expression is not instantiation-dependent, and then again when
> > > > > tsubst_*.
> > > > >
> > > > > For instance, in initlist107.C, when parsing a functional cast, we
> > > > > call
> > > > > finish_compound_literal which calls reshape_init, which turns
> > > > >
> > > > >{ NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
> > > > >
> > > > > into
> > > > >
> > > > >{ { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
> > > > >
> > > > > and then digest_init turns that into
> > > > >
> > > > >{ .x = { 1, 2 } }
> > > > >
> > > > > which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the
> > > > > subexpression
> > > > > "{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so it's
> > > > > not
> > > > > BRACE_ENCLOSED_INITIALIZER_P.
> > > > >
> > > > > And then tsubst_* processes "{ .x = { 1, 2 } }". The case CONSTRUCTOR
> > > > > in tsubst_copy_and_build will call finish_compound_literal on a copy
> > > > > of
> > > > > "{ 1, 2 }" wrapped in a new { }, because the whole expr has
> > > > > TREE_HAS_CONSTRUCTOR.
> > > > > That crashes in reshape_init_r in the
> > > > > 6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
> > > > > block; we have a constructor, it's not COMPOUND_LITERAL_P, and because
> > > > > digest_init had given it the type int[3], we hit
> > > > > 6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P
> > > > > (stripped_init));
> > > > >
> > > > > As expand_default_init explains in a comment, a CONSTRUCTOR of the
> > > > > target's type
> > > > > is a previously digested initializer, so we should probably do a
> > > > > similar trick
> > > > > here. This fixes all the variants of the problem I've come up with.
> > > > >
> > > > > 80864 is a similar case, we reshape when parsing and then second time
> > > > > in
> > > > > fold_non_dependent_expr called from store_init_value, because of the
> > > > > 'constexpr'.
> > > > >
> > > > > Also update a stale comment.
> > > > >
> > > > > Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8
> > > > > after a while?
> > > > >
> > > > > 2019-01-29 Marek Polacek
> > > > >
> > > > > PR c++/89083, c++/80864 - ICE with list initialization in
> > > > > template.
> > > > > * decl.c (reshape_init_r): Don't reshape a digested
> > > > > initializer.
> > > > >
> > > > > * g++.dg/cpp0x/initlist107.C: New test.
> > > > > * g++.dg/cpp0x/initlist108.C: New test.
> > > > > * g++.dg/cpp0x/initlist109.C: New test.
> > > > >
> > > > > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > > > > index 79eeac177b6..da08ecc21aa 100644
> > > > > --- gcc/cp/decl.c
> > > > > +++ gcc/cp/decl.c
> > > > > @@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter *d,
> > > > > bool first_initializer_p,
> > > > > ;
> > > > >else if (COMPOUND_LITERAL_P (stripped_init))
> > > > >/* For a nested compound literal, there is no need to
> > > > > reshape since
> > > > > -brace elision is not allowed. Even if we decided to
> > > > > allow it,
> > > > > -we should add a call to reshape_init in
> > > > > finish_compound_literal,
> > > > > -before calling digest_init, so changing this code would
> > > > > still
> > > > > -not be necessary. */
> > > > > +we called reshape_init in finish_compound_literal,
> > > > > before calling
> > > > > +digest_init. */
> > > > > gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P
> > > > > (stripped_init));
> > > > > + /* Similarly, a CONSTRUCTOR of the target's type is a
> > > > > previously
> > > > > +digested initializer. */
> > > > > + else if (same_type_ignoring_top_level_qualifiers_p (type,
> > > > > +
> > > > > TREE_TYPE (init)))
> > > >
> > > > Hmm, aren't both of these tests true for a dependent compound literal,
> > > > which won't have been reshaped already?
> > >
> > > I'm hoping that can't happen, but it's a good question. When we have a
> > > dependent compound
Re: [PATCH 3/3][GCC][AARCH64] Add support for pointer authentication B key
On 23/01/2019 10:22, Sam Tebbs wrote: > On 14/01/2019 10:43, Kyrill Tkachov wrote: > >> On 08/01/19 11:38, Sam Tebbs wrote: >> >> >> >> On 1/7/19 6:28 PM, James Greenhalgh wrote: >> >> > On Fri, Dec 21, 2018 at 09:00:10AM -0600, Sam Tebbs wrote: >> >> >> On 11/9/18 11:04 AM, Sam Tebbs wrote: >> >> > >> >> > >> >> > >> >> >> Attached is an improved patch with "hint" removed from the test scans, >> >> >> pauth_hint_num_a and pauth_hint_num_b merged into pauth_hint_num and the >> >> >> "gcc_assert (cfun->machine->frame.laid_out)" removal reverted since was >> >> >> an unnecessary change. >> >> >> >> >> >> OK for trunk? >> >> > While the AArch64 parts look OK to me and are buried behind an option so >> > are >> >> > relatively safe even though we're late in development, you'll need someone >> >> > else to approve the libgcc changes. Especially as you change a generic >> >> > routine with an undocumented (?) AArch64-specific change. >> >> > >> >> > Thanks, >> >> > James >> >> >> >> Thanks James, CC'ing Ian Lance Taylor. >> >> >> Jeff, could you help with reviewing the libgcc changes please? >> I believe the latest version was posted at: >> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01569.html >> >> Thanks, >> Kyrill > ping 3. The preceding two patches were committed a while ago but require > the minor libgcc changes in this patch, which are the only parts left to > be reviewed. ping 4 >>> The documentation relevant to the libgcc change is expected to be >>> >>> published in the near future. >>> >>> >>> >>> > >>> >>> >> gcc/ >>> >>> >> 2018-12-21 Sam Tebbs >>> >>> >> >>> >>> >> * config/aarch64/aarch64-builtins.c (aarch64_builtins): Add >>> >>> >> AARCH64_PAUTH_BUILTIN_AUTIB1716 and >>> >>AARCH64_PAUTH_BUILTIN_PACIB1716. >>> >>> >> * config/aarch64/aarch64-builtins.c >>> >>(aarch64_init_pauth_hint_builtins): >>> >>> >> Add autib1716 and pacib1716 initialisation. >>> >>> >> * config/aarch64/aarch64-builtins.c (aarch64_expand_builtin): Add >>> >>checks >>> >>> >> for autib1716 and pacib1716. >>> >>> >> * config/aarch64/aarch64-protos.h (aarch64_key_type, >>> >>> >> aarch64_post_cfi_startproc): Define. >>> >>> >> * config/aarch64/aarch64-protos.h (aarch64_ra_sign_key): Define >>> >>extern. >>> >>> >> * config/aarch64/aarch64.c >>> >>(aarch64_return_address_signing_enabled): Add >>> >>> >> check for b-key. >>> >>> >> * config/aarch64/aarch64.c (aarch64_ra_sign_key, >>> >>> >> aarch64_post_cfi_startproc, aarch64_handle_pac_ret_b_key): Define. >>> >>> >> * config/aarch64/aarch64.h (TARGET_ASM_POST_CFI_STARTPROC): Define. >>> >>> >> * config/aarch64/aarch64.c (aarch64_pac_ret_subtypes): Add "b-key". >>> >>> >> * config/aarch64/aarch64.md (unspec): Add UNSPEC_AUTIA1716, >>> >>> >> UNSPEC_AUTIB1716, UNSPEC_AUTIASP, UNSPEC_AUTIBSP, UNSPEC_PACIA1716, >>> >>> >> UNSPEC_PACIB1716, UNSPEC_PACIASP, UNSPEC_PACIBSP. >>> >>> >> * config/aarch64/aarch64.md (do_return): Add check for b-key. >>> >>> >> * config/aarch64/aarch64.md (sp): Replace >>> >>> >> pauth_hint_num_a with pauth_hint_num. >>> >>> >> * config/aarch64/aarch64.md (1716): Replace >>> >>> >> pauth_hint_num_a with pauth_hint_num. >>> >>> >> * config/aarch64/aarch64.opt (msign-return-address=): Deprecate. >>> >>> >> * config/aarch64/iterators.md (PAUTH_LR_SP): Add UNSPEC_AUTIASP, >>> >>> >> UNSPEC_AUTIBSP, UNSPEC_PACIASP, UNSPEC_PACIBSP. >>> >>> >> * config/aarch64/iterators.md (PAUTH_17_16): Add UNSPEC_AUTIA1716, >>> >>> >> UNSPEC_AUTIB1716, UNSPEC_PACIA1716, UNSPEC_PACIB1716. >>> >>> >> * config/aarch64/iterators.md (pauth_mnem_prefix): Add >>> >>UNSPEC_AUTIA1716, >>> >>> >> UNSPEC_AUTIB1716, UNSPEC_PACIA1716, UNSPEC_PACIB1716, >>> >>UNSPEC_AUTIASP, >>> >>> >> UNSPEC_AUTIBSP, UNSPEC_PACIASP, UNSPEC_PACIBSP. >>> >>> >> * config/aarch64/iterators.md (pauth_hint_num_a): Replace >>> >>> >> UNSPEC_PACI1716 and UNSPEC_AUTI1716 with UNSPEC_PACIA1716 and >>> >>> >> UNSPEC_AUTIA1716 respectively. >>> >>> >> * config/aarch64/iterators.md (pauth_hint_num_a): Rename to >>> >>pauth_hint_num >>> >>> >> and add UNSPEC_PACIBSP, UNSPEC_AUTIBSP, UNSPEC_PACIB1716, >>> >>UNSPEC_AUTIB1716. >>> >>> >> >>> >>> >> gcc/testsuite >>> >>> >> 2018-12-21 Sam Tebbs >>> >>> >> >>> >>> >> * gcc.target/aarch64/return_address_sign_1.c (dg-final): Replace >>> >>> >> "autiasp" and "paciasp" with "hint\t29 // autisp" and >>> >>> >> "hint\t25 // pacisp" respectively. >>> >>> >> * gcc.target/aarch64/return_address_sign_2.c (dg-final): Replace >>> >>> >> "paciasp" with "hint\t25 // pacisp". >>> >>> >> * gcc.target/aarch64/return_address_sign_3.c (dg-final): Replace >>> >>> >> "paciasp" and "autiasp" with "pacisp" and "autisp" respectively. >>> >>> >> * gcc.target/aarch64/return_address_sign_b_1.c: New file. >>> >>> >> * gcc.t
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On Thu, Jan 31, 2019 at 3:45 PM Jakub Jelinek wrote:
>
> On Thu, Jan 31, 2019 at 09:30:13AM -0500, Aldy Hernandez wrote:
> > > > (LOOPS_HAVE_PREHEADERS). This avoids unnecessary changes to the CFG.
> > > > But really, I'm just guessing here. LOOPS_NORMAL would also work,
> > > > albeit creating forwarder blocks.
> > > >
> > > > Tested on x86-64 Linux.
> > > >
> > > > What do you think?
> > >
> > > As far as I understand fold_return_value is true/false independent
> > > of -W* flags (but dependent on -fprintf-return-value or so). This means
> > > that your patch avoids the risk of CFG changes dependent on
> > > -W* flags. This means you could safely use LOOPS_NORMAL
> >
> > But isn't my code inside of ::execute, which is still gated by
> > fold_return_value AND all the -W* flags:?
> >
> > bool
> > pass_sprintf_length::gate (function *)
> > {
> > return ((warn_format_overflow > 0
> > || warn_format_trunc > 0
> > || flag_printf_return_value)
> > && (optimize > 0) == fold_return_value);
> > }
> >
> > Thus, I think we need to move the loop initialization somewhere else ??.
>
> Then perhaps turn the gate into just return (optimize > 0) ==
> fold_return_value;
> and in execute do what you're adding and guard the rest with the above
> condition? As -fprintf-return-value is on by default for C-family, it
> shouldn't
> change much.
> + adjust comment on the gate of course.
Don't you alreday have
@@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
init_target_to_host_charmap ();
calculate_dominance_info (CDI_DOMINATORS);
+ bool optimizing_late = optimize > 0 && fold_return_value;
+ if (optimizing_late)
+{
+ /* ?? We should avoid changing the CFG as much as possible.
...
+ loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
+ scev_initialize ();
+}
so loops are only initialized if fold_return_value is true? Ah - but that's
the pass parameter from params.def rather than the flag to enable
the folding... So indeed, change it to include && flag_printf_return_value
Richard.
> Jakub
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On Thu, Jan 31, 2019 at 03:56:12PM +0100, Richard Biener wrote:
> Don't you alreday have
>
> @@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
>init_target_to_host_charmap ();
>
>calculate_dominance_info (CDI_DOMINATORS);
> + bool optimizing_late = optimize > 0 && fold_return_value;
> + if (optimizing_late)
> +{
> + /* ?? We should avoid changing the CFG as much as possible.
> ...
> + loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
> + scev_initialize ();
> +}
>
> so loops are only initialized if fold_return_value is true? Ah - but that's
> the pass parameter from params.def rather than the flag to enable
> the folding... So indeed, change it to include && flag_printf_return_value
fold_return_value is not the same thing as flag_printf_return_value,
the former is just a bool whether it is the -O0 or -O1+ version of the pass.
So, optimizing_late doesn't make much sense, one can use optimize > 0
directly instead.
If changing the above to && flag_printf_return_value then people will
complain that they get the false positive warning with -Wall
-fno-printf-return-value.
Jakub
[C++ PATCH] PR c++/88752 - ICE with lambda and constexpr if.
In this testcase, we look for an instantiation of the outer lambda from
within the inner lambda. enclosing_instantiation_of didn't handle this
properly, as it assumed that any references would be from the same lambda
nesting depth. Fixed thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
* cp-tree.h (LAMBDA_EXPR_INSTANTIATED): New.
* pt.c (tsubst_lambda_expr): Set it.
(instantiated_lambda_fn_p): Check it.
(enclosing_instantiation_of): Use it.
---
gcc/cp/cp-tree.h| 5
gcc/cp/pt.c | 22 +++-
gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C | 28 +
gcc/cp/ChangeLog| 8 ++
4 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 77e1425b435..dada3a6aa41 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -453,6 +453,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
DECLTYPE_FOR_REF_CAPTURE (in DECLTYPE_TYPE)
CONSTRUCTOR_C99_COMPOUND_LITERAL (in CONSTRUCTOR)
OVL_NESTED_P (in OVERLOAD)
+ LAMBDA_EXPR_INSTANTIATED (in LAMBDA_EXPR)
4: IDENTIFIER_MARKED (IDENTIFIER_NODEs)
TREE_HAS_CONSTRUCTOR (in INDIRECT_REF, SAVE_EXPR, CONSTRUCTOR,
CALL_EXPR, or FIELD_DECL).
@@ -1334,6 +1335,10 @@ enum cp_lambda_default_capture_mode_type {
#define LAMBDA_EXPR_CAPTURE_OPTIMIZED(NODE) \
TREE_LANG_FLAG_2 (LAMBDA_EXPR_CHECK (NODE))
+/* True iff this LAMBDA_EXPR was generated in tsubst_lambda_expr. */
+#define LAMBDA_EXPR_INSTANTIATED(NODE) \
+ TREE_LANG_FLAG_3 (LAMBDA_EXPR_CHECK (NODE))
+
/* True if this TREE_LIST in LAMBDA_EXPR_CAPTURE_LIST is for an explicit
capture. */
#define LAMBDA_CAPTURE_EXPLICIT_P(NODE) \
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index cb06a570d48..f100f62f9a1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13298,6 +13298,19 @@ lambda_fn_in_template_p (tree fn)
return CLASSTYPE_TEMPLATE_INFO (closure) != NULL_TREE;
}
+/* True if FN is the substitution (via tsubst_lambda_expr) of a function for
+ which the above is true. */
+
+bool
+instantiated_lambda_fn_p (tree fn)
+{
+ if (!fn || !LAMBDA_FUNCTION_P (fn))
+return false;
+ tree closure = DECL_CONTEXT (fn);
+ tree lam = CLASSTYPE_LAMBDA_EXPR (closure);
+ return LAMBDA_EXPR_INSTANTIATED (lam);
+}
+
/* We're instantiating a variable from template function TCTX. Return the
corresponding current enclosing scope. This gets complicated because lambda
functions in templates are regenerated rather than instantiated, but generic
@@ -13317,13 +13330,19 @@ enclosing_instantiation_of (tree otctx)
{
tree ofn = fn;
int flambda_count = 0;
- for (; flambda_count < lambda_count && fn && LAMBDA_FUNCTION_P (fn);
+ for (; fn && instantiated_lambda_fn_p (fn);
fn = decl_function_context (fn))
++flambda_count;
if ((fn && DECL_TEMPLATE_INFO (fn))
? most_general_template (fn) != most_general_template (tctx)
: fn != tctx)
continue;
+ if (flambda_count != lambda_count)
+ {
+ gcc_assert (flambda_count > lambda_count);
+ for (; flambda_count > lambda_count; --flambda_count)
+ ofn = decl_function_context (ofn);
+ }
gcc_assert (DECL_NAME (ofn) == DECL_NAME (otctx)
|| DECL_CONV_FN_P (ofn));
return ofn;
@@ -17870,6 +17889,7 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t
complain, tree in_decl)
LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (r)
= LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (t);
LAMBDA_EXPR_MUTABLE_P (r) = LAMBDA_EXPR_MUTABLE_P (t);
+ LAMBDA_EXPR_INSTANTIATED (r) = true;
if (LAMBDA_EXPR_EXTRA_SCOPE (t) == NULL_TREE)
/* A lambda in a default argument outside a class gets no
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C
new file mode 100644
index 000..e85dcdc7f77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if26.C
@@ -0,0 +1,28 @@
+// PR c++/88752
+// { dg-do compile { target c++17 } }
+
+template struct b { static constexpr int c = a; };
+class d;
+template struct e { typedef d f; };
+template using h = typename e::f;
+template constexpr bool i = b::c;
+class d {
+public:
+ using j = float;
+};
+template void k();
+int main() { k(); }
+template l m;
+template void n(r o) {
+ [](int) {}(o(m));
+}
+template void k() {
+ n([](auto inputs) {
+auto p(inputs);
+using s = h;
+s q;
+if constexpr (i)
+ [&] { return q; }();
+return 42;
+ });
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index af4d9c2635e..507103791e7 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,11 @@
+2019-01-30 Jason Merrill
+
+ PR c++/88752 - ICE with lambda and constexpr if.
+ * cp-tree.h (LAMBDA_EXPR_INSTANTIATED): New.
+ * pt.c (tsubst
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On Thu, Jan 31, 2019 at 4:02 PM Jakub Jelinek wrote:
>
> On Thu, Jan 31, 2019 at 03:56:12PM +0100, Richard Biener wrote:
> > Don't you alreday have
> >
> > @@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
> >init_target_to_host_charmap ();
> >
> >calculate_dominance_info (CDI_DOMINATORS);
> > + bool optimizing_late = optimize > 0 && fold_return_value;
> > + if (optimizing_late)
> > +{
> > + /* ?? We should avoid changing the CFG as much as possible.
> > ...
> > + loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
> > + scev_initialize ();
> > +}
> >
> > so loops are only initialized if fold_return_value is true? Ah - but that's
> > the pass parameter from params.def rather than the flag to enable
> > the folding... So indeed, change it to include && flag_printf_return_value
>
> fold_return_value is not the same thing as flag_printf_return_value,
> the former is just a bool whether it is the -O0 or -O1+ version of the pass.
> So, optimizing_late doesn't make much sense, one can use optimize > 0
> directly instead.
>
> If changing the above to && flag_printf_return_value then people will
> complain that they get the false positive warning with -Wall
> -fno-printf-return-value.
Sure - too bad then. Another option would be to make SCEV / niter analysis
"safe" to be called with LOOPS_AVOID_CFG_MANIPULATIONs (multiple
latches, multiple entries into headers, etc.).
Richard.
> Jakub
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On 1/31/19 9:50 AM, Marek Polacek wrote:
On Wed, Jan 30, 2019 at 05:37:13PM -0500, Jason Merrill wrote:
On 1/30/19 4:15 PM, Marek Polacek wrote:
On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek wrote:
My recent patch for 88815 and 78244 caused 89083, a P1 9 regression, which
happens to be the same problem as 80864 and its many dupes, something I'd
been meaning to fix for a long time.
Basically, the problem is repeated reshaping of a constructor, once when
parsing, and then again when substituting. With the recent fix, we call
reshape_init + digest_init in finish_compound_literal even in a template
if the expression is not instantiation-dependent, and then again when
tsubst_*.
For instance, in initlist107.C, when parsing a functional cast, we call
finish_compound_literal which calls reshape_init, which turns
{ NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
into
{ { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
and then digest_init turns that into
{ .x = { 1, 2 } }
which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the subexpression
"{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so it's not
BRACE_ENCLOSED_INITIALIZER_P.
And then tsubst_* processes "{ .x = { 1, 2 } }". The case CONSTRUCTOR
in tsubst_copy_and_build will call finish_compound_literal on a copy of
"{ 1, 2 }" wrapped in a new { }, because the whole expr has
TREE_HAS_CONSTRUCTOR.
That crashes in reshape_init_r in the
6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
block; we have a constructor, it's not COMPOUND_LITERAL_P, and because
digest_init had given it the type int[3], we hit
6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
As expand_default_init explains in a comment, a CONSTRUCTOR of the target's type
is a previously digested initializer, so we should probably do a similar trick
here. This fixes all the variants of the problem I've come up with.
80864 is a similar case, we reshape when parsing and then second time in
fold_non_dependent_expr called from store_init_value, because of the
'constexpr'.
Also update a stale comment.
Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8 after a while?
2019-01-29 Marek Polacek
PR c++/89083, c++/80864 - ICE with list initialization in template.
* decl.c (reshape_init_r): Don't reshape a digested initializer.
* g++.dg/cpp0x/initlist107.C: New test.
* g++.dg/cpp0x/initlist108.C: New test.
* g++.dg/cpp0x/initlist109.C: New test.
diff --git gcc/cp/decl.c gcc/cp/decl.c
index 79eeac177b6..da08ecc21aa 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter *d, bool
first_initializer_p,
;
else if (COMPOUND_LITERAL_P (stripped_init))
/* For a nested compound literal, there is no need to reshape since
-brace elision is not allowed. Even if we decided to allow it,
-we should add a call to reshape_init in finish_compound_literal,
-before calling digest_init, so changing this code would still
-not be necessary. */
+we called reshape_init in finish_compound_literal, before calling
+digest_init. */
gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));
+ /* Similarly, a CONSTRUCTOR of the target's type is a previously
+digested initializer. */
+ else if (same_type_ignoring_top_level_qualifiers_p (type,
+ TREE_TYPE (init)))
Hmm, aren't both of these tests true for a dependent compound literal,
which won't have been reshaped already?
I'm hoping that can't happen, but it's a good question. When we have a
dependent compound literal, finish_compound_literal just sets
TREE_HAS_CONSTRUCTOR and returns it, so then in tsubst_*, after substituting
each element of the constructor, we call finish_compound_literal. The
constructor is no longer dependent and since we operate on a copy on which
we didn't set TREE_HAS_CONSTRUCTOR, the first condition shouldn't be true.
And the second condition should also never be true for a compound literal
that hasn't been reshaped, because digest_init is only ever called after
reshape_init (and the comment for digest_init_r says it assumes that
reshape_init has already run).
And because, as above, tsubst_* builds up a CONSTRUCTOR with
init_list_type_node and feeds that to finish_compound_literal.
Yes.
I suppose that means we do the same thing for a non-dependent CONSTRUCTOR
that has already been reshaped, but it should be harmless.
The type of a CONSTRUCTOR can also by changed
in tsubst_copy_and_build:
19269 TREE_TYPE (r) = type;
but I haven't been able to trigger any problem yet. Worst comes to worst this
patch changes t
Re: [C++PATCH] [PR86379] do not use TREE_TYPE for USING_DECL_SCOPE
On 1/30/19 8:07 PM, Alexandre Oliva wrote:
It's too risk to reuse the type field for USING_DECL_SCOPE.
Language-independent parts of the compiler, such as location and
non-lvalue wrappers, happily take the TREE_TYPE of a USING_DECL as if
it was a type rather than an unrelated scope.
For better or worse, USING_DECLs use the non-common struct so we can
use the otherwise unused result field. Adjust fallout, from uses of
TREE_TYPE that were supposed to be USING_DECL_SCOPE, to other
accidental uses of TREE_TYPE of a USING_DECL.
Regstrapped on x86_64- and i686-linux-gnu. Ok to install?
(but see the additional patchlet below)
for gcc/cp/ChangeLog
PR c++/86379
* cp-tree.h (USING_DECL_SCOPE): Use result rather than type.
* name-lookup.c (strip_using_decl): Use USING_DECL_SCOPE.
* search.c (protected_accessible_p): Follow USING_DECL_DECLS.
(shared_member_p): Likewise.
(lookup_member): Likewise.
* decl.c (copy_fn_p): Likewise.
(grok_special_member_properties): Do not test USING_DECL for
staticness.
* semantics.c (finish_omp_declare_simd_methods): Likewise.
for gcc/testsuite/ChangeLog
PR c++/86379
* g++.dg/cpp0x/pr86379.C: New.
---
gcc/cp/cp-tree.h |2
gcc/cp/decl.c| 10 +-
gcc/cp/name-lookup.c |2
gcc/cp/search.c | 23 +++-
gcc/cp/semantics.c |3
gcc/testsuite/g++.dg/cpp0x/pr86379.C | 207 ++
6 files changed, 240 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr86379.C
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 77e1425b4357b..053ed5ace6d42 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3288,7 +3288,7 @@ struct GTY(()) lang_decl {
#define DECL_DEPENDENT_P(NODE) DECL_LANG_FLAG_0 (USING_DECL_CHECK (NODE))
/* The scope named in a using decl. */
-#define USING_DECL_SCOPE(NODE) TREE_TYPE (USING_DECL_CHECK (NODE))
+#define USING_DECL_SCOPE(NODE) DECL_RESULT_FLD (USING_DECL_CHECK (NODE))
/* The decls named by a using decl. */
#define USING_DECL_DECLS(NODE) DECL_INITIAL (USING_DECL_CHECK (NODE))
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 79eeac177b64c..86101d3bc3b45 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13174,6 +13174,13 @@ copy_fn_p (const_tree d)
tree arg_type;
int result = 1;
+ while (TREE_CODE (d) == USING_DECL)
+{
+ d = USING_DECL_DECLS (d);
+ if (!d)
+ return result;
+}
Let's use strip_using_decl instead of writing the loop here and in the
other similar places.
@@ -13288,7 +13295,8 @@ grok_special_member_properties (tree decl)
{
tree class_type;
- if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (decl))
+ if (TREE_CODE (decl) != USING_DECL
+ && !DECL_NONSTATIC_MEMBER_FUNCTION_P (decl))
return;
Is there a reason not to use it here, as well?
Jason
Re: [PR middle-end/85598] make -Wprintf* pass use loop info for PHI's
On Thu, Jan 31, 2019 at 04:05:51PM +0100, Richard Biener wrote:
> > On Thu, Jan 31, 2019 at 03:56:12PM +0100, Richard Biener wrote:
> > > Don't you alreday have
> > >
> > > @@ -4200,10 +4202,34 @@ pass_sprintf_length::execute (function *fun)
> > >init_target_to_host_charmap ();
> > >
> > >calculate_dominance_info (CDI_DOMINATORS);
> > > + bool optimizing_late = optimize > 0 && fold_return_value;
> > > + if (optimizing_late)
> > > +{
> > > + /* ?? We should avoid changing the CFG as much as possible.
> > > ...
> > > + loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
> > > + scev_initialize ();
> > > +}
> > >
> > > so loops are only initialized if fold_return_value is true? Ah - but
> > > that's
> > > the pass parameter from params.def rather than the flag to enable
> > > the folding... So indeed, change it to include &&
> > > flag_printf_return_value
> >
> > fold_return_value is not the same thing as flag_printf_return_value,
> > the former is just a bool whether it is the -O0 or -O1+ version of the pass.
> > So, optimizing_late doesn't make much sense, one can use optimize > 0
> > directly instead.
> >
> > If changing the above to && flag_printf_return_value then people will
> > complain that they get the false positive warning with -Wall
> > -fno-printf-return-value.
>
> Sure - too bad then. Another option would be to make SCEV / niter analysis
> "safe" to be called with LOOPS_AVOID_CFG_MANIPULATIONs (multiple
> latches, multiple entries into headers, etc.).
But then that isn't likely going to make it into GCC9.
Do we care that much about -W* not affecting code generation when we have
many -W* options that do affect it and aren't going to be fixed in GCC9 (and
unlikely later on either - mainly the C++ caching related ones), plus
it could affect code generation only if one uses -fno-printf-return-value
explicitly?
Jakub
Re: [PATCH, RFC] Avoid the -D option which is not available install-sh
On 1/31/19 1:21 PM, Rainer Orth wrote: > Hi Bernd, > >> I have fixed the installation with the attached patch, but when I regenerate >> the automake >> files using automake-1.15.1 and autoconf-2.69, I have an issue that >> apparently >> the configure.ac must be out of sync, and the the generated files are missing >> the option --runstatedir no matter what I do. At least on the source >> >> RFC, because I am not sure what the --runstatedir option is, and if it is >> intentional to remove, >> and forgotten to re-generate, or if was intended to add, and forgotten to >> check in the >> configure.ac. >> >> Attached patch which fixes the install issue, and removes the --runstatedir >> configure option. >> Is OK as is, or has anybody an idea how to fix this mess? > > those configure files have been generated with some modified version of > autoconf: --runstatedir isn't present in vanilla autoconf 2.69, but only > in git autoconf. Since there are no uses of it I could find, please do > regenerate with autoconf 2.69 (preferably self-built since distros tend > to include random patches which only confuse future developers). > Yes, I build those always out of the tar balls. tar xf autoconf-2.69.tar.gz cd autoconf-2.69 ./configure --prefix=$(cd ..;pwd)/auto-install make && make install cd .. PATH=$PWD/auto-install/bin:$PATH tar xf automake-1.15.1.tar.gz cd automake-1.15.1 ./configure --prefix=$(cd ..;pwd)/auto-install make && make install cd .. cd gcc-trunk/libphobos autoconf && automake get the following messages: libdruntime/Makefile.am:160: warning: source file 'rt/bss_section.c' is in a subdirectory, libdruntime/Makefile.am:160: but option 'subdir-objects' is disabled libdruntime/Makefile.am:158: warning: source file 'core/threadasm.S' is in a subdirectory, libdruntime/Makefile.am:158: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/adler32.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/compress.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/crc32.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/deflate.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/gzclose.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/gzlib.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/gzread.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/gzwrite.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/infback.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/inffast.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/inflate.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/inftrees.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/trees.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/uncompr.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled src/Makefile.am:106: warning: source file '$(top_srcdir)/../zlib/zutil.c' is in a subdirectory, src/Makefile.am:106: but option 'subdir-objects' is disabled and exactly the same result. So I would suggest to revert the changes from the unreleased autoconf. Is the patch OK for trunk as-is ? Thanks Bernd.
Re: [PATCH, RFC] Avoid the -D option which is not available install-sh
Hi Bernd, >> those configure files have been generated with some modified version of >> autoconf: --runstatedir isn't present in vanilla autoconf 2.69, but only >> in git autoconf. Since there are no uses of it I could find, please do >> regenerate with autoconf 2.69 (preferably self-built since distros tend >> to include random patches which only confuse future developers). >> > > Yes, I build those always out of the tar balls. good. > cd gcc-trunk/libphobos > autoconf && automake You should be careful to use the same options as in Makefile.in, in the case of automake --foreign --ignore-deps. > get the following messages: > > libdruntime/Makefile.am:160: warning: source file 'rt/bss_section.c' is in > a subdirectory, > libdruntime/Makefile.am:160: but option 'subdir-objects' is disabled [...] > and exactly the same result. I think Joseph mentioned those when gcc trunk was moved to newer autoconf and automake versions. > So I would suggest to revert the changes from the unreleased autoconf. IMO you should always regenerate with the documented/required versions. Almost everything else is a prior mistake. > Is the patch OK for trunk as-is ? That's for Iain to decide. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"
Hi!
On Thu, 21 Jan 2016 22:54:26 +0100, I wrote:
> Committed to gomp-4_0-branch in r232709:
>
> commit 41a76d233e714fd7b79dc1f40823f607c38306ba
> Author: tschwinge
> Date: Thu Jan 21 21:52:50 2016 +
>
> Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid
> offloading"
> +! The warning is only triggered for -O2 and higher.
> +! { dg-xfail-if "n/a" { openacc_nvidia_accel_selected } { "-O0" "-O1" } { ""
> } }
> +!$ACC KERNELS /* { dg-warning "OpenACC kernels construct will be executed
> sequentially; will by default avoid offloading to prevent data copy penalty"
> "" { target openacc_nvidia_accel_selected } } */
That can actually be done in a better way, so that we match up exactly
when and where the diagnostic appears, and where not; pushed the attached
to openacc-gcc-8-branch in commit
dfae8e0dab1edfc8d8207eafd1b694c4e1fcd680 'Un-parallelized OpenACC kernels
constructs with nvptx offloading: "avoid offloading": better method for
XFAILing specific cases'.
Grüße
Thomas
>From dfae8e0dab1edfc8d8207eafd1b694c4e1fcd680 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Tue, 29 Jan 2019 20:42:13 +0100
Subject: [PATCH] Un-parallelized OpenACC kernels constructs with nvptx
offloading: "avoid offloading": better method for XFAILing specific cases
gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_opt_levels_2_plus)
(check_effective_target_opt_levels_size): New.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-1.c:
Update.
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-2.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/combined-directives-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/kernels-parallel-loop-data-enter-exit.c:
Likewise.
* testsuite/libgomp.oacc-fortran/asyncwait-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/avoid-offloading-1.f: Likewise.
* testsuite/libgomp.oacc-fortran/avoid-offloading-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/deviceptr-1.f90: Likewise.
* testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-2.f95: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-2.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit-2.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-enter-exit.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data-update.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop-data.f95: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-loop.f95: Likewise.
* testsuite/libgomp.oacc-fortran/kernels-parallel-loop-data-enter-exit.f95:
Likewise.
* testsuite/libgomp.oacc-fortran/non-scalar-data.f90: Likewise.
---
gcc/testsuite/ChangeLog.openacc | 6
gcc/testsuite/lib/target-supports.exp | 10 ++
libgomp/ChangeLog.openacc | 31 +++
.../avoid-offloading-1.c | 5 +--
.../avoid-offloading-2.c | 5 +--
.../combined-directives-1.c | 10 +++---
.../kernels-parallel-loop-data-enter-exit.c | 8 ++---
.../libgomp.oacc-fortran/asyncwait-1.f90 | 9 ++
.../libgomp.oacc-fortran/avoid-offloading-1.f | 4 +--
.../libgomp.oacc-fortran/avoid-offloading-2.f | 4 +--
.../libgomp.oacc-fortran/deviceptr-1.f90 | 7 ++---
.../initialize_kernels_loops.f90 | 5 +--
.../libgomp.oacc-fortran/kernels-loop-2.f95 | 9 ++
.../kernels-loop-data-2.f95 | 9 ++
.../kernels-loop-data-enter-exit-2.f95| 9 ++
.../kernels-loop-data-enter-exit.f95 | 9 ++
.../kernels-loop-data-update.f95 | 7 ++---
.../kernels-loop-data.f95 | 9 ++
.../libgomp.oacc-fortran/kernels-loop.f95 | 5 +--
.../kernels-parallel-loop-data-enter-exit.f95 | 7 ++---
.../libgomp.oacc-fortran/non-scalar-data.f90 | 7 ++---
21 files changed, 86 insertions(+), 89 deletions(-)
diff --git a/gcc/testsuite/ChangeLog.openacc b/gcc/testsuite/ChangeLog.openacc
index 41913f7fa02..2479367dce4 100644
--- a/gcc/testsuite/ChangeLog.openacc
+++ b/gcc/testsuite/ChangeLog.openacc
@@ -1,3 +1,9 @@
+2019-01-31 Thomas Schwinge
+
+ * lib/target-supports.exp
+ (check_effective_target_opt_levels_2_plus)
+ (check_effective_target_opt_levels_size): New.
+
2019-01-31 Julian Brown
* c-c++-common/goacc/deep-copy-arrayofstruct.c: New test.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index cfc22a22975..206bb2a2b11 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9326,3 +9326,13 @@ proc check_effective_target_cet { } {
}
} "-O2" ]
}
+
+# Return 1 if we have optimization level -O2 or higher.
+proc check_effective_target_opt_levels_2_plus { } {
+return [check-flags [list "" { *-*-* } { "-O*" } { "-O0" "-Og" "-O" "-O1" }]];
+}
+
+# Return 1 if w
Re: [PATCH 1/4] [og8] Allow NULL for update directives in OpenACC 2.6
Hi Kwok!
On Wed, 30 Jan 2019 22:18:43 +, Kwok Cheung Yeung
wrote:
> A non-present passed-by-reference Fortran optional argument is
> represented by a null pointer. When passed to an update directive, it
> should be ignored as variable mappings are not created for null
> pointers. This should be safe as it is not possible to change a
> non-present argument into a present one (or vice-versa) in Fortran.
>
> libgomp/
> * oacc-mem.c (update_dev_host): Return early if the host address
> is NULL.
>
> Reviewed-by: Julian Brown
> Reviewed-by: Thomas Schwinge
As I'd mentioned a few weeks ago internally, this change:
> --- a/libgomp/oacc-mem.c
> +++ b/libgomp/oacc-mem.c
> @@ -819,6 +819,12 @@ update_dev_host (int is_dev, void *h, size_t s, int
> async)
> if (acc_dev->capabilities & GOMP_OFFLOAD_CAP_SHARED_MEM)
> return;
>
> + /* Fortran optional arguments that are non-present result in a
> + null host address here. This can safely be ignored as it is
> + not possible to 'update' a non-present optional argument. */
> + if (h == NULL)
> +return;
... doesn't just affect the Fortran "update" directive but also the C/C++
one, and the "acc_update_device", "acc_update_self" runtime library
functions, and thus invalidates the C/C++
"libgomp.oacc-c-c++-common/lib-43.c", and
"libgomp.oacc-c-c++-common/lib-47.c" test cases, so these will have to be
adjusted (that is, removed). I pushed the attached to
openacc-gcc-8-branch in commit 745d3a19c63ec9c1de3f44e0dd5ee3ff126e2828
"Remove libgomp.oacc-c-c++-common/lib-43.c,
libgomp.oacc-c-c++-common/lib-47.c".
For avoidance of doubt: I'm not objecting to your code change. On
contrary, I do have an issue open to verify whether a host-NULL should
actually be accepted in even more places, as a no-op. But we'll have to
review/adjust/test all the code, not just "update_dev_host". (That's for
later, of course.)
A (very) quick check with the PGI compiler shows that they're also
handling such NULL pointers as no-ops.
Grüße
Thomas
>From 745d3a19c63ec9c1de3f44e0dd5ee3ff126e2828 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 31 Jan 2019 18:08:09 +0100
Subject: [PATCH] Remove libgomp.oacc-c-c++-common/lib-43.c,
libgomp.oacc-c-c++-common/lib-47.c
They're invalid after commit 550afd2b2b47091f43780f0fbf5ead87f73d9b1e "[og8]
Allow NULL for update directives in OpenACC 2.6".
libgomp/
* testsuite/libgomp.oacc-c-c++-common/lib-43.c: Remove.
* testsuite/libgomp.oacc-c-c++-common/lib-47.c: Likewise.
---
libgomp/ChangeLog.openacc | 3 ++
.../libgomp.oacc-c-c++-common/lib-43.c| 51 ---
.../libgomp.oacc-c-c++-common/lib-47.c| 49 --
3 files changed, 3 insertions(+), 100 deletions(-)
delete mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c
delete mode 100644 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c
diff --git a/libgomp/ChangeLog.openacc b/libgomp/ChangeLog.openacc
index d558f0df97b..edb7d3f76eb 100644
--- a/libgomp/ChangeLog.openacc
+++ b/libgomp/ChangeLog.openacc
@@ -1,5 +1,8 @@
2019-01-31 Thomas Schwinge
+ * testsuite/libgomp.oacc-c-c++-common/lib-43.c: Remove.
+ * testsuite/libgomp.oacc-c-c++-common/lib-47.c: Likewise.
+
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-1.c:
Update.
* testsuite/libgomp.oacc-c-c++-common/avoid-offloading-2.c:
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c
deleted file mode 100644
index 5db29124e9e..000
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c
+++ /dev/null
@@ -1,51 +0,0 @@
-/* Exercise acc_update_device with a NULL data address on nvidia targets. */
-
-/* { dg-do run { target openacc_nvidia_accel_selected } } */
-
-#include
-#include
-#include
-
-int
-main (int argc, char **argv)
-{
- const int N = 256;
- int i;
- unsigned char *h;
- void *d;
-
- h = (unsigned char *) malloc (N);
-
- for (i = 0; i < N; i++)
-{
- h[i] = i;
-}
-
- d = acc_copyin (h, N);
- if (!d)
-abort ();
-
- for (i = 0; i < N; i++)
-{
- h[i] = 0xab;
-}
-
- fprintf (stderr, "CheCKpOInT\n");
- acc_update_device (0, N);
-
- acc_copyout (h, N);
-
- for (i = 0; i < N; i++)
-{
- if (h[i] != 0xab)
- abort ();
-}
-
- free (h);
-
- return 0;
-}
-
-/* { dg-output "CheCKpOInT(\n|\r\n|\r).*" } */
-/* { dg-output "\\\[\[^\n\r]*,256\\\] is not mapped" } */
-/* { dg-shouldfail "" } */
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c
deleted file mode 100644
index c2140429cb1..000
--- a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/* Exercise acc_update_self with a NULL data mapping on nvidia targets. */
-
-/* { dg-do run { target openacc_nvidia_accel_selected } } */
-
-#include
-#include
-#include
-#include
-
-int
-main (int argc, c
Re: [PATCH] Fix bogus fix-it for FLT_MAX (PR c/89122)
On 1/31/19 7:13 AM, David Malcolm wrote:
On Thu, 2019-01-31 at 10:35 +0100, Richard Biener wrote:
On Thu, Jan 31, 2019 at 12:09 AM David Malcolm
wrote:
PR c/89122 reports that we emit a bogus fix-it hint for the case
where
the code uses FLT_MAX, but has included rather than
:
x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function); did
you
mean 'INT_MAX'?
3 | float f = FLT_MAX;
| ^~~
| INT_MAX
This patch adds some knowledge of (and ) to
known-headers.cc, fixing the issue:
x.c:3:11: error: 'FLT_MAX' undeclared here (not in a function)
3 | float f = FLT_MAX;
| ^~~
x.c:2:1: note: 'FLT_MAX' is defined in header ''; did you
forget
to '#include '?
1 | #include
+++ |+#include
2 |
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Is this OK for trunk in stage 4? (presumably very low risk)
What does it not say for
int i = FLT_MAX;
? Hopefully it doesn't suggest to include float.h but suggests
to include limits.h and INT_MAX?
The suggestions code (lookup_name_fuzzy) doesn't take types into
account, and has no knowledge of the "int-ness" of i. It's purely
looking for matches for names that it didn't recognize (albeit with an
enum to hint at whether it's looking for a type vs a function-like
thing vs "anything", but that wouldn't help here).
Trunk emits:
y.c:1:9: error: 'FLT_MAX' undeclared here (not in a function)
1 | int i = FLT_MAX;
| ^~~
With the patch it does indeed tell the user where FLT_MAX is:
y.c:1:9: error: 'FLT_MAX' undeclared here (not in a function)
1 | int i = FLT_MAX;
| ^~~
y.c:1:1: note: 'FLT_MAX' is defined in header ''; did you
forget to '#include '?
+++ |+#include
1 | int i = FLT_MAX;
This doesn't seem too bad to me (in that it's screaming "float" to the
user); if the user ignores that and blindly follows the suggestion,
they get:
y.c:2:9: warning: overflow in conversion from 'float' to 'int' changes
value from '3.40282347e+38f' to '2147483647' [-Woverflow]
2 | int i = FLT_MAX;
| ^~~
y.c:2:1: warning: overflow in constant expression [-Woverflow]
2 | int i = FLT_MAX;
| ^~~
It's not clear to me that we would want a fix-it hint for this case
(where the compiler knows about FLT_MAX) - maybe the user meant to
write that? Such a fix-it hint might look something like:
y.c:2:9: warning: overflow in conversion from 'float' to 'int' changes
value from '3.40282347e+38f' to '2147483647'; did you mean 'INT_MAX' [-
Woverflow]
2 | int i = FLT_MAX;
| ^~~
| INT_MAX
...or somesuch, but that's clearly too ambitious a patch for stage 4.
Would that be reasonable for the next stage 1?
FWIW, I agree that your patch is an improvement (thank you!) I tend
to forget that FLT_MAX is not defined in and I'm pretty
sure others do too, so these hints are helpful. Especially for some
of the less commonly used symbols like the INT_LEASTN_MIN kind (in
) vs INT_MIN (in ) et al.
Just as food for thought for now, in C++, to avoid errors due to
-Wnarrowing, I think the hints will ultimately need to consider
types at least in some cases. E.g., in
int dmax { D_MAX };
when D_MAX is not defined, if it were to be replaced by DBL_MAX as
the hint suggests, the declaration would fail to compile.
Martin
In the meantime, is the original patch OK?
Thanks
Dave
gcc/c-family/ChangeLog:
PR c/89122
* known-headers.cc (get_stdlib_header_for_name): Add
{FLT|DBL|LDBL}_{MAX|MIN} to "hints" array.
gcc/testsuite/ChangeLog:
PR c/89122
* g++.dg/spellcheck-stdlib.C (test_FLT_MAX): New test.
* gcc.dg/spellcheck-stdlib.c (test_FLT_MAX): New test.
---
gcc/c-family/known-headers.cc| 8
gcc/testsuite/g++.dg/spellcheck-stdlib.C | 5 +
gcc/testsuite/gcc.dg/spellcheck-stdlib.c | 5 +
3 files changed, 18 insertions(+)
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-
headers.cc
index e3dcf73..c222f30 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -84,6 +84,14 @@ get_stdlib_header_for_name (const char *name,
enum stdlib lib)
{"ULONG_MAX", {"", ""} },
{"USHRT_MAX", {"", ""} },
+/* and . */
+{"DBL_MAX", {"", ""} },
+{"DBL_MIN", {"", ""} },
+{"FLT_MAX", {"", ""} },
+{"FLT_MIN", {"", ""} },
+{"LDBL_MAX", {"", ""} },
+{"LDBL_MIN", {"", ""} },
+
/* and . */
{"va_list", {"", ""} },
diff --git a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
index 11a4e3e..31e91fe 100644
--- a/gcc/testsuite/g++.dg/spellcheck-stdlib.C
+++ b/gcc/testsuite/g++.dg/spellcheck-stdlib.C
@@ -77,6 +77,11 @@ int test_INT_MAX (void)
// { dg-message "'INT_MAX' is defined in header ''; did
you forget to '#include '?" "" { target *-*-* }
INT_MAX_line }
}
+/* Missing . */
+float te
Re: [PATCH 4/4] [og8] Add tests for Fortran optional arguments in OpenACC 2.6
Hi Kwok!
On Wed, 30 Jan 2019 22:24:48 +, Kwok Cheung Yeung
wrote:
> diff --git
> a/libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
> b/libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
> new file mode 100644
I'm seeing this one fail at run time: "libgomp: use_device_ptr pointer
wasn't mapped". Is this expected (and should thus be XFAILed), or
unexpected?
Grüße
Thomas
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
> @@ -0,0 +1,37 @@
> +! Test the host_data construct with optional arguments.
> +! Based on host_data-1.f90.
> +
> +! { dg-do run }
> +! { dg-additional-options "-cpp" }
> +
> +program test
> + implicit none
> +
> + integer, target :: i
> + integer, pointer :: ip, iph
> +
> + ! Assign the same targets
> + ip => i
> + iph => i
> +
> + call foo(iph)
> + call foo(iph, ip)
> +contains
> + subroutine foo(iph, ip)
> +integer, pointer :: iph
> +integer, pointer, optional :: ip
> +
> +!$acc data copyin(i)
> +!$acc host_data use_device(ip)
> +
> +! Test how the pointers compare inside a host_data construct
> +#if ACC_MEM_SHARED
> +if (present(ip) .and. .not. associated(ip, iph)) STOP 1
> +#else
> +if (present(ip) .and. associated(ip, iph)) STOP 2
> +#endif
> +
> +!$acc end host_data
> +!$acc end data
> + end subroutine foo
> +end program test
Re: [PATCH] Fix bogus fix-it for FLT_MAX (PR c/89122)
On Thu, Jan 31, 2019 at 09:13:24AM -0500, David Malcolm wrote: > In the meantime, is the original patch OK? Yes, thanks. Jakub
[PATCH] [og8] Ensure that optional-arguments check is specific to Fortran
Hi,
This adds an extra check in omp_is_optional_argument to confirm that
Fortran is being used, to guard against it accidently matching against
some other case in another language.
This will be committed to openacc-gcc-8-branch shortly.
Kwok
gcc/
* omp-general.c (omp_is_optional_argument): Add comment. Add extra
check for Fortran language.
Reviewed-by: Julian Brown
---
gcc/ChangeLog.openacc | 5 +
gcc/omp-general.c | 7 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index 783ba6c..5104eaa 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,3 +1,8 @@
+2019-01-31 Kwok Cheung Yeung
+
+ * omp-general.c (omp_is_optional_argument): Add comment. Add extra
+ check for Fortran language.
+
2019-01-31 Julian Brown
* gimplify.c (gimplify_scan_omp_clauses): Handle array sections on
diff --git a/gcc/omp-general.c b/gcc/omp-general.c
index dd37c46..8e37cfc 100644
--- a/gcc/omp-general.c
+++ b/gcc/omp-general.c
@@ -51,7 +51,12 @@ omp_find_clause (tree clauses, enum omp_clause_code kind)
bool
omp_is_optional_argument (tree decl)
{
- return TREE_CODE (decl) == PARM_DECL && DECL_BY_REFERENCE (decl)
+ /* A passed-by-reference Fortran optional argument is similar to
+ a normal argument, but since it can be null the type is a
+ POINTER_TYPE rather than a REFERENCE_TYPE. */
+ return lang_GNU_Fortran ()
+&& TREE_CODE (decl) == PARM_DECL
+&& DECL_BY_REFERENCE (decl)
&& TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE;
}
--
2.8.1
Re: [PATCH 4/4] [og8] Add tests for Fortran optional arguments in OpenACC 2.6
The use_device_ptr patch (which needed reviewing) is needed for that
test. I bundled all the new tests into one commit, but forgot to exclude
that particular test. I will post and push that patch a little later.
Kwok
On 31/01/2019 5:20 pm, Thomas Schwinge wrote:
Hi Kwok!
On Wed, 30 Jan 2019 22:24:48 +, Kwok Cheung Yeung
wrote:
diff --git
a/libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
b/libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
new file mode 100644
I'm seeing this one fail at run time: "libgomp: use_device_ptr pointer
wasn't mapped". Is this expected (and should thus be XFAILed), or
unexpected?
Grüße
Thomas
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/optional-host_data.f90
@@ -0,0 +1,37 @@
+! Test the host_data construct with optional arguments.
+! Based on host_data-1.f90.
+
+! { dg-do run }
+! { dg-additional-options "-cpp" }
+
+program test
+ implicit none
+
+ integer, target :: i
+ integer, pointer :: ip, iph
+
+ ! Assign the same targets
+ ip => i
+ iph => i
+
+ call foo(iph)
+ call foo(iph, ip)
+contains
+ subroutine foo(iph, ip)
+integer, pointer :: iph
+integer, pointer, optional :: ip
+
+!$acc data copyin(i)
+!$acc host_data use_device(ip)
+
+! Test how the pointers compare inside a host_data construct
+#if ACC_MEM_SHARED
+if (present(ip) .and. .not. associated(ip, iph)) STOP 1
+#else
+if (present(ip) .and. associated(ip, iph)) STOP 2
+#endif
+
+!$acc end host_data
+!$acc end data
+ end subroutine foo
+end program test
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On Thu, Jan 31, 2019 at 10:17:54AM -0500, Jason Merrill wrote:
> On 1/31/19 9:50 AM, Marek Polacek wrote:
> > On Wed, Jan 30, 2019 at 05:37:13PM -0500, Jason Merrill wrote:
> > > On 1/30/19 4:15 PM, Marek Polacek wrote:
> > > > On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
> > > > > On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> > > > > > On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek
> > > > > > wrote:
> > > > > > >
> > > > > > > My recent patch for 88815 and 78244 caused 89083, a P1 9
> > > > > > > regression, which
> > > > > > > happens to be the same problem as 80864 and its many dupes,
> > > > > > > something I'd
> > > > > > > been meaning to fix for a long time.
> > > > > > >
> > > > > > > Basically, the problem is repeated reshaping of a constructor,
> > > > > > > once when
> > > > > > > parsing, and then again when substituting. With the recent fix,
> > > > > > > we call
> > > > > > > reshape_init + digest_init in finish_compound_literal even in a
> > > > > > > template
> > > > > > > if the expression is not instantiation-dependent, and then again
> > > > > > > when
> > > > > > > tsubst_*.
> > > > > > >
> > > > > > > For instance, in initlist107.C, when parsing a functional cast,
> > > > > > > we call
> > > > > > > finish_compound_literal which calls reshape_init, which turns
> > > > > > >
> > > > > > > { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
> > > > > > >
> > > > > > > into
> > > > > > >
> > > > > > > { { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
> > > > > > >
> > > > > > > and then digest_init turns that into
> > > > > > >
> > > > > > > { .x = { 1, 2 } }
> > > > > > >
> > > > > > > which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the
> > > > > > > subexpression
> > > > > > > "{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so
> > > > > > > it's not
> > > > > > > BRACE_ENCLOSED_INITIALIZER_P.
> > > > > > >
> > > > > > > And then tsubst_* processes "{ .x = { 1, 2 } }". The case
> > > > > > > CONSTRUCTOR
> > > > > > > in tsubst_copy_and_build will call finish_compound_literal on a
> > > > > > > copy of
> > > > > > > "{ 1, 2 }" wrapped in a new { }, because the whole expr has
> > > > > > > TREE_HAS_CONSTRUCTOR.
> > > > > > > That crashes in reshape_init_r in the
> > > > > > >6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
> > > > > > > block; we have a constructor, it's not COMPOUND_LITERAL_P, and
> > > > > > > because
> > > > > > > digest_init had given it the type int[3], we hit
> > > > > > >6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P
> > > > > > > (stripped_init));
> > > > > > >
> > > > > > > As expand_default_init explains in a comment, a CONSTRUCTOR of
> > > > > > > the target's type
> > > > > > > is a previously digested initializer, so we should probably do a
> > > > > > > similar trick
> > > > > > > here. This fixes all the variants of the problem I've come up
> > > > > > > with.
> > > > > > >
> > > > > > > 80864 is a similar case, we reshape when parsing and then second
> > > > > > > time in
> > > > > > > fold_non_dependent_expr called from store_init_value, because of
> > > > > > > the 'constexpr'.
> > > > > > >
> > > > > > > Also update a stale comment.
> > > > > > >
> > > > > > > Bootstrapped/regtest running on x86_64-linux, ok for trunk and 8
> > > > > > > after a while?
> > > > > > >
> > > > > > > 2019-01-29 Marek Polacek
> > > > > > >
> > > > > > > PR c++/89083, c++/80864 - ICE with list initialization
> > > > > > > in template.
> > > > > > > * decl.c (reshape_init_r): Don't reshape a digested
> > > > > > > initializer.
> > > > > > >
> > > > > > > * g++.dg/cpp0x/initlist107.C: New test.
> > > > > > > * g++.dg/cpp0x/initlist108.C: New test.
> > > > > > > * g++.dg/cpp0x/initlist109.C: New test.
> > > > > > >
> > > > > > > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > > > > > > index 79eeac177b6..da08ecc21aa 100644
> > > > > > > --- gcc/cp/decl.c
> > > > > > > +++ gcc/cp/decl.c
> > > > > > > @@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter
> > > > > > > *d, bool first_initializer_p,
> > > > > > > ;
> > > > > > > else if (COMPOUND_LITERAL_P (stripped_init))
> > > > > > > /* For a nested compound literal, there is no need to
> > > > > > > reshape since
> > > > > > > -brace elision is not allowed. Even if we decided to
> > > > > > > allow it,
> > > > > > > -we should add a call to reshape_init in
> > > > > > > finish_compound_literal,
> > > > > > > -before calling digest_init, so changing this code
> > > > > > > would still
> > > > > > > -not be necessary. */
> > > > > > > +we called reshape_init in finish_compound_literal,
> > > > > > > before calling
> > > > > > > +digest_init. */
> > > > > > > gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P
> > > > > >
Re: Provide __start_minfo/__stop_minfo for linkers that don't (PR d/87864)
Looks good to me, although ultimately Iain has to decide of course.
One nitpick: wouldn't you have to somehow mark __start/__stop _minfo as
hidden? This is important in the case where you have multiple shared
libraries and each library should have its own __start/__stop symbold to
braket the library's minfo section.
Also 'if !DRUNTIME_OS_MINFO_BRACKETING' might be the wrong
condition/name in Makefile.am if we add back support for per-module
constructor-based module registration (instead of calling
_d_dso_registry once per shared library passing all ModuleInfos in that
library, call another hook _d_register_module once per module and pass
only one ModuleInfo). But we can fix that if we ever need to add back
support for that second approach. (If this startfile/endfile approach is
portable enough, we may be able to avoid that).
Best regards,
Johannes
Am 29.01.19 um 13:24 schrieb Rainer Orth:
Solaris ld only gained support for section bracketing in Solaris 11.4.
Fortunately, in gdc it is only used for the minfo section, so it's easy
to provide a workaround by adding two additional startup files
drt{begin,end}.o which define __start_minfo and __stop_minfo.
This patch does just that.
I've raised a couple of questions in the PR already:
* I've introduced a new -dstartfiles option which triggers the use of
libgphobos.spec even with -nophoboslib. Since it's effectively
internal to the build system, I'm not currently documenting it.
* I'm reading the spec file addition from a file: keeping it in a make
variable would be extremely messy due to the necessary quoting.
* I've chosen to use -Wc instead of -Xcompiler throughout: it's way
shorter when more options need to be passed and it can take several
comma-separated options at once.
* libdruntime/gcc/drtstuff.c needs a copyright notice unless one wants
to keep it in the public domain (also plausible). Effectively
something for Iain to decide.
Bootstrapped without regressions on i386-pc-solaris2.11 (Solaris 11.3),
no regressions compared to Solaris 11.4 test results.
Rainer
[PATCH] Fix ARM --enable-checking=release bootstrap (PR bootstrap/88714)
Hi!
As mentioned in the PR, armv7hl-linux-gnueabi doesn't currently bootstrap
with --enable-checking=release (and profiledbootstrap is broken too),
the problem is that e.g. tree-ssa-sccvn.c is miscompiled.
The problem is that the various ldrdstrd.md peephole2s generate for
non-thumb{1,2} DImode loads and stores, but just use whatever alias set
and MEM_EXPR and other MEM attributes the first of the two MEMs had.
That is wrong e.g. for alias oracle and during the tree-ssa-sccvn.c
compilation sched2 because of that reorders ldrd with another store that
must not be reordered.
One possibility is to force alias set of 0 and clear MEM_EXPR, but that
pessimizes code too much (there is a patch in the PR that I've
bootstrapped/regtested and we are using temporarily in Fedora).
The following patch instead creates new patterns that keep referencing the
two original MEMs, so no unification of alias sets or MEM_EXPRs is needed.
Bootstrapped/regtested on armv7hl-linux-gnueabi (c,c++ only), distro build
(all languages) still ongoing (25 hours and hasn't even finished bootstrap),
ok for trunk?
In the PR, Matthew Malcomson suggested some changes, I'm fine e.g. with
adding && arm_legitimate_address_p (DImode, XEXP (operands[?], 0), true)
to the conditions (or add some helper function that calls this and checks
other stuff), but I really don't have access to hw where I can reasonably
test this. There is also a question whether ldm2_* or ldrd are preferrable,
etc. If ldrd is faster, then e.g. ldrdstrd.md is missing a peephole2 that
would handle reg1 = const1; reg2 = const2; mem1 = reg1; mem2 = reg2;,
it only handles reg1 = const1; mem1 = reg1; reg2 = const2; mem2 = reg2;
but sched1 in many cases reorders that.
Or if somebody wants to take the patch over from here, fine with me too.
As I wrote in the PR, I see also some cleanup possibilities for GCC10 in the
ARM backend, something that has been done a few years ago in x86 and
recently e.g. also in rs6000, removals of "" constraints from match_operand,
use of REG_P/MEM_P etc. macros, formatting fixes.
2019-01-31 Jakub Jelinek
PR bootstrap/88714
* config/arm/arm.c (gen_operands_ldrd_strd): If successful, for
TARGET_ARM adjust operands[3] to be always PLUS of operands[2]
and 4. Formatting fixes.
* config/arm/ldrdstrd.md: Handle TARGET_ARM like TARGET_THUMB2
in all peephole2s, use peephole2 patterns where possible instead
of generating code by hand + DONE. Formatting fixes.
* config/arm/arm.md (*arm_ldrd, *arm_strd): New define_insns.
(*thumb2_ldrd, *thumb2_ldrd_base, *thumb2_ldrd_base_neg, *thumb2_strd,
*thumb2_strd_base, *thumb2_strd_base_neg): Formatting fixes.
* config/arm/vfd.md (*ldrd_vfp, *strd_vfp): New define_insns.
* config/arm/iwmmxt.md (*iwmmxt_arm_ldrd, *iwmmxt_arm_strd): Likewise.
* gcc.c-torture/execute/pr88714.c: New test.
--- gcc/config/arm/arm.c.jj 2019-01-22 23:26:46.815210588 +0100
+++ gcc/config/arm/arm.c2019-01-30 11:31:58.626214346 +0100
@@ -15748,7 +15748,7 @@ gen_operands_ldrd_strd (rtx *operands, b
/* Make sure we generate legal instructions. */
if (operands_ok_ldrd_strd (operands[0], operands[1], base, offset,
false, load))
-return true;
+goto ok;
/* In Thumb state, where registers are almost unconstrained, there
is little hope to fix it. */
@@ -15761,7 +15761,7 @@ gen_operands_ldrd_strd (rtx *operands, b
std::swap (operands[0], operands[1]);
if (operands_ok_ldrd_strd (operands[0], operands[1], base, offset,
false, load))
-return true;
+goto ok;
}
if (const_store)
@@ -15785,10 +15785,10 @@ gen_operands_ldrd_strd (rtx *operands, b
strd r0, [r2]
*/
if (operands_ok_ldrd_strd (operands[1], operands[0], base, offset,
- false, false))
+false, false))
{
std::swap (operands[0], operands[1]);
- return true;
+ goto ok;
}
/* Try to find a free DI register. */
@@ -15810,13 +15810,22 @@ gen_operands_ldrd_strd (rtx *operands, b
gcc_assert (REGNO (operands[0]) % 2 == 0);
gcc_assert (REGNO (operands[0]) + 1 == REGNO (operands[1]));
- return (operands_ok_ldrd_strd (operands[0], operands[1],
- base, offset,
- false, load));
+ if (operands_ok_ldrd_strd (operands[0], operands[1],
+base, offset, false, load))
+ goto ok;
}
}
return false;
+
+ ok:
+ if (TARGET_ARM)
+{
+ rtx a = gen_rtx_PLUS (SImode, copy_rtx (XEXP (operands[nops], 0)),
+ GEN_INT (4));
+ operands[nops + 1] = replace_equiv_address_nv (operands[nops + 1], a);
+}
+ return true;
}
[PATCH] [og8] Allow optional arguments to be used in the use_device OpenACC clause
This patch allows for the use of Fortran optional arguments in the
use_device clause of a host_data directive.
I will push this into openacc-gcc-8-branch later today.
Kwok
Optional arguments should be treated as references rather than pointers
in the lowering. However, for non-present arguments, this would result
in a null dereference, so conditionals need to be added to detect and
handle this.
gcc/
* omp-low.c (lower_omp_target): For use_device clauses, generate
conditional statements to treat Fortran optional arguments like
references if non-null, or propogate null arguments into offloaded
code otherwise.
Reviewed-by: Julian Brown
---
gcc/ChangeLog.openacc | 7 +
gcc/omp-low.c | 77
---
2 files changed, 80 insertions(+), 4 deletions(-)
diff --git a/gcc/ChangeLog.openacc b/gcc/ChangeLog.openacc
index 5104eaa..58258fd 100644
--- a/gcc/ChangeLog.openacc
+++ b/gcc/ChangeLog.openacc
@@ -1,5 +1,12 @@
2019-01-31 Kwok Cheung Yeung
+ * omp-low.c (lower_omp_target): For use_device clauses, generate
+ conditional statements to treat Fortran optional arguments like
+ references if non-null, or propogate null arguments into offloaded
+ code otherwise.
+
+2019-01-31 Kwok Cheung Yeung
+
* omp-general.c (omp_is_optional_argument): Add comment. Add extra
check for Fortran language.
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index ef71704..3ae39c3 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -8938,18 +8938,51 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
tkind = GOMP_MAP_FIRSTPRIVATE_INT;
type = TREE_TYPE (ovar);
if (TREE_CODE (type) == ARRAY_TYPE)
- var = build_fold_addr_expr (var);
+ {
+ var = build_fold_addr_expr (var);
+ gimplify_assign (x, var, &ilist);
+ }
else
{
- if (omp_is_reference (ovar))
+ tree opt_arg_label;
+ bool optional_arg_p = omp_is_optional_argument (ovar);
+
+ if (optional_arg_p)
+ {
+ tree null_label
+ = create_artificial_label (UNKNOWN_LOCATION);
+ tree notnull_label
+ = create_artificial_label (UNKNOWN_LOCATION);
+ opt_arg_label
+ = create_artificial_label (UNKNOWN_LOCATION);
+ tree new_x = copy_node (x);
+ gcond *cond = gimple_build_cond (EQ_EXPR, ovar,
+null_pointer_node,
+null_label,
+notnull_label);
+ gimple_seq_add_stmt (&ilist, cond);
+ gimple_seq_add_stmt (&ilist,
+gimple_build_label (null_label));
+ gimplify_assign (new_x, null_pointer_node, &ilist);
+ gimple_seq_add_stmt (&ilist,
+gimple_build_goto (opt_arg_label));
+ gimple_seq_add_stmt (&ilist,
+gimple_build_label (notnull_label));
+ }
+
+ if (omp_is_reference (ovar) || optional_arg_p)
{
type = TREE_TYPE (type);
if (TREE_CODE (type) != ARRAY_TYPE)
var = build_simple_mem_ref (var);
var = fold_convert (TREE_TYPE (x), var);
+ gimplify_assign (x, var, &ilist);
}
+
+ if (optional_arg_p)
+ gimple_seq_add_stmt (&ilist,
+ gimple_build_label (opt_arg_label));
}
- gimplify_assign (x, var, &ilist);
s = size_int (0);
decl_args = append_decl_arg (ovar, decl_args, ctx);
purpose = size_int (map_idx++);
@@ -9137,11 +9170,43 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
{
tree type = TREE_TYPE (var);
tree new_var = lookup_decl (var, ctx);
- if (omp_is_reference (var))
+ tree opt_arg_label = NULL_TREE;
+
+ if (omp_is_reference (var) || omp_is_optional_argument (var))
{
type = TREE_TYPE (type);
if (TREE_CODE (type) != ARRAY_TYPE)
{
+ if (omp_is_optional_argument (var))
+ {
+ tree null_label
+ = create_artificial_label (UNKNOWN_LOCATION);
+ tree notnull_label
+ = create_artificial_label (UNKNOWN_LOCATION);
+ opt_
Re: [libphobos] Work around lack of dlpi_tls_modid before Solaris 11.5
Hi Rainer, I'd recommend not using such a workaround: This means getTLSRange will always return an empty range, but the GC uses this to scan TLS memory. This means a GC collection can delete objects which are still pointed to from TLS. This leads to hard to debug errors, and if I remember correctly, the testsuite will not catch these errors. I think we have code in phobos though which references objects only from TLS and this will break after a GC collection. I just noticed we now have similar code in upstream druntime for uclibc though so I also posted a comment there: https://github.com/dlang/druntime/pull/2157 I'm not sure what's a good solution here. EmuTLS has got the same problem, but I'll post a RFC patch next weekend which would allow to scan the emuTLS memory. If we somehow make that work, I'd recommend to use emuTLS instead of native TLS if there's no way to scan the native TLS*. FYI Martin Nowak(in CC) wrote most of the original code for rt.sections so he's the expert we'd have to ask. * Maybe we could implement a more runtime-independent approach to scan native TLS? 1) We somehow need to bracket the TLS section (it would have to be per-shared-library though, we basically need thread-local, hidden __start_tls and __stop_tls symbols). 2) We need to emit a hidden _dso_scan_tls function into each D library. A pointer to this DSO specific function then has to be passed in CompilerDSOData to _d_dso_registry. 3) tlsRange has to forward to the correct, DSO specific _dso_scan_tls. 2 and 3 are easy but I'm not sure if we can do 1. Best regards, Johannes Am 29.01.19 um 11:52 schrieb Rainer Orth: Before Solaris 11.5, struct dl_phdr_info lacked the dlpi_tls_modid member. While the support might be backported to Solaris 11.4, it certainly won't to previous Solaris releases. To work around this, I've used the following patch. Again, it's pretty straightforward. Point of note: * On Solaris, FreeBSD and NetBSD, dl_phdr_info is always visible in , while on Linux one needs to define _GNU_SOURCE. AC_USE_SYSTEM_EXTENSION takes care of this, but needs to be called early (i.e. not in DRUNTIME_OS_DLPI_TLS_MODID) to avoid an autoconf warning: configure.ac:129: warning: AC_COMPILE_IFELSE was called before AC_USE_SYSTEM_EXTENSIONS m4/druntime/os.m4:190: DRUNTIME_OS_DLPI_TLS_MODID is expanded from... configure.ac:129: the top level Tested on i386-pc-solaris2.11 (Solaris 11.4) and x86_64-pc-linux-gnu. Not unexpectedly, there are a couple of regressions compared to the Solaris 11.5/x86 results: +FAIL: gdc.test/runnable/testaa.d execution test +FAIL: gdc.test/runnable/testaa.d -fPIC execution test +FAIL: gdc.test/runnable/testaa.d -fPIC -shared-libphobos execution test +FAIL: gdc.test/runnable/testaa.d -shared-libphobos execution test 32 and 64-bit +FAIL: gdc.test/runnable/xtest55.d execution test +FAIL: gdc.test/runnable/xtest55.d -shared-libphobos execution test 64-bit only +FAIL: libphobos.shared/link_linkdep.d -I/vol/gcc/src/hg/trunk/local/libphobos/t estsuite/libphobos.shared liblinkdep.so lib.so -shared-libphobos execution test +FAIL: libphobos.shared/load_linkdep.d -shared-libphobos -ldl execution test +FAIL: libphobos.shared/load_loaddep.d -shared-libphobos -ldl execution test +FAIL: libphobos.shared/linkDR.c -shared-libphobos -ldl -pthread execution test +FAIL: libphobos.shared/host.c -ldl -pthread execution test +FAIL: libphobos.shared/loadDR.c -ldl -pthread -g execution test 32 and 64-bit +FAIL: libphobos.shared/link.d -I/vol/gcc/src/hg/trunk/local/libphobos/testsuite/libphobos.shared lib.so -shared-libphobos execution test 64-bit only I haven't looked much closer yet, just posting this to see if anything along those lines could be acceptable at all. Rainer
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On Thu, Jan 31, 2019 at 12:32 PM Marek Polacek wrote:
> On Thu, Jan 31, 2019 at 10:17:54AM -0500, Jason Merrill wrote:
> > On 1/31/19 9:50 AM, Marek Polacek wrote:
> > > On Wed, Jan 30, 2019 at 05:37:13PM -0500, Jason Merrill wrote:
> > > > On 1/30/19 4:15 PM, Marek Polacek wrote:
> > > > > On Wed, Jan 30, 2019 at 04:11:11PM -0500, Marek Polacek wrote:
> > > > > > On Tue, Jan 29, 2019 at 09:40:18PM -0500, Jason Merrill wrote:
> > > > > > > On Tue, Jan 29, 2019 at 6:53 PM Marek Polacek
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > My recent patch for 88815 and 78244 caused 89083, a P1 9
> > > > > > > > regression, which
> > > > > > > > happens to be the same problem as 80864 and its many dupes,
> > > > > > > > something I'd
> > > > > > > > been meaning to fix for a long time.
> > > > > > > >
> > > > > > > > Basically, the problem is repeated reshaping of a constructor,
> > > > > > > > once when
> > > > > > > > parsing, and then again when substituting. With the recent
> > > > > > > > fix, we call
> > > > > > > > reshape_init + digest_init in finish_compound_literal even in a
> > > > > > > > template
> > > > > > > > if the expression is not instantiation-dependent, and then
> > > > > > > > again when
> > > > > > > > tsubst_*.
> > > > > > > >
> > > > > > > > For instance, in initlist107.C, when parsing a functional cast,
> > > > > > > > we call
> > > > > > > > finish_compound_literal which calls reshape_init, which turns
> > > > > > > >
> > > > > > > > { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> }
> > > > > > > >
> > > > > > > > into
> > > > > > > >
> > > > > > > > { { NON_LVALUE_EXPR<1>, NON_LVALUE_EXPR<2> } }
> > > > > > > >
> > > > > > > > and then digest_init turns that into
> > > > > > > >
> > > > > > > > { .x = { 1, 2 } }
> > > > > > > >
> > > > > > > > which is a compound literal (TREE_HAS_CONSTRUCTOR set), but the
> > > > > > > > subexpression
> > > > > > > > "{ 1, 2 }" isn't. "{ 1, 2 }" will now have the type int[3], so
> > > > > > > > it's not
> > > > > > > > BRACE_ENCLOSED_INITIALIZER_P.
> > > > > > > >
> > > > > > > > And then tsubst_* processes "{ .x = { 1, 2 } }". The case
> > > > > > > > CONSTRUCTOR
> > > > > > > > in tsubst_copy_and_build will call finish_compound_literal on a
> > > > > > > > copy of
> > > > > > > > "{ 1, 2 }" wrapped in a new { }, because the whole expr has
> > > > > > > > TREE_HAS_CONSTRUCTOR.
> > > > > > > > That crashes in reshape_init_r in the
> > > > > > > >6155 if (TREE_CODE (stripped_init) == CONSTRUCTOR)
> > > > > > > > block; we have a constructor, it's not COMPOUND_LITERAL_P, and
> > > > > > > > because
> > > > > > > > digest_init had given it the type int[3], we hit
> > > > > > > >6172 gcc_assert (BRACE_ENCLOSED_INITIALIZER_P
> > > > > > > > (stripped_init));
> > > > > > > >
> > > > > > > > As expand_default_init explains in a comment, a CONSTRUCTOR of
> > > > > > > > the target's type
> > > > > > > > is a previously digested initializer, so we should probably do
> > > > > > > > a similar trick
> > > > > > > > here. This fixes all the variants of the problem I've come up
> > > > > > > > with.
> > > > > > > >
> > > > > > > > 80864 is a similar case, we reshape when parsing and then
> > > > > > > > second time in
> > > > > > > > fold_non_dependent_expr called from store_init_value, because
> > > > > > > > of the 'constexpr'.
> > > > > > > >
> > > > > > > > Also update a stale comment.
> > > > > > > >
> > > > > > > > Bootstrapped/regtest running on x86_64-linux, ok for trunk and
> > > > > > > > 8 after a while?
> > > > > > > >
> > > > > > > > 2019-01-29 Marek Polacek
> > > > > > > >
> > > > > > > > PR c++/89083, c++/80864 - ICE with list
> > > > > > > > initialization in template.
> > > > > > > > * decl.c (reshape_init_r): Don't reshape a digested
> > > > > > > > initializer.
> > > > > > > >
> > > > > > > > * g++.dg/cpp0x/initlist107.C: New test.
> > > > > > > > * g++.dg/cpp0x/initlist108.C: New test.
> > > > > > > > * g++.dg/cpp0x/initlist109.C: New test.
> > > > > > > >
> > > > > > > > diff --git gcc/cp/decl.c gcc/cp/decl.c
> > > > > > > > index 79eeac177b6..da08ecc21aa 100644
> > > > > > > > --- gcc/cp/decl.c
> > > > > > > > +++ gcc/cp/decl.c
> > > > > > > > @@ -6161,11 +6161,17 @@ reshape_init_r (tree type, reshape_iter
> > > > > > > > *d, bool first_initializer_p,
> > > > > > > > ;
> > > > > > > > else if (COMPOUND_LITERAL_P (stripped_init))
> > > > > > > > /* For a nested compound literal, there is no need
> > > > > > > > to reshape since
> > > > > > > > -brace elision is not allowed. Even if we decided
> > > > > > > > to allow it,
> > > > > > > > -we should add a call to reshape_init in
> > > > > > > > finish_compound_literal,
> > > > > > > > -before calling digest_init, so changing this code
> > > > > > > > would still
> > > > > > > > -not be nece
[PATCH, alpha]: Use -mfp-rounding-mode=d for libgcc2 on linux
Hello! As exposed by gcc.dg/torture/fp-int-convert-timode-?.c testcases from PR88931, it is expected that libgcc2 rounds calculations according to set FP rounding mode. To achieve dynamic rounding, we have to pass -mfp-rounding-mode=d in addition to -mieee when compiling libgcc2. 2019-01-31 Uroš Bizjak * config/alpha/t-linux: Add -mfp-rounding-mode=d to HOST_LIBGCC2_CFLAGS. Patch was bootstrapped and regression tested on alphaev68-linux-gnu, where it fixes all failures with mentioned testcases. Committed to mainline SVN. Uros. Index: config/alpha/t-linux === --- config/alpha/t-linux(revision 268424) +++ config/alpha/t-linux(working copy) @@ -1 +1,4 @@ SHLIB_MAPFILES += $(srcdir)/config/alpha/libgcc-alpha-ldbl.ver + +# Use dynamic rounding mode. +HOST_LIBGCC2_CFLAGS += -mfp-rounding-mode=d
Re: C++ PATCH for c++/89083, c++/80864 - ICE with list initialization in template
On Thu, Jan 31, 2019 at 03:14:39PM -0500, Jason Merrill wrote: > OK. Thanks, committed. Note that I plan to backport the patch to 8 after a while. Marek
Re: [patch, fortran] Fix PR 88669, rejects-valid
Am 27.01.19 um 14:18 schrieb Thomas Koenig: Hello world, the attached, rather straightforward patch fixes a rejects-valid error by fixing up the contiguous attribute for a class, and by using the correct attributes. Regression-tested. OK for trunk? PING ** (4./7.)? Regards Thomas
Fix inconsistent operator delete usages
I was writing a test which needed to override the std::nothrow
versions of the operator new and delete to control get_temporary_buffer
behavior and noticed that it is inconsistent with
release_temporary_buffer in terms of new/delete operators.
Grepping for other std::nothrow usages I found some others and
especially one in libsupc++.
I don't know how serious it is considering the Standard. As long as
you stick to the libstdc++ operators it is fine. Only users overriding
those operators will notice.
Tested under Linux x86_64 normal mode with some failures but none
related to this patch I think but of course you better check on your side.
* libsupc++/atexit_thread.cc (run(void*)): Call std::nothrow delete
operator.
* include/bits/stl_tempbuf.h (return_temporary_buffer): Likewise.
* include/profile/impl/profiler_trace.h
(__trace_base<>::~__trace_base()): Likewise.
(__trace_base<>::__add_object(__stack_t)): Likewise.
(__trace_base<>::__retire_object(__stack_t)): Likewise.
Let me know if it is a go.
François
diff --git a/libstdc++-v3/include/bits/stl_tempbuf.h b/libstdc++-v3/include/bits/stl_tempbuf.h
index b6ad9ee6a46..e614a77bc4f 100644
--- a/libstdc++-v3/include/bits/stl_tempbuf.h
+++ b/libstdc++-v3/include/bits/stl_tempbuf.h
@@ -110,7 +110,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
template
inline void
return_temporary_buffer(_Tp* __p)
-{ ::operator delete(__p); }
+{ ::operator delete(__p, std::nothrow); }
/**
diff --git a/libstdc++-v3/include/profile/impl/profiler_trace.h b/libstdc++-v3/include/profile/impl/profiler_trace.h
index 261f3b3cc72..36822ef77ac 100644
--- a/libstdc++-v3/include/profile/impl/profiler_trace.h
+++ b/libstdc++-v3/include/profile/impl/profiler_trace.h
@@ -200,7 +200,7 @@ namespace __gnu_profile
{
for (typename __stack_table_t::iterator __it
= __stack_table.begin(); __it != __stack_table.end(); ++__it)
- delete __it->first;
+ ::operator delete(__it->first, std::nothrow);
}
__object_info* __add_object(__stack_t __stack);
@@ -235,14 +235,14 @@ namespace __gnu_profile
if (__max_mem() != 0 && __objects_byte_size >= __max_mem())
{
- delete __stack;
+ ::operator delete(__stack, std::nothrow);
return 0;
}
__object_info* __ret = new(std::nothrow) __object_info(__stack);
if (!__ret)
{
- delete __stack;
+ ::operator delete(__stack, std::nothrow);
return 0;
}
@@ -277,16 +277,16 @@ namespace __gnu_profile
__stack_info(__info)));
}
else
- delete __stack;
+ ::operator delete(__stack, std::nothrow);
}
else
{
// Merge object info into info summary for this call context.
__stack_it->second.__merge(__info);
- delete __stack;
+ ::operator delete(__stack, std::nothrow);
}
- delete __obj_info;
+ ::operator delete(__obj_info, std::nothrow);
__objects_byte_size -= sizeof(__object_info);
}
diff --git a/libstdc++-v3/libsupc++/atexit_thread.cc b/libstdc++-v3/libsupc++/atexit_thread.cc
index 25334250dab..d47d1654b28 100644
--- a/libstdc++-v3/libsupc++/atexit_thread.cc
+++ b/libstdc++-v3/libsupc++/atexit_thread.cc
@@ -79,7 +79,7 @@ namespace {
FreeLibrary (e->dll);
#endif
e = e->next;
- delete (old_e);
+ ::operator delete(old_e, std::nothrow);
}
}
Re: [patch, fortran] Fix PR 88669, rejects-valid
On Thu, Jan 31, 2019 at 10:23:17PM +0100, Thomas Koenig wrote: > Am 27.01.19 um 14:18 schrieb Thomas Koenig: > > Hello world, > > > > the attached, rather straightforward patch fixes a rejects-valid error > > by fixing up the contiguous attribute for a class, and by using the > > correct attributes. > > > > Regression-tested. OK for trunk? > > PING ** (4./7.)? > OK. -- Steve
Re: [PATCH] print correct array sizes in errors (PR 87996)
On 1/30/19 3:15 PM, Jason Merrill wrote:
On 1/29/19 7:15 PM, Martin Sebor wrote:
+ /* Try to convert the original SIZE to a ssizetype. */
+ if (orig_size != error_mark_node
+ && !TYPE_UNSIGNED (TREE_TYPE (orig_size)))
+ {
+ if (TREE_CODE (size) == INTEGER_CST
+ && tree_int_cst_sign_bit (size))
+ diagsize = build_converted_constant_expr (ssizetype, size,
+ tsubst_flags_t ());
+ else if (size == error_mark_node
+ && TREE_CODE (orig_size) == INTEGER_CST
+ && tree_int_cst_sign_bit (orig_size))
+ diagsize = build_converted_constant_expr (ssizetype, orig_size,
+ tsubst_flags_t ());
+ }
Using build_converted_constant_expr here looks odd; that's a
language-level notion, and we're dealing with compiler internals.
fold_convert seems more appropriate.
Done.
+ if (TREE_CONSTANT (size))
+ {
+ if (!diagsize && TREE_CODE (size) == INTEGER_CST)
+ diagsize = size;
+ }
+ else
size = osize;
}
@@ -9732,15 +9758,12 @@ compute_array_index_type_loc (location_t
name_loc,
if (TREE_CODE (size) == INTEGER_CST)
{
/* An array must have a positive number of elements. */
- if (!valid_constant_size_p (size))
+ if (!diagsize)
+ diagsize = size;
It seems like the earlier hunk here is unnecessary; if size is an
INTEGER_CST, it will be unchanged, and so be used for diagsize in the
latter hunk without any changes to the earlier location. Actually, why
not do all of the diagsize logic down here? There doesn't seem to be
anything above that relies on information we will have lost at this point.
Sure. Done in the attached revision.
Martin
PR c++/87996 - [8/9 Regression] size of array is negative error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
gcc/ChangeLog:
PR c++/87996
* builtins.c (max_object_size): Move from here...
* builtins.h (max_object_size): ...and here...
* tree.c (max_object_size): ...to here...
* tree.h (max_object_size): ...and here.
gcc/c-family/ChangeLog:
PR c++/87996
* c-common.c (invalid_array_size_error): New function.
(valid_array_size_p): Call it. Handle size as well as type.
* c-common.h (valid_constant_size_p): New function.
(enum cst_size_error): New type.
gcc/cp/ChangeLog:
PR c++/87996
* decl.c (compute_array_index_type_loc): Preserve signed sizes
for diagnostics. Call valid_array_size_p instead of error.
* init.c (build_new_1): Compute size for diagnostic. Call
invalid_array_size_error
(build_new): Call valid_array_size_p instead of error.
gcc/testsuite/ChangeLog:
PR c++/87996
* c-c++-common/array-5.c: New test.
* c-c++-common/pr68107.c: Adjust text of diagnostics.
* g++.dg/init/new38.C: Same.
* g++.dg/init/new43.C: Same.
* g++.dg/init/new44.C: Same.
* g++.dg/init/new46.C: Same.
* g++.dg/other/large-size-array.C: Same.
* g++.dg/other/new-size-type.C: Same.
* g++.dg/template/array30.C: Same.
* g++.dg/template/array32.C: New test.
* g++.dg/template/dependent-name3.C: Adjust.
* gcc.dg/large-size-array-3.c: Same.
* gcc.dg/large-size-array-5.c: Same.
* gcc.dg/large-size-array.c: Same.
* g++.old-deja/g++.brendan/array1.C: Same.
* g++.old-deja/g++.mike/p6149.C: Same.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 268430)
+++ gcc/builtins.c (working copy)
@@ -11210,12 +11210,3 @@ target_char_cst_p (tree t, char *p)
*p = (char)tree_to_uhwi (t);
return true;
}
-
-/* Return the maximum object size. */
-
-tree
-max_object_size (void)
-{
- /* To do: Make this a configurable parameter. */
- return TYPE_MAX_VALUE (ptrdiff_type_node);
-}
Index: gcc/builtins.h
===
--- gcc/builtins.h (revision 268430)
+++ gcc/builtins.h (working copy)
@@ -150,6 +150,5 @@ extern internal_fn replacement_internal_fn (gcall
extern void warn_string_no_nul (location_t, const char *, tree, tree);
extern tree unterminated_array (tree, tree * = NULL, bool * = NULL);
-extern tree max_object_size ();
#endif /* GCC_BUILTINS_H */
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 268430)
+++ gcc/c-family/c-common.c (working copy)
@@ -8231,29 +8231,82 @@ reject_gcc_builtin (const_tree expr, location_t lo
return false;
}
+/* Issue an ERROR for an invalid SIZE of array NAME which is null
+ for unnamed arrays. */
+
+void
+invalid_array_size_error (location_t loc, cst_size_error error,
+ const_tree size, const_tree name)
+{
+ tree maxsize = max_object_size ();
+ switch (error)
+{
+case cst_size_negative:
+ if (name)
+ error_at (loc, "size %qE of array %qE is negative",
+ size, name);
+ else
+ error_at (loc, "size %qE of array is negative",
+ size);
+ break;
+case cst_size_too_b
[C++ PATCH] Reject invalid GNU attribute syntax (PR c++/87175)
Hi!
THe following patch rejects invalid __attribute__ syntax where one or both
opening parens are missing, but it is accepted anyway.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-01-31 Jakub Jelinek
PR c++/87175
* parser.c (cp_parser_gnu_attributes_opt): Set ok to false
if require_open failed.
* g++.dg/ext/attrib57.C: New test.
--- gcc/cp/parser.c.jj 2019-01-28 23:29:40.719949614 +0100
+++ gcc/cp/parser.c 2019-01-31 10:16:22.653631278 +0100
@@ -25768,9 +25768,11 @@ cp_parser_gnu_attributes_opt (cp_parser*
cp_lexer_consume_token (parser->lexer);
/* Look for the two `(' tokens. */
matching_parens outer_parens;
- outer_parens.require_open (parser);
+ if (!outer_parens.require_open (parser))
+ ok = false;
matching_parens inner_parens;
- inner_parens.require_open (parser);
+ if (!inner_parens.require_open (parser))
+ ok = false;
/* Peek at the next token. */
token = cp_lexer_peek_token (parser->lexer);
--- gcc/testsuite/g++.dg/ext/attrib57.C.jj 2019-01-31 10:24:25.353702392
+0100
+++ gcc/testsuite/g++.dg/ext/attrib57.C 2019-01-31 10:23:57.007170898 +0100
@@ -0,0 +1,6 @@
+// PR c++/87175
+// { dg-do compile }
+// { dg-options "" }
+
+struct __attribute__)) foo { };// { dg-error "expected" }
+struct __attribute__()) bar { };// { dg-error "expected" }
Jakub
[PATCH] Don't ICE on parloops with multiple EH regions without common parent (PR tree-optimization/88107)
Hi!
While OpenMP parsing ensures the parallel, task, taskloop, target, teams
etc. body are wrapped in ERT_MUST_NOT_THROW EH regions, for parloops we can
actually end up with multiple different EH regions. If they still have some
common outer region, perhaps covering much bigger part of code than the
region itself, we still handle it by duplicating perhaps more of EH tree
than strictly necessary (but it isn't that easy to determine what are all
the roots we want to copy), if there isn't a common outer region, we ICE.
The following patch just extends what we are actually doing to copying the
whole EH tree of the function in that case, eh cleanups can remove
unreachable regions later on.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-01-31 Jakub Jelinek
PR tree-optimization/88107
* tree-cfg.c (find_outermost_region_in_block): Add ALL argument,
instead of assertion that eh_region_outermost is non-NULL, if it
is NULL, set *ALL to true and return NULL.
(move_sese_region_to_fn): Adjust caller, if all is set, call
duplicate_eh_regions with NULL region.
* gcc.dg/gomp/pr88107.c: New test.
--- gcc/tree-cfg.c.jj 2019-01-28 11:33:14.704888408 +0100
+++ gcc/tree-cfg.c 2019-01-31 17:17:58.357007322 +0100
@@ -7143,11 +7143,14 @@ move_block_to_fn (struct function *dest_
}
/* Examine the statements in BB (which is in SRC_CFUN); find and return
- the outermost EH region. Use REGION as the incoming base EH region. */
+ the outermost EH region. Use REGION as the incoming base EH region.
+ If there is no single outermost region, return NULL and set *ALL to
+ true. */
static eh_region
find_outermost_region_in_block (struct function *src_cfun,
- basic_block bb, eh_region region)
+ basic_block bb, eh_region region,
+ bool *all)
{
gimple_stmt_iterator si;
@@ -7166,7 +7169,11 @@ find_outermost_region_in_block (struct f
else if (stmt_region != region)
{
region = eh_region_outermost (src_cfun, stmt_region, region);
- gcc_assert (region != NULL);
+ if (region == NULL)
+ {
+ *all = true;
+ return NULL;
+ }
}
}
}
@@ -7501,12 +7508,17 @@ move_sese_region_to_fn (struct function
if (saved_cfun->eh)
{
eh_region region = NULL;
+ bool all = false;
FOR_EACH_VEC_ELT (bbs, i, bb)
- region = find_outermost_region_in_block (saved_cfun, bb, region);
+ {
+ region = find_outermost_region_in_block (saved_cfun, bb, region,
&all);
+ if (all)
+ break;
+ }
init_eh_for_function ();
- if (region != NULL)
+ if (region != NULL || all)
{
new_label_map = htab_create (17, tree_map_hash, tree_map_eq, free);
eh_map = duplicate_eh_regions (saved_cfun, region, 0,
--- gcc/testsuite/gcc.dg/gomp/pr88107.c.jj 2019-01-31 18:11:53.605582170
+0100
+++ gcc/testsuite/gcc.dg/gomp/pr88107.c 2019-01-31 18:10:43.100745223 +0100
@@ -0,0 +1,35 @@
+/* PR tree-optimization/88107 */
+/* { dg-do compile { target fgraphite } } */
+/* { dg-require-effective-target vect_simd_clones } */
+/* { dg-options "-O2 -fexceptions -floop-nest-optimize -fnon-call-exceptions
-fopenmp-simd -ftree-parallelize-loops=2" } */
+
+#define N 1024
+int a[N], b[N];
+long int c[N];
+unsigned char d[N];
+
+#pragma omp declare simd notinbranch
+__attribute__((noinline)) static int
+foo (long int a, int b, int c)
+{
+ return a + b + c;
+}
+
+#pragma omp declare simd notinbranch
+__attribute__((noinline)) static long int
+bar (int a, int b, long int c)
+{
+ return a + b + c;
+}
+
+void
+baz (void)
+{
+ int i;
+ #pragma omp simd
+ for (i = 0; i < N; i++)
+a[i] = foo (c[i], a[i], b[i]) + 6;
+ #pragma omp simd
+ for (i = 0; i < N; i++)
+c[i] = bar (a[i], b[i], c[i]) * 2;
+}
Jakub
[PATCH] Fix mode-switching (PR rtl-optimization/88593)
Hi!
I've successfully bootstrapped/regtested following patch from the PR on
x86_64-linux and i686-linux. Will you commit it?
2019-01-31 Richard Biener
PR rtl-optimization/88593
* mode-switching.c (optimize_mode_switching): Free dominators before
calling cleanup_cfg.
--- gcc/mode-switching.c
+++ gcc/mode-switching.c
@@ -856,7 +856,10 @@ optimize_mode_switching (void)
commit_edge_insertions ();
if (targetm.mode_switching.entry && targetm.mode_switching.exit)
-cleanup_cfg (CLEANUP_NO_INSN_DEL);
+{
+ free_dominance_info (CDI_DOMINATORS);
+ cleanup_cfg (CLEANUP_NO_INSN_DEL);
+}
else if (!need_commit && !emitted)
return 0;
Jakub
[PATCH] Teach VRP about ABSU_EXPR (PR tree-optimization/89143)
Hi!
As mentioned in the PR, with the introduction of ABSU_EXPR where we were
previously using ABS_EXPR we've regressed various cases where VRP used to be
able to determine ranges for ABS_EXPR, but as ABSU_EXPR is unknown, we
always defer to VARYING. ABSU_EXPR is actually much easier to handle than
ABS_EXPR. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2019-01-31 Jakub Jelinek
PR tree-optimization/89143
* wide-int-range.h (wide_int_range_absu): Declare.
* wide-int-range.cc (wide_int_range_absu): New function.
* tree-vrp.c (extract_range_from_unary_expr): Handle ABSU_EXPR.
* gcc.dg/tree-ssa/vrp121.c: New test.
--- gcc/wide-int-range.h.jj 2019-01-01 12:37:19.272940249 +0100
+++ gcc/wide-int-range.h2019-01-31 21:09:24.045463875 +0100
@@ -107,6 +107,10 @@ extern bool wide_int_range_abs (wide_int
const wide_int &vr0_min,
const wide_int &vr0_max,
bool overflow_undefined);
+extern void wide_int_range_absu (wide_int &min, wide_int &max,
+unsigned prec,
+const wide_int &vr0_min,
+const wide_int &vr0_max);
extern bool wide_int_range_convert (wide_int &min, wide_int &max,
signop inner_sign,
unsigned inner_prec,
--- gcc/wide-int-range.cc.jj2019-01-01 12:37:15.62771 +0100
+++ gcc/wide-int-range.cc 2019-01-31 21:23:09.122900358 +0100
@@ -735,6 +735,37 @@ wide_int_range_abs (wide_int &min, wide_
return true;
}
+/* Calculate ABSU_EXPR on a range and store the result in [MIN, MAX]. */
+
+void
+wide_int_range_absu (wide_int &min, wide_int &max,
+unsigned prec, const wide_int &vr0_min,
+const wide_int &vr0_max)
+{
+ /* Pass through VR0 the easy cases. */
+ if (wi::ges_p (vr0_min, 0))
+{
+ min = vr0_min;
+ max = vr0_max;
+ return;
+}
+
+ min = wi::abs (vr0_min);
+ max = wi::abs (vr0_max);
+
+ /* If the range contains zero then we know that the minimum value in the
+ range will be zero. */
+ if (wi::ges_p (vr0_max, 0))
+{
+ if (wi::gtu_p (min, max))
+ max = min;
+ min = wi::zero (prec);
+}
+ else
+/* Otherwise, swap MIN and MAX. */
+std::swap (min, max);
+}
+
/* Convert range in [VR0_MIN, VR0_MAX] with INNER_SIGN and INNER_PREC,
to a range in [MIN, MAX] with OUTER_SIGN and OUTER_PREC.
--- gcc/tree-vrp.c.jj 2019-01-01 12:37:15.886995805 +0100
+++ gcc/tree-vrp.c 2019-01-31 21:26:42.326334608 +0100
@@ -2196,6 +2196,16 @@ extract_range_from_unary_expr (value_ran
vr->set_varying ();
return;
}
+ else if (code == ABSU_EXPR)
+{
+ wide_int wmin, wmax;
+ wide_int vr0_min, vr0_max;
+ extract_range_into_wide_ints (&vr0, SIGNED, prec, vr0_min, vr0_max);
+ wide_int_range_absu (wmin, wmax, prec, vr0_min, vr0_max);
+ vr->set (VR_RANGE, wide_int_to_tree (type, wmin),
+ wide_int_to_tree (type, wmax));
+ return;
+}
/* For unhandled operations fall back to varying. */
vr->set_varying ();
--- gcc/testsuite/gcc.dg/tree-ssa/vrp121.c.jj 2019-01-31 22:05:49.575733486
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp121.c 2019-01-31 22:05:15.813288163
+0100
@@ -0,0 +1,67 @@
+/* PR tree-optimization/89143 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-not "link_error \\\(" "optimized" } } */
+
+void link_error (void);
+
+void
+f1 (signed char i)
+{
+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > __SCHAR_MAX__ + 1)
+link_error ();
+}
+
+void
+f2 (signed char i)
+{
+ if (i < 0 || i > 15)
+__builtin_unreachable ();
+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > 15)
+link_error ();
+}
+
+void
+f3 (signed char i)
+{
+ if (i < 19 || i > 25)
+__builtin_unreachable ();
+ if (__builtin_abs (i) < 19 || __builtin_abs (i) > 25)
+link_error ();
+}
+
+void
+f4 (signed char i)
+{
+ if (i > -60)
+__builtin_unreachable ();
+ if (__builtin_abs (i) < 60 || __builtin_abs (i) > __SCHAR_MAX__ + 1)
+link_error ();
+}
+
+void
+f5 (signed char i)
+{
+ if (i < -__SCHAR_MAX__ || i > -30)
+__builtin_unreachable ();
+ if (__builtin_abs (i) < 30 || __builtin_abs (i) > __SCHAR_MAX__)
+link_error ();
+}
+
+void
+f6 (signed char i)
+{
+ if (i < -__SCHAR_MAX__ || i > 30)
+__builtin_unreachable ();
+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > __SCHAR_MAX__)
+link_error ();
+}
+
+void
+f7 (signed char i)
+{
+ if (i < -31 || i > 30)
+__builtin_unreachable ();
+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > 31)
+link_error ();
+}
Jakub
[PATCH] Shut up bogus clang warning on omp-low.c (PR middle-end/89137)
Hi! In an if (code == OMP_FOR || code == OMP_SECTIONS) guarded block c will be always initialized, yet clang warns anyway. Changed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2019-01-31 Jakub Jelinek PR middle-end/89137 * omp-low.c (lower_omp_task_reductions): Drop redundant test to avoid bogus clang warning. --- gcc/omp-low.c.jj2019-01-16 09:35:05.657305002 +0100 +++ gcc/omp-low.c 2019-01-31 11:57:08.992987893 +0100 @@ -7132,7 +7132,7 @@ lower_omp_task_reductions (omp_context * lab3 = create_artificial_label (UNKNOWN_LOCATION); if (code == OMP_FOR) c = gimple_omp_for_clauses (ctx->stmt); - else if (code == OMP_SECTIONS) + else /* if (code == OMP_SECTIONS) */ c = gimple_omp_sections_clauses (ctx->stmt); c = OMP_CLAUSE_DECL (omp_find_clause (c, OMP_CLAUSE__REDUCTEMP_)); cancellable = c; Jakub
C++ PATCH for c++/88983 - ICE with switch in constexpr function
Here we have switch (1) with body
if (1)
{
case 1:;
return = 1;
}
else
{
default:;
}
so we're looking for "case 1:", which we found in the then branch while
evaluating the COND_EXPR, so *jump_target is cleared. But it's followed
by a jumping statement so *jump_target is set to a RETURN_EXPR, which as
the new comment describes, confuses the code in .
label_matches then crashes if it gets a RETURN_EXPR as a jump_target.
I've expanded the original testcase so as to cover break/continue after
the label.
I imagine this could also be fixed differently -- don't call label_matches
in cxx_eval_constant_expression if jump_target isn't a label/switch case.
Bootstrapped/regtested on x86_64-linux, ok for trunk? I'd like to commit
to 8 too.
2019-01-31 Marek Polacek
PR c++/88983 - ICE with switch in constexpr function.
* constexpr.c (cxx_eval_switch_expr): Use SWITCH_COND and SWITCH_BODY.
(cxx_eval_constant_expression) : Don't look for the
label in the else branch if we found it in the then branch.
* g++.dg/cpp1y/constexpr-88983.C: New test.
diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 19eb44fc0c0..fc12912676d 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -4140,13 +4140,13 @@ cxx_eval_switch_expr (const constexpr_ctx *ctx, tree t,
bool *non_constant_p, bool *overflow_p,
tree *jump_target)
{
- tree cond = TREE_OPERAND (t, 0);
+ tree cond = SWITCH_COND (t);
cond = cxx_eval_constant_expression (ctx, cond, false,
non_constant_p, overflow_p);
VERIFY_CONSTANT (cond);
*jump_target = cond;
- tree body = TREE_OPERAND (t, 1);
+ tree body = SWITCH_BODY (t);
constexpr_ctx new_ctx = *ctx;
constexpr_switch_state css = css_default_not_seen;
new_ctx.css_state = &css;
@@ -4681,6 +4681,7 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
case COND_EXPR:
if (jump_target && *jump_target)
{
+ tree orig_jump = *jump_target;
/* When jumping to a label, the label might be either in the
then or else blocks, so process then block first in skipping
mode first, and if we are still in the skipping mode at its end,
@@ -4688,7 +4689,19 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
r = cxx_eval_constant_expression (ctx, TREE_OPERAND (t, 1),
lval, non_constant_p, overflow_p,
jump_target);
- if (*jump_target)
+ /* It's possible that we found the label in the then block. But
+it could have been followed by another jumping statement, e.g.
+say we're looking for case 1:
+ if (cond)
+ {
+ // skipped statements
+ case 1:; // clears up *jump_target
+ return 1; // and sets it to a RETURN_EXPR
+ }
+ else { ... }
+in which case we need not go looking to the else block.
+(goto is not allowed in a constexpr function.) */
+ if (*jump_target && *jump_target == orig_jump)
r = cxx_eval_constant_expression (ctx, TREE_OPERAND (t, 2),
lval, non_constant_p, overflow_p,
jump_target);
diff --git gcc/testsuite/g++.dg/cpp1y/constexpr-88983.C
gcc/testsuite/g++.dg/cpp1y/constexpr-88983.C
new file mode 100644
index 000..9d70601d427
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-88983.C
@@ -0,0 +1,71 @@
+// PR c++/88983
+// { dg-do compile { target c++14 } }
+
+constexpr int
+fn1 (int ay)
+{
+ switch (ay)
+{
+ if (1)
+{
+ case 1:
+return 1;
+}
+ else
+{
+ default:;
+}
+}
+
+ return 0;
+}
+
+constexpr int
+fn2 (int ay)
+{
+ switch (ay)
+{
+ if (1)
+{
+ case 1:
+ break;
+}
+ else
+{
+ default:;
+}
+}
+
+ return 0;
+}
+
+constexpr int
+fn3 (int ay)
+{
+ int i = 0;
+ while (i++ < 100)
+{
+ if (i == 1)
+ return 1;
+ switch (ay)
+ {
+ if (1)
+ {
+ case 1:
+ continue;
+ }
+ else
+ {
+ default:;
+ return -1;
+ }
+ }
+ return -1;
+}
+
+ return -1;
+}
+
+static_assert (fn1 (1) == 1, "");
+static_assert (fn2 (1) == 0, "");
+static_assert (fn3 (1) == 1, "");
Re: C++ PATCH for c++/88983 - ICE with switch in constexpr function
On 1/31/19 7:01 PM, Marek Polacek wrote: + if (*jump_target && *jump_target == orig_jump) You shouldn't need to check that it's non-null, since the enclosing if established that orig_jump will be non-null. OK with that tweak. Jason
Re: [C++ PATCH] Reject invalid GNU attribute syntax (PR c++/87175)
On 1/31/19 5:51 PM, Jakub Jelinek wrote: Hi! THe following patch rejects invalid __attribute__ syntax where one or both opening parens are missing, but it is accepted anyway. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2019-01-31 Jakub Jelinek PR c++/87175 * parser.c (cp_parser_gnu_attributes_opt): Set ok to false if require_open failed. OK. Jason
Re: C++ PATCH for c++/88983 - ICE with switch in constexpr function
On Thu, Jan 31, 2019 at 07:11:59PM -0500, Jason Merrill wrote: > On 1/31/19 7:01 PM, Marek Polacek wrote: > > + if (*jump_target && *jump_target == orig_jump) > > You shouldn't need to check that it's non-null, since the enclosing if > established that orig_jump will be non-null. OK with that tweak. Duh, of course. Committed with that fixed. Marek
Re: [PATCH AutoFDO]Restoring indirect call value profile transformation
On Tue, Jan 15, 2019 at 1:10 AM Andi Kleen wrote: > > On Mon, Jan 14, 2019 at 04:15:20PM +0800, Bin.Cheng wrote: > > On Mon, Jan 14, 2019 at 4:07 PM Andi Kleen wrote: > > > > > > Bin Cheng, > > > > > > I did some testing on this now. The attached patch automatically > > > increases the iterations > > > for autofdo profiles. > > Hi Andi, thanks very much for tuning these. > > > > > > But even with even more iterations I still have stable failures in > > > > > > FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold > > > FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler size[ > > > \ta-zA-Z0-0]+foo[._]+cold > > I think these two are supposed to fail with current code base. > > Sorry for being late. > We should mark it as XFAIL then I guess. Yeah > > Is it understood why it doesn't work? I didn't dig into it, but I think the reason is autofdo::zero count is not considered as cold as profile count. It's kind of reasonable, otherwise too much code would be categorized as cold. > > > > FAIL: gcc.dg/tree-prof/indir-call-prof.c scan-ipa-dump afdo "Indirect > > > call -> direct call.* a1 transformation on insn" > > I also got unstable pass/fail for indirect call optimization when > > tuning iterations, and haven't got an iteration number which passes > > all the time. I guess we need to combine decreasing of sampling count > > here. > > Okay I will look into that. > > Could also try if prime sample after values help, this sometimes fixes > problems with systematically missing some code in sampling. > > > > FAIL: gcc.dg/tree-prof/peel-1.c scan-tree-dump cunroll "Peeled loop ., 1 > > > times" > > This one should fail too. > > Same. Maybe I shouldn't use words "should fail", but the reason is we don't consider autofdo profile count as reliable in niters analysis. Maybe this can be improved somehow. Thanks, bin > > -Andi
Re: [PATCH] Integration of parallel standard algorithms for c++17
from upstream * testsuite/25_algorithms/pstl/alg.modifying.operations/unique_copy_equal.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/adjacent_find.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/all_of.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/any_of.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/count.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/equal.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/find.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/find_end.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/find_first_of.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/find_if.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/for_each.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/mismatch.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/none_of.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/nth_element.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/search.cc:update from upstream * testsuite/25_algorithms/pstl/alg.nonmodifying/search_n.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/alg.heap.operations/is_heap.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/alg.lex.comparison/lexicographical_compare.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/alg.min.max/minmax_element.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/alg.set.operations/includes.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/alg.set.operations/set.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/is_sorted.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/partial_sort.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/partial_sort_copy.cc:update from upstream * testsuite/25_algorithms/pstl/alg.sorting/sort.cc:update from upstream * testsuite/26_numerics/pstl/numeric.ops/adjacent_difference.cc:update from upstream * testsuite/26_numerics/pstl/numeric.ops/reduce.cc:update from upstream * testsuite/26_numerics/pstl/numeric.ops/scan.cc:update from upstream * testsuite/26_numerics/pstl/numeric.ops/transform_reduce.cc:update from upstream * testsuite/26_numerics/pstl/numeric.ops/transform_scan.cc:update from upstream * testsuite/util/pstl/parallel_utils.h:update from upstream * testsuite/util/pstl/pstl_test_config.h:update from upstream gg 20190131-pstl-integration.patch.bz2 Description: application/bzip
Re: [PATCH] Don't ICE on parloops with multiple EH regions without common parent (PR tree-optimization/88107)
On January 31, 2019 11:56:39 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>While OpenMP parsing ensures the parallel, task, taskloop, target,
>teams
>etc. body are wrapped in ERT_MUST_NOT_THROW EH regions, for parloops we
>can
>actually end up with multiple different EH regions. If they still have
>some
>common outer region, perhaps covering much bigger part of code than the
>region itself, we still handle it by duplicating perhaps more of EH
>tree
>than strictly necessary (but it isn't that easy to determine what are
>all
>the roots we want to copy), if there isn't a common outer region, we
>ICE.
>
>The following patch just extends what we are actually doing to copying
>the
>whole EH tree of the function in that case, eh cleanups can remove
>unreachable regions later on.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2019-01-31 Jakub Jelinek
>
> PR tree-optimization/88107
> * tree-cfg.c (find_outermost_region_in_block): Add ALL argument,
> instead of assertion that eh_region_outermost is non-NULL, if it
> is NULL, set *ALL to true and return NULL.
> (move_sese_region_to_fn): Adjust caller, if all is set, call
> duplicate_eh_regions with NULL region.
>
> * gcc.dg/gomp/pr88107.c: New test.
>
>--- gcc/tree-cfg.c.jj 2019-01-28 11:33:14.704888408 +0100
>+++ gcc/tree-cfg.c 2019-01-31 17:17:58.357007322 +0100
>@@ -7143,11 +7143,14 @@ move_block_to_fn (struct function *dest_
> }
>
>/* Examine the statements in BB (which is in SRC_CFUN); find and return
>- the outermost EH region. Use REGION as the incoming base EH
>region. */
>+ the outermost EH region. Use REGION as the incoming base EH
>region.
>+ If there is no single outermost region, return NULL and set *ALL to
>+ true. */
>
> static eh_region
> find_outermost_region_in_block (struct function *src_cfun,
>- basic_block bb, eh_region region)
>+ basic_block bb, eh_region region,
>+ bool *all)
> {
> gimple_stmt_iterator si;
>
>@@ -7166,7 +7169,11 @@ find_outermost_region_in_block (struct f
> else if (stmt_region != region)
> {
> region = eh_region_outermost (src_cfun, stmt_region, region);
>-gcc_assert (region != NULL);
>+if (region == NULL)
>+ {
>+*all = true;
>+return NULL;
>+ }
> }
> }
> }
>@@ -7501,12 +7508,17 @@ move_sese_region_to_fn (struct function
> if (saved_cfun->eh)
> {
> eh_region region = NULL;
>+ bool all = false;
>
> FOR_EACH_VEC_ELT (bbs, i, bb)
>- region = find_outermost_region_in_block (saved_cfun, bb, region);
>+ {
>+region = find_outermost_region_in_block (saved_cfun, bb, region,
>&all);
>+if (all)
>+ break;
>+ }
>
> init_eh_for_function ();
>- if (region != NULL)
>+ if (region != NULL || all)
> {
> new_label_map = htab_create (17, tree_map_hash, tree_map_eq, free);
> eh_map = duplicate_eh_regions (saved_cfun, region, 0,
>--- gcc/testsuite/gcc.dg/gomp/pr88107.c.jj 2019-01-31
>18:11:53.605582170 +0100
>+++ gcc/testsuite/gcc.dg/gomp/pr88107.c2019-01-31 18:10:43.100745223
>+0100
>@@ -0,0 +1,35 @@
>+/* PR tree-optimization/88107 */
>+/* { dg-do compile { target fgraphite } } */
>+/* { dg-require-effective-target vect_simd_clones } */
>+/* { dg-options "-O2 -fexceptions -floop-nest-optimize
>-fnon-call-exceptions -fopenmp-simd -ftree-parallelize-loops=2" } */
>+
>+#define N 1024
>+int a[N], b[N];
>+long int c[N];
>+unsigned char d[N];
>+
>+#pragma omp declare simd notinbranch
>+__attribute__((noinline)) static int
>+foo (long int a, int b, int c)
>+{
>+ return a + b + c;
>+}
>+
>+#pragma omp declare simd notinbranch
>+__attribute__((noinline)) static long int
>+bar (int a, int b, long int c)
>+{
>+ return a + b + c;
>+}
>+
>+void
>+baz (void)
>+{
>+ int i;
>+ #pragma omp simd
>+ for (i = 0; i < N; i++)
>+a[i] = foo (c[i], a[i], b[i]) + 6;
>+ #pragma omp simd
>+ for (i = 0; i < N; i++)
>+c[i] = bar (a[i], b[i], c[i]) * 2;
>+}
>
> Jakub
Re: [PATCH] Teach VRP about ABSU_EXPR (PR tree-optimization/89143)
On February 1, 2019 12:00:26 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, with the introduction of ABSU_EXPR where we
>were
>previously using ABS_EXPR we've regressed various cases where VRP used
>to be
>able to determine ranges for ABS_EXPR, but as ABSU_EXPR is unknown, we
>always defer to VARYING. ABSU_EXPR is actually much easier to handle
>than
>ABS_EXPR. Bootstrapped/regtested on x86_64-linux and i686-linux, ok
>for
>trunk?
OK.
Richard.
>2019-01-31 Jakub Jelinek
>
> PR tree-optimization/89143
> * wide-int-range.h (wide_int_range_absu): Declare.
> * wide-int-range.cc (wide_int_range_absu): New function.
> * tree-vrp.c (extract_range_from_unary_expr): Handle ABSU_EXPR.
>
> * gcc.dg/tree-ssa/vrp121.c: New test.
>
>--- gcc/wide-int-range.h.jj2019-01-01 12:37:19.272940249 +0100
>+++ gcc/wide-int-range.h 2019-01-31 21:09:24.045463875 +0100
>@@ -107,6 +107,10 @@ extern bool wide_int_range_abs (wide_int
> const wide_int &vr0_min,
> const wide_int &vr0_max,
> bool overflow_undefined);
>+extern void wide_int_range_absu (wide_int &min, wide_int &max,
>+ unsigned prec,
>+ const wide_int &vr0_min,
>+ const wide_int &vr0_max);
> extern bool wide_int_range_convert (wide_int &min, wide_int &max,
> signop inner_sign,
> unsigned inner_prec,
>--- gcc/wide-int-range.cc.jj 2019-01-01 12:37:15.62771 +0100
>+++ gcc/wide-int-range.cc 2019-01-31 21:23:09.122900358 +0100
>@@ -735,6 +735,37 @@ wide_int_range_abs (wide_int &min, wide_
> return true;
> }
>
>+/* Calculate ABSU_EXPR on a range and store the result in [MIN, MAX].
>*/
>+
>+void
>+wide_int_range_absu (wide_int &min, wide_int &max,
>+ unsigned prec, const wide_int &vr0_min,
>+ const wide_int &vr0_max)
>+{
>+ /* Pass through VR0 the easy cases. */
>+ if (wi::ges_p (vr0_min, 0))
>+{
>+ min = vr0_min;
>+ max = vr0_max;
>+ return;
>+}
>+
>+ min = wi::abs (vr0_min);
>+ max = wi::abs (vr0_max);
>+
>+ /* If the range contains zero then we know that the minimum value in
>the
>+ range will be zero. */
>+ if (wi::ges_p (vr0_max, 0))
>+{
>+ if (wi::gtu_p (min, max))
>+ max = min;
>+ min = wi::zero (prec);
>+}
>+ else
>+/* Otherwise, swap MIN and MAX. */
>+std::swap (min, max);
>+}
>+
> /* Convert range in [VR0_MIN, VR0_MAX] with INNER_SIGN and INNER_PREC,
>to a range in [MIN, MAX] with OUTER_SIGN and OUTER_PREC.
>
>--- gcc/tree-vrp.c.jj 2019-01-01 12:37:15.886995805 +0100
>+++ gcc/tree-vrp.c 2019-01-31 21:26:42.326334608 +0100
>@@ -2196,6 +2196,16 @@ extract_range_from_unary_expr (value_ran
> vr->set_varying ();
> return;
> }
>+ else if (code == ABSU_EXPR)
>+{
>+ wide_int wmin, wmax;
>+ wide_int vr0_min, vr0_max;
>+ extract_range_into_wide_ints (&vr0, SIGNED, prec, vr0_min,
>vr0_max);
>+ wide_int_range_absu (wmin, wmax, prec, vr0_min, vr0_max);
>+ vr->set (VR_RANGE, wide_int_to_tree (type, wmin),
>+ wide_int_to_tree (type, wmax));
>+ return;
>+}
>
> /* For unhandled operations fall back to varying. */
> vr->set_varying ();
>--- gcc/testsuite/gcc.dg/tree-ssa/vrp121.c.jj 2019-01-31
>22:05:49.575733486 +0100
>+++ gcc/testsuite/gcc.dg/tree-ssa/vrp121.c 2019-01-31
>22:05:15.813288163 +0100
>@@ -0,0 +1,67 @@
>+/* PR tree-optimization/89143 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -fdump-tree-optimized" } */
>+/* { dg-final { scan-tree-dump-not "link_error \\\(" "optimized" } }
>*/
>+
>+void link_error (void);
>+
>+void
>+f1 (signed char i)
>+{
>+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > __SCHAR_MAX__ + 1)
>+link_error ();
>+}
>+
>+void
>+f2 (signed char i)
>+{
>+ if (i < 0 || i > 15)
>+__builtin_unreachable ();
>+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > 15)
>+link_error ();
>+}
>+
>+void
>+f3 (signed char i)
>+{
>+ if (i < 19 || i > 25)
>+__builtin_unreachable ();
>+ if (__builtin_abs (i) < 19 || __builtin_abs (i) > 25)
>+link_error ();
>+}
>+
>+void
>+f4 (signed char i)
>+{
>+ if (i > -60)
>+__builtin_unreachable ();
>+ if (__builtin_abs (i) < 60 || __builtin_abs (i) > __SCHAR_MAX__ + 1)
>+link_error ();
>+}
>+
>+void
>+f5 (signed char i)
>+{
>+ if (i < -__SCHAR_MAX__ || i > -30)
>+__builtin_unreachable ();
>+ if (__builtin_abs (i) < 30 || __builtin_abs (i) > __SCHAR_MAX__)
>+link_error ();
>+}
>+
>+void
>+f6 (signed char i)
>+{
>+ if (i < -__SCHAR_MAX__ || i > 30)
>+__builtin_unreachable ();
>+ if (__builtin_abs (i) < 0 || __builtin_abs (i) > __SCHAR_MAX__)
>+link_error ();
>+}
>+
>+void
>+f7 (signed char i)
>+{
>+ if (i < -31 || i > 30)
>+__builtin_unreachable ();
>+ if (__bui
