[C++ PATCH] PR c++/79133
Tested on Linux-PPC64. Ok for trunk, perhaps with the change
that I move the test under cpp1y, since it's a c++14 test anyway?
I considered pushing the captures into the parameter scope. I don't
know how to do that; changing the pushdecl_outermost_localscope
to a pushdecl doesn't seem to cut it; I guess that I should add
a new function into name-lookup.[ch], but I wonder whether
that makes sense, considering that this is lambda-only functionality.
I also wonder whether it makes more sense than the solution
in this patch, considering that we handle packs here as well
and capturepack/parampack, capturepack/param, capture/parampack
and capture/param clashes.
Guidance welcome. This approach has the benefit that it, well,
seems to work. :)
2018-07-07 Ville Voutilainen
gcc/cp/
PR c++/79133
* lambda.c (start_lambda_function): Reject captures and parameters
with the same name.
testsuite/
PR c++/79133
* g++.dg/cpp0x/lambda/lambda-shadow3.C: New.
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index 3776d6b..534434a 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -1424,7 +1424,28 @@ start_lambda_function (tree fco, tree lambda_expr)
/* Push the proxies for any explicit captures. */
for (tree cap = LAMBDA_EXPR_CAPTURE_LIST (lambda_expr); cap;
cap = TREE_CHAIN (cap))
-build_capture_proxy (TREE_PURPOSE (cap), TREE_VALUE (cap));
+{
+ /* DR 2211: check that captures and parameters
+ do not have the same name. */
+ for (tree parms = DECL_ARGUMENTS (fco); parms;
+ parms = TREE_CHAIN (parms))
+ {
+ tree real_cap = TREE_VALUE (cap);
+ tree real_parms = parms;
+ if (PACK_EXPANSION_P (real_cap))
+ real_cap = PACK_EXPANSION_PATTERN (real_cap);
+ if (PACK_EXPANSION_P (parms))
+ real_parms = PACK_EXPANSION_PATTERN (parms);
+ if (DECL_P (real_cap)
+ && DECL_NAME (real_cap) != this_identifier
+ && DECL_NAME (real_cap) == DECL_NAME (real_parms))
+ error_at (DECL_SOURCE_LOCATION (parms),
+ "capture %qE and lambda parameter %qE "
+ "have the same name",
+ cap, parms);
+ }
+ build_capture_proxy (TREE_PURPOSE (cap), TREE_VALUE (cap));
+}
return body;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
new file mode 100644
index 000..b006470
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-shadow3.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++14 } }
+
+int main() {
+ int x = 42;
+ auto lambda = [x](int x) {}; // { dg-error "have the same name" }
+ auto lambda2 = [x=x](int x) {}; // { dg-error "have the same name" }
+ auto lambda3 = [x](auto... x) {}; // { dg-error "have the same name" }
+ auto lambda4 = [](auto... x) {
+auto lambda5 = [x...](auto... x) {}; // { dg-error "have the same name" }
+auto lambda6 = [x...](int x) {}; // { dg-error "have the same name" }
+ };
+}
Re: [PATCH] [ARC] Add support for HS4x cpus.
* Claudiu Zissulescu [2018-06-13 12:09:18 +0300]:
> From: Claudiu Zissulescu
>
> This patch adds support for two ARCHS variations.
>
> Ok to apply?
> Claudiu
Sorry for the delay, this looks fine.
Thanks,
Andrew
>
> gcc/
> 2017-03-10 Claudiu Zissulescu
>
> * config/arc/arc-arch.h (arc_tune_attr): Add new tune parameters
> for ARCHS4x.
> * config/arc/arc-cpus.def (hs4x): New cpu.
> (hs4xd): Likewise.
> * config/arc/arc-tables.opt: Regenerate.
> * config/arc/arc.c (arc_sched_issue_rate): New function.
> (TARGET_SCHED_ISSUE_RATE): Define.
> (TARGET_SCHED_EXPOSED_PIPELINE): Likewise.
> * config/arc/arc.md (attr type): Add fpu_fuse, fpu_sdiv, fpu_ddiv,
> fpu_cvt.
> (attr tune): Add ARCHS4x tune values.
> (attr tune_dspmpy): Define.
> (*tst): Correct instruction type.
> * config/arc/arcHS.md: Don't use this automaton for ARCHS4x cpus.
> * config/arc/arcHS4x.md: New file.
> * config/arc/fpu.md: Update instruction type attributes.
> * config/arc/t-multilib: Regenerate.
> ---
> gcc/config/arc/arc-arch.h | 5 +-
> gcc/config/arc/arc-cpus.def | 8 +-
> gcc/config/arc/arc-tables.opt | 6 +
> gcc/config/arc/arc.c | 19 +++
> gcc/config/arc/arc.md | 24 +++-
> gcc/config/arc/arcHS.md | 6 +
> gcc/config/arc/arcHS4x.md | 221 ++
> gcc/config/arc/fpu.md | 16 +--
> 8 files changed, 289 insertions(+), 16 deletions(-)
> create mode 100644 gcc/config/arc/arcHS4x.md
>
> diff --git a/gcc/config/arc/arc-arch.h b/gcc/config/arc/arc-arch.h
> index 64866dd529b..01f95946623 100644
> --- a/gcc/config/arc/arc-arch.h
> +++ b/gcc/config/arc/arc-arch.h
> @@ -73,7 +73,10 @@ enum arc_tune_attr
> ARC_TUNE_ARC600,
> ARC_TUNE_ARC700_4_2_STD,
> ARC_TUNE_ARC700_4_2_XMAC,
> -ARC_TUNE_CORE_3
> +ARC_TUNE_CORE_3,
> +ARC_TUNE_ARCHS4X,
> +ARC_TUNE_ARCHS4XD,
> +ARC_TUNE_ARCHS4XD_SLOW
>};
>
> /* CPU specific properties. */
> diff --git a/gcc/config/arc/arc-cpus.def b/gcc/config/arc/arc-cpus.def
> index 1fce81f6933..4aa422f1a39 100644
> --- a/gcc/config/arc/arc-cpus.def
> +++ b/gcc/config/arc/arc-cpus.def
> @@ -59,10 +59,12 @@ ARC_CPU (archs,hs, FL_MPYOPT_2|FL_DIVREM|FL_LL64,
> NONE)
> ARC_CPU (hs34,hs, FL_MPYOPT_2, NONE)
> ARC_CPU (hs38,hs, FL_MPYOPT_9|FL_DIVREM|FL_LL64, NONE)
> ARC_CPU (hs38_linux, hs, FL_MPYOPT_9|FL_DIVREM|FL_LL64|FL_FPU_FPUD_ALL, NONE)
> +ARC_CPU (hs4x, hs, FL_MPYOPT_9|FL_DIVREM|FL_LL64, ARCHS4X)
> +ARC_CPU (hs4xd, hs, FL_MPYOPT_9|FL_DIVREM|FL_LL64, ARCHS4XD)
>
> -ARC_CPU (arc600, 6xx, FL_BS, ARC600)
> -ARC_CPU (arc600_norm, 6xx, FL_BS|FL_NORM, ARC600)
> -ARC_CPU (arc600_mul64, 6xx, FL_BS|FL_NORM|FL_MUL64, ARC600)
> +ARC_CPU (arc600, 6xx, FL_BS, ARC600)
> +ARC_CPU (arc600_norm, 6xx, FL_BS|FL_NORM, ARC600)
> +ARC_CPU (arc600_mul64,6xx, FL_BS|FL_NORM|FL_MUL64, ARC600)
> ARC_CPU (arc600_mul32x16, 6xx, FL_BS|FL_NORM|FL_MUL32x16, ARC600)
> ARC_CPU (arc601, 6xx, 0, ARC600)
> ARC_CPU (arc601_norm, 6xx, FL_NORM, ARC600)
> diff --git a/gcc/config/arc/arc-tables.opt b/gcc/config/arc/arc-tables.opt
> index 3b17b3de7d5..2afaf5bd83c 100644
> --- a/gcc/config/arc/arc-tables.opt
> +++ b/gcc/config/arc/arc-tables.opt
> @@ -63,6 +63,12 @@ Enum(processor_type) String(hs38) Value(PROCESSOR_hs38)
> EnumValue
> Enum(processor_type) String(hs38_linux) Value(PROCESSOR_hs38_linux)
>
> +EnumValue
> +Enum(processor_type) String(hs4x) Value(PROCESSOR_hs4x)
> +
> +EnumValue
> +Enum(processor_type) String(hs4xd) Value(PROCESSOR_hs4xd)
> +
> EnumValue
> Enum(processor_type) String(arc600) Value(PROCESSOR_arc600)
>
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 2bedc9af37e..03a2f4223c0 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -483,6 +483,22 @@ arc_autovectorize_vector_sizes (vector_sizes *sizes)
> }
> }
>
> +
> +/* Implements target hook TARGET_SCHED_ISSUE_RATE. */
> +static int
> +arc_sched_issue_rate (void)
> +{
> + switch (arc_tune)
> +{
> +case TUNE_ARCHS4X:
> +case TUNE_ARCHS4XD:
> + return 3;
> +default:
> + break;
> +}
> + return 1;
> +}
> +
> /* TARGET_PRESERVE_RELOAD_P is still awaiting patch re-evaluation / review.
> */
> static bool arc_preserve_reload_p (rtx in) ATTRIBUTE_UNUSED;
> static rtx arc_delegitimize_address (rtx);
> @@ -565,6 +581,9 @@ static rtx arc_legitimize_address_0 (rtx, rtx,
> machine_mode mode);
> #undef TARGET_SCHED_ADJUST_PRIORITY
> #define TARGET_SCHED_ADJUST_PRIORITY arc_sched_adjust_priority
>
> +#undef TARGET_SCHED_ISSUE_RATE
> +#define TARGET_SCHED_ISSUE_RATE arc_sched_issue_rate
> +
> #undef TARGET_VECTOR_MODE_SUPPORTED_P
> #define TARGET_VECTOR_MODE_SUPPORTED_P arc_vector_mode_supported_p
>
> diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
> index 091f1092bed..5610b
Re: [PING][PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble
On 7/5/18 2:36 PM, Jeff Law wrote: > On 07/02/2018 03:50 PM, Peter Bergner wrote: >> I'd like to PING: >> >> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html >> >> I've included the entire patch below, since I missed the test cases in >> the original submission and Segher asked for some updated text for the >> hook documentation which I've included below. > > OK. Is that an ok for GCC 8 as well which I asked for in the initial patch submission? Peter
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
On Fri, Jul 6, 2018 at 12:16 AM, Arnaud Charlet wrote: >> Ada is a low priority side project for me, so if you want non-trivial changes >> it may be a while before I can get to them. There is a lot of other stuff >> higher on my priority list at the moment, such as getting native gdb support >> working. If this isn't OK as is, then I'm willing to put work-in-progress >> patches in a bug report or on a branch or something. >> >> OK? > > This is OK, thanks. > >> Jim >> >> gcc/ada/ >> * Makefile.rtl: Add riscv*-linux* support. >> * libgnarl/s-linux__riscv.ads: New. >> * libgnat/system-linux-riscv.ads: New. Committed. Jim
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
On Fri, Jul 6, 2018 at 12:18 AM, Arnaud Charlet wrote: >> These are some patches I needed to complete my cross build of a native >> riscv linux Ada compiler. Some paths were different on the build machine >> and host machine. I needed to pass options into gnatmake to work around >> this, >> and that required fixing some makefile rules to use $(GNATMAKE) instead of >> calling gnatmake directly. >> >> Tested with native riscv-linux bootstrap with Ada enabled. >> >> OK? > > OK, thanks. > >> Jim >> >> gcc/ada/ >> * Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of >> gnatmake. >> (einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise. >> * gcc-interface/Makefile.in (xoscons): Likewise. Committed. Jim
Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2
> On Jul 6, 2018, at 12:20 PM, Richard Sandiford
> wrote:
>
> Double empty line.
>
> OK otherwise, thanks. (Think this counts as a gen* patch.)
>
> Richard
Thanks. Committed as shown below.
paul
ChangeLog:
2018-07-06 Paul Koning
* doc/md.texi (define_split): Document DONE and FAIL.
(define_peephole2): Ditto.
Index: doc/md.texi
===
--- doc/md.texi (revision 262478)
+++ doc/md.texi (working copy)
@@ -8060,6 +8060,30 @@ those in @code{define_expand}, however, these stat
generate any new pseudo-registers. Once reload has completed, they also
must not allocate any space in the stack frame.
+There are two special macros defined for use in the preparation statements:
+@code{DONE} and @code{FAIL}. Use them with a following semicolon,
+as a statement.
+
+@table @code
+
+@findex DONE
+@item DONE
+Use the @code{DONE} macro to end RTL generation for the splitter. The
+only RTL insns generated as replacement for the matched input insn will
+be those already emitted by explicit calls to @code{emit_insn} within
+the preparation statements; the replacement pattern is not used.
+
+@findex FAIL
+@item FAIL
+Make the @code{define_split} fail on this occasion. When a @code{define_split}
+fails, it means that the splitter was not truly available for the inputs
+it was given, and the input insn will not be split.
+@end table
+
+If the preparation falls through (invokes neither @code{DONE} nor
+@code{FAIL}), then the @code{define_split} uses the replacement
+template.
+
Patterns are matched against @var{insn-pattern} in two different
circumstances. If an insn needs to be split for delay slot scheduling
or insn scheduling, the insn is already known to be valid, which means
@@ -8615,6 +8639,33 @@ so here's a silly made-up example:
"")
@end smallexample
+There are two special macros defined for use in the preparation statements:
+@code{DONE} and @code{FAIL}. Use them with a following semicolon,
+as a statement.
+
+@table @code
+
+@findex DONE
+@item DONE
+Use the @code{DONE} macro to end RTL generation for the peephole. The
+only RTL insns generated as replacement for the matched input insn will
+be those already emitted by explicit calls to @code{emit_insn} within
+the preparation statements; the replacement pattern is not used.
+
+@findex FAIL
+@item FAIL
+Make the @code{define_peephole2} fail on this occasion. When a
@code{define_peephole2}
+fails, it means that the replacement was not truly available for the
+particular inputs it was given. In that case, GCC may still apply a
+later @code{define_peephole2} that also matches the given insn pattern.
+(Note that this is different from @code{define_split}, where @code{FAIL}
+prevents the input insn from being split at all.)
+@end table
+
+If the preparation falls through (invokes neither @code{DONE} nor
+@code{FAIL}), then the @code{define_peephole2} uses the replacement
+template.
+
@noindent
If we had not added the @code{(match_dup 4)} in the middle of the input
sequence, it might have been the case that the register we chose at the
Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2
On 07/06/2018 10:20 AM, Richard Sandiford wrote:
> Paul Koning writes:
>> @@ -8615,6 +8639,34 @@ so here's a silly made-up example:
>>"")
>> @end smallexample
>>
>> +There are two special macros defined for use in the preparation statements:
>> +@code{DONE} and @code{FAIL}. Use them with a following semicolon,
>> +as a statement.
>> +
>> +@table @code
>> +
>> +@findex DONE
>> +@item DONE
>> +Use the @code{DONE} macro to end RTL generation for the peephole. The
>> +only RTL insns generated as replacement for the matched input insn will
>> +be those already emitted by explicit calls to @code{emit_insn} within
>> +the preparation statements; the replacement pattern is not used.
>> +
>> +@findex FAIL
>> +@item FAIL
>> +Make the @code{define_peephole2} fail on this occasion. When a
>> @code{define_peephole2}
>> +fails, it means that the replacement was not truly available for the
>> +particular inputs it was given. In that case, GCC may still apply a
>> +later @code{define_peephole2} that also matches the given insn pattern.
>> +(Note that this is different from @code{define_split}, where @code{FAIL}
>> +prevents the input insn from being split at all.)
>> +@end table
>> +
>> +If the preparation falls through (invokes neither @code{DONE} nor
>> +@code{FAIL}), then the @code{define_peephole2} uses the replacement
>> +template.
>> +
>> +
>> @noindent
>> If we had not added the @code{(match_dup 4)} in the middle of the input
>> sequence, it might have been the case that the register we chose at the
>
> Double empty line.
>
> OK otherwise, thanks. (Think this counts as a gen* patch.)
:-) Close enough for me.
Jeff
Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2
Paul Koning writes:
> @@ -8615,6 +8639,34 @@ so here's a silly made-up example:
>"")
> @end smallexample
>
> +There are two special macros defined for use in the preparation statements:
> +@code{DONE} and @code{FAIL}. Use them with a following semicolon,
> +as a statement.
> +
> +@table @code
> +
> +@findex DONE
> +@item DONE
> +Use the @code{DONE} macro to end RTL generation for the peephole. The
> +only RTL insns generated as replacement for the matched input insn will
> +be those already emitted by explicit calls to @code{emit_insn} within
> +the preparation statements; the replacement pattern is not used.
> +
> +@findex FAIL
> +@item FAIL
> +Make the @code{define_peephole2} fail on this occasion. When a
> @code{define_peephole2}
> +fails, it means that the replacement was not truly available for the
> +particular inputs it was given. In that case, GCC may still apply a
> +later @code{define_peephole2} that also matches the given insn pattern.
> +(Note that this is different from @code{define_split}, where @code{FAIL}
> +prevents the input insn from being split at all.)
> +@end table
> +
> +If the preparation falls through (invokes neither @code{DONE} nor
> +@code{FAIL}), then the @code{define_peephole2} uses the replacement
> +template.
> +
> +
> @noindent
> If we had not added the @code{(match_dup 4)} in the middle of the input
> sequence, it might have been the case that the register we chose at the
Double empty line.
OK otherwise, thanks. (Think this counts as a gen* patch.)
Richard
Re: [PATCH] fold strlen() of aggregate members (PR 77357)
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
>
> GCC folds accesses to members of constant aggregates except
> for character arrays/strings. For example, the strlen() call
> below is not folded:
>
>const char a[][4] = { "1", "12" };
>
>int f (void) { retturn strlen (a[1]); }
>
> The attached change set enhances the string_constant() function
> to make it possible to extract string constants from aggregate
> initializers (CONSTRUCTORS).
>
> The initial solution was much simpler but as is often the case,
> MEM_REF made it fail to fold things like:
>
>int f (void) { retturn strlen (a[1] + 1); }
>
> Handling those made the project a bit more interesting and
> the final solution somewhat more involved.
>
> To handle offsets into aggregate string members the patch also
> extends the fold_ctor_reference() function to extract entire
> string array initializers even if the offset points past
> the beginning of the string and even though the size and
> exact type of the reference are not known (there isn't enough
> information in a MEM_REF to determine that).
>
> Tested along with the patch for PR 86415 on x86_64-linux.
+ if (TREE_CODE (init) == CONSTRUCTOR)
+ {
+ tree type;
+ if (TREE_CODE (arg) == ARRAY_REF
+ || TREE_CODE (arg) == MEM_REF)
+ type = TREE_TYPE (arg);
+ else if (TREE_CODE (arg) == COMPONENT_REF)
+ {
+ tree field = TREE_OPERAND (arg, 1);
+ type = TREE_TYPE (field);
+ }
+ else
+ return NULL_TREE;
what's wrong with just
type = TREE_TYPE (field);
?
+ base_off *= BITS_PER_UNIT;
poly_uint64 isn't enough for "bits", with wide-int you'd use offset_int,
for poly you'd then use poly_offset?
You extend fold_ctor_reference to treat size == 0 specially but then
bother to compute a size here - that looks unneeded?
While the offset of the reference determines the first field in the
CONSTRUCTOR, how do you know the access doesn't touch
adjacent ones? STRING_CSTs do not have to be '\0' terminated,
so consider
char x[2][4] = { "abcd", "abcd" };
and MEM[&x] with a char[8] type? memcpy "inlining" will create
such MEMs for example.
@@ -6554,8 +6577,16 @@ fold_nonarray_ctor_reference (tree type, tree ctor,
tree byte_offset = DECL_FIELD_OFFSET (cfield);
tree field_offset = DECL_FIELD_BIT_OFFSET (cfield);
tree field_size = DECL_SIZE (cfield);
- offset_int bitoffset;
- offset_int bitoffset_end, access_end;
+
+ if (!field_size && TREE_CODE (cval) == STRING_CST)
+ {
+ /* Determine the size of the flexible array member from
+the size of the string initializer provided for it. */
+ unsigned HOST_WIDE_INT len = TREE_STRING_LENGTH (cval);
+ tree eltype = TREE_TYPE (TREE_TYPE (cval));
+ len *= tree_to_uhwi (TYPE_SIZE (eltype));
+ field_size = build_int_cst (size_type_node, len);
+ }
Why does this only apply to STRING_CST initializers and not CONSTRUCTORS,
say, for
struct S { int i; int a[]; } s = { 1, { 2, 3, 4, 5, 6 } };
? And why not use simply
field_size = TYPE_SIZE (TREE_TYPE (cval));
like you do in c_strlen?
Otherwise looks reasonable.
Thanks,
Richard.
> Martin
Re: [PATCH] Fix sigsegv on -fdump-tree-all-enumerate_locals
On 07/06/2018 08:41 AM, Richard Biener wrote: > On Fri, Jul 6, 2018 at 3:30 PM Tom de Vries wrote: >> >> Hi, >> >> this patch fixes a sigsegv when using -fdump-tree-all-enumerate_locals, by >> handling cfun->cfg == NULL conservatively in dump_enumerated_decls. >> >> OK for trunk? > > Ok for the tree-dfa.c part. OK on the testsuite part. jeff
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
Michael Meissner writes:
> On Fri, Jul 06, 2018 at 10:16:34AM -0300, Tulio Magno Quites Machado Filho
> wrote:
>> I suggest to test with the following program:
>>
>> #include
>>
>> int
>> main ()
>> {
>> return !isinfl(__builtin_infl());
>> }
>>
>> Build it with:
>> gcc -mabi=ieeelongdouble -fno-builtin -Wno-psabi -lm test-ldbl.c
>>
>> If the execution of the program returns 0, your math library supports IEEE
>> long
>> double.
>
> Thanks, but I suspect that it won't work for building cross compilers
Indeed.
> or for building where the compiler built uses the Advance Toolchain libraries
> and
> shared library loader instead of the system versions using the configuration
> option --with-advance-toolchain=atx.y.
It should work. Maybe with extra compiler flags.
> The issue is you need to test whether the target GLIBC has the support when
> configuring the compiler, but if you are building for a cross target, you
> can't
> run the resulting binary.
Agreed.
> So I used the GLIBC version tests that were already part of the GCC
> configuration.
I understand, but those versions are incorrect. Let me elaborate:
1) There should be no special code for the Advance Toolchain because it uses
the same glibc as everyone else.
2) While glibc is under development, its version is based on the last released
version, e.g.: current master code has version 2.27.9000. That's why the
Advance Toolchain libraries you accessed had a minor version of 27.
So, when you say minor version 28, are you referring to 2.28, which doesn't
support IEEE long double or 2.28.9000 which will support IEEE long double?
> If there is a simple method that works for cross compilers or where a
> specified
> sysroot is used, it would be simpler than having version checks.
Ideally we would have a macro to identify this, but it's hard to rely
on a macro when the code is not upstream yet.
--
Tulio Magno
Re: calculate overflow type in wide int arithmetic
On Fri, Jul 6, 2018 at 9:50 AM Aldy Hernandez wrote:
>
>
>
> On 07/05/2018 05:50 AM, Richard Biener wrote:
> > On Thu, Jul 5, 2018 at 9:35 AM Aldy Hernandez wrote:
> >>
> >> The reason for this patch are the changes showcased in tree-vrp.c.
> >> Basically I'd like to discourage rolling our own overflow and underflow
> >> calculation when doing wide int arithmetic. We should have a
> >> centralized place for this, that is-- in the wide int code itself ;-).
> >>
> >> The only cases I care about are plus/minus, which I have implemented,
> >> but we also get division for free, since AFAICT, division can only
> >> positive overflow:
> >>
> >> -MIN / -1 => +OVERFLOW
> >>
> >> Multiplication OTOH, can underflow, but I've not implemented it because
> >> we have no uses for it. I have added a note in the code explaining this.
> >>
> >> Originally I tried to only change plus/minus, but that made code that
> >> dealt with plus/minus in addition to div or mult a lot uglier. You'd
> >> have to special case "int overflow_for_add_stuff" and "bool
> >> overflow_for_everything_else". Changing everything to int, makes things
> >> consistent.
> >>
> >> Note: I have left poly-int as is, with its concept of yes/no for
> >> overflow. I can adapt this as well if desired.
> >>
> >> Tested on x86-64 Linux.
> >>
> >> OK for trunk?
> >
> > looks all straight-forward but the following:
> >
> > else if (op1)
> > {
> > if (minus_p)
> > - {
> > - wi = -wi::to_wide (op1);
> > -
> > - /* Check for overflow. */
> > - if (sgn == SIGNED
> > - && wi::neg_p (wi::to_wide (op1))
> > - && wi::neg_p (wi))
> > - ovf = 1;
> > - else if (sgn == UNSIGNED && wi::to_wide (op1) != 0)
> > - ovf = -1;
> > - }
> > + wi = wi::neg (wi::to_wide (op1));
> > else
> > wi = wi::to_wide (op1);
> >
> > you fail to handle - -INT_MIN.
>
> Woah, very good catch. I previously had this implemented as wi::sub(0,
> op1, &ovf) which was calculating overflow correctly but when I
> implemented the overflow type in wi::neg I missed this. Thanks.
>
> >
> > Given the fact that for multiplication (or others, didn't look too close)
> > you didn't implement the direction indicator I wonder if it would be more
> > appropriate to do
> >
> > enum ovfl { OVFL_NONE = 0, OVFL_UNDERFLOW = -1, OVFL_OVERFLOW = 1,
> > OVFL_UNKNOWN = 2 };
> >
> > and tell us the "truth" here?
>
> Excellent idea...though it came with lots of typing :). Fixed.
>
> BTW, if I understand correctly, I've implemented the overflow types
> correctly for everything but multiplication (which we have no users for
> and I return OVF_UNKNOWN). I have indicated this in comments. Also,
> for division I did nothing special, as we can only +OVERFLOW.
>
> >
> > Hopefully if (overflow) will still work with that.
>
> It does.
>
> >
> > Otherwise can you please add a toplevel comment to wide-int.h as to what the
> > overflow result semantically is for a) SIGNED and b) UNSIGNED operations?
>
> Done. Let me know if the current comment is what you had in mind.
>
> OK for trunk?
I'd move accumulate_overflow to wi::, it looks generally useful. That function
misses to handle the !suboverflow && overflow case optimally.
I see that poly-int choses to accumulate overflow (callers need to
initialize it)
while wide_int chooses not to accumulate... to bad this is
inconsistent. Richard?
OK with the fix/move of accumulate_overflow.
Thanks,
Richard.
Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2
Thanks Richard. Some comments, and an updated proposed patch.
paul
> On Jul 6, 2018, at 9:04 AM, Richard Sandiford
> wrote:
>
> ...
>> @@ -8232,6 +8256,15 @@ functionality as two separate @code{define_insn} a
>> patterns. It exists for compactness, and as a maintenance tool to prevent
>> having to ensure the two patterns' templates match.
>>
>> +In @code{define_insn_and_split}, the output template is usually simply
>> +@samp{#} since the assembly output is done by @code{define_insn}
>> +statements matching the generated insns, not by this
>> +@code{define_insn_and_split} statement. But if @code{FAIL} is used in
>> +the preparation statements for certain input insns, those will not be
>> +split and during assembly output will again match this
>> +@code{define_insn_and_split}. In that case, the appropriate assembly
>> +output statements are needed in the output template.
>> +
>
> I agree "#" on its own is relatively common, but it's also not that
> unusual to have a define_insn_and_split in which the define_insn part
> handles simple alternatives directly and leaves more complex ones to
> be split. Maybe that's more common on RISC-like targets.
>
> Also, the define_split matches the template independently of the
> define_insn, so it can sometimes split insns that match an earlier
> define_insn rather than the one in the define_insn_and_split.
> (That might be bad practice.) So using "#" and FAIL together is valid
> if the FAIL only happens for cases that match earlier define_insns.
>
> Another case is when the define_split condition doesn't start with
> "&&" and is less strict than the define_insn condition. This can
> be useful if the define_split is supposed to match patterns created
> by combine.
>
> So maybe we should instead expand the FAIL documentation to say that
> a define_split must not FAIL when splitting an instruction whose
> output template is "#".
I played with this a bit and couldn't come up with a good wording. The case is
already covered; I was trying to make it clearer but your comments indicate the
picture is bigger than I thought.
>> @@ -8615,6 +8648,31 @@ so here's a silly made-up example:
>> "")
>> @end smallexample
>>
>> +There are two special macros defined for use in the preparation statements:
>> +@code{DONE} and @code{FAIL}. Use them with a following semicolon,
>> +as a statement.
>> +
>> +@table @code
>> +
>> +@findex DONE
>> +@item DONE
>> +Use the @code{DONE} macro to end RTL generation for the peephole. The
>> +only RTL insns generated as replacement for the matched input insn will
>> +be those already emitted by explicit calls to @code{emit_insn} within
>> +the preparation statements; the replacement pattern is not used.
>> +
>> +@findex FAIL
>> +@item FAIL
>> +Make the @code{define_peephole2} fail on this occasion. When a
>> @code{define_peephole2}
>> +fails, it means that the replacement was not truly available for the
>> +particular inputs it was given, and the input insns are left unchanged.
>
> If it FAILs, GCC will try to apply later define_peehole2s instead.
> (This is in contrast to define_split, so it's a bit inconsistent.
> Would be easy to make define_split behave the same way if there was a
> motivating case.)
Interesting. I added words to the FAIL description of both define_split and
define_peephole2 to state the behavior and highlight the difference.
ChangeLog:
2018-07-05 Paul Koning
* doc/md.texi (define_split): Document DONE and FAIL. Describe
interaction with usual "#" output template in
define_insn_and_split.
(define_peephole2): Document DONE and FAIL.
Index: doc/md.texi
===
--- doc/md.texi (revision 262455)
+++ doc/md.texi (working copy)
@@ -8060,6 +8060,30 @@ those in @code{define_expand}, however, these stat
generate any new pseudo-registers. Once reload has completed, they also
must not allocate any space in the stack frame.
+There are two special macros defined for use in the preparation statements:
+@code{DONE} and @code{FAIL}. Use them with a following semicolon,
+as a statement.
+
+@table @code
+
+@findex DONE
+@item DONE
+Use the @code{DONE} macro to end RTL generation for the splitter. The
+only RTL insns generated as replacement for the matched input insn will
+be those already emitted by explicit calls to @code{emit_insn} within
+the preparation statements; the replacement pattern is not used.
+
+@findex FAIL
+@item FAIL
+Make the @code{define_split} fail on this occasion. When a @code{define_split}
+fails, it means that the splitter was not truly available for the inputs
+it was given, and the input insn will not be split.
+@end table
+
+If the preparation falls through (invokes neither @code{DONE} nor
+@code{FAIL}), then the @code{define_split} uses the replacement
+template.
+
Patterns are matched against @var{insn-pattern} in two different
circumstances. If an insn needs to be split for d
Re: [PATCH] Fix sigsegv on -fdump-tree-all-enumerate_locals
On Fri, Jul 6, 2018 at 3:30 PM Tom de Vries wrote:
>
> Hi,
>
> this patch fixes a sigsegv when using -fdump-tree-all-enumerate_locals, by
> handling cfun->cfg == NULL conservatively in dump_enumerated_decls.
>
> OK for trunk?
Ok for the tree-dfa.c part.
Richard.
> Thanks,
> - Tom
>
> Fix sigsegv on -fdump-tree-all-enumerate_locals
>
> 2018-07-06 Tom de Vries
>
> * tree-dfa.c (dump_enumerated_decls): Handle cfun->cfg == NULL.
>
> * gcc.misc-tests/options.exp (check_for_all_options): Clean up dump
> files.
> (get_dump_flags): New proc.
> (toplevel): Test all dump flags.
>
> ---
> gcc/testsuite/gcc.misc-tests/options.exp | 38
>
> gcc/tree-dfa.c | 3 +++
> 2 files changed, 41 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.misc-tests/options.exp
> b/gcc/testsuite/gcc.misc-tests/options.exp
> index 693b40df1fd..faeae705c08 100644
> --- a/gcc/testsuite/gcc.misc-tests/options.exp
> +++ b/gcc/testsuite/gcc.misc-tests/options.exp
> @@ -52,6 +52,10 @@ proc check_for_all_options {language gcc_options
> compiler_pattern as_pattern ld_
> }
> set gcc_output [gcc_target_compile $filename.c $filename.x executable
> $gcc_options]
> remote_file build delete $filename.c $filename.x $filename.gcno
> +set dumpfiles [glob -nocomplain $filename.c.*]
> +foreach dumpfile $dumpfiles {
> + remote_file build delete $dumpfile
> +}
>
> if {![regexp -- "/${compiler}(\\.exe)? -quiet.*$compiler_pattern"
> $gcc_output]} {
> fail "$test (compiler options)"
> @@ -70,4 +74,38 @@ proc check_for_all_options {language gcc_options
> compiler_pattern as_pattern ld_
>
> check_for_all_options c {--coverage} {-fprofile-arcs -ftest-coverage} {}
> {-lgcov}
>
> +proc get_dump_flags {} {
> +set res [list]
> +
> +global srcdir
> +set file "$srcdir/../dumpfile.c"
> +
> +set a [open $file]
> +set lines [split [read $a] "\n"]
> +close $a
> +
> +set domatch 0
> +foreach line $lines {
> + if { [regexp "dump_options.* =" $line] } {
> + set domatch 1
> + } elseif { [regexp "^\};" $line] } {
> + set domatch 0
> + }
> + if { $domatch } {
> + if { [regexp "\"(.*)\"" $line match submatch] } {
> + lappend res $submatch
> + }
> + }
> +}
> +
> +return $res
> +}
> +
> +foreach flag [get_dump_flags] {
> +check_for_all_options c -fdump-tree-all-$flag {} {} {}
> +check_for_all_options c -fdump-ipa-all-$flag {} {} {}
> +check_for_all_options c -fdump-rtl-all-$flag {} {} {}
> +check_for_all_options c -fdump-lang-all-$flag {} {} {}
> +}
> +
> gcc_parallel_test_enable 1
> diff --git a/gcc/tree-dfa.c b/gcc/tree-dfa.c
> index 00aa75f47ab..ee2ff2958db 100644
> --- a/gcc/tree-dfa.c
> +++ b/gcc/tree-dfa.c
> @@ -992,6 +992,9 @@ dump_enumerated_decls_push (tree *tp, int *walk_subtrees,
> void *data)
> void
> dump_enumerated_decls (FILE *file, dump_flags_t flags)
> {
> + if (!cfun->cfg)
> +return;
> +
>basic_block bb;
>struct walk_stmt_info wi;
>auto_vec decl_list;
Re: [PATCH][debug] Handle references to skipped params in remap_ssa_name
On Fri, Jul 6, 2018 at 12:47 PM Tom de Vries wrote:
>
> On 07/05/2018 01:39 PM, Richard Biener wrote:
> > On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries wrote:
> >>
> >> [ was: Re: [testsuite/guality, committed] Prevent optimization of local in
> >> vla-1.c ]
> >>
> >> On Wed, Jul 04, 2018 at 02:32:27PM +0200, Tom de Vries wrote:
> >>> On 07/03/2018 11:05 AM, Tom de Vries wrote:
> On 07/02/2018 10:16 AM, Jakub Jelinek wrote:
> > On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
>
>
>
> >> [debug] Handle references to skipped params in remap_ssa_name
> >>
> >> 2018-07-05 Tom de Vries
> >>
> >> * tree-inline.c (remap_ssa_name): Handle references to skipped
> >> params.
> >>
> >> ---
> >> gcc/tree-inline.c | 17 +++--
> >> 1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> >> index 427ef959740..0fa996cab49 100644
> >> --- a/gcc/tree-inline.c
> >> +++ b/gcc/tree-inline.c
> >> @@ -204,11 +204,22 @@ remap_ssa_name (tree name, copy_body_data *id)
> >> gimple *def_temp;
> >> gimple_stmt_iterator gsi;
> >> tree val = SSA_NAME_VAR (name);
> >> + bool skipped_parm_decl = false;
> >>
> >> n = id->decl_map->get (val);
> >> if (n != NULL)
> >> - val = *n;
> >> - if (TREE_CODE (val) != PARM_DECL)
> >> + {
> >> + if (TREE_CODE (*n) == DEBUG_EXPR_DECL)
> >> + return *n;
> >> +
> >> + if (TREE_CODE (*n) == VAR_DECL
> >> + && DECL_ABSTRACT_ORIGIN (*n)
> >> + && TREE_CODE (DECL_ABSTRACT_ORIGIN (*n)) == PARM_DECL)
> >> + skipped_parm_decl = true;
> >> + else
> >> + val = *n;
> >> + }
> >> + if (TREE_CODE (val) != PARM_DECL && !skipped_parm_decl)
> >
> > I wonder if this cannot be more easily set up in
> > copy_arguments_for_versioning
> > which already does
> >
> > else if (!id->decl_map->get (arg))
> > {
> > /* Make an equivalent VAR_DECL. If the argument was used
> >as temporary variable later in function, the uses will be
> >replaced by local variable. */
> > tree var = copy_decl_to_var (arg, id);
> > insert_decl_map (id, arg, var);
> > /* Declare this new variable. */
> > DECL_CHAIN (var) = *vars;
> > *vars = var;
> > }
> >
> > which just misses to re-map the default def of the PARM_DECL (in case it
> > exists)
> > to the same(?) var?
>
> I've updated the patch to add a debug expr here in
> copy_arguments_for_versioning for every parameter that has a default
> def, and to use that debug expr in remap_ssa_name.
>
> > All remaining uses should be in debug stmts (I hope).
>
> I ran into a test-case where that was not the case, so I had to handle
> that in remap_ssa_name, the comment in the patch describes that in more
> detail.
I see.
I now also spotted the code in remap_ssa_name that is supposed to handle
this it seems and for the testcase we only give up because the PARM_DECL is
remapped to a VAR_DECL. So I suppose it is to be handled via the
debug-args stuff
which probably lacks in the area of versioning.
Your patch feels like it adds stuff ontop of existing mechanisms that
should "just work"
with the correct setup at the correct places...
Jakub, can you shed any light on how this is supposed to work?
Looking at rev. 175288
it's not entirely clear to me?
Richard.
> Bootstrapped and reg-tested on x86_64.
>
> OK for trunk?
>
> Thanks,
> - Tom
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
On Fri, Jul 06, 2018 at 09:46:36AM -0400, Michael Meissner wrote:
> On Fri, Jul 06, 2018 at 10:16:34AM -0300, Tulio Magno Quites Machado Filho
> wrote:
> > I suggest to test with the following program:
> >
> > #include
> >
> > int
> > main ()
> > {
> > return !isinfl(__builtin_infl());
> > }
> >
> > Build it with:
> > gcc -mabi=ieeelongdouble -fno-builtin -Wno-psabi -lm test-ldbl.c
> >
> > If the execution of the program returns 0, your math library supports IEEE
> > long
> > double.
>
> Thanks, but I suspect that it won't work for building cross compilers or for
> building where the compiler built uses the Advance Toolchain libraries and
> shared library loader instead of the system versions using the configuration
> option --with-advance-toolchain=atx.y.
>
> The issue is you need to test whether the target GLIBC has the support when
> configuring the compiler, but if you are building for a cross target, you
> can't
> run the resulting binary. Even on a native system, with options like
> --with-advance-toolchain and --with-sysroot, the libraries used by the host
> compiler used to build stage1 of GCC might be different from the libraries
> used
> to build the target compiler (or stage2/stage3 in a bootstrap native build).
>
> So I used the GLIBC version tests that were already part of the GCC
> configuration.
>
> If there is a simple method that works for cross compilers or where a
> specified
> sysroot is used, it would be simpler than having version checks.
Version checks are terrible. This is nothing new.
For cross builds you can just assume it works. That should work fine here.
For cross builds the burden of having compatible versions of everything is
on the user anyhow (I'm not saying this is a good thing, but this is the
status quo).
Maybe some test could be done that mimics what happens 10m into a build
(the build failure)? But Tulio's test should be okay for most cases, too.
Segher
[PATCH] PR libstdc++/84928 use std::move in algorithms
P0616R0 altered the effects of the algorithms to use std::move
on the accumulator values (resolving LWG 2055). This implements the
change for C++2a, but retains the previous behaviour for older
standards.
* include/bits/stl_numeric.h (_GLIBCXX_MOVE_IF_20): Define macro to
conditionally move, according to __cplusplus value.
(accumulate, inner_product, partial_sum, adjacent_difference): Use
_GLIBCXX_MOVE_IF_20.
* testsuite/26_numerics/accumulate/lwg2055.cc: New test.
* testsuite/26_numerics/adjacent_difference/lwg2055.cc: New test.
* testsuite/26_numerics/inner_product/lwg2055.cc: New test.
* testsuite/26_numerics/partial_sum/lwg2055.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit 1a98726ac77827d3978d694f33ef5183ff3c2def
Author: Jonathan Wakely
Date: Fri Jul 6 14:58:03 2018 +0100
PR libstdc++/84928 use std::move in algorithms
P0616R0 altered the effects of the algorithms to use std::move
on the accumulator values (resolving LWG 2055). This implements the
change for C++2a, but retains the previous behaviour for older
standards.
* include/bits/stl_numeric.h (_GLIBCXX_MOVE_IF_20): Define macro to
conditionally move, according to __cplusplus value.
(accumulate, inner_product, partial_sum, adjacent_difference): Use
_GLIBCXX_MOVE_IF_20.
* testsuite/26_numerics/accumulate/lwg2055.cc: New test.
* testsuite/26_numerics/adjacent_difference/lwg2055.cc: New test.
* testsuite/26_numerics/inner_product/lwg2055.cc: New test.
* testsuite/26_numerics/partial_sum/lwg2055.cc: New test.
diff --git a/libstdc++-v3/include/bits/stl_numeric.h
b/libstdc++-v3/include/bits/stl_numeric.h
index dcc29fe065c..f4f6f9ef5ae 100644
--- a/libstdc++-v3/include/bits/stl_numeric.h
+++ b/libstdc++-v3/include/bits/stl_numeric.h
@@ -104,6 +104,14 @@ namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_ALGO
+#if __cplusplus > 201703L
+// _GLIBCXX_RESOLVE_LIB_DEFECTS
+// DR 2055. std::move in std::accumulate and other algorithms
+# define _GLIBCXX_MOVE_IF_20(_E) std::move(_E)
+#else
+# define _GLIBCXX_MOVE_IF_20(_E) _E
+#endif
+
/**
* @brief Accumulate values in a range.
*
@@ -124,7 +132,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
__glibcxx_requires_valid_range(__first, __last);
for (; __first != __last; ++__first)
- __init = __init + *__first;
+ __init = _GLIBCXX_MOVE_IF_20(__init) + *__first;
return __init;
}
@@ -151,7 +159,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
__glibcxx_requires_valid_range(__first, __last);
for (; __first != __last; ++__first)
- __init = __binary_op(__init, *__first);
+ __init = __binary_op(_GLIBCXX_MOVE_IF_20(__init), *__first);
return __init;
}
@@ -180,7 +188,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
__glibcxx_requires_valid_range(__first1, __last1);
for (; __first1 != __last1; ++__first1, (void)++__first2)
- __init = __init + (*__first1 * *__first2);
+ __init = _GLIBCXX_MOVE_IF_20(__init) + (*__first1 * *__first2);
return __init;
}
@@ -214,7 +222,8 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
__glibcxx_requires_valid_range(__first1, __last1);
for (; __first1 != __last1; ++__first1, (void)++__first2)
- __init = __binary_op1(__init, __binary_op2(*__first1, *__first2));
+ __init = __binary_op1(_GLIBCXX_MOVE_IF_20(__init),
+ __binary_op2(*__first1, *__first2));
return __init;
}
@@ -251,7 +260,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
*__result = __value;
while (++__first != __last)
{
- __value = __value + *__first;
+ __value = _GLIBCXX_MOVE_IF_20(__value) + *__first;
*++__result = __value;
}
return ++__result;
@@ -292,7 +301,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
*__result = __value;
while (++__first != __last)
{
- __value = __binary_op(__value, *__first);
+ __value = __binary_op(_GLIBCXX_MOVE_IF_20(__value), *__first);
*++__result = __value;
}
return ++__result;
@@ -332,7 +341,7 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
while (++__first != __last)
{
_ValueType __tmp = *__first;
- *++__result = __tmp - __value;
+ *++__result = __tmp - _GLIBCXX_MOVE_IF_20(__value);
__value = _GLIBCXX_MOVE(__tmp);
}
return ++__result;
@@ -375,12 +384,14 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
while (++__first != __last)
{
_ValueType __tmp = *__first;
- *++__result = __binary_op(__tmp, __value);
+ *++__result = __binary_op(__tmp, _GLIBCXX_MOVE_IF_20(__value));
__value = _GLIBCXX_MOVE(__tmp);
}
return ++__result;
}
+#undef _GLIBCXX_MOVE_IF_20
+
_GLIBCXX_END_NAMESPACE_ALGO
} // namespace std
diff --git
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
On Fri, Jul 06, 2018 at 09:38:02AM -0400, Michael Meissner wrote: > On Fri, Jul 06, 2018 at 06:38:55AM -0500, Segher Boessenkool wrote: > > On Fri, Jul 06, 2018 at 01:51:37AM -0400, Michael Meissner wrote: > > > case "$target:$with_long_double_format" in > > > > > - xpowerpc64*-*-linux*:*) > > > > So this case could never happen. The changelog should mention it fixes > > that bug (and having it as a separate patch is much preferred!) > > I assume what happened is I accidently added the 'x' to the working copy after > submitting the patch, but before committing it and I didn't notice it. Since > it is in configuration support, it isn't part of the test sutie, and it wasn't > noticed. > > I can add a line to the ChangeLog if desired. > > > Other than this thing, the original code was easier to read. What does > > this part of the patch improve? > > You complained that you were getting errors when using the system glibc (based > on 2.27 on an Ubuntu system) and using --with-long-double-format=ieee (where > it > would die in the middle of building libstdc++-v3). No, _this part_ of the patch. The part that doesn't change behaviour (but see above): * configure.ac (powerpc64*-*-linux*): Combine big and little endian checks for the long double format. I asked Tulio to comment on if this is a good way to detect usable glibc versions for default ieee long double. I haven't reviewed that part of your patch yet. Segher
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
On Fri, Jul 06, 2018 at 10:16:34AM -0300, Tulio Magno Quites Machado Filho
wrote:
> I suggest to test with the following program:
>
> #include
>
> int
> main ()
> {
> return !isinfl(__builtin_infl());
> }
>
> Build it with:
> gcc -mabi=ieeelongdouble -fno-builtin -Wno-psabi -lm test-ldbl.c
>
> If the execution of the program returns 0, your math library supports IEEE
> long
> double.
Thanks, but I suspect that it won't work for building cross compilers or for
building where the compiler built uses the Advance Toolchain libraries and
shared library loader instead of the system versions using the configuration
option --with-advance-toolchain=atx.y.
The issue is you need to test whether the target GLIBC has the support when
configuring the compiler, but if you are building for a cross target, you can't
run the resulting binary. Even on a native system, with options like
--with-advance-toolchain and --with-sysroot, the libraries used by the host
compiler used to build stage1 of GCC might be different from the libraries used
to build the target compiler (or stage2/stage3 in a bootstrap native build).
So I used the GLIBC version tests that were already part of the GCC
configuration.
If there is a simple method that works for cross compilers or where a specified
sysroot is used, it would be simpler than having version checks.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
On Fri, Jul 06, 2018 at 06:38:55AM -0500, Segher Boessenkool wrote: > On Fri, Jul 06, 2018 at 01:51:37AM -0400, Michael Meissner wrote: > > case "$target:$with_long_double_format" in > > > - xpowerpc64*-*-linux*:*) > > So this case could never happen. The changelog should mention it fixes > that bug (and having it as a separate patch is much preferred!) I assume what happened is I accidently added the 'x' to the working copy after submitting the patch, but before committing it and I didn't notice it. Since it is in configuration support, it isn't part of the test sutie, and it wasn't noticed. I can add a line to the ChangeLog if desired. > Other than this thing, the original code was easier to read. What does > this part of the patch improve? You complained that you were getting errors when using the system glibc (based on 2.27 on an Ubuntu system) and using --with-long-double-format=ieee (where it would die in the middle of building libstdc++-v3). I wrote the patch to check that the glibc has the support so it fails when configuring the compiler and gives a sensible message (need glibc 2.28). But it doesn't really change anything. If you have an appropriate glibc, it will build without the patch, and if you don't, it will fail. But it should be friendlier to people building the compiler to understand why it failed. I could duplicate the tests for glibc 2.28 (and AT-next alpha) for big endian and little endian if desired, but it seemed clearer to me to combine the code rather than duplicate the tests. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
[PATCH] Fix sigsegv on -fdump-tree-all-enumerate_locals
Hi,
this patch fixes a sigsegv when using -fdump-tree-all-enumerate_locals, by
handling cfun->cfg == NULL conservatively in dump_enumerated_decls.
OK for trunk?
Thanks,
- Tom
Fix sigsegv on -fdump-tree-all-enumerate_locals
2018-07-06 Tom de Vries
* tree-dfa.c (dump_enumerated_decls): Handle cfun->cfg == NULL.
* gcc.misc-tests/options.exp (check_for_all_options): Clean up dump
files.
(get_dump_flags): New proc.
(toplevel): Test all dump flags.
---
gcc/testsuite/gcc.misc-tests/options.exp | 38
gcc/tree-dfa.c | 3 +++
2 files changed, 41 insertions(+)
diff --git a/gcc/testsuite/gcc.misc-tests/options.exp
b/gcc/testsuite/gcc.misc-tests/options.exp
index 693b40df1fd..faeae705c08 100644
--- a/gcc/testsuite/gcc.misc-tests/options.exp
+++ b/gcc/testsuite/gcc.misc-tests/options.exp
@@ -52,6 +52,10 @@ proc check_for_all_options {language gcc_options
compiler_pattern as_pattern ld_
}
set gcc_output [gcc_target_compile $filename.c $filename.x executable
$gcc_options]
remote_file build delete $filename.c $filename.x $filename.gcno
+set dumpfiles [glob -nocomplain $filename.c.*]
+foreach dumpfile $dumpfiles {
+ remote_file build delete $dumpfile
+}
if {![regexp -- "/${compiler}(\\.exe)? -quiet.*$compiler_pattern"
$gcc_output]} {
fail "$test (compiler options)"
@@ -70,4 +74,38 @@ proc check_for_all_options {language gcc_options
compiler_pattern as_pattern ld_
check_for_all_options c {--coverage} {-fprofile-arcs -ftest-coverage} {}
{-lgcov}
+proc get_dump_flags {} {
+set res [list]
+
+global srcdir
+set file "$srcdir/../dumpfile.c"
+
+set a [open $file]
+set lines [split [read $a] "\n"]
+close $a
+
+set domatch 0
+foreach line $lines {
+ if { [regexp "dump_options.* =" $line] } {
+ set domatch 1
+ } elseif { [regexp "^\};" $line] } {
+ set domatch 0
+ }
+ if { $domatch } {
+ if { [regexp "\"(.*)\"" $line match submatch] } {
+ lappend res $submatch
+ }
+ }
+}
+
+return $res
+}
+
+foreach flag [get_dump_flags] {
+check_for_all_options c -fdump-tree-all-$flag {} {} {}
+check_for_all_options c -fdump-ipa-all-$flag {} {} {}
+check_for_all_options c -fdump-rtl-all-$flag {} {} {}
+check_for_all_options c -fdump-lang-all-$flag {} {} {}
+}
+
gcc_parallel_test_enable 1
diff --git a/gcc/tree-dfa.c b/gcc/tree-dfa.c
index 00aa75f47ab..ee2ff2958db 100644
--- a/gcc/tree-dfa.c
+++ b/gcc/tree-dfa.c
@@ -992,6 +992,9 @@ dump_enumerated_decls_push (tree *tp, int *walk_subtrees,
void *data)
void
dump_enumerated_decls (FILE *file, dump_flags_t flags)
{
+ if (!cfun->cfg)
+return;
+
basic_block bb;
struct walk_stmt_info wi;
auto_vec decl_list;
RE: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian
Hi Christoph,
> 90d62e699bce9594879be2e3016c9b36c7e064c8..703632240822e762a90657096
> > >> 4b949c783df56f3 100644
> > >> --- a/gcc/config/arm/arm.c
> > >> +++ b/gcc/config/arm/arm.c
> > >> @@ -31508,8 +31508,8 @@ arm_can_change_mode_class
> (machine_mode from, machine_mode to,
> > >>{
> > >> if (TARGET_BIG_END
> > >> && !(GET_MODE_SIZE (from) == 16 && GET_MODE_SIZE (to) == 8)
> > >> - && (GET_MODE_SIZE (from) > UNITS_PER_WORD
> > >> - || GET_MODE_SIZE (to) > UNITS_PER_WORD)
> > >> + && (GET_MODE_UNIT_SIZE (from) > UNITS_PER_WORD
> > >> + || GET_MODE_UNIT_SIZE (to) > UNITS_PER_WORD)
> > >>
>
> After this commit (r262436), I have noticed regressions on armeb-none-linux-
> gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16
> FAIL: gcc.dg/vect/vect-nop-move.c execution test
> FAIL: g++.dg/torture/vshuf-v2si.C -O3 -g execution test
> FAIL: g++.dg/torture/vshuf-v4si.C -O3 -g execution test
> FAIL: g++.dg/torture/vshuf-v8hi.C -O3 -g execution test
>
> Can you have a look?
Sorry! I know you reported these before so I did explicitly test them, but it
turns
out a configuration issue in our scripts was causing armeb linux builds to skip
execution tests. So the execution parts of these tests never showed up and so
the
regression was clean.
I know what's wrong and will submit a patch soon.
Thanks,
Tamar
>
> > >> Does GET_MODE_UNIT_SIZE do what you want? Its documentation in
> rtl.texi says:
> > >> "Returns the size in bytes of the subunits of a datum of mode @var{m}.
> > >>This is the same as @code{GET_MODE_SIZE} except in the case of
> complex
> > >>modes. For them, the unit size is the size of the real or imaginary
> > >>part."
> > >>
> > >> Does it also do the right thing for vector modes (GET_MODE_SIZE
> (GET_MODE_INNER (mode))) ?
> > >> If so, this patch is ok, but we'll need to update the documentation to
> make it more explicit.
> > > I don't know what the documentation is trying to say here, but the key is
> the first part:
> > >
> > > "returns the size in bytes of the subunits of a datum of mode m"
> > >
> > > MODE: V4SI, GET_MODE_UNIT_SIZE: 4, GET_MODE_SIZE: 16
> > >
> > > So GET_MODE_UNIT_SIZE (m) * GET_MODE_NUNITS(m) ==
> GET_MODE_SIZE (m)
> > >
> > > or GET_MODE_UNIT_SIZE (m) == GET_MODE_SIZE (GET_MODE_INNER
> (mode)).
> > >
> > > From this the only time GET_MODE_UNIT_SIZE is equal to
> > > GET_MODE_SIZE is on non-vector modes of V1 vector modes.
> >
> > Right, this is what I thought, but the documentation is not as clear as it
> could be.
> > Your patch is ok for trunk.
> >
> > Thanks,
> > Kyrill
> >
> > > Kind Regards,
> > > Tamar
> > >
> > >> Thanks for the patch,
> > >> Kyrill
> > >>
> > >>
> > >>
> >
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
Michael Meissner writes:
> This patch adds a simple check of whether the GLIBC should be capable of
> switching the long double format on the PowerPC to IEEE 128-bit floating
> point.
> At the moment, library work is not yet finished, but I'm assuming that the
> patches will be in place when GLIBC 2.28 is released. If it turns out that
> the
> finished support does not make it until 2.29, we can adjust the patch later.
>
> Right now, if you use standard GLIBC 2.27 or earlier (ignoring the bits that
> actually use long double that will need to be handled), you will not be able
> to
> build libstdc++-v3 when long double is configured to be IEEE 128-bit due to
> errors with overloaded functions like issignalling (where both __float128 and
> long double versions are defined). The GLIBC team has a fix for this, and it
> should appear in 2.28.
>
> This patch checks whether the GLIBC version is 2.28 before allowing you to
> switch the long double type. Because the work to prepare GLIBC for the switch
> is being done using an Advance Toolchain framework, the patch allows an
> Advance
> Toolchain 2.27 with the --with-advance-toolchain configuration option (the
> official AT 11 release uses GLIBC 2.26 as a framework, and when completed the
> AT 12 release should use GLIBC 2.28).
>
> I have checked it on a little endian power8 system, building both toolchains
> using IBM long double and IEEE long double configurations. The tests that
> depend on the library support for long double that failed before still fail.
>
> I also did IEEE long double builds using the host GLIBC and that AT 11, and
> verified that once GCC is configured it generates an error. I built bootstrap
> compilers on a big endian system, and verified if I selected IEEE long double,
> it would fail, since I currently don't have a big endian GLIBC with the fixes
> installed.
>
> Can I check this in the trunk at on the GCC 8 branch?
>
> 2018-07-05 Michael Meissner
>
> * configure.ac (powerpc64*-*-linux*): Combine big and little
> endian checks for the long double format. Add checks to make sure
> the GLIBC can handle configuration of long double to be IEEE
> 128-bit before building GCC.
> * configure: Regenerate.
>
> --
> Michael Meissner, IBM
> IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
> email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
> [ ieee128-patch129b: text/plain ]
> Index: gcc/configure.ac
> ===
> --- gcc/configure.ac (revision 262443)
> +++ gcc/configure.ac (working copy)
> @@ -6031,23 +6031,48 @@ AC_ARG_WITH([long-double-format],
>[AS_HELP_STRING([--with-long-double-format={ieee,ibm}]
> [Specify whether PowerPC long double uses IEEE or IBM
> format])],[
> case "$target:$with_long_double_format" in
> - powerpc64le-*-linux*:ieee | powerpc64le-*-linux*:ibm)
> -:
> -;;
> - powerpc64-*-linux*:ieee | powerpc64-*-linux*:ibm)
> -# IEEE 128-bit emulation is only built on 64-bit VSX Linux systems
> -case "$with_cpu" in
> - power7 | power8 | power9 | power1*)
> + powerpc64le-*-linux*:ibm | powerpc64-*-linux*:ibm | \
> + powerpc64le-*-linux*:ieee | powerpc64-*-linux*:ieee)
> +# IEEE 128-bit emulation is only built on 64-bit VSX Linux systems.
> +# Little endian 64-bit systems are always VSX, but big endian systems
> +# might default to power4.
> +case "$target:$with_cpu" in
> + powerpc64le-* | *:power7 | *:power8 | *:power9 | *:power1*)
> :
> ;;
>*)
> AC_MSG_ERROR([Configuration option --with-long-double-format is only \
> supported if the default cpu is power7 or newer])
> with_long_double_format=""
> - ;;
> - esac
> - ;;
> - xpowerpc64*-*-linux*:*)
> +esac
> +
> +if test "x$with_long_double_format" = xieee; then
> + # See if we have a new enough GLIBC to allow using IEEE 128-bit long
> + # double. We assume the public 2.28 GLIBC and the development version
> of
> + # the Advance Toolchain (2.27) have all of the missing bits.
> + ieee_minor="28"
> + glibc_ieee="no"
> + atoolchain=""
> + if test "x$with_advance_toolchain" != x \
> + -a -d "/opt/$with_advance_toolchain/." \
> + -a -d "/opt/$with_advance_toolchain/bin/." \
> + -a -d "/opt/$with_advance_toolchain/include/."; then
> +
> + ieee_minor="27"
These minor versions are confusing and shouldn't differ between the Advance
Toolchain and glibc.
I suggest to test with the following program:
#include
int
main ()
{
return !isinfl(__builtin_infl());
}
Build it with:
gcc -mabi=ieeelongdouble -fno-builtin -Wno-psabi -lm test-ldbl.c
If the execution of the program returns 0, your math library supports IEEE long
double.
--
Tulio Magno
Re: [PATCH] doc clarification: DONE and FAIL in define_split and define_peephole2
Paul Koning writes:
> Currently DONE and FAIL are documented only for define_expand, but
> they also work in essentially the same way for define_split and
> define_peephole2.
>
> If FAIL is used in a define_insn_and_split, the output pattern cannot
> be the usual "#" dummy value.
>
> This patch updates the doc to describe those cases. Ok for trunk?
>
> paul
>
> ChangeLog:
>
> 2018-07-05 Paul Koning
>
> * doc/md.texi (define_split): Document DONE and FAIL. Describe
> interaction with usual "#" output template in
> define_insn_and_split.
> (define_peephole2): Document DONE and FAIL.
>
> Index: doc/md.texi
> ===
> --- doc/md.texi (revision 262455)
> +++ doc/md.texi (working copy)
> @@ -8060,6 +8060,30 @@ those in @code{define_expand}, however, these stat
> generate any new pseudo-registers. Once reload has completed, they also
> must not allocate any space in the stack frame.
>
> +There are two special macros defined for use in the preparation statements:
> +@code{DONE} and @code{FAIL}. Use them with a following semicolon,
> +as a statement.
> +
> +@table @code
> +
> +@findex DONE
> +@item DONE
> +Use the @code{DONE} macro to end RTL generation for the splitter. The
> +only RTL insns generated as replacement for the matched input insn will
> +be those already emitted by explicit calls to @code{emit_insn} within
> +the preparation statements; the replacement pattern is not used.
> +
> +@findex FAIL
> +@item FAIL
> +Make the @code{define_split} fail on this occasion. When a
> @code{define_split}
> +fails, it means that the splitter was not truly available for the inputs
> +it was given, and this split is not done.
> +@end table
> +
> +If the preparation falls through (invokes neither @code{DONE} nor
> +@code{FAIL}), then the @code{define_split} uses the replacement
> +template.
> +
> Patterns are matched against @var{insn-pattern} in two different
> circumstances. If an insn needs to be split for delay slot scheduling
> or insn scheduling, the insn is already known to be valid, which means
Looks good.
> @@ -8232,6 +8256,15 @@ functionality as two separate @code{define_insn} a
> patterns. It exists for compactness, and as a maintenance tool to prevent
> having to ensure the two patterns' templates match.
>
> +In @code{define_insn_and_split}, the output template is usually simply
> +@samp{#} since the assembly output is done by @code{define_insn}
> +statements matching the generated insns, not by this
> +@code{define_insn_and_split} statement. But if @code{FAIL} is used in
> +the preparation statements for certain input insns, those will not be
> +split and during assembly output will again match this
> +@code{define_insn_and_split}. In that case, the appropriate assembly
> +output statements are needed in the output template.
> +
I agree "#" on its own is relatively common, but it's also not that
unusual to have a define_insn_and_split in which the define_insn part
handles simple alternatives directly and leaves more complex ones to
be split. Maybe that's more common on RISC-like targets.
Also, the define_split matches the template independently of the
define_insn, so it can sometimes split insns that match an earlier
define_insn rather than the one in the define_insn_and_split.
(That might be bad practice.) So using "#" and FAIL together is valid
if the FAIL only happens for cases that match earlier define_insns.
Another case is when the define_split condition doesn't start with
"&&" and is less strict than the define_insn condition. This can
be useful if the define_split is supposed to match patterns created
by combine.
So maybe we should instead expand the FAIL documentation to say that
a define_split must not FAIL when splitting an instruction whose
output template is "#".
> @@ -8615,6 +8648,31 @@ so here's a silly made-up example:
>"")
> @end smallexample
>
> +There are two special macros defined for use in the preparation statements:
> +@code{DONE} and @code{FAIL}. Use them with a following semicolon,
> +as a statement.
> +
> +@table @code
> +
> +@findex DONE
> +@item DONE
> +Use the @code{DONE} macro to end RTL generation for the peephole. The
> +only RTL insns generated as replacement for the matched input insn will
> +be those already emitted by explicit calls to @code{emit_insn} within
> +the preparation statements; the replacement pattern is not used.
> +
> +@findex FAIL
> +@item FAIL
> +Make the @code{define_peephole2} fail on this occasion. When a
> @code{define_peephole2}
> +fails, it means that the replacement was not truly available for the
> +particular inputs it was given, and the input insns are left unchanged.
If it FAILs, GCC will try to apply later define_peehole2s instead.
(This is in contrast to define_split, so it's a bit inconsistent.
Would be easy to make define_split behave the same way if there was a
motivating case.)
Thanks,
Richa
[PATCH] Simplify linker script patterns for std::exception_ptr
* config/abi/pre/gnu.ver: Use wildcards to combine related patterns.
Tested x86_64-linux and powerpc64le-linux, committed to trunk.
commit 6ae49a85e8e83390225aae7dbbe01518005cf34f
Author: Jonathan Wakely
Date: Fri Jul 6 13:40:00 2018 +0100
Simplify linker script patterns for std::exception_ptr
* config/abi/pre/gnu.ver: Use wildcards to combine related patterns.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
b/libstdc++-v3/config/abi/pre/gnu.ver
index e634d3ab707..b09bdef6d09 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2174,14 +2174,10 @@ CXXABI_1.3.3 {
#ifdef HAVE_EXCEPTION_PTR_SINCE_GCC46
# exception_ptr
-_ZNSt15__exception_ptr13exception_ptrC1Ev;
-_ZNSt15__exception_ptr13exception_ptrC2Ev;
-_ZNSt15__exception_ptr13exception_ptrC1ERKS0_;
-_ZNSt15__exception_ptr13exception_ptrC2ERKS0_;
-_ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE;
-_ZNSt15__exception_ptr13exception_ptrC2EMS0_FvvE;
-_ZNSt15__exception_ptr13exception_ptrD1Ev;
-_ZNSt15__exception_ptr13exception_ptrD2Ev;
+_ZNSt15__exception_ptr13exception_ptrC[12]Ev;
+_ZNSt15__exception_ptr13exception_ptrC[12]ERKS0_;
+_ZNSt15__exception_ptr13exception_ptrC[12]EMS0_FvvE;
+_ZNSt15__exception_ptr13exception_ptrD[12]Ev;
_ZNSt15__exception_ptr13exception_ptraSERKS0_;
_ZNKSt15__exception_ptr13exception_ptrcvMS0_FvvEEv;
_ZNKSt15__exception_ptr13exception_ptrntEv;
[PATCH] P0935R0 Eradicating unnecessarily explicit default constructors
This is the last remaining piece of P0935R0. This adds a default
constructor to each of the streambuf and stream types in so
that default construction does not use the 'explicit' constructor that
has a single, defaulted argument.
P0935R0 Eradicating unnecessarily explicit default constructors
* config/abi/pre/gnu.ver: Tighten existing patterns and export new
default constructor symbols.
* include/std/sstream (basic_stringbuf, basic_istringstream)
(basic_ostringstream, basic_stringstream): Remove default arguments
from explicit constructors taking ios_base::openmode and add separate
non-explicit default constructors.
* testsuite/27_io/basic_istringstream/cons/default.cc: New.
* testsuite/27_io/basic_ostringstream/cons/default.cc: New.
* testsuite/27_io/basic_stringstream/cons/default.cc: New.
* testsuite/27_io/basic_stringbuf/cons/char/default.cc: New.
* testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc: New.
Tested powerpc64le-linux, committed to trunk.
commit 650035269ded698f16e66fa04f8d21dcb1b94fa8
Author: Jonathan Wakely
Date: Fri Jul 6 11:38:57 2018 +0100
P0935R0 Eradicating unnecessarily explicit default constructors
This is the last remaining piece of P0935R0. This adds a default
constructor to each of the streambuf and stream types in so
that default construction does not use the 'explicit' constructor that
has a single, defaulted argument.
P0935R0 Eradicating unnecessarily explicit default constructors
* config/abi/pre/gnu.ver: Tighten existing patterns and export new
default constructor symbols.
* include/std/sstream (basic_stringbuf, basic_istringstream)
(basic_ostringstream, basic_stringstream): Remove default arguments
from explicit constructors taking ios_base::openmode and add
separate
non-explicit default constructors.
* testsuite/27_io/basic_istringstream/cons/default.cc: New.
* testsuite/27_io/basic_ostringstream/cons/default.cc: New.
* testsuite/27_io/basic_stringstream/cons/default.cc: New.
* testsuite/27_io/basic_stringbuf/cons/char/default.cc: New.
* testsuite/27_io/basic_stringbuf/cons/wchar_t/default.cc: New.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver
b/libstdc++-v3/config/abi/pre/gnu.ver
index 521cebf1f80..e634d3ab707 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1748,10 +1748,20 @@ GLIBCXX_3.4.21 {
_ZStplI[cw]St11char_traitsI[cw]ESaI[cw]EENSt7__cxx1112basic_stringIT_T0_T1_EE*;
# ABI-tagged stringstreams
-_ZNSt7__cxx1115basic_stringbuf*;
-_ZNSt7__cxx1118basic_stringstream*;
-_ZNSt7__cxx1119basic_istringstream*;
-_ZNSt7__cxx1119basic_ostringstream*;
+# _ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]*;
+
_ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]E[ORS]*;
+_ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EED[012]Ev;
+_ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]*__xfer_bufptrs*;
+
_ZNSt7__cxx1115basic_stringbufI[cw]St11char_traitsI[cw]ESaI[cw]EE[a1346789]*;
+# _ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]*;
+
_ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]E[ORS]*;
+
_ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EED[012]Ev;
+_ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE[a34]*;
+# _ZNSt7__cxx1119basic_istringstreamI[cw]St11char_traitsI[cw]*;
+# _ZNSt7__cxx1119basic_ostringstreamI[cw]St11char_traitsI[cw]*;
+
_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]E[ORS]*;
+
_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EED[012]Ev;
+
_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EE[a34]*;
_ZNKSt7__cxx1115basic_stringbuf*;
_ZNKSt7__cxx1118basic_stringstream*;
_ZNKSt7__cxx1119basic_istringstream*;
@@ -2021,6 +2031,14 @@ GLIBCXX_3.4.26 {
_ZNSt13runtime_errorC[12]EOS_;
_ZNSt13runtime_erroraSEOS_;
+# Default constructors for stringstreams
+_ZNSt15basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+_ZNSt18basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+_ZNSt19basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+_ZNSt7__cxx1115basic_stringbuf[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+
_ZNSt7__cxx1118basic_stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+
_ZNSt7__cxx1119basic_[io]stringstreamI[cw]St11char_traitsI[cw]ESaI[cw]EEC[12]Ev;
+
} GLIBCXX_3.4.25;
# Symbols in the support library (libsupc++) have their own tag.
diff --git a/libstdc++-v3/include/std/sstream b/libstdc++-v3/include/std/sstream
index 8ad18d00fb6..71d69e94b65 100644
--- a/libstdc++-v3/include/std/sstream
++
Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.
On Fri, Jul 6, 2018 at 1:13 PM, Tamar Christina wrote: >> >> >> >> So I am curious as to why this shows up in Christophe's test but not >> >> in any of your test runs or indeed the testruns with our scripts. >> >> > > The test was changed before sending out, the individual entries moved to > a macro. I then verified the code generation and did not rerun it through > the testsuite. So It didn't get the -pedantic added. I see. Thanks for the clarification. Ramana
RE: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.
> >> > >> So I am curious as to why this shows up in Christophe's test but not > >> in any of your test runs or indeed the testruns with our scripts. > >> The test was changed before sending out, the individual entries moved to a macro. I then verified the code generation and did not rerun it through the testsuite. So It didn't get the -pedantic added. > >> Ideally this should have been caught by the testing you do , just > >> curious as to why -Wpedantic is getting caught in Christophe's bot > >> but not our bot. Searching through gcc.target/aarch64 I see no use of > >> -Wpedantic in any of the exp files. So is this coming from the top > >> level in your testing Christophe ? > >> > > > > In my gcc.log, the compilation line is: > > /xgcc -B//gcc/ /gcc/testsuite/gcc.target/aarch64/struct_cpy.c > > -fno-diagnostics-show-caret -fdiagnostics-color=never -ansi > > -pedantic-errors -ffat-lto-objects -S -o struct_cpy.s > > > > I do not override it at the top level. > > I now see aarch64.exp:set DEFAULT_CFLAGS " -ansi -pedantic-errors" > > So looks like a botched test run then. My bad.. > > Ramana > > > > > >> Ramana > >> > > >> > Thanks, > >> > Tamar > >> > > >> > gcc/testsuite/ > >> > 2018-07-06 Tamar Christina > >> > > >> > * gcc.target/aarch64/struct_cpy.c: Remove ;. > >> > > >> > --
Re: [committed] [PR tree-optimization/86010] More aggressively trim partially dead mem* and str* calls
Hi Jeff,
On Fri, 6 Jul 2018 at 05:44, Jeff Law wrote:
>
> As noted in BZ 86010 we can be more aggressive when trimming tails of
> mem* or str* calls in gimple DSE since trimming a tail doesn't affect
> alignment and residuals are usually handled pretty efficiently in libc.
>
> Additionally, if the total number of live bytes left is smaller than a
> word, then it's highly likely we'll open-code the mem* or str* routine.
> So we allow more aggressive trimming in that case too.
>
> What's left to be able to close out 86010 is to identify when a memory
> store could be merged with a subsequent memset. I'm skeptical of the
> importance of that optimization, though perhaps it comes up often enough
> with structure initializations to be worth doing.
>
> Bootstrapped and regression tested on x86_64-linux-gnu. Installing on
> the trunk.
>
This is causing a regression on arm and i686:
gcc.dg/tree-ssa/pr30375.c: pattern found 0 times
FAIL: gcc.dg/tree-ssa/pr30375.c scan-tree-dump-times dse1
"MEM\\[\\(struct _s \\*\\)&signInfo \\+ [0-9]+B\\] = {}" 1
> Jeff
Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.
On Fri, Jul 6, 2018 at 1:04 PM, Christophe Lyon wrote: > On Fri, 6 Jul 2018 at 13:56, Ramana Radhakrishnan > wrote: >> >> On Fri, Jul 6, 2018 at 10:16 AM, Tamar Christina >> wrote: >> > Hi All, >> > >> > This fixes a -Wpedantic error with the testcase because of extra ; left >> > after the >> > functions. >> > >> > Regtested single test on aarch64-none-elf and no issues. >> > >> > Committed under the GCC obvious rule. >> >> >> So I am curious as to why this shows up in Christophe's test but not >> in any of your test runs or indeed the testruns with our scripts. >> >> Ideally this should have been caught by the testing you do , just >> curious as to why -Wpedantic is getting caught in Christophe's bot but >> not our bot. Searching through gcc.target/aarch64 I see no use of >> -Wpedantic in any of the exp files. So is this coming from the top >> level in your testing Christophe ? >> > > In my gcc.log, the compilation line is: > /xgcc -B//gcc/ /gcc/testsuite/gcc.target/aarch64/struct_cpy.c > -fno-diagnostics-show-caret -fdiagnostics-color=never -ansi > -pedantic-errors -ffat-lto-objects -S -o struct_cpy.s > > I do not override it at the top level. I now see aarch64.exp:set DEFAULT_CFLAGS " -ansi -pedantic-errors" So looks like a botched test run then. My bad.. Ramana > >> Ramana >> > >> > Thanks, >> > Tamar >> > >> > gcc/testsuite/ >> > 2018-07-06 Tamar Christina >> > >> > * gcc.target/aarch64/struct_cpy.c: Remove ;. >> > >> > --
Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.
On Fri, 6 Jul 2018 at 13:56, Ramana Radhakrishnan wrote: > > On Fri, Jul 6, 2018 at 10:16 AM, Tamar Christina > wrote: > > Hi All, > > > > This fixes a -Wpedantic error with the testcase because of extra ; left > > after the > > functions. > > > > Regtested single test on aarch64-none-elf and no issues. > > > > Committed under the GCC obvious rule. > > > So I am curious as to why this shows up in Christophe's test but not > in any of your test runs or indeed the testruns with our scripts. > > Ideally this should have been caught by the testing you do , just > curious as to why -Wpedantic is getting caught in Christophe's bot but > not our bot. Searching through gcc.target/aarch64 I see no use of > -Wpedantic in any of the exp files. So is this coming from the top > level in your testing Christophe ? > In my gcc.log, the compilation line is: /xgcc -B//gcc/ /gcc/testsuite/gcc.target/aarch64/struct_cpy.c -fno-diagnostics-show-caret -fdiagnostics-color=never -ansi -pedantic-errors -ffat-lto-objects -S -o struct_cpy.s I do not override it at the top level. > Ramana > > > > Thanks, > > Tamar > > > > gcc/testsuite/ > > 2018-07-06 Tamar Christina > > > > * gcc.target/aarch64/struct_cpy.c: Remove ;. > > > > --
Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.
On Fri, Jul 6, 2018 at 10:16 AM, Tamar Christina wrote: > Hi All, > > This fixes a -Wpedantic error with the testcase because of extra ; left after > the > functions. > > Regtested single test on aarch64-none-elf and no issues. > > Committed under the GCC obvious rule. So I am curious as to why this shows up in Christophe's test but not in any of your test runs or indeed the testruns with our scripts. Ideally this should have been caught by the testing you do , just curious as to why -Wpedantic is getting caught in Christophe's bot but not our bot. Searching through gcc.target/aarch64 I see no use of -Wpedantic in any of the exp files. So is this coming from the top level in your testing Christophe ? Ramana > > Thanks, > Tamar > > gcc/testsuite/ > 2018-07-06 Tamar Christina > > * gcc.target/aarch64/struct_cpy.c: Remove ;. > > --
Re: [PATCH], Add configuration checks to PowerPC --with-long-double-format=ieee
On Fri, Jul 06, 2018 at 01:51:37AM -0400, Michael Meissner wrote: > case "$target:$with_long_double_format" in > - xpowerpc64*-*-linux*:*) So this case could never happen. The changelog should mention it fixes that bug (and having it as a separate patch is much preferred!) Other than this thing, the original code was easier to read. What does this part of the patch improve? Segher
Re: [PATCH] Fix several AVX512 intrinsic mask arguments.
On Thu, Jul 05, 2018 at 11:57:26PM +0300, Grazvydas Ignotas wrote:
> I think it would be more efficient if you took care of it. I won't
> have time for at least a few days anyway.
Here is what I have ATM, but will still need to work on the testsuite side
for it and bootstrap/regtest it.
In addition to the checks I've posted I've also done:
echo `sed -n '/^_mm.*__mmask/,/^}/p' config/i386/*.h | sed 's/^}/@@@/'` | sed
's/@@@/}\n/g' > /tmp/11
echo `sed -n '/^#define[ \t]_mm/,/)$/p' config/i386/*.h | sed 's/)$/@@@/' | sed
's/\\$//'` | sed 's/@@@/)\n/g' | grep __mmask >> /tmp/11
for i in `grep '__builtin.*_UQI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask8; done
for i in `grep '__builtin.*_UHI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask16; done
for i in `grep '__builtin.*_USI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask32; done
for i in `grep '__builtin.*_UDI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask64; done
for i in `grep '__builtin.*_QI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask8; done
for i in `grep '__builtin.*_HI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask16; done
for i in `grep '__builtin.*_SI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask32; done
for i in `grep '__builtin.*_DI)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask64; done
for i in `grep '__builtin.*_UQI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask8; done
for i in `grep '__builtin.*_UHI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask16; done
for i in `grep '__builtin.*_USI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask32; done
for i in `grep '__builtin.*_UDI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask64; done
for i in `grep '__builtin.*_QI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask8; done
for i in `grep '__builtin.*_HI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask16; done
for i in `grep '__builtin.*_SI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask32; done
for i in `grep '__builtin.*_DI_INT)' config/i386/i386-builtin.def | sed
's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[ \t(].*__mmask' /tmp/11 | grep
-v __mmask64; done
and finally manual checking (could be automated too) of:
for i in `grep '__builtin.*_INT)' config/i386/i386-builtin.def | grep -v
'_U\?[QHSD]I_INT)' | sed 's/^[^"]*"//;s/".*$//' | sort -u`; do grep $i'[
\t(].*__mmask' /tmp/11 | grep -v __mmask32; done
For this last one, it is about trying to verify what kind of
'__v\(2\|4\|8\|16\|32\|64\)[qhsd][if]'
is used with the different __mmask, 2/4/8 should be used with __mmask8,
16 with __mmask16, 32 with __mmask32 and 64 with __mmask64.
Some fixes in the patch are mostly for consistency and harmless for code
generation (e.g. when argument should have been __mmask8 but was __mmask16),
but several changes should fix wrong-code bugs.
--- gcc/config/i386/avx512bwintrin.h.jj 2018-01-03 10:20:06.699535804 +0100
+++ gcc/config/i386/avx512bwintrin.h2018-07-06 09:53:44.657235040 +0200
@@ -3043,7 +3043,7 @@ _mm512_cmp_epi16_mask (__m512i __X, __m5
extern __inline __mmask64
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_mask_cmp_epi8_mask (__mmask32 __U, __m512i __X, __m512i __Y,
+_mm512_mask_cmp_epi8_mask (__mmask64 __U, __m512i __X, __m512i __Y,
const int __P)
{
return (__mmask64) __builtin_ia32_cmpb512_mask ((__v64qi) __X,
@@ -3081,7 +3081,7 @@ _mm512_cmp_epu16_mask (__m512i __X, __m5
extern __inline __mmask64
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_mask_cmp_epu8_mask (__mmask32 __U, __m512i __X, __m512i __Y,
+_mm512_mask_cmp_epu8_mask (__mmask64 __U, __m512i __X, __m512i __Y,
const int __P)
{
return (__mmask64) __builtin_ia32_ucmpb512_mask ((__v64qi) __X,
--- gcc/config/i386/avx512bitalgintrin.h.jj
Re: [PATCH][debug] Handle references to skipped params in remap_ssa_name
On 07/05/2018 01:39 PM, Richard Biener wrote:
> On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries wrote:
>>
>> [ was: Re: [testsuite/guality, committed] Prevent optimization of local in
>> vla-1.c ]
>>
>> On Wed, Jul 04, 2018 at 02:32:27PM +0200, Tom de Vries wrote:
>>> On 07/03/2018 11:05 AM, Tom de Vries wrote:
On 07/02/2018 10:16 AM, Jakub Jelinek wrote:
> On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
>> [debug] Handle references to skipped params in remap_ssa_name
>>
>> 2018-07-05 Tom de Vries
>>
>> * tree-inline.c (remap_ssa_name): Handle references to skipped
>> params.
>>
>> ---
>> gcc/tree-inline.c | 17 +++--
>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
>> index 427ef959740..0fa996cab49 100644
>> --- a/gcc/tree-inline.c
>> +++ b/gcc/tree-inline.c
>> @@ -204,11 +204,22 @@ remap_ssa_name (tree name, copy_body_data *id)
>> gimple *def_temp;
>> gimple_stmt_iterator gsi;
>> tree val = SSA_NAME_VAR (name);
>> + bool skipped_parm_decl = false;
>>
>> n = id->decl_map->get (val);
>> if (n != NULL)
>> - val = *n;
>> - if (TREE_CODE (val) != PARM_DECL)
>> + {
>> + if (TREE_CODE (*n) == DEBUG_EXPR_DECL)
>> + return *n;
>> +
>> + if (TREE_CODE (*n) == VAR_DECL
>> + && DECL_ABSTRACT_ORIGIN (*n)
>> + && TREE_CODE (DECL_ABSTRACT_ORIGIN (*n)) == PARM_DECL)
>> + skipped_parm_decl = true;
>> + else
>> + val = *n;
>> + }
>> + if (TREE_CODE (val) != PARM_DECL && !skipped_parm_decl)
>
> I wonder if this cannot be more easily set up in copy_arguments_for_versioning
> which already does
>
> else if (!id->decl_map->get (arg))
> {
> /* Make an equivalent VAR_DECL. If the argument was used
>as temporary variable later in function, the uses will be
>replaced by local variable. */
> tree var = copy_decl_to_var (arg, id);
> insert_decl_map (id, arg, var);
> /* Declare this new variable. */
> DECL_CHAIN (var) = *vars;
> *vars = var;
> }
>
> which just misses to re-map the default def of the PARM_DECL (in case it
> exists)
> to the same(?) var?
I've updated the patch to add a debug expr here in
copy_arguments_for_versioning for every parameter that has a default
def, and to use that debug expr in remap_ssa_name.
> All remaining uses should be in debug stmts (I hope).
I ran into a test-case where that was not the case, so I had to handle
that in remap_ssa_name, the comment in the patch describes that in more
detail.
Bootstrapped and reg-tested on x86_64.
OK for trunk?
Thanks,
- Tom
[debug] Handle references to skipped params in remap_ssa_name
When compiling guality/vla-1.c with -O3 -g, vla a in f1 is optimized away, but
f1 still contains a debug expression describing the upper bound of the vla
(D.1914):
...
__attribute__((noinline))
f1 (intD.6 iD.1900)
{
saved_stack.1_2 = __builtin_stack_save ();
# DEBUG BEGIN_STMT
# DEBUG D#3 => i_1(D) + 1
# DEBUG D#2 => (long intD.8) D#3
# DEBUG D#1 => D#2 + -1
# DEBUG D.1914 => (sizetype) D#1
...
Then f1 is cloned to a version f1.constprop with no parameters, eliminating
parameter i, and 'DEBUG D#3 => i_1(D) + 1' turns into 'D#3 => NULL'.
Consequently, print sizeof (a) yields '0' in gdb.
This patch fixes that by defining debug expressions for default defs of
eliminated parameters in copy_arguments_for_versioning:
...
__attribute__((noinline))
f1.constprop ()
{
intD.6 iD.1949;
# DEBUG D#8 s=> iD.1900
# DEBUG iD.1949 => D#8
+ # DEBUG D#6 s=> iD.1900
saved_stack.1_1 = __builtin_stack_save ();
# DEBUG BEGIN_STMT
- # DEBUG D#3 => NULL
+ # DEBUG D#3 => D#6 + 1
# DEBUG D#2 => (long intD.8) D#3
# DEBUG D#1 => D#2 + -1
# DEBUG D.1951 => (sizetype) D#1
...
The inserted debug expression (D#6) is a duplicate of the debug expression
that will be inserted after copy_body in tree_function_versioning (D#8), so the
patch contains a todo to fix the duplication.
Bootstrapped and reg-tested on x86_64.
2018-07-05 Tom de Vries
* tree-inline.c (create_debug_expr): Factor out of ...
(remap_ssa_name): ... here. Use debug expr only for debug uses.
(copy_arguments_for_versioning): Add debug expr mapping for skipped
param default defs.
(tree_function_versioning): Insert statements defining debug exprs.
---
gcc/tree-inline.c | 66 ---
1 file changed, 58 insertions(+), 8 deletions(-)
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 427ef959740..11440f49cf0 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -179,6 +179,24 @@ insert_debug_decl_map
[committed][gcc][patch] Require sse for testcase on i686.
Hi All,
This fixes an ABI warning generated on i686-pc-linux-gnu when using
`vector_size` with no sse enabled explicitly.
Regtested single test on x86_64-pc-linux-gnu with -m32 and no issues.
Committed under the GCC obvious rule.
Thanks,
Tamar
gcc/testsuite/
2018-07-06 Tamar Christina
PR target/84711
* gcc.dg/vect/pr84711.c: Add -msse for i686 targets.
--
diff --git a/gcc/testsuite/gcc.dg/vect/pr84711.c b/gcc/testsuite/gcc.dg/vect/pr84711.c
index dbe61bef0dc35cdbcacf7a9217951888b64a99f1..87763aaabed22a043680223b466b3f43ca70744e 100644
--- a/gcc/testsuite/gcc.dg/vect/pr84711.c
+++ b/gcc/testsuite/gcc.dg/vect/pr84711.c
@@ -1,6 +1,8 @@
/* { dg-do compile } */
/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target sse { target i386*-*-* } } */
/* { dg-options "-O2" } */
+/* { dg-additional-options "-msse" { target i386*-*-* } } */
typedef int v4si
__attribute__ ((vector_size (16)));
Re: [PATCH][debug] Handle references to skipped params in remap_ssa_name
On Thu, Jul 5, 2018 at 4:12 PM Tom de Vries wrote:
>
> On 07/05/2018 01:39 PM, Richard Biener wrote:
> > On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries wrote:
> >>
> >> [ was: Re: [testsuite/guality, committed] Prevent optimization of local in
> >> vla-1.c ]
> >>
> >> On Wed, Jul 04, 2018 at 02:32:27PM +0200, Tom de Vries wrote:
> >>> On 07/03/2018 11:05 AM, Tom de Vries wrote:
> On 07/02/2018 10:16 AM, Jakub Jelinek wrote:
> > On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
> >> Given the array has size i + 1 it's upper bound should be 'i' and 'i'
> >> should be available via DW_OP_[GNU_]entry_value.
> >>
> >> I see it is
> >>
> >> <175> DW_AT_upper_bound : 10 byte block: 75 1 8 20 24 8 20 26 31
> >> 1c (DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl;
> >> DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus)
> >>
> >> and %rdi is 1. Not sure why gdb fails to print it's length. Yes, the
> >> storage itself doesn't have a location but the
> >> type specifies the size.
> >>
> >> (gdb) ptype a
> >> type = char [variable length]
> >> (gdb) p sizeof(a)
> >> $3 = 0
> >>
> >> this looks like a gdb bug to me?
> >>
>
> With gdb patch:
> ...
> diff --git a/gdb/findvar.c b/gdb/findvar.c
> index 8ad5e25cb2..ebaff923a1 100644
> --- a/gdb/findvar.c
> +++ b/gdb/findvar.c
> @@ -789,6 +789,8 @@ default_read_var_value
> break;
>
> case LOC_OPTIMIZED_OUT:
> + if (is_dynamic_type (type))
> + type = resolve_dynamic_type (type, NULL,
> +/* Unused address. */ 0);
> return allocate_optimized_out_value (type);
>
> default:
> ...
>
> I get:
> ...
> $ ./gdb -batch -ex "b f1" -ex "r" -ex "p sizeof (a)" vla-1.exe
> Breakpoint 1 at 0x4004a8: file vla-1.c, line 17.
>
> Breakpoint 1, f1 (i=i@entry=5) at vla-1.c:17
> 17return a[0];
> $1 = 6
> ...
>
> >>>
> >>> Well, for -O1 and -O2.
> >>>
> >>> For O3, I get instead:
> >>> ...
> >>> $ ./gdb vla-1.exe -q -batch -ex "b f1" -ex "run" -ex "p sizeof (a)"
> >>> Breakpoint 1 at 0x4004b0: f1. (2 locations)
> >>>
> >>> Breakpoint 1, f1 (i=5) at vla-1.c:17
> >>> 17return a[0];
> >>> $1 = 0
> >>> ...
> >>>
> >>
> >> Hi,
> >>
> >> When compiling guality/vla-1.c with -O3 -g, vla 'a[i + 1]' in f1 is
> >> optimized
> >> away, but f1 still contains a debug expression describing the upper bound
> >> of the
> >> vla (D.1914):
> >> ...
> >> __attribute__((noinline))
> >> f1 (intD.6 iD.1900)
> >> {
> >>
> >>saved_stack.1_2 = __builtin_stack_save ();
> >># DEBUG BEGIN_STMT
> >># DEBUG D#3 => i_1(D) + 1
> >># DEBUG D#2 => (long intD.8) D#3
> >># DEBUG D#1 => D#2 + -1
> >># DEBUG D.1914 => (sizetype) D#1
> >> ...
> >>
> >> Then f1 is cloned to a version f1.constprop with no parameters, eliminating
> >> parameter i, and 'DEBUG D#3 => i_1(D) + 1' turns into 'D#3 => NULL'.
> >> Consequently, 'print sizeof (a)' yields '0' in gdb.
> >
> > So does gdb correctly recognize there isn't any size available or do we
> > somehow
> > generate invalid debug info, not recognizing that D#3 => NULL means
> > "optimized out" and thus all dependent expressions are "optimized out" as
> > well?
> >
> > That is, shouldn't gdb do
> >
> > (gdb) print sizeof (a)
> >
> >
> > ?
>
> The type for the vla gcc is emitting is an DW_TAG_array_type with
> DW_TAG_subrange_type without DW_AT_upper_bound or DW_AT_count, which
> makes the upper bound value 'unknown'. So I'd say the debug info is valid.
OK, that sounds reasonable. I wonder if languages like Ada have a way
to declare an array type with unknown upper bound but known lower bound.
For
typedef int arr[];
arr *x;
we generate just
<1><2d>: Abbrev Number: 2 (DW_TAG_typedef)
<2e> DW_AT_name: arr
<32> DW_AT_decl_file : 1
<33> DW_AT_decl_line : 1
<34> DW_AT_decl_column : 13
<35> DW_AT_type: <0x39>
<1><39>: Abbrev Number: 3 (DW_TAG_array_type)
<3a> DW_AT_type: <0x44>
<3e> DW_AT_sibling : <0x44>
<2><42>: Abbrev Number: 4 (DW_TAG_subrange_type)
<2><43>: Abbrev Number: 0
which does
(gdb) ptype arr
type = int []
(gdb) ptype x
type = int (*)[]
(gdb) p sizeof (arr)
$1 = 0
so I wonder whether the patch makes it print
instead? I think both 0 and are less than ideal
and maybe would be better. In the type case
above it's certainly not "optimized out".
> Using this gdb patch:
> ...
> diff --git a/gdb/eval.c b/gdb/eval.c
> index 9db6e7c69d..ea6f782c5b 100644
> --- a/gdb/eval.c
> +++ b/gdb/eval.c
> @@ -3145,6 +3145,8 @@ evaluate_subexp_for_sizeof (...)
> {
> val = evaluate_subexp (NULL_TYPE, exp, pos, EVAL_NORMAL);
> type = value_type (val);
> + if (TYPE_LE
[PATCH] include/std/variant (__accepted_index): Use void_t.
Tested powerpc64le-linux, committed to trunk.
commit d66ad3c7feea986bfb95543e07b7063931d97e96
Author: Jonathan Wakely
Date: Fri Jul 6 09:58:12 2018 +0100
* include/std/variant (__accepted_index): Use void_t.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 63eafdd58e5..66d878142a4 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -710,7 +710,8 @@ namespace __variant
};
// Helper for variant(_Tp&&) and variant::operator=(_Tp&&).
- // __accepted_index maps the arbitrary _Tp to an alternative type in
_Variant.
+ // __accepted_index maps an arbitrary _Tp to an alternative type in _Variant
+ // (or to variant_npos).
template
struct __accepted_index
{ static constexpr size_t value = variant_npos; };
@@ -718,8 +719,7 @@ namespace __variant
template
struct __accepted_index<
_Tp, variant<_Types...>,
- decltype(__overload_set<_Types...>::_S_fun(std::declval<_Tp>()),
- std::declval())>
+ void_t::_S_fun(std::declval<_Tp>()))>>
{
static constexpr size_t value = sizeof...(_Types) - 1
- decltype(__overload_set<_Types...>::
Re: [PATCH 1/3][POPCOUNT] Handle COND_EXPR in expression_expensive_p
On Fri, Jul 6, 2018 at 11:45 AM Kugan Vivekanandarajah wrote: > > Hi Richard, > > > It was rewrite_to_non_trapping_overflow available in tree.h. Thus > > final value replacement > > could use that before gimplifying instead of using > > rewrite_to_defined_overflow > Thanks. > > Is the attached patch OK? I am testing this on x86_64-linux-gnu and if > there is no new regressions. Please clean up the control flow to if (...) def = rewrite_to_non_trapping_overflow (def); def = force_gimple_operand_gsi (&gsi, def, false, NULL_TREE, true, GSI_SAME_STMT); OK with that change. Richard. > Thanks, > Kugan > > gcc/ChangeLog: > > 2018-07-06 Kugan Vivekanandarajah > > * tree-scalar-evolution.c (final_value_replacement_loop): Use > rewrite_to_non_trapping_overflow instead of rewrite_to_defined_overflow.
[PATCH] Fix PR86413
The following fixes
FAIL: gcc.dg/guality/pr48437.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none line 14 i == 0
because we now prune non-local/VAR_DECLs from BLOCK trees during
free-lang-data (after we emitted early dwarf). gen_block_die
isn't prepared for that and now refuses to add low/high-PC
attributes to blocks that got all BLOCK_VARS stripped that way.
The fix is to simply always emit them for early generated DIEs
(so we only ever elide the DIE creation during early dwarf).
Note this would allow us to prune BLOCK_VARS completely after
early dwarf generation (but we need to keep the BLOCK tree itself
for scoping obviously).
Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok?
Thanks,
Richard.
2018-07-06 Richard Biener
PR debug/86413
* dwarf2out.c (gen_block_die): For an early generated DIE
always output high/low PC attributes.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a7c4620cfc3..95232177d83 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -25622,6 +25622,11 @@ gen_block_die (tree stmt, dw_die_ref context_die)
/* The outer scopes for inlinings *must* always be represented. We
generate DW_TAG_inlined_subroutine DIEs for them. (See below.) */
must_output_die = 1;
+ else if (BLOCK_DIE (stmt))
+/* If we already have a DIE then it was filled early. Meanwhile
+ we might have pruned all BLOCK_VARS as optimized out but we
+ still want to generate high/low PC attributes so output it. */
+must_output_die = 1;
else
{
/* Determine if this block directly contains any "significant"
Re: [PATCH 1/3][POPCOUNT] Handle COND_EXPR in expression_expensive_p
Hi Richard,
> It was rewrite_to_non_trapping_overflow available in tree.h. Thus
> final value replacement
> could use that before gimplifying instead of using rewrite_to_defined_overflow
Thanks.
Is the attached patch OK? I am testing this on x86_64-linux-gnu and if
there is no new regressions.
Thanks,
Kugan
gcc/ChangeLog:
2018-07-06 Kugan Vivekanandarajah
* tree-scalar-evolution.c (final_value_replacement_loop): Use
rewrite_to_non_trapping_overflow instead of rewrite_to_defined_overflow.
From 68a4f232f6cde68751f6785059121fe116363886 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah
Date: Fri, 6 Jul 2018 13:34:41 +1000
Subject: [PATCH] rewrite with rewrite_to_non_trapping_overflow
Change-Id: Ica4407eab1c2b6f4190d8c0df6308154ffad2c1f
---
gcc/tree-scalar-evolution.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/gcc/tree-scalar-evolution.c b/gcc/tree-scalar-evolution.c
index 4b0ec02..3b4f0aa 100644
--- a/gcc/tree-scalar-evolution.c
+++ b/gcc/tree-scalar-evolution.c
@@ -267,6 +267,7 @@ along with GCC; see the file COPYING3. If not see
#include "gimple-iterator.h"
#include "gimplify-me.h"
#include "tree-cfg.h"
+#include "tree-eh.h"
#include "tree-ssa-loop-ivopts.h"
#include "tree-ssa-loop-manip.h"
#include "tree-ssa-loop-niter.h"
@@ -3616,24 +3617,9 @@ final_value_replacement_loop (struct loop *loop)
&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (def)))
{
gimple_seq stmts;
- gimple_stmt_iterator gsi2;
+ def = rewrite_to_non_trapping_overflow (def);
def = force_gimple_operand (def, &stmts, true, NULL_TREE);
- gsi2 = gsi_start (stmts);
- while (!gsi_end_p (gsi2))
- {
- gimple *stmt = gsi_stmt (gsi2);
- gimple_stmt_iterator gsi3 = gsi2;
- gsi_next (&gsi2);
- gsi_remove (&gsi3, false);
- if (is_gimple_assign (stmt)
- && arith_code_with_undefined_signed_overflow
- (gimple_assign_rhs_code (stmt)))
- gsi_insert_seq_before (&gsi,
- rewrite_to_defined_overflow (stmt),
- GSI_SAME_STMT);
- else
- gsi_insert_before (&gsi, stmt, GSI_SAME_STMT);
- }
+ gsi_insert_seq_before (&gsi, stmts, GSI_SAME_STMT);
}
else
def = force_gimple_operand_gsi (&gsi, def, false, NULL_TREE,
--
2.7.4
[committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.
Hi All,
This fixes a -Wpedantic error with the testcase because of extra ; left after
the
functions.
Regtested single test on aarch64-none-elf and no issues.
Committed under the GCC obvious rule.
Thanks,
Tamar
gcc/testsuite/
2018-07-06 Tamar Christina
* gcc.target/aarch64/struct_cpy.c: Remove ;.
--
diff --git a/gcc/testsuite/gcc.target/aarch64/struct_cpy.c b/gcc/testsuite/gcc.target/aarch64/struct_cpy.c
index 4feb3ea990994e0de82b3d54f13ec073cfa7a335..26195971e6446e1ca9559f443ed51273aaec3d40 100644
--- a/gcc/testsuite/gcc.target/aarch64/struct_cpy.c
+++ b/gcc/testsuite/gcc.target/aarch64/struct_cpy.c
@@ -46,22 +46,22 @@ struct struct16 foo16 = {
volatile struct struct##x var##x = foo##x; \
}
-FUN(1);
-FUN(2);
-FUN(3);
-FUN(4);
-FUN(5);
-FUN(6);
-FUN(7);
-FUN(8);
-FUN(9);
-FUN(10);
-FUN(11);
-FUN(12);
-FUN(13);
-FUN(14);
-FUN(15);
-FUN(16);
+FUN(1)
+FUN(2)
+FUN(3)
+FUN(4)
+FUN(5)
+FUN(6)
+FUN(7)
+FUN(8)
+FUN(9)
+FUN(10)
+FUN(11)
+FUN(12)
+FUN(13)
+FUN(14)
+FUN(15)
+FUN(16)
/* { dg-final { scan-assembler-times {ldr\s} 18 } } */
/* { dg-final { scan-assembler-times {ldrb} 4 } } */
[PATCH] RISC-V: Report error if function declare with different
Hi all:
This patch implemented TARGET_MERGE_DECL_ATTRIBUTES hook to check the
interrupter is all compatible, tested with rv32ima and rv64ima elf
toolchain.
gcc/ChangeLog
2018-07-06 Kito Cheng
* config/riscv/riscv.c (enum riscv_privilege_levels): Add UNKNOWN_MODE.
(riscv_expand_epilogue): Add more assertion to check interrupt mode.
(riscv_set_current_function): Extract getting interrupt type to new
function.
(riscv_get_interrupt_type): New function.
(riscv_merge_decl_attributes): New function, checking interrupt type is
same.
(TARGET_MERGE_DECL_ATTRIBUTES): Define.
gcc/testsuite/ChangeLog
2018-07-06 Kito Cheng
* gcc.target/riscv/interrupt-conflict-mode.c: New.
From ae275a1edd9b5c5f0126417542607aa667234823 Mon Sep 17 00:00:00 2001
From: Kito Cheng
Date: Tue, 3 Jul 2018 13:29:02 +0800
Subject: [PATCH] RISC-V: Report error if function declare with different
interrupt mode.
---
gcc/config/riscv/riscv.c | 82 +++
.../riscv/interrupt-conflict-mode.c | 10 +++
2 files changed, 74 insertions(+), 18 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/interrupt-conflict-mode.c
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index d87836f53f8..c10c58e3cd5 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -123,7 +123,7 @@ struct GTY(()) riscv_frame_info {
};
enum riscv_privilege_levels {
- USER_MODE, SUPERVISOR_MODE, MACHINE_MODE
+ UNKNOWN_MODE, USER_MODE, SUPERVISOR_MODE, MACHINE_MODE
};
struct GTY(()) machine_function {
@@ -3984,6 +3984,8 @@ riscv_expand_epilogue (int style)
{
enum riscv_privilege_levels mode = cfun->machine->interrupt_mode;
+ gcc_assert (mode != UNKNOWN_MODE);
+
if (mode == MACHINE_MODE)
emit_jump_insn (gen_riscv_mret ());
else if (mode == SUPERVISOR_MODE)
@@ -4530,6 +4532,37 @@ riscv_function_ok_for_sibcall (tree decl ATTRIBUTE_UNUSED,
return true;
}
+/* Get the intterupt type, return UNKNOWN_MODE if it's not
+ interrupt function. */
+static enum riscv_privilege_levels
+riscv_get_interrupt_type (tree decl)
+{
+ gcc_assert (decl != NULL_TREE);
+
+ if ((TREE_CODE(decl) != FUNCTION_DECL)
+ || (!riscv_interrupt_type_p (TREE_TYPE (decl
+return UNKNOWN_MODE;
+
+ tree attr_args
+= TREE_VALUE (lookup_attribute ("interrupt",
+TYPE_ATTRIBUTES (TREE_TYPE (decl;
+
+ if (attr_args && TREE_CODE (TREE_VALUE (attr_args)) != VOID_TYPE)
+{
+ const char *string = TREE_STRING_POINTER (TREE_VALUE (attr_args));
+
+ if (!strcmp (string, "user"))
+ return USER_MODE;
+ else if (!strcmp (string, "supervisor"))
+ return SUPERVISOR_MODE;
+ else /* Must be "machine". */
+ return MACHINE_MODE;
+}
+ else
+/* Interrupt attributes are machine mode by default. */
+return MACHINE_MODE;
+}
+
/* Implement `TARGET_SET_CURRENT_FUNCTION'. */
/* Sanity cheching for above function attributes. */
static void
@@ -4554,9 +4587,6 @@ riscv_set_current_function (tree decl)
{
tree ret = TREE_TYPE (TREE_TYPE (decl));
tree args = TYPE_ARG_TYPES (TREE_TYPE (decl));
- tree attr_args
- = TREE_VALUE (lookup_attribute ("interrupt",
- TYPE_ATTRIBUTES (TREE_TYPE (decl;
if (TREE_CODE (ret) != VOID_TYPE)
error ("%qs function cannot return a value", "interrupt");
@@ -4564,26 +4594,39 @@ riscv_set_current_function (tree decl)
if (args && TREE_CODE (TREE_VALUE (args)) != VOID_TYPE)
error ("%qs function cannot have arguments", "interrupt");
- if (attr_args && TREE_CODE (TREE_VALUE (attr_args)) != VOID_TYPE)
- {
- const char *string = TREE_STRING_POINTER (TREE_VALUE (attr_args));
-
- if (!strcmp (string, "user"))
- cfun->machine->interrupt_mode = USER_MODE;
- else if (!strcmp (string, "supervisor"))
- cfun->machine->interrupt_mode = SUPERVISOR_MODE;
- else /* Must be "machine". */
- cfun->machine->interrupt_mode = MACHINE_MODE;
- }
- else
- /* Interrupt attributes are machine mode by default. */
- cfun->machine->interrupt_mode = MACHINE_MODE;
+ cfun->machine->interrupt_mode = riscv_get_interrupt_type (decl);
+
+ gcc_assert (cfun->machine->interrupt_mode != UNKNOWN_MODE);
}
/* Don't print the above diagnostics more than once. */
cfun->machine->attributes_checked_p = 1;
}
+/* Implement TARGET_MERGE_DECL_ATTRIBUTES. */
+static tree
+riscv_merge_decl_attributes (tree olddecl, tree newdecl)
+{
+ tree combined_attrs;
+
+ enum riscv_privilege_levels old_interrupt_type
+= riscv_get_interrupt_type (olddecl);
+ enum riscv_privilege_levels new_interrupt_type
+= riscv_get_interrupt_type (newdecl);
+
+ /* Check old and new has same interrupt type. */
+ if ((old_interrupt_type != UNKNOWN_MODE)
+ && (new_interrupt_type != UNKNOWN_MODE)
+ && (old_interrupt_type != new_interrupt_type))
+error ("%qs function cannot have different
Re: [PATCH] Move ((A & N) + B) & M -> (A + B) & M etc. optimization from fold-const.c to match.pd (PR tree-optimization/86401)
On Thu, 5 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> I've encountered this while testing the rotate patterns in discussion
> with Jonathan for the std::__rot{l,r}, in the rotate-9.c test without
> this patch f1 is optimized into a rotate, but f2 is not.
>
> Fixed by moving the optimization from fold-const.c to match.pd (well,
> leaving a helper in fold-const.c to avoid too much duplication).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2018-07-05 Jakub Jelinek
>
> PR tree-optimization/86401
> * fold-const.c (fold_binary_loc) : Move the
> ((A & N) + B) & M -> (A + B) & M etc. optimization into ...
> (fold_bit_and_mask): ... here. New helper function for match.pd.
> * fold-const.h (fold_bit_and_mask): Declare.
> * match.pd (((A & N) + B) & M -> (A + B) & M): New optimization.
>
> * gcc.dg/tree-ssa/pr86401-1.c: New test.
> * gcc.dg/tree-ssa/pr86401-2.c: New test.
> * c-c++-common/rotate-9.c: New test.
>
> --- gcc/fold-const.c.jj 2018-06-26 09:05:23.196346433 +0200
> +++ gcc/fold-const.c 2018-07-04 12:47:59.139981801 +0200
> @@ -10236,121 +10236,6 @@ fold_binary_loc (location_t loc, enum tr
> }
> }
>
> - /* For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,
> - ((A & N) + B) & M -> (A + B) & M
> - Similarly if (N & M) == 0,
> - ((A | N) + B) & M -> (A + B) & M
> - and for - instead of + (or unary - instead of +)
> - and/or ^ instead of |.
> - If B is constant and (B & M) == 0, fold into A & M. */
> - if (TREE_CODE (arg1) == INTEGER_CST)
> - {
> - wi::tree_to_wide_ref cst1 = wi::to_wide (arg1);
> - if ((~cst1 != 0) && (cst1 & (cst1 + 1)) == 0
> - && INTEGRAL_TYPE_P (TREE_TYPE (arg0))
> - && (TREE_CODE (arg0) == PLUS_EXPR
> - || TREE_CODE (arg0) == MINUS_EXPR
> - || TREE_CODE (arg0) == NEGATE_EXPR)
> - && (TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg0))
> - || TREE_CODE (TREE_TYPE (arg0)) == INTEGER_TYPE))
> - {
> - tree pmop[2];
> - int which = 0;
> - wide_int cst0;
> -
> - /* Now we know that arg0 is (C + D) or (C - D) or
> - -C and arg1 (M) is == (1LL << cst) - 1.
> - Store C into PMOP[0] and D into PMOP[1]. */
> - pmop[0] = TREE_OPERAND (arg0, 0);
> - pmop[1] = NULL;
> - if (TREE_CODE (arg0) != NEGATE_EXPR)
> - {
> - pmop[1] = TREE_OPERAND (arg0, 1);
> - which = 1;
> - }
> -
> - if ((wi::max_value (TREE_TYPE (arg0)) & cst1) != cst1)
> - which = -1;
> -
> - for (; which >= 0; which--)
> - switch (TREE_CODE (pmop[which]))
> - {
> - case BIT_AND_EXPR:
> - case BIT_IOR_EXPR:
> - case BIT_XOR_EXPR:
> - if (TREE_CODE (TREE_OPERAND (pmop[which], 1))
> - != INTEGER_CST)
> - break;
> - cst0 = wi::to_wide (TREE_OPERAND (pmop[which], 1)) & cst1;
> - if (TREE_CODE (pmop[which]) == BIT_AND_EXPR)
> - {
> - if (cst0 != cst1)
> - break;
> - }
> - else if (cst0 != 0)
> - break;
> - /* If C or D is of the form (A & N) where
> -(N & M) == M, or of the form (A | N) or
> -(A ^ N) where (N & M) == 0, replace it with A. */
> - pmop[which] = TREE_OPERAND (pmop[which], 0);
> - break;
> - case INTEGER_CST:
> - /* If C or D is a N where (N & M) == 0, it can be
> -omitted (assumed 0). */
> - if ((TREE_CODE (arg0) == PLUS_EXPR
> - || (TREE_CODE (arg0) == MINUS_EXPR && which == 0))
> - && (cst1 & wi::to_wide (pmop[which])) == 0)
> - pmop[which] = NULL;
> - break;
> - default:
> - break;
> - }
> -
> - /* Only build anything new if we optimized one or both arguments
> - above. */
> - if (pmop[0] != TREE_OPERAND (arg0, 0)
> - || (TREE_CODE (arg0) != NEGATE_EXPR
> - && pmop[1] != TREE_OPERAND (arg0, 1)))
> - {
> - tree utype = TREE_TYPE (arg0);
> - if (! TYPE_OVERFLOW_WRAPS (TREE_TYPE (arg0)))
> - {
> - /* Perform the operations in a type that has defined
> - overflow behavior. */
> - utype = unsigned_type_for (TREE_TYPE (arg0));
> - if (pmop[0] != NULL)
> - pmop[0] = fold_convert_loc (loc, utype, pmop[0]);
> - if (pmop[1]
Re: [PATCH][GCC][mid-end] Correct subreg no-op handling for big-endian vec_select.
On Thu, 28 Jun 2018 at 05:11, Jeff Law wrote: > > On 06/19/2018 08:11 AM, Tamar Christina wrote: > > Hi All, > > > > Previously GCC's no-op detection could would consider something a no-op > > even when the > > mode change is not directly possible. This caused subregs that shouldn't > > be removed > > to be treated as a no-op and deleted. > > > > Regtested on armeb-none-eabi and no regressions. > > Bootstrapped on arm-none-linux-gnueabihf and no issues. > > > > Ok for trunk? and for backport to GCC 8? > > > > Thanks, > > Tamar > > > > gcc/ > > 2018-06-19 Tamar Christina > > > > PR target/84711 > > * rtlanal.c (set_noop_p): Constrain on mode change, > > include hard-reg-set.h > > > OK. Though please include a testcase. I believe you had > big-endian-subreg.c in the original target specific approach to fixing > this problem. That'd be fine to re-use here. > Hi, It looks like this new test fails on x86_32 (i686-pc-linux-gnu): /gcc/testsuite/gcc.dg/vect/pr84711.c: In function 'fn1': /gcc/testsuite/gcc.dg/vect/pr84711.c:8:5: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 /gcc/testsuite/gcc.dg/vect/pr84711.c:8:5: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi] FAIL: gcc.dg/vect/pr84711.c -flto -ffat-lto-objects (test for excess errors) Excess errors: /gcc/testsuite/gcc.dg/vect/pr84711.c:8:5: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi] > jeff
Re: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian
Hi Tamar,
On Wed, 20 Jun 2018 at 15:35, Kyrill Tkachov
wrote:
>
>
> On 20/06/18 11:33, Tamar Christina wrote:
> > Hi Kyrill,
> >
> > Many thanks for the review!
> >
> > The 06/20/2018 09:43, Kyrill Tkachov wrote:
> >> Hi Tamar,
> >>
> >> On 19/06/18 15:14, Tamar Christina wrote:
> >>> Hi All,
> >>>
> >>> This patch requires
> >>> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to work,
> >>> it has been accepted once already but caused a regression on certain
> >>> configuratoins.
> >>> I am re-submitting it with the required mid-end change and requesting a
> >>> back-port.
> >>>
> >>> --- original patch.
> >>>
> >>> Taking the subreg of a vector mode on big-endian may result in an infinite
> >>> recursion and eventually a segfault once we run out of stack space.
> >>>
> >>> As an example, taking a subreg of V4HF to SImode we end up in the
> >>> following
> >>> loop on big-endian:
> >>>
> >>> #861 0x008462e9 in operand_subword_force
> >>> src/gcc/gcc/emit-rtl.c:1787
> >>> #862 0x00882a90 in emit_move_multi_word src/gcc/gcc/expr.c:3621
> >>> #863 0x0087eea1 in emit_move_insn_1 src/gcc/gcc/expr.c:3698
> >>> #864 0x0087f350 in emit_move_insn src/gcc/gcc/expr.c:3757
> >>> #865 0x0085e326 in copy_to_reg src/gcc/gcc/explow.c:603
> >>> #866 0x008462e9 in operand_subword_force
> >>> src/gcc/gcc/emit-rtl.c:1787
> >>>
> >>> The reason is that operand_subword_force will always fail. When the value
> >>> is in
> >>> a register that can't be accessed as a multi word the code tries to
> >>> create a new
> >>> psuedo register and emit the value to it. Eventually you end up in
> >>> simplify_gen_subreg
> >>> which calls validate_subreg.
> >>>
> >>> validate_subreg will however always fail because of the
> >>> REG_CAN_CHANGE_MODE_P check.
> >>>
> >>> On little endian this check always returns true. On big-endian this check
> >>> is supposed
> >>> to prevent values that have a size larger than word size, due to those
> >>> being stored in
> >>> VFP registers.
> >>>
> >>> However we are only interested in a subreg of the vector mode, so we
> >>> should be checking
> >>> the unit size, not the size of the entire mode. Doing this fixes the
> >>> problem.
> >>>
> >>> Regtested on armeb-none-eabi and no regressions.
> >>> Bootstrapped on arm-none-linux-gnueabihf and no issues.
> >>>
> >>> Ok for trunk? and for backport to GCC 8?
> >>>
> >>> Thanks,
> >>> Tamar
> >>>
> >>> gcc/
> >>> 2018-06-19 Tamar Christina
> >>>
> >>> PR target/84711
> >>> * config/arm/arm.c (arm_can_change_mode_class): Use
> >>> GET_MODE_UNIT_SIZE
> >>> instead of GET_MODE_SIZE when comparing Units.
> >>>
> >>> gcc/testsuite/
> >>> 2018-06-19 Tamar Christina
> >>>
> >>> PR target/84711
> >>> * gcc.target/arm/big-endian-subreg.c: New.
> >>>
> >>> --
> >>
> >> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> >> index
> >> 90d62e699bce9594879be2e3016c9b36c7e064c8..703632240822e762a906570964b949c783df56f3
> >> 100644
> >> --- a/gcc/config/arm/arm.c
> >> +++ b/gcc/config/arm/arm.c
> >> @@ -31508,8 +31508,8 @@ arm_can_change_mode_class (machine_mode from,
> >> machine_mode to,
> >>{
> >> if (TARGET_BIG_END
> >> && !(GET_MODE_SIZE (from) == 16 && GET_MODE_SIZE (to) == 8)
> >> - && (GET_MODE_SIZE (from) > UNITS_PER_WORD
> >> - || GET_MODE_SIZE (to) > UNITS_PER_WORD)
> >> + && (GET_MODE_UNIT_SIZE (from) > UNITS_PER_WORD
> >> + || GET_MODE_UNIT_SIZE (to) > UNITS_PER_WORD)
> >>
After this commit (r262436), I have noticed regressions on
armeb-none-linux-gnueabihf
--with-cpu cortex-a9
--with-fpu neon-fp16
FAIL: gcc.dg/vect/vect-nop-move.c execution test
FAIL: g++.dg/torture/vshuf-v2si.C -O3 -g execution test
FAIL: g++.dg/torture/vshuf-v4si.C -O3 -g execution test
FAIL: g++.dg/torture/vshuf-v8hi.C -O3 -g execution test
Can you have a look?
> >> Does GET_MODE_UNIT_SIZE do what you want? Its documentation in rtl.texi
> >> says:
> >> "Returns the size in bytes of the subunits of a datum of mode @var{m}.
> >>This is the same as @code{GET_MODE_SIZE} except in the case of complex
> >>modes. For them, the unit size is the size of the real or imaginary
> >>part."
> >>
> >> Does it also do the right thing for vector modes (GET_MODE_SIZE
> >> (GET_MODE_INNER (mode))) ?
> >> If so, this patch is ok, but we'll need to update the documentation to
> >> make it more explicit.
> > I don't know what the documentation is trying to say here, but the key is
> > the first part:
> >
> > "returns the size in bytes of the subunits of a datum of mode m"
> >
> > MODE: V4SI, GET_MODE_UNIT_SIZE: 4, GET_MODE_SIZE: 16
> >
> > So GET_MODE_UNIT_SIZE (m) * GET_MODE_NUNITS(m) == GET_MODE_SIZE (m)
> >
> > or GET_MODE_UNIT_SIZE (m) == GET_MODE_SIZE (GET_MODE_INNER (mode)).
> >
> > From this the only time GET_MODE_UNIT_SIZE is equal to GET_MODE_SIZE is on
> > non-vector modes of V1 vector modes.
>
> Right,
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
> Ada doesn't use trampolines if you define... > > > + Always_Compatible_Rep : constant Boolean := False; > > ...this to False. And also define TARGET_CUSTOM_FUNCTION_DESCRIPTORS for the architecture. -- Eric Botcazou
Re: [PATCH][GCC][AArch64] Simplify movmem code by always doing overlapping copies when larger than 8 bytes.
Hi Tamar, On Tue, 3 Jul 2018 at 19:13, James Greenhalgh wrote: > > On Tue, Jun 19, 2018 at 09:09:27AM -0500, Tamar Christina wrote: > > Hi All, > > > > OK. > > Thanks, > James > > > Thanks, > > Tamar > > > > gcc/ > > 2018-06-19 Tamar Christina > > > > * config/aarch64/aarch64.c (aarch64_expand_movmem): Fix mode size. > > > > gcc/testsuite/ > > 2018-06-19 Tamar Christina > > > > * gcc.target/aarch64/struct_cpy.c: New. > > The new test has a typo making it fail to compile: /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:49:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:50:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:51:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:52:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:53:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:54:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:55:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:56:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:57:7: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:58:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:59:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:60:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:61:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:62:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:63:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] /gcc/testsuite/gcc.target/aarch64/struct_cpy.c:64:8: error: ISO C does not allow extra ';' outside of a function [-Wpedantic] Would you mind fixing it? Thanks, Christophe > > --
Re: calculate overflow type in wide int arithmetic
On 07/05/2018 05:50 AM, Richard Biener wrote:
On Thu, Jul 5, 2018 at 9:35 AM Aldy Hernandez wrote:
The reason for this patch are the changes showcased in tree-vrp.c.
Basically I'd like to discourage rolling our own overflow and underflow
calculation when doing wide int arithmetic. We should have a
centralized place for this, that is-- in the wide int code itself ;-).
The only cases I care about are plus/minus, which I have implemented,
but we also get division for free, since AFAICT, division can only
positive overflow:
-MIN / -1 => +OVERFLOW
Multiplication OTOH, can underflow, but I've not implemented it because
we have no uses for it. I have added a note in the code explaining this.
Originally I tried to only change plus/minus, but that made code that
dealt with plus/minus in addition to div or mult a lot uglier. You'd
have to special case "int overflow_for_add_stuff" and "bool
overflow_for_everything_else". Changing everything to int, makes things
consistent.
Note: I have left poly-int as is, with its concept of yes/no for
overflow. I can adapt this as well if desired.
Tested on x86-64 Linux.
OK for trunk?
looks all straight-forward but the following:
else if (op1)
{
if (minus_p)
- {
- wi = -wi::to_wide (op1);
-
- /* Check for overflow. */
- if (sgn == SIGNED
- && wi::neg_p (wi::to_wide (op1))
- && wi::neg_p (wi))
- ovf = 1;
- else if (sgn == UNSIGNED && wi::to_wide (op1) != 0)
- ovf = -1;
- }
+ wi = wi::neg (wi::to_wide (op1));
else
wi = wi::to_wide (op1);
you fail to handle - -INT_MIN.
Woah, very good catch. I previously had this implemented as wi::sub(0,
op1, &ovf) which was calculating overflow correctly but when I
implemented the overflow type in wi::neg I missed this. Thanks.
Given the fact that for multiplication (or others, didn't look too close)
you didn't implement the direction indicator I wonder if it would be more
appropriate to do
enum ovfl { OVFL_NONE = 0, OVFL_UNDERFLOW = -1, OVFL_OVERFLOW = 1,
OVFL_UNKNOWN = 2 };
and tell us the "truth" here?
Excellent idea...though it came with lots of typing :). Fixed.
BTW, if I understand correctly, I've implemented the overflow types
correctly for everything but multiplication (which we have no users for
and I return OVF_UNKNOWN). I have indicated this in comments. Also,
for division I did nothing special, as we can only +OVERFLOW.
Hopefully if (overflow) will still work with that.
It does.
Otherwise can you please add a toplevel comment to wide-int.h as to what the
overflow result semantically is for a) SIGNED and b) UNSIGNED operations?
Done. Let me know if the current comment is what you had in mind.
OK for trunk?
gcc/
* tree-vrp.c (vrp_int_const_binop): Change overflow type to
overflow_type.
(combine_bound): Use wide-int overflow calculation instead of
rolling our own.
* calls.c (maybe_warn_alloc_args_overflow): Change overflow type to
overflow_type.
* fold-const.c (int_const_binop_2): Same.
(extract_muldiv_1): Same.
(fold_div_compare): Same.
(fold_abs_const): Same.
* match.pd: Same.
* poly-int.h (add): Same.
(sub): Same.
(neg): Same.
(mul): Same.
* predict.c (predict_iv_comparison): Same.
* profile-count.c (slow_safe_scale_64bit): Same.
* simplify-rtx.c (simplify_const_binary_operation): Same.
* tree-chrec.c (tree_fold_binomial): Same.
* tree-data-ref.c (split_constant_offset_1): Same.
* tree-if-conv.c (idx_within_array_bound): Same.
* tree-scalar-evolution.c (iv_can_overflow_p): Same.
* tree-ssa-phiopt.c (minmax_replacement): Same.
* tree-vect-loop.c (is_nonwrapping_integer_induction): Same.
* tree-vect-stmts.c (vect_truncate_gather_scatter_offset): Same.
* vr-values.c (vr_values::adjust_range_with_scev): Same.
* wide-int.cc (wi::add_large): Same.
(wi::mul_internal): Same.
(wi::sub_large): Same.
(wi::divmod_internal): Same.
* wide-int.h: Change overflow type to overflow_type for neg, add,
mul, smul, umul, div_trunc, div_floor, div_ceil, div_round,
mod_trunc, mod_ceil, mod_round, add_large, sub_large,
mul_internal, divmod_internal.
(overflow_type): New enum.
gcc/cp/
* decl.c (build_enumerator): Change overflow type to overflow_type.
* init.c (build_new_1): Same.
diff --git a/gcc/calls.c b/gcc/calls.c
index 1970f1c51dd..2a08822d310 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1517,7 +1517,7 @@ maybe_warn_alloc_args_overflow (tree fn, tree exp, tree args[2], int idx[2])
wide_int x = wi::to_wide (argrange[0][0], szprec);
wide_int y = wi::to_wide (argrange[1][0], szprec);
- bool vflow;
+ wi::overflow_type vflow;
wide_int prod = wi::umul (x, y, &vflow);
if (vflow)
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 0ea3c4a3490..93773fa632d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14628,7 +14628,6 @@ build_enumerator (tree name, tree value, tree enumtype, tree attrib
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
> The result is good enough to bootstrap natively and seems to give reasonable > native testsuite results for a first attempt. The machine I'm running on > has broken icache flushing, so trampolines won't work, and I suspect that > is causing a lot of the testsuite failures. Ada doesn't use trampolines if you define... > + Always_Compatible_Rep : constant Boolean := False; ...this to False. -- Eric Botcazou
Re: [PATCH] C++: Fix PR86083
On 06/20/2018 01:41 PM, Andreas Krebbel wrote: > When turning a user-defined numerical literal into an operator > invocation the literal needs to be translated to the execution > character set. > > Bootstrapped and regtested on s390x. x86_64 still running. > Ok to apply if x86_64 is clean? > > Bye, > > -Andreas- > > gcc/cp/ChangeLog: > > 2018-06-20 Andreas Krebbel > > PR C++/86082 > * parser.c (make_char_string_pack): > (cp_parser_userdef_numeric_literal): > > gcc/testsuite/ChangeLog: > > 2018-06-20 Andreas Krebbel > > PR C++/86082 > * g++.dg/pr86082.C: New test. I've tested the patch also on GCC 7 and 8 branch. Ok to apply there as well? The backport will include the testcase fix from Rainer: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01601.html -Andreas-
Re: [PATCH, Ada] Makefile patches from initial RISC-V cross/native build.
> These are some patches I needed to complete my cross build of a native > riscv linux Ada compiler. Some paths were different on the build machine > and host machine. I needed to pass options into gnatmake to work around this, > and that required fixing some makefile rules to use $(GNATMAKE) instead of > calling gnatmake directly. > > Tested with native riscv-linux bootstrap with Ada enabled. > > OK? OK, thanks. > Jim > > gcc/ada/ > * Make-generated.in (treeprs.ads): Use $(GNATMAKE) instead of > gnatmake. > (einfo.h, sinfo.h, stamp-snames, stamp-nmake): Likewise. > * gcc-interface/Makefile.in (xoscons): Likewise.
Re: [PATCH, Ada] RISC-V: Initial riscv linux Ada port.
> Ada is a low priority side project for me, so if you want non-trivial changes > it may be a while before I can get to them. There is a lot of other stuff > higher on my priority list at the moment, such as getting native gdb support > working. If this isn't OK as is, then I'm willing to put work-in-progress > patches in a bug report or on a branch or something. > > OK? This is OK, thanks. > Jim > > gcc/ada/ > * Makefile.rtl: Add riscv*-linux* support. > * libgnarl/s-linux__riscv.ads: New. > * libgnat/system-linux-riscv.ads: New.
