Re: [PR89862] Fix ARM lto bootstrap
> I have also tested the patch with x86_64-linux-gnu with no new regressions. > Is this OK for trunk? Yes, but please put it on all active branches. -- Eric Botcazou
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On Thu, 28 Mar 2019, Jason Merrill wrote: > On 3/26/19 4:40 AM, Richard Biener wrote: > > On Mon, 18 Mar 2019, Richard Biener wrote: > > > > > On Fri, 15 Mar 2019, Jason Merrill wrote: > > > > > > > On 3/15/19 9:33 AM, Richard Biener wrote: > > > > > > > > > > The following is an attempt to fix PR71598 where C (and C++?) have > > > > > an implementation-defined compatible integer type for each enum > > > > > and the TBAA rules mandate that accesses using a compatible type > > > > > are allowed. > > > > > > > > This does not apply to C++; an enum does not alias its underlying type. > > > > > > Thus the following different patch, introducing c_get_alias_set and > > > only doing the special handling for C family frontends (I assume > > > that at least ObjC is also affected). > > > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > > > Ping. Also consider the additional testcase below to be added. > > > > Richard. > > > > 2019-03-18 Richard Biener > > > > PR c/71598 > > * gimple.c: Include langhooks.h. > > (gimple_get_alias_set): Treat enumeral types as the underlying > > integer type. > > Won't this affect all languages? It affects all languages during the LTO optimization phase, yes. There's unfortunately no way around that at the moment. Richard.
Re: [RS6000] PR89271, gcc.target/powerpc/vsx-simode2.c
Hi Iain, On Fri, Mar 29, 2019 at 01:32:28AM +, Iain Sandoe wrote: > > > On 28 Mar 2019, at 18:08, Segher Boessenkool > > wrote: > >> diff --git a/gcc/config/rs6000/darwin.h b/gcc/config/rs6000/darwin.h > >> index 9fb36e41e7d..20c59f89c8f 100644 > >> --- a/gcc/config/rs6000/darwin.h > >> +++ b/gcc/config/rs6000/darwin.h > >> @@ -346,7 +346,8 @@ extern int darwin_emit_branch_islands; > >> && reg_class_subset_p (BASE_REGS, (CLASS))) \ > >>? BASE_REGS \ > >>: (GET_MODE_CLASS (GET_MODE (X)) == MODE_INT\ > >> - && (CLASS) == GEN_OR_FLOAT_REGS)\ > >> + && ((CLASS) == GEN_OR_FLOAT_REGS\ > >> +|| (CLASS) == GEN_OR_VSX_REGS)) \ > >>? GENERAL_REGS \ > >>: (CLASS)) > > > > Darwin doesn't do VSX at all… > > Well.. Darwin doesn’t currently run on any CPU with VSX hardware… "Currently"? Do you have plans to change that? :-) > However, in their wisdom, the folks who were implementing it way back when > made Darwin have a soft implementation of V2DF and V2DI (in case that > matters, which seems unlikely in this context). > > > But maybe there is something that can get > > allocated to both FPRs and VRs, sure. And GPRs. > > not sure what is being asked or stated here - is there a question about ABI, > or > just the assertion that some quantities could be placed in GPRs, FPRs or VRs? > > (the latter seems reasonable to me, the former I’d need to think some more > about). It is mostly questioning if Darwin should have any VSX code. The change here seems to be harmless, but does it make much sense? Segher
Re: [RS6000] PR89271, gcc.target/powerpc/vsx-simode2.c
Hi Segher, > On 29 Mar 2019, at 09:33, Segher Boessenkool > wrote: > On Fri, Mar 29, 2019 at 01:32:28AM +, Iain Sandoe wrote: >> >>> On 28 Mar 2019, at 18:08, Segher Boessenkool >>> wrote: diff --git a/gcc/config/rs6000/darwin.h b/gcc/config/rs6000/darwin.h index 9fb36e41e7d..20c59f89c8f 100644 --- a/gcc/config/rs6000/darwin.h +++ b/gcc/config/rs6000/darwin.h @@ -346,7 +346,8 @@ extern int darwin_emit_branch_islands; && reg_class_subset_p (BASE_REGS, (CLASS))) \ ? BASE_REGS \ : (GET_MODE_CLASS (GET_MODE (X)) == MODE_INT \ - && (CLASS) == GEN_OR_FLOAT_REGS)\ + && ((CLASS) == GEN_OR_FLOAT_REGS\ +|| (CLASS) == GEN_OR_VSX_REGS)) \ ? GENERAL_REGS \ : (CLASS)) >>> >>> Darwin doesn't do VSX at all… >> >> Well.. Darwin doesn’t currently run on any CPU with VSX hardware… > > "Currently"? Do you have plans to change that? :-) Well .. we all have long-term objectives, right? :-) >> However, in their wisdom, the folks who were implementing it way back when >> made Darwin have a soft implementation of V2DF and V2DI (in case that >> matters, which seems unlikely in this context). >> >>> But maybe there is something that can get >>> allocated to both FPRs and VRs, sure. And GPRs. >> >> not sure what is being asked or stated here - is there a question about ABI, >> or >> just the assertion that some quantities could be placed in GPRs, FPRs or VRs? >> >> (the latter seems reasonable to me, the former I’d need to think some more >> about). > > It is mostly questioning if Darwin should have any VSX code. The change > here seems to be harmless, but does it make much sense? I don’t think it makes any sense to add any more overt VSX support (the oddity of soft support for the two VSX vector sizes mentioned is a pain when dealing with other compilers), thanks Iain
Re: [RS6000] PR89271, gcc.target/powerpc/vsx-simode2.c
Hi!
On Fri, Mar 29, 2019 at 04:00:55PM +1030, Alan Modra wrote:
> On Thu, Mar 28, 2019 at 01:08:55PM -0500, Segher Boessenkool wrote:
> > Darwin doesn't do VSX at all... But maybe there is something that can get
> > allocated to both FPRs and VRs, sure. And GPRs.
> >
> > This PREFERRED_RELOAD_CLASS, but it makes me worried if there are places
> > where we should care about this change for correctness.
>
> For sure there are other places. A new union register class trips all
> those places where union classes fail. For example,
> ira.c:setup_class_translate_array doesn't give useful answers for
> GEN_OR_VSX_REGS, or GEN_OR_FLOAT_REGS for that matter. That makes
> uses of ira_allocno_class_translate and ira_pressure_class_translate
> for pseudos suspect whenever one of the union classes is involved.
And not all of those places will fail in an obviouswayfail. Well, stage 1,
we'll find them all in time :-)
> rs6000_ira_change_pseudo_allocno_class helps of course, in that
> GEN_OR_VSX_REGS mostly won't be used.
Heh.
> > > @@ -34966,22 +34970,56 @@ rs6000_register_move_cost (machine_mode mode,
> > > reg_class_t from, reg_class_t to)
> > > {
> > >int ret;
> > > + reg_class_t rclass;
> > >
> > >if (TARGET_DEBUG_COST)
> > > dbg_cost_ctrl++;
> > >
> > > + /* If we have VSX, we can easily move between FPR or Altivec registers,
> > > + otherwise we can only easily move within classes.
> > > + Do this first so we give best-case answers for union classes
> > > + containing both gprs and vsx regs. */
> > > + HARD_REG_SET to_vsx, from_vsx;
> > > + COPY_HARD_REG_SET (to_vsx, reg_class_contents[to]);
> > > + AND_HARD_REG_SET (to_vsx, reg_class_contents[VSX_REGS]);
> > > + COPY_HARD_REG_SET (from_vsx, reg_class_contents[from]);
> > > + AND_HARD_REG_SET (from_vsx, reg_class_contents[VSX_REGS]);
> >
> > This is a bit expensive to run at every call of rs6000_register_move_cost.
> > Can it be precomputed easily?
>
> register_move_cost tends to be cached by callers of this function, so
> I'm inclined to go for simple and correct rather than fast and
> complicated.
The main problem is that every op on HARD_REG_SET can be *very* expensive.
It isn't obvious to a reader how big it is. But this is target code of
course, and for us it is only 128 bits these days. Okay.
> > > + {
> > > + if (TARGET_DIRECT_MOVE
> > > + && (rs6000_tune == PROCESSOR_POWER8
> > > + || rs6000_tune == PROCESSOR_POWER9))
> >
> > TARGET_DIRECT_MOVE is always on for these CPUs. Should this also use the
> > m*vsr* cost with say -mcpu=power7 -mtune=power9?
>
> No, because if we don't generate m*vsr*, and we shouldn't, then that
> would be telling a lie.
Then should we have those "tune" things in this conditional? Just do it
for any direct move target?
> > This list makes me think... Should there be a GEN_OR_ALTIVEC as well?
>
> That might make sense for pre-vsx processors, if you can find a
> testcase where the GENERAL_REGS cost is the same as ALTIVEC_REGS cost.
> Extending rs6000_ira_change_pseudo_allocno_class to handle
> GEN_OR_FLOAT_REGS and VSX_REGS for !TARGET_VSX might be an idea too.
>
> Where the cost for moves between float and altivec is low, you'll find
> that VSX_REGS is always used as the allocno class whenever
> ALTIVEC_REGS is preferred. So for power7 and later I expect
> GEN_OR_ALTIVEC_REGS wouldn't ever be used as an allocno class.
I was thinking for those instructions that work only on VRs. But those
already had variants that work on float (like lxssp), or they are insn
for quad precision float (ieee128), and those don't go in GPRs anyway.
So nothing to worry about :-)
Segher
Re: [PATCH][Tree-optimization/PR89730]grant always_inline when -flive-patching=inline-only-static
On Thu, Mar 28, 2019 at 6:53 PM Qing Zhao wrote: > > > > On Mar 28, 2019, at 11:30 AM, Qing Zhao wrote: > > > > Thanks. > > > > I updated ipa-inline.c as you suggested, and tested the gcc with all > > live-patching-*.c testing cases, all were fine. > > bootstrapped on aarch64, and now the regression testing is running. > > the regression test passed without any issue. OK. Thanks, Richard. > qing > > > > the new patch is as following: > > > > Okay for trunk? > > > > thanks. > > > > Qing > > > > gcc/ChangeLog: > > > > 2019-03-28 qing zhao > > > > PR tree-optimization/89730 > > * ipa-inline.c (can_inline_edge_p): Delete the checking for > > -flive-patching=inline-only-static. > > (can_inline_edge_by_limits_p): Add the checking for > > -flive-patching=inline-only-static and grant always_inline > > even when -flive-patching=inline-only-static is specified. > > > > > > gcc/testsuite/ChangeLog: > > > > 2019-03-28 qing zhao > > > > PR tree-optimization/89730 > > * gcc.dg/live-patching-4.c: New test. > > > > >
[PATCH] Enhance option suggestion for options expected an argument (PR driver/89861).
Hi.
The patch enhances option suggestion for options that expect
an argument.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-03-29 Martin Liska
PR driver/89861
* opt-suggestions.c (option_proposer::build_option_suggestions):
Add variant without any argument in order to provide better
hints.
gcc/testsuite/ChangeLog:
2019-03-29 Martin Liska
PR driver/89861
* gcc.dg/spellcheck-options-18.c: New test.
* gcc.dg/spellcheck-options-19.c: New test.
* gcc.dg/spellcheck-options-20.c: New test.
* gcc.dg/spellcheck-options-13.c: Adjust expected output.
* gcc.dg/completion-2.c: Add one variant with no argument.
---
gcc/opt-suggestions.c| 8
gcc/testsuite/gcc.dg/completion-2.c | 1 +
gcc/testsuite/gcc.dg/spellcheck-options-13.c | 2 +-
gcc/testsuite/gcc.dg/spellcheck-options-18.c | 3 +++
gcc/testsuite/gcc.dg/spellcheck-options-19.c | 3 +++
gcc/testsuite/gcc.dg/spellcheck-options-20.c | 3 +++
6 files changed, 19 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/spellcheck-options-18.c
create mode 100644 gcc/testsuite/gcc.dg/spellcheck-options-19.c
create mode 100644 gcc/testsuite/gcc.dg/spellcheck-options-20.c
diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
index c14c29d3083..415dcc9fc45 100644
--- a/gcc/opt-suggestions.c
+++ b/gcc/opt-suggestions.c
@@ -134,6 +134,10 @@ option_proposer::build_option_suggestions (const char *prefix)
with_arg);
free (with_arg);
}
+
+ /* Add also variant without an option argument. */
+ add_misspelling_candidates (m_option_suggestions, option,
+ opt_text);
}
else
{
@@ -172,6 +176,10 @@ option_proposer::build_option_suggestions (const char *prefix)
"-fsanitize=address"
rather than to "-Wframe-address" (PR driver/69265). */
{
+ /* Add also variant without an option argument. */
+ add_misspelling_candidates (m_option_suggestions, option,
+ opt_text);
+
for (int j = 0; sanitizer_opts[j].name != NULL; ++j)
{
struct cl_option optb;
diff --git a/gcc/testsuite/gcc.dg/completion-2.c b/gcc/testsuite/gcc.dg/completion-2.c
index ac7508591de..166bfdc1424 100644
--- a/gcc/testsuite/gcc.dg/completion-2.c
+++ b/gcc/testsuite/gcc.dg/completion-2.c
@@ -7,4 +7,5 @@
-flto-partition=max
-flto-partition=none
-flto-partition=one
+-flto-partition=
{ dg-end-multiline-output "" } */
diff --git a/gcc/testsuite/gcc.dg/spellcheck-options-13.c b/gcc/testsuite/gcc.dg/spellcheck-options-13.c
index 19b63af565b..0d00642d87e 100644
--- a/gcc/testsuite/gcc.dg/spellcheck-options-13.c
+++ b/gcc/testsuite/gcc.dg/spellcheck-options-13.c
@@ -2,4 +2,4 @@
/* { dg-do compile } */
/* { dg-options "-fsanitize" } */
-/* { dg-error "unrecognized command line option .-fsanitize..$" "" { target *-*-* } 0 } */
+/* { dg-error "unrecognized command line option '-fsanitize'; did you mean '-fsanitize='?" "" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.dg/spellcheck-options-18.c b/gcc/testsuite/gcc.dg/spellcheck-options-18.c
new file mode 100644
index 000..387d04e3743
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/spellcheck-options-18.c
@@ -0,0 +1,3 @@
+/* { dg-do compile } */
+/* { dg-options "-fprofile-update" } */
+/* { dg-error "unrecognized command line option '-fprofile-update'; did you mean '-fprofile-update='?" "" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.dg/spellcheck-options-19.c b/gcc/testsuite/gcc.dg/spellcheck-options-19.c
new file mode 100644
index 000..5a104763993
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/spellcheck-options-19.c
@@ -0,0 +1,3 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-sanitize" } */
+/* { dg-error "unrecognized command line option '-fno-sanitize'; did you mean '-fno-sanitize='?" "" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.dg/spellcheck-options-20.c b/gcc/testsuite/gcc.dg/spellcheck-options-20.c
new file mode 100644
index 000..dfc6149e023
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/spellcheck-options-20.c
@@ -0,0 +1,3 @@
+/* { dg-do compile } */
+/* { dg-options "-Walloc-size-larger-than" } */
+/* { dg-error "unrecognized command line option '-Walloc-size-larger-than'; did you mean '-Walloc-size-larger-than='?" "" { target *-*-* } 0 } */
[PATCH] Fix PR83033
Hi all, simple patch addressing minor style issue into gcc/config/aarch64/cortex-a57-fma-steering.c. make BOOT_CFLAGS='-mcpu=cortex-a57' bootstrap Okay for trunk? Bests Andrea 2019-03-29 Andrea Corallo PR target/83033 * config/aarch64/cortex-a57-fma-steering.c (fma_forest): Fix missing copy constructor. (fma_root_node): Likewise. (func_fma_steering): Likewise. diff --git a/gcc/config/aarch64/cortex-a57-fma-steering.c b/gcc/config/aarch64/cortex-a57-fma-steering.c index f2da03a..a390a62 100644 --- a/gcc/config/aarch64/cortex-a57-fma-steering.c +++ b/gcc/config/aarch64/cortex-a57-fma-steering.c @@ -114,6 +114,8 @@ public: void dispatch (); private: + fma_forest (const fma_forest &); + /* The list of roots that form this forest. */ std::list *m_roots; @@ -180,6 +182,8 @@ public: void dump_info (fma_forest *); private: + fma_root_node (const fma_root_node &); + /* The forest this node belonged to when it was created. */ fma_forest *m_forest; }; @@ -203,6 +207,7 @@ public: void execute_fma_steering (); private: + func_fma_steering (const func_fma_steering &); void dfs (void (*) (fma_forest *), void (*) (fma_forest *, fma_root_node *), void (*) (fma_forest *, fma_node *), bool); void analyze ();
Re: [PATCH] Fix PR83033
Hi Alejandro, On 3/29/19 11:01 AM, Andrea Corallo wrote: Hi all, simple patch addressing minor style issue into gcc/config/aarch64/cortex-a57-fma-steering.c. make BOOT_CFLAGS='-mcpu=cortex-a57' bootstrap Okay for trunk? Bests Andrea Thanks for the patch. This looks ok to me but you'll need approval from an aarch64 maintainer (I've CC'ed them for you) Kyrill 2019-03-29 Andrea Corallo PR target/83033 * config/aarch64/cortex-a57-fma-steering.c (fma_forest): Fix missing copy constructor. (fma_root_node): Likewise. (func_fma_steering): Likewise.
Re: [RS6000] PR89271, gcc.target/powerpc/vsx-simode2.c
On Fri, Mar 29, 2019 at 04:47:21AM -0500, Segher Boessenkool wrote:
> On Fri, Mar 29, 2019 at 04:00:55PM +1030, Alan Modra wrote:
> > On Thu, Mar 28, 2019 at 01:08:55PM -0500, Segher Boessenkool wrote:
> > > TARGET_DIRECT_MOVE is always on for these CPUs. Should this also use the
> > > m*vsr* cost with say -mcpu=power7 -mtune=power9?
> >
> > No, because if we don't generate m*vsr*, and we shouldn't, then that
> > would be telling a lie.
>
> Then should we have those "tune" things in this conditional? Just do it
> for any direct move target?
Oh, right. I think we still need to "tune" the cost to reflect
actual hardware, but that shouldn't be in the outer condition. So
if (TARGET_DIRECT_MOVE)
{
if (rs6000_tune != PROCESSOR_POWER9)
ret = 4 * hard_regno_nregs (0, mode);
else
ret = 2 * hard_regno_nregs (0, mode);
...
should be good enough.
--
Alan Modra
Australia Development Lab, IBM
Re: [PATCH, RFC] Wrong warning message fix for gcc 9
Martin Sebor wrote 2019-03-28 22:44:
On 3/28/19 11:49 AM, Roman Zhuykov wrote:
Ping
A week ago I decided it is so minor that I can report here with a
patch without creating bugzilla PR.
Technically it is a "9 regression" in new functionality added back in
summer.
Patch was succesfully bootstrapped and regtested on x86_64.
Ok for trunk?
Have found an option, which passes buggy function and all subsequent
checks:
"-fdiagnostics-minimum-margin-width=-1" gives an error, but
"-fdiagnostics-minimum-margin-width=42xyz" silently sets it to -1 :)
Thanks for the patch! The change makes sense to me. Can you
please also add a test case to the test suite?
Added the test, is such filename (and contents) ok ?
I can't approve patches, even obvious ones, so please wait for
an approval from a maintainer before committing it.
CC'ed to "option handling" maintainer here.
--
Roman
gcc/testsuite/ChangeLog:
2019-03-29 Roman Zhuykov
* gcc.dg/diag-sanity.c: New test.
gcc/ChangeLog:
2019-03-29 Roman Zhuykov
* opts-common.c (integral_argument): Set errno properly in one case.
diff --git a/gcc/opts-common.c b/gcc/opts-common.c
--- a/gcc/opts-common.c
+++ b/gcc/opts-common.c
@@ -205,8 +205,10 @@ integral_argument (const char *arg, int *err, bool
byte_size_suffix)
value = strtoull (arg, &end, 0);
if (*end)
{
- /* errno is most likely EINVAL here. */
- *err = errno;
+ if (errno)
+ *err = errno;
+ else
+ *err = EINVAL;
return -1;
}
diff --git a/gcc/testsuite/gcc.dg/diag-sanity.c
b/gcc/testsuite/gcc.dg/diag-sanity.c
new file mode 100644
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/diag-sanity.c
@@ -0,0 +1,7 @@
+/* Verify that an invalid argument is diagnosed correcly.
+ { dg-do compile }
+ { dg-options "-fdiagnostics-minimum-margin-width=42xyz
-flto-compression-level=2-O2" } */
+
+
+/* { dg-error "argument to '-fdiagnostics-minimum-margin-width=' should
be a non-negative integer" "" { target *-*-* } 0 }
+ { dg-error "argument to '-flto-compression-level=' should be a
non-negative integer" "" { target *-*-* } 0 } */
Martin
чт, 21 мар. 2019 г. в 18:53, Roman Zhuykov :
Hello, I have found a minor diagnostic issue.
Since r262910 we got a little odd error messages in cases like this:
$ gcc -flto-compression-level=2-O2 -c empty.c
gcc: error: argument to '-flto-compression-level=' is not between 0
and 9
$ g++ -fabi-version=2-O2 -c empty.cpp
cc1plus: error: '-fabi-version=1' is no longer supported
Old messages were more correct:
$ gcc-8 -flto-compression-level=2-O2 -c empty.c
gcc: error: argument to '-flto-compression-level=' should be a
non-negative integer
$ g++-8 -fabi-version=2-O2 -c empty.cpp
g++: error: argument to '-fabi-version=' should be a non-negative
integer
When UInteger option value string is not a number, but it's first
char
is a digit, integral_argument function returns -1 without setting
*err.
Proposed untested patch attached.
--
Best Regards,
Roman Zhuykov
gcc/ChangeLog:
2019-03-21 Roman Zhuykov
* opts-common.c (integral_argument): Set errno properly in one case.
diff --git a/gcc/opts-common.c b/gcc/opts-common.c
--- a/gcc/opts-common.c
+++ b/gcc/opts-common.c
@@ -205,8 +205,10 @@ integral_argument (const char *arg, int *err,
bool byte_size_suffix)
value = strtoull (arg, &end, 0);
if (*end)
{
- /* errno is most likely EINVAL here. */
- *err = errno;
+ if (errno)
+ *err = errno;
+ else
+ *err = EINVAL;
return -1;
}
Re: Implement C++20 constexpr , , and
Greetings, This patch implements C++20 constexpr for , , . It's a large patch but only affects C++20 and the volume is mostly test cases. This differs from the previous patch in actually testing constexpr :-\ and in the addition of wrappers for __builtin_memmove and __builtin_memcmp that supply constexpr branches if C++20 and is_constant_evaluated(). This builds and tests clean on x86_64-linux. OK? 2019-03-29 Edward Smith-Rowland <3dw...@verizon.net> Implement C++20 p0202 - Add Constexpr Modifiers to Functions in and Headers. Implement C++20 p1023 - constexpr comparison operators for std::array. * include/bits/algorithmfwd.h (all_of, any_of, binary_search, copy, copy_backward, copy_if, copy_n, equal_range, fill, fill_n, find_end, find_if_not, includes, is_heap, is_heap_until, is_partitioned, is_permutation, is_sorted, is_sorted_until, lower_bound, none_of, partition_copy, partition_point, remove, remove_if, remove_copy, remove_copy_if, replace_copy, replace_copy_if, reverse_copy, rotate_copy, unique, upper_bound, adjacent_find, count, count_if, equal, find, find_first_of, find_if, for_each, generate, generate_n, lexicographical_compare, merge, mismatch, replace, replace_if, search, search_n, set_difference, set_intersection, set_symmetric_difference, set_union, transform, unique_copy): Mark constexpr. Make versions of operator() const. * include/bits/cpp_type_traits.h (__miter_base): Make constexpr. * include/bits/predefined_ops.h (_Iter_less_val, __iter_comp_val, _Val_less_iter, __val_less_iter, __val_comp_iter, _Iter_equal_to_iter, __iter_equal_to_iter, _Iter_equal_to_val, __iter_equal_to_val, _Iter_comp_val, __iter_comp_val, _Val_comp_iter, __val_comp_iter, _Iter_equals_val, __iter_equals_val, _Iter_equals_iter, __iter_comp_iter, __pred_iter, __iter_comp_val, __negate): Constexpr ctors. Add const operator(). * include/bits/stl_algo.h (__find_if, __find_if_not, __find_if_not_n, __search, __search_n_aux, __search_n, __find_end, find_end, all_of none_of, any_of, find_if_not, is_partitioned, partition_point, __remove_copy_if, remove_copy, remove_copy_if, copy_if, __copy_n, copy_n, partition_copy, __remove_if, remove, remove_if, __adjacent_find, __unique, unique, __unique_copy, reverse_copy, rotate_copy, __unguarded_linear_insert, __insertion_sort, __unguarded_insertion_sort, __final_insertion_sort, lower_bound, __upper_bound, upper_bound, __equal_range, equal_range, binary_search, __includes, includes, __next_permutation, __prev_permutation, __replace_copy_if, replace_copy, replace_copy_if, __count_if, is_sorted, __is_sorted_until, is_sorted_until, __is_permutation, is_permutation, for_each, find, find_if, find_first_of, adjacent_find, count, count_if, search, search_n, transform, replace, replace_if, generate, generate_n, unique_copy, __merge, merge, __set_union, set_union, __set_intersection, set_intersection, __set_difference, set_difference, __set_symmetric_difference, set_symmetric_difference): Constexpr. * include/bits/stl_algobase.h (__niter_base, __niter_wrap, __copy_m, __copy_move_a, copy, move, __copy_move_backward::__copy_move_b, __copy_move_backward_a, __copy_move_backward_a2, copy_backward, move_backward, fill, __fill_a, __fill_n_a, fill_n, __equal::equal, __equal_aux, __newlast1, __cnd2, __newlast1, __cnd2, __lexicographical_compare_impl, __lexicographical_compare::__lc, __lexicographical_compare, __lexicographical_compare_aux, __lower_bound, lower_bound, equal, __equal4, lexicographical_compare, __mismatch, mismatch): Constexpr. (__memmove, __memcmp): New constexpr wrappers. * include/bits/stl_heap.h (__is_heap_until, __is_heap, is_heap_until, is_heap): Constexpr. * include/bits/stl_iterator.h (__niter_base, __miter_base): Constexpr. * include/std/array: Make comparison ops constexpr. * include/std/utility: Make exchange constexpr. * testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust. * testsuite/23_containers/array/tuple_interface/ tuple_element_neg.cc: Adjust. * testsuite/25_algorithms/copy_n/58982.cc: Adjust error scan. * testsuite/25_algorithms/copy/58982.cc: Adjust error scan. * testsuite/20_util/exchange/constexpr.cc: New. * testsuite/23_containers/array/comparison_operators/constexpr.cc: New. * testsuite/25_algorithms/headers/algorithm/synopsis.cc: Constexpr. * testsuite/25_algorithms/adjacent_find/constexpr.cc: New. * testsuite/25_algorithms/all_of/constexpr.cc: New. * testsuite/25_algorithms/any_of/constexpr.cc: New. * testsu
Re: Implement C++20 constexpr , , and
On Fri, Mar 29, 2019 at 09:10:26AM -0400, Ed Smith-Rowland via gcc-patches
wrote:
> Greetings,
>
> This patch implements C++20 constexpr for , , .
>
> It's a large patch but only affects C++20 and the volume is mostly test
> cases.
>
> This differs from the previous patch in actually testing constexpr :-\ and
> in the addition of wrappers for __builtin_memmove and __builtin_memcmp that
> supply constexpr branches if C++20 and is_constant_evaluated().
+void*
+__memmove(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
+{
+#if __cplusplus > 201703L
+ if (is_constant_evaluated())
+ {
+ for(; __num > 0; --__num)
+ {
+ *__dst = *__src;
+ ++__src;
+ ++__dst;
+ }
+ return __dst;
+ }
+ else if (__num)
+#endif
+ return __builtin_memmove(__dst, __src, sizeof(_Tp) * abs(__num));
+ return __dst;
...
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
+ __memmove(__result, __first, _Num);
...
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
+ __memmove(__result - _Num, __first, _Num);
Why the abs in there, that is something that wasn't previously there and
if the compiler doesn't figure out that __last >= __first, it would mean
larger emitted code for the non-constexpr case. As memmove argument is
size_t, wouldn't it be better to make __num just size_t and remove this abs?
Also, wouldn't it be better to have on the other side the __num == 0
handling inside of __memmove, you already have it there for C++2a, but not
for older. You could then drop the if (_Num) guards around __memmove.
Also, shouldn't the is_constant_evaluated() calls be guarded with
_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED ? Without that it won't be
defined...
Jakub
Re: [PATCH, wwwdocs] Mention -march=armv8.5-a and other new command line options for AArch64 and Arm for GCC 9
Hi James On 22/03/2019 16:25, James Greenhalgh wrote: > On Wed, Mar 20, 2019 at 10:17:41AM +, Sudakshina Das wrote: >> Hi Kyrill >> >> On 12/03/2019 12:03, Kyrill Tkachov wrote: >>> Hi Sudi, >>> >>> On 2/22/19 10:45 AM, Sudakshina Das wrote: Hi This patch documents the addition of the new Armv8.5-A and corresponding extensions in the gcc-9/changes.html. As per https://gcc.gnu.org/about.html, I have used W3 Validator. Is this ok for cvs? Thanks Sudi >>> >>> >>> Index: htdocs/gcc-9/changes.html >>> === >>> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v >>> retrieving revision 1.43 >>> diff -u -r1.43 changes.html >>> --- htdocs/gcc-9/changes.html 21 Feb 2019 10:32:55 - 1.43 >>> +++ htdocs/gcc-9/changes.html 21 Feb 2019 18:25:09 - >>> @@ -283,6 +283,19 @@ >>> >>> The intrinsics are defined by the ACLE specification. >>> >>> + >>> + The Armv8.5-A architecture is now supported. This can be used by >>> specifying the >>> + -march=armv8.5-a option. >>> >>> >>> I tend to prefer the wording "... is now supported through the >>> -march=armv8.5-a option". >>> Otherwise it reads as the compiler "using" the architecture, whereas we >>> usually talk about "targeting" an architecture. >>> >>> + >>> + The Armv8.5-A architecture also adds some security features that >>> are optional to all older >>> + architecture versions. These are also supported now and only effect >>> the assembler. >>> + >>> + Speculation Barrier instruction using >>> -march=armv8-a+sb. >>> + Execution and Data Prediction Restriction instructions using >>> -march=armv8-a+predres. >>> + Speculative Store Bypass Safe instruction using >>> -march=armv8-a+ssbs. This does not >>> + require a compiler option for Arm and thus >>> -march=armv8-a+ssbs is a AArch64 specific option. >>> >>> "AArch64-specific" >>> >>> >>> LGTM otherwise. >>> Thanks, >>> Kyrill >> >> Thanks for the review and sorry for the delay in response. I had edited >> the language for adding new options in a few other places as well. >> >> + The Armv8.5-A architecture also adds some security features that are >> +optional to all older architecture versions. These are also supported >> now > > s/also supported now/now supported/ > >> +and only effect the assembler. > > s/effect/affect/ > >> + >> + Speculation Barrier instruction through the >> + -march=armv8-a+sb option. >> + Execution and Data Prediction Restriction instructions through >> + the -march=armv8-a+predres option. >> + Speculative Store Bypass Safe instruction through the >> + -march=armv8-a+ssbs option. This does not require a >> + compiler option for Arm and thus -march=armv8-a+ssbs >> + is an AArch64-specific option. >> + >> + >> >> >> AArch64 specific >> @@ -362,6 +380,23 @@ >> The default value is 16 (64Kb) and can be changed at configure >> time using the flag >> --with-stack-clash-protection-guard-size=12|16. >> >> + >> +The option -msign-return-address= has been deprecated. This >> +has been replaced by the new -mbranch-protection= option. >> This >> +new option can now be used to enable the return address signing as well >> as >> +the new Branch Target Identification feature of Armv8.5-A architecture. >> For >> +more information on the arguments accepted by this option, please refer >> to >> + > href="https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options";>AArch64-Options. >> + >> + The following optional extensions to Armv8.5-A architecture are also >> + supported now and only effect the assembler. > > s/effect/affect/ > >> + >> + Random Number Generation instructions through the >> + -march=armv8.5-a+rng option. >> + Memory Tagging Extension through the >> + -march=armv8.5-a+memtag option. >> + >> + >> >> >> Arm specific > > Otherwise, OK by me but feel free to wait for people with gooder > grammar than me to have their say. > Thanks for spotting those. So far no one else with gooder grammar has pointed out anything else. I will commit the patch with the changes you suggested on Monday if no one else has any other objections. Thanks Sudi > Thanks, > James >
[PATCH] Fix GIMPLE part of PR87984
The following patch addresses the issue that asms which clobber
hard registers are no optimization barriers for local hardreg
vars on GIMPLE.
Bootstrapped / tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
2019-03-29 Richard Biener
PR tree-optimization/87984
* gimple.c (gimple_asm_clobbers_memory_p): Treat asms
which clobber registers as modifying memory.
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 270012)
+++ gcc/gimple.c(working copy)
@@ -2727,11 +2738,16 @@ gimple_asm_clobbers_memory_p (const gasm
{
unsigned i;
+ /* While strictly speaking only a "memory" clobber denotes clobbering
+ memory in GIMPLE we also treat local hard-register variables as
+ memory so simply treat all clobbers as memory. The only exception
+ is the special clobber "cc". */
for (i = 0; i < gimple_asm_nclobbers (stmt); i++)
{
tree op = gimple_asm_clobber_op (stmt, i);
- if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "memory") == 0)
- return true;
+ if (strcmp (TREE_STRING_POINTER (TREE_VALUE (op)), "cc") == 0)
+ continue;
+ return true;
}
/* Non-empty basic ASM implicitly clobbers memory. */
[PATCH, GCC, AARCH64] Add GNU note section with BTI and PAC.
Hi
This patch adds the GNU NOTE section to the BTI and/or PAC
enabled objects for linux targets.
The ABI document that we published mentioning GNU NOTE section is below:
https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2018q4
The patches needed for these in binutils are already approved and committed.
https://sourceware.org/ml/binutils/2019-03/msg00072.html
Bootstrapped and regression tested with aarch64-none-linux-gnu.
Is this ok for trunk?
Thanks
Sudi
*** gcc/ChangeLog ***
2018-xx-xx Sudakshina Das
* config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END): Define for
AArch64.
(aarch64_file_end_indicate_exec_stack): Add gnu note section.
gcc/testsuite/ChangeLog:
2018-xx-xx Sudakshina Das
* gcc.target/aarch64/bti-1.c: Add scan directive for gnu note section
for linux targets.
* gcc.target/aarch64/va_arg_1.c: Don't run for aarch64 linux
targets
with --enable-standard-branch-protection.
diff --git a/gcc/config/aarch64/aarch64-linux.h b/gcc/config/aarch64/aarch64-linux.h
index 9d0292d64f20939ccedd7ab56027aa1282826b23..5e8b34ded03c78493f868e38647bf57c2da5187c 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -83,7 +83,7 @@
#define GNU_USER_TARGET_D_CRITSEC_SIZE 48
-#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
+#define TARGET_ASM_FILE_END aarch64_file_end_indicate_exec_stack
/* Uninitialized common symbols in non-PIE executables, even with
strong definitions in dependent shared libraries, will resolve
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b38505b0872688634b2d3f625ab8d313e89cfca0..d616c8360b396ebe3ab2ac0fb799b30830df2b3e 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -18744,6 +18744,67 @@ aarch64_stack_protect_guard (void)
return NULL_TREE;
}
+/* Implement TARGET_ASM_FILE_END for AArch64. This adds the AArch64 GNU NOTE
+ section at the end if needed. */
+#define ASM_LONG "\t.long\t"
+#define GNU_PROPERTY_AARCH64_FEATURE_1_AND 0xc000
+#define GNU_PROPERTY_AARCH64_FEATURE_1_BTI (1U << 0)
+#define GNU_PROPERTY_AARCH64_FEATURE_1_PAC (1U << 1)
+void
+aarch64_file_end_indicate_exec_stack ()
+{
+ file_end_indicate_exec_stack ();
+
+ if (!aarch64_bti_enabled ()
+ && aarch64_ra_sign_scope == AARCH64_FUNCTION_NONE)
+{
+ return;
+}
+
+ unsigned feature_1_and = 0;
+ if (aarch64_bti_enabled ())
+feature_1_and |= GNU_PROPERTY_AARCH64_FEATURE_1_BTI;
+
+ if (aarch64_ra_sign_scope != AARCH64_FUNCTION_NONE)
+feature_1_and |= GNU_PROPERTY_AARCH64_FEATURE_1_PAC;
+
+ if (feature_1_and)
+{
+ int p2align = ptr_mode == SImode ? 2 : 3;
+
+ /* Generate GNU_PROPERTY_AARCH64_FEATURE_1_XXX. */
+ switch_to_section (get_section (".note.gnu.property",
+ SECTION_NOTYPE, NULL));
+
+ ASM_OUTPUT_ALIGN (asm_out_file, p2align);
+ /* name length. */
+ fprintf (asm_out_file, ASM_LONG " 1f - 0f\n");
+ /* data length. */
+ fprintf (asm_out_file, ASM_LONG " 4f - 1f\n");
+ /* note type: NT_GNU_PROPERTY_TYPE_0. */
+ fprintf (asm_out_file, ASM_LONG " 5\n");
+ fprintf (asm_out_file, "0:\n");
+ /* vendor name: "GNU". */
+ fprintf (asm_out_file, STRING_ASM_OP " \"GNU\"\n");
+ fprintf (asm_out_file, "1:\n");
+ ASM_OUTPUT_ALIGN (asm_out_file, p2align);
+ /* pr_type: GNU_PROPERTY_AARCH64_FEATURE_1_AND. */
+ fprintf (asm_out_file, ASM_LONG " 0x%x\n",
+ GNU_PROPERTY_AARCH64_FEATURE_1_AND);
+ /* pr_datasz. */\
+ fprintf (asm_out_file, ASM_LONG " 3f - 2f\n");
+ fprintf (asm_out_file, "2:\n");
+ /* GNU_PROPERTY_AARCH64_FEATURE_1_XXX. */
+ fprintf (asm_out_file, ASM_LONG " 0x%x\n", feature_1_and);
+ fprintf (asm_out_file, "3:\n");
+ ASM_OUTPUT_ALIGN (asm_out_file, p2align);
+ fprintf (asm_out_file, "4:\n");
+}
+}
+#undef GNU_PROPERTY_AARCH64_FEATURE_1_PAC
+#undef GNU_PROPERTY_AARCH64_FEATURE_1_BTI
+#undef GNU_PROPERTY_AARCH64_FEATURE_1_AND
+#undef ASM_LONG
/* Target-specific selftests. */
diff --git a/gcc/testsuite/gcc.target/aarch64/bti-1.c b/gcc/testsuite/gcc.target/aarch64/bti-1.c
index a8c60412e310a4f322372f334ae5314f426d310e..5a556b08ed15679b25676a11fe9c7a64641ee671 100644
--- a/gcc/testsuite/gcc.target/aarch64/bti-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/bti-1.c
@@ -61,3 +61,4 @@ lab2:
}
/* { dg-final { scan-assembler-times "hint\t34" 1 } } */
/* { dg-final { scan-assembler-times "hint\t36" 12 } } */
+/* { dg-final { scan-assembler ".note.gnu.property" { target *-*-linux* } } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/va_arg_1.c b/gcc/testsuite/gcc.target/aarch64/va_arg_1.c
index e8e3cdac51350b545e5c2a644a3e1f4d1c37f88d..1fe92ff08935d4c6f08affcbd77ea91537030640 100644
--- a/gcc/testsuite/gcc.target/aarch64/va_arg_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/va_arg_1.c
@@ -4,7 +4,9 @@
int
f
Re: [PATCH] Fix PR83033
On 3/29/19 12:10 PM, Kyrill Tkachov wrote: Hi Alejandro, Sorry, I meant to say Andrea! Kyrill On 3/29/19 11:01 AM, Andrea Corallo wrote: > Hi all, > simple patch addressing minor style issue into > gcc/config/aarch64/cortex-a57-fma-steering.c. > > make BOOT_CFLAGS='-mcpu=cortex-a57' bootstrap > > Okay for trunk? > > Bests > Andrea > Thanks for the patch. This looks ok to me but you'll need approval from an aarch64 maintainer (I've CC'ed them for you) Kyrill > > 2019-03-29 Andrea Corallo > > PR target/83033 > * config/aarch64/cortex-a57-fma-steering.c > (fma_forest): Fix missing copy constructor. > (fma_root_node): Likewise. > (func_fma_steering): Likewise. >
[PATCH][DOC][OBVIOUS] Remove -Wchkp from documentation.
Hi.
That's one obvious patch where I remove the option from documentation.
Martin
gcc/ChangeLog:
2019-03-29 Martin Liska
* doc/invoke.texi: Remove -Wchkp from documentation.
---
gcc/doc/invoke.texi | 6 --
1 file changed, 6 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1787967d753..0e179c6357c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4500,12 +4500,6 @@ of error, as programmers often forget that this type is signed on some
machines.
This warning is enabled by @option{-Wall}.
-@item -Wchkp
-@opindex Wchkp
-@opindex Wno-chkp
-Warn about an invalid memory access that is found by Pointer Bounds Checker
-(@option{-fcheck-pointer-bounds}).
-
@item -Wno-coverage-mismatch
@opindex Wno-coverage-mismatch
@opindex Wcoverage-mismatch
Re: [C++ debug PATCH] [PR88534] accept VAR_DECL in class literal template parms
On 3/28/19 7:54 PM, Martin Sebor wrote:
On 3/28/19 11:45 AM, Jason Merrill wrote:
On 3/27/19 6:56 PM, Martin Sebor wrote:
On 3/27/19 3:11 PM, Martin Sebor wrote:
On 3/27/19 4:44 AM, Jonathan Wakely wrote:
On 21/03/19 15:03 -0400, Jason Merrill wrote:
On 3/20/19 6:06 PM, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 10:58:32PM +0100, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 05:55:04PM -0400, Marek Polacek wrote:
On Wed, Mar 20, 2019 at 04:56:33PM -0300, Alexandre Oliva wrote:
On Mar 20, 2019, Marek Polacek wrote:
This test fails with
pr88534.C:58:1: sorry, unimplemented: string literal in
function template signature
Interesting... gcc-8 rejected it with an error message
rejecting the
template parameter, but my latest trunk build (dated Mar 13,
r269641)
compiles it all right. Was there a subsequent fix, maybe? I
didn't
realize it was supposed to be rejected.
Ah, that problem only started with r269814, namely this hunk:
Maybe this is done too early and should be postponed to
genericization
(perhaps except for TREE_STATIC vars)?
Or skip when DECL is template_parm_object_p.
Or handle it in mangle.c. I don't see any reason we shouldn't accept
struct A
{
char c[4];
};
template struct B { };
B b;
Probably we should use the same mangling whether the initializer
for c was spelled as a string literal or list of integers.
The thing we still don't want to allow is mangling the *address*
of a string literal.
Will that help PR 47488 as well?
What I have (attached) accepts all three test cases from PR 47488
(comment #0, #1, #2, and #5) but with different mangling.
The difference in the mangling of the function in the test case
in comment #0 is
Clang: _Z1gIiEDTcl1fcvT__ELA1_KcEEERKS0_
GCC 9: _Z1gIiEDTcl1fcvT__ELKc0EEERKS0_
I'm not very familiar with the C++ ABI mangling but from what
I can tell, Clang treats the type as a literal array of 1 const
char element (LA1_Kc) without actually encoding its value, while
with my patch GCC encodes it as a constant literal initializer
consisting of 1 null char (LKc0). In other words, Clang would
mangle these two the same for the same T:
template < typename T >
decltype (f (T(), "123")) g (const T&);
template < typename T >
decltype (f (T(), "abc")) g (const T&);
while GCC would mangle them differently.
Which is correct? Clang's seems correct in this case but would
it also be correct to mangle Jason's B the same as
B?
After some poking around I found the issue below that seems
to answer the question at least for Jason's example:
https://github.com/itanium-cxx-abi/cxx-abi/issues/64
But this is an open issue that leaves some other questions
unanswered, mainly that of the exact encoding of the literal
(the length of the directly encoded subsequence and the hash
algorithm to compute the hash value of the string).
In any event, using the same encoding as for initializer
lists (i.e., (elt-type, elt-value)...) doesn't follow this
approach.
Should I prototype the solution outlined in the issue for
GCC 9?
I think let's leave that for the future, and use the aggregate
encoding for GCC 9.
I suppose there's still the question of compatibility between
initializer lists and string literals, namely whether this
B
is supposed to mangle the same as
B
The ABI issue only talks about string literals and not braced
initializer lists. I see in Revision History [150204] Add
mangling for braced initializer lists, so presumably there
is a difference, but I can't find what it is.
The issue for mangling template arguments of class type is
https://github.com/itanium-cxx-abi/cxx-abi/issues/63
Whoops. Off-by-one error. Thanks!
The mangling of braced-init-lists is
# type {expr-list}, conversion with braced-init-list argument
::= tl * E
# {expr-list}, braced-init-list in any other context
::= il * E
Your patch doesn't use this mangling. Here's a variant of my example
that actually causes these to show up in the mangling:
struct A { char c[4]; };
template struct B { };
void f(B) {}
void g(B) {}
Right, that's also what I'm testing. There are few interesting
variations. Given
struct A { char c[5]; };
all of these are equivalent and so should mangle the same:
void f (B) {}
void f (B) {}
void f (B) {}
void f (B) {}
void f (B) {}
Interior nuls need to be mangled but the trailing ones, either
explicit or implicit, don't. That also needs to be specified
in the ABI.
Agreed, good thought.
I believe we also need to handle these the same, both during
overloading and mangling:
void f (B) {}
void f (B) {}
void f (B) {}
void f (B) {}
Indeed.
GCC currently treats them as distinct irrespective of A's member's
type. I opened bug 89878 for this since I don't expect to deal
with the overloading part in this patch.
Thanks.
Jason
Re: Implement C++20 constexpr , , and
On Tue, Mar 19, 2019 at 4:57 PM Ed Smith-Rowland via gcc-patches wrote: > > On 3/18/19 6:18 PM, Jonathan Wakely wrote: > > On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote: > > I'm very surprised that none of the algos that dispatch to > > __builtin_memove need changes, because those optimizations won't work > > in constant expressions. I would expect to have to use > > std::is_constant_evaluated to disable the optimizations when used in > > constant expressions. > > > As am I. As I mentioned on IRC I could roll a constexpr memmove. > > I was wondering if somehow I'm not checking what I think I'm checking > (but I don't see how.) > > I wonder if the builtins are handled differently somehow by the front > end. I'm still not sure why __builtin_memcmp is OK for array == array > but not array != array. In that case I just do element by element > compare for constexpr now anyway. Is there a PR about making these builtins work in constexpr? Jason
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On Fri, Mar 29, 2019 at 4:48 AM Richard Biener wrote: > > On Thu, 28 Mar 2019, Jason Merrill wrote: > > > On 3/26/19 4:40 AM, Richard Biener wrote: > > > On Mon, 18 Mar 2019, Richard Biener wrote: > > > > > > > On Fri, 15 Mar 2019, Jason Merrill wrote: > > > > > > > > > On 3/15/19 9:33 AM, Richard Biener wrote: > > > > > > > > > > > > The following is an attempt to fix PR71598 where C (and C++?) have > > > > > > an implementation-defined compatible integer type for each enum > > > > > > and the TBAA rules mandate that accesses using a compatible type > > > > > > are allowed. > > > > > > > > > > This does not apply to C++; an enum does not alias its underlying > > > > > type. > > > > > > > > Thus the following different patch, introducing c_get_alias_set and > > > > only doing the special handling for C family frontends (I assume > > > > that at least ObjC is also affected). > > > > > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > > > > > Ping. Also consider the additional testcase below to be added. > > > > > > Richard. > > > > > > 2019-03-18 Richard Biener > > > > > > PR c/71598 > > > * gimple.c: Include langhooks.h. > > > (gimple_get_alias_set): Treat enumeral types as the underlying > > > integer type. > > > > Won't this affect all languages? > > It affects all languages during the LTO optimization phase, yes. > There's unfortunately no way around that at the moment. Ah, well. Looks good to me, then. Jason > Richard.
Re: Implement C++20 constexpr , , and
On Fri, Mar 29, 2019 at 11:07:53AM -0400, Jason Merrill wrote: > On Tue, Mar 19, 2019 at 4:57 PM Ed Smith-Rowland via gcc-patches > wrote: > > > > On 3/18/19 6:18 PM, Jonathan Wakely wrote: > > > On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote: > > > I'm very surprised that none of the algos that dispatch to > > > __builtin_memove need changes, because those optimizations won't work > > > in constant expressions. I would expect to have to use > > > std::is_constant_evaluated to disable the optimizations when used in > > > constant expressions. > > > > > As am I. As I mentioned on IRC I could roll a constexpr memmove. > > > > I was wondering if somehow I'm not checking what I think I'm checking > > (but I don't see how.) > > > > I wonder if the builtins are handled differently somehow by the front > > end. I'm still not sure why __builtin_memcmp is OK for array == array > > but not array != array. In that case I just do element by element > > compare for constexpr now anyway. > > Is there a PR about making these builtins work in constexpr? Yes, PR80265. Jakub
C++ PATCH to add test for c++/89871
As per the PR.
Tested on x86_64-linux, applying to trunk.
2019-03-29 Marek Polacek
PR c++/89871
* g++.dg/cpp2a/desig14.C: New test.
diff --git gcc/testsuite/g++.dg/cpp2a/desig14.C
gcc/testsuite/g++.dg/cpp2a/desig14.C
new file mode 100644
index 000..cfcaa88485c
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/desig14.C
@@ -0,0 +1,18 @@
+// PR c++/89871
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wall" }
+
+struct A {};
+struct B {};
+
+struct S {
+ union {
+A a;
+B b;
+ };
+};
+
+int main() {
+ S s;
+ s = S{.a = A{}};
+}
C++ PATCH for c++/89876 - ICE with deprecated conversion
Here a missing guard caused the usual "Error reporting routines re-entered."
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-03-29 Marek Polacek
PR c++/89876 - ICE with deprecated conversion.
* call.c (convert_like_real): Only give warnings with tf_warning.
* g++.dg/warn/conv5.C: New test.
diff --git gcc/cp/call.c gcc/cp/call.c
index bc5179416a5..519dad9bf2c 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -7446,7 +7446,8 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
case ck_qual:
/* Warn about deprecated conversion if appropriate. */
- string_conv_p (totype, expr, 1);
+ if (complain & tf_warning)
+ string_conv_p (totype, expr, 1);
break;
case ck_ptr:
diff --git gcc/testsuite/g++.dg/warn/conv5.C gcc/testsuite/g++.dg/warn/conv5.C
new file mode 100644
index 000..e238f9f30b7
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/conv5.C
@@ -0,0 +1,11 @@
+// PR c++/89876
+// { dg-do compile { target c++11 } }
+// { dg-prune-output "sorry" }
+
+template
+T f (T, char*);
+
+template
+decltype (f (T (), "")) g (T) { return ""; } // { dg-error "invalid
conversion" }
+
+void h () { g (0); }
Re: Implement C++20 constexpr , , and
On 3/29/19 9:23 AM, Jakub Jelinek wrote:
On Fri, Mar 29, 2019 at 09:10:26AM -0400, Ed Smith-Rowland via gcc-patches
wrote:
Greetings,
This patch implements C++20 constexpr for , , .
It's a large patch but only affects C++20 and the volume is mostly test
cases.
This differs from the previous patch in actually testing constexpr :-\ and
in the addition of wrappers for __builtin_memmove and __builtin_memcmp that
supply constexpr branches if C++20 and is_constant_evaluated().
+void*
+__memmove(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
+{
+#if __cplusplus > 201703L
+ if (is_constant_evaluated())
+ {
+ for(; __num > 0; --__num)
+ {
+ *__dst = *__src;
+ ++__src;
+ ++__dst;
+ }
+ return __dst;
+ }
+ else if (__num)
+#endif
+ return __builtin_memmove(__dst, __src, sizeof(_Tp) * abs(__num));
+ return __dst;
..
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
+ __memmove(__result, __first, _Num);
..
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
+ __memmove(__result - _Num, __first, _Num);
Why the abs in there, that is something that wasn't previously there and
if the compiler doesn't figure out that __last >= __first, it would mean
larger emitted code for the non-constexpr case. As memmove argument is
size_t, wouldn't it be better to make __num just size_t and remove this abs?
Also, wouldn't it be better to have on the other side the __num == 0
handling inside of __memmove, you already have it there for C++2a, but not
for older. You could then drop the if (_Num) guards around __memmove.
memmove needs to be able to work with __last < __first also.
I was getting negative __num and when passed to __builtin_memmove which
takes size_t got blowups.
I'm not sure why it worked before. __builtin_memmove will work with
__last < __first and sensible positive __num.
When I tried to do what __builtin_memmove or ::memmove must do with
unsigned num I would need to branch on __last < __first
and copy backwards. But pointer comparisons were getting caught as
non-constexpr.
I'll look at the __num==0 (noop) testing.
Also, shouldn't the is_constant_evaluated() calls be guarded with
_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED ? Without that it won't be
defined...
I am trying for a C++20-only patch (hoping to get it in for 9) so I used
the library function and tested __cplusplus > 201703L.
We could do _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED and then we
could use these for lower version. Maybe stage 1?
Jakub
Re: [PATCH] Enhance option suggestion for options expected an argument (PR driver/89861).
On 3/29/19 4:58 AM, Martin Liška wrote: > Hi. > > The patch enhances option suggestion for options that expect > an argument. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > > gcc/ChangeLog: > > 2019-03-29 Martin Liska > > PR driver/89861 > * opt-suggestions.c (option_proposer::build_option_suggestions): > Add variant without any argument in order to provide better > hints. > > gcc/testsuite/ChangeLog: > > 2019-03-29 Martin Liska > > PR driver/89861 > * gcc.dg/spellcheck-options-18.c: New test. > * gcc.dg/spellcheck-options-19.c: New test. > * gcc.dg/spellcheck-options-20.c: New test. > * gcc.dg/spellcheck-options-13.c: Adjust expected output. > * gcc.dg/completion-2.c: Add one variant with no argument. OK. jeff
Re: Implement C++20 constexpr , , and
On 3/29/19 11:12 AM, Jakub Jelinek wrote: On Fri, Mar 29, 2019 at 11:07:53AM -0400, Jason Merrill wrote: On Tue, Mar 19, 2019 at 4:57 PM Ed Smith-Rowland via gcc-patches wrote: On 3/18/19 6:18 PM, Jonathan Wakely wrote: On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote: I'm very surprised that none of the algos that dispatch to __builtin_memove need changes, because those optimizations won't work in constant expressions. I would expect to have to use std::is_constant_evaluated to disable the optimizations when used in constant expressions. As am I. As I mentioned on IRC I could roll a constexpr memmove. I was wondering if somehow I'm not checking what I think I'm checking (but I don't see how.) I wonder if the builtins are handled differently somehow by the front end. I'm still not sure why __builtin_memcmp is OK for array == array but not array != array. In that case I just do element by element compare for constexpr now anyway. Is there a PR about making these builtins work in constexpr? Yes, PR80265. Jakub I see what you did there ;-) I could make my patch use the same idiom as what you have in the char_traits patch if folks would prefer. BTW, what does (void) __s; do? In other news, assuming that it's official there was constexpr in char_traits in some paper. I was going to try that but it looks like you were starting. Ed
Re: [PATCH] correct maximum valid alignment in error message (PR 89812)
On 3/26/19 9:29 AM, Jakub Jelinek wrote: > On Mon, Mar 25, 2019 at 11:41:35AM -0600, Jeff Law wrote: >>> PR c/89812 - incorrect maximum in error: requested alignment >>> ‘536870912’ exceeds maximum 2147483648 >>> >>> gcc/c-family/ChangeLog: >>> >>> PR c/89812 >>> * c-common.c (check_user_alignment): Rename local. Correct maximum >>> alignment in diagnostic. Avoid assuming argument fits in SHWI, >>> convert it to UHWI when it fits. >>> >>> gcc/testsuite/ChangeLog: >>> >>> PR c/89812 >>> * gcc.dg/attr-aligned-3.c: New test. >> OK > > The test FAILs on all 32-bit targets (where __UINT64_TYPE__ is unsigned long > long) due to -pedantic-errors, and I bet will fail on all non-ELF targets on > AVR, because only config/elfos.h defines 1 << 28 as MAX_OFILE_ALIGNMENT (in > bytes) and the test relies on exactly that value, nothing else. > > Fixed thusly, tested on x86_64-linux (-m32/-m64), ok for trunk? > > If we have some elf targets that still don't use elfos.h, we might need to > add them next to avr too. > > 2019-03-26 Jakub Jelinek > > PR c/89812 > * gcc.dg/attr-aligned-3.c: Limit the test to known ELF targets > other than AVR. Add dg-options "". OK. Jeff
Re: [PATCH] correct maximum valid alignment in error message (PR 89812)
On 3/26/19 4:49 PM, Rainer Orth wrote: > Hi Jakub, > >> On Mon, Mar 25, 2019 at 11:41:35AM -0600, Jeff Law wrote: PR c/89812 - incorrect maximum in error: requested alignment ‘536870912’ exceeds maximum 2147483648 gcc/c-family/ChangeLog: PR c/89812 * c-common.c (check_user_alignment): Rename local. Correct maximum alignment in diagnostic. Avoid assuming argument fits in SHWI, convert it to UHWI when it fits. gcc/testsuite/ChangeLog: PR c/89812 * gcc.dg/attr-aligned-3.c: New test. >>> OK >> >> The test FAILs on all 32-bit targets (where __UINT64_TYPE__ is unsigned long >> long) due to -pedantic-errors, and I bet will fail on all non-ELF targets on >> AVR, because only config/elfos.h defines 1 << 28 as MAX_OFILE_ALIGNMENT (in >> bytes) and the test relies on exactly that value, nothing else. >> >> Fixed thusly, tested on x86_64-linux (-m32/-m64), ok for trunk? >> >> If we have some elf targets that still don't use elfos.h, we might need to >> add them next to avr too. > > FWIW, adding *-*-solaris2.* to the target list lets the test also PASS > on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit each). Go for it. And ISTM that this kind of change should be well within the space where you should be able to commit w/o approvals :-) jeff
Re: Implement C++20 constexpr , , and
On Fri, Mar 29, 2019 at 12:30:02PM -0400, Ed Smith-Rowland wrote: > I see what you did there ;-) I could make my patch use the same idiom as > what you have in the char_traits patch if folks would prefer. > > BTW, what does > > (void) __s; Avoid -Wunused-parameter warning. Jakub
Re: Implement C++20 constexpr , , and
On Fri, Mar 29, 2019 at 12:02:48PM -0400, Ed Smith-Rowland wrote:
> > > This differs from the previous patch in actually testing constexpr :-\ and
> > > in the addition of wrappers for __builtin_memmove and __builtin_memcmp
> > > that
> > > supply constexpr branches if C++20 and is_constant_evaluated().
> > +void*
> > +__memmove(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
> > +{
> > +#if __cplusplus > 201703L
> > + if (is_constant_evaluated())
> > + {
> > + for(; __num > 0; --__num)
> > + {
> > + *__dst = *__src;
> > + ++__src;
> > + ++__dst;
> > + }
> > + return __dst;
> > + }
> > + else if (__num)
> > +#endif
> > + return __builtin_memmove(__dst, __src, sizeof(_Tp) * abs(__num));
> > + return __dst;
> > ..
> > const ptrdiff_t _Num = __last - __first;
> >if (_Num)
> > - __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
> > + __memmove(__result, __first, _Num);
> > ..
> > const ptrdiff_t _Num = __last - __first;
> >if (_Num)
> > - __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
> > + __memmove(__result - _Num, __first, _Num);
> >
> > Why the abs in there, that is something that wasn't previously there and
> > if the compiler doesn't figure out that __last >= __first, it would mean
> > larger emitted code for the non-constexpr case. As memmove argument is
> > size_t, wouldn't it be better to make __num just size_t and remove this abs?
> > Also, wouldn't it be better to have on the other side the __num == 0
> > handling inside of __memmove, you already have it there for C++2a, but not
> > for older. You could then drop the if (_Num) guards around __memmove.
>
> memmove needs to be able to work with __last < __first also.
I don't get it, you are replacing calls with __builtin_memmove with
__memmove, and the __builtin_memmove calls didn't do anything like that,
the last argument is size_t and didn't use any abs. So are you saying you
see crashes with the current code (when not in constexpr contexts) that your
patch fixes?
Jakub
[PATCH, PR d/89255][1/3] Add -fbuilding-libphobos-tests
Hi,
Currently, the druntime and phobos unittests are compiled as a
separate check program, then ran by the
libphobos.unittest/unittest.exp script. As PR 89255 notes, this
process lacks proper multilib handling.
What I want to do instead is compile and run each module that contains
unittests as a standalone program using dg-runtest. Doing this
however requires linking to libphobos, where a second copy of the
module and all its symbols exist. This does not fair well at all with
shared libraries where the D runtime module registry will error and
abort because of two modules in different DSOs have the same name.
To handle this conflict, I've added a new internal option that
instructs the compiler to put the reference to all unittest functions
in another symbol.
Its use being along the lines of:
# make: Compile module to then add to libphobos.a and libphobos.so
gdc-c $PIC $MULTILIB $GDCFLAGS core/foo.d
# make check: Compile module as standalone program linking
# against libphobos, trusting that any symbol that appears in the
# library is overridden without a linking error.
gdc $MULTILIB -fmain -funittest -fbuilding-libphobos-tests core/foo.d
I checked this on x86_64-linux-gnu, and all links, runs, and passes
without problems.
Would there be any problems in doing this with other linkers/platforms?
--
Iain
---
gcc/d/ChangeLog:
2019-03-29 Iain Buclaw
* lang.opt (-fbuiding-libphobos-tests): Add option.
* modules.cc (build_module_tree): Generate second moduleinfo symbol to
hold reference to unittests if flag_building_libphobos_tests.
---
diff --git a/gcc/d/lang.opt b/gcc/d/lang.opt
index 523f73c90de..f65be444d45 100644
--- a/gcc/d/lang.opt
+++ b/gcc/d/lang.opt
@@ -197,6 +197,10 @@ Enum(bounds_check) String(safeonly) Value(1)
EnumValue
Enum(bounds_check) String(on) Value(2)
+; Generates a secondary ModuleInfo symbol for linking in unittests
+fbuilding-libphobos-tests
+D Undocumented Var(flag_building_libphobos_tests)
+
fbuiltin
D Var(flag_no_builtin, 0)
; Documented in C
diff --git a/gcc/d/modules.cc b/gcc/d/modules.cc
index a1fc534c3b6..a863f525a27 100644
--- a/gcc/d/modules.cc
+++ b/gcc/d/modules.cc
@@ -718,6 +718,33 @@ build_module_tree (Module *decl)
}
}
+ /* For libphobos-internal use only. Generate a separate module info symbol
+ that references all compiled in unittests, this allows compiling library
+ modules and linking to libphobos without having run-time conflicts because
+ of two ModuleInfo records with the same name being present in two DSOs. */
+ if (flag_building_libphobos_tests && mi.unitTests)
+{
+ /* Associate the module info symbol with a mock module. */
+ const char *name = concat (GDC_PREFIX ("modtest__"),
+ decl->ident->toChars (), NULL);
+ Module *tm = Module::create (decl->arg, Identifier::idPool (name), 0, 0);
+ Dsymbols members;
+
+ /* Setting parent puts module in the same package as the current, to
+ avoid any symbol conflicts. */
+ tm->parent = decl->parent;
+ tm->members = &members;
+ /* Register the current module as being imported by the mock module.
+ This informs run-time that there is a dependency between the two. */
+ tm->aimports.push (decl);
+
+ tm->stest = build_funcs_gates_fn (get_identifier ("*__modtest"),
+ mi.unitTests, NULL);
+ mi.unitTests = NULL;
+
+ layout_moduleinfo (tm);
+}
+
/* Default behavior is to always generate module info because of templates.
Can be switched off for not compiling against runtime library. */
if (!global.params.betterC
Re: [PATCH, GCC, AARCH64] Add GNU note section with BTI and PAC.
> +#define ASM_LONG "\t.long\t"
Do not replicate targetm.asm_out.aligned_op.si, or integer_asm_op, really.
> +aarch64_file_end_indicate_exec_stack ()
> +{
> + file_end_indicate_exec_stack ();
> +
> + if (!aarch64_bti_enabled ()
> + && aarch64_ra_sign_scope == AARCH64_FUNCTION_NONE)
> +{
> + return;
> +}
This is redundant with...
> +
> + unsigned feature_1_and = 0;
> + if (aarch64_bti_enabled ())
> +feature_1_and |= GNU_PROPERTY_AARCH64_FEATURE_1_BTI;
> +
> + if (aarch64_ra_sign_scope != AARCH64_FUNCTION_NONE)
> +feature_1_and |= GNU_PROPERTY_AARCH64_FEATURE_1_PAC;
> +
> + if (feature_1_and)
... this. I prefer the second, as it's obvious.
> + ASM_OUTPUT_ALIGN (asm_out_file, p2align);
> + /* name length. */
> + fprintf (asm_out_file, ASM_LONG " 1f - 0f\n");
> + /* data length. */
> + fprintf (asm_out_file, ASM_LONG " 4f - 1f\n");
> + /* note type: NT_GNU_PROPERTY_TYPE_0. */
> + fprintf (asm_out_file, ASM_LONG " 5\n");
> + fprintf (asm_out_file, "0:\n");
> + /* vendor name: "GNU". */
> + fprintf (asm_out_file, STRING_ASM_OP " \"GNU\"\n");
> + fprintf (asm_out_file, "1:\n");
> + ASM_OUTPUT_ALIGN (asm_out_file, p2align);
> + /* pr_type: GNU_PROPERTY_AARCH64_FEATURE_1_AND. */
> + fprintf (asm_out_file, ASM_LONG " 0x%x\n",
> +GNU_PROPERTY_AARCH64_FEATURE_1_AND);
> + /* pr_datasz. */\
> + fprintf (asm_out_file, ASM_LONG " 3f - 2f\n");
> + fprintf (asm_out_file, "2:\n");
> + /* GNU_PROPERTY_AARCH64_FEATURE_1_XXX. */
> + fprintf (asm_out_file, ASM_LONG " 0x%x\n", feature_1_and);
> + fprintf (asm_out_file, "3:\n");
> + ASM_OUTPUT_ALIGN (asm_out_file, p2align);
> + fprintf (asm_out_file, "4:\n");
This could stand to use a comment, a moment's thinking about the sizes, and to
use the existing asm output functions.
/* PT_NOTE header: namesz, descsz, type.
namesz = 4 ("GNU\0")
descsz = 12 (see below)
type = 5 (NT_GNU_PROPERTY_TYPE_0). */
assemble_align (POINTER_SIZE);
assemble_integer (GEN_INT (4), 4, 32, 1);
assemble_integer (GEN_INT (12), 4, 32, 1);
assemble_integer (GEN_INT (5), 4, 32, 1);
/* PT_NOTE name */
assemble_string ("GNU", 4);
/* PT_NOTE contents for NT_GNU_PROPERTY_TYPE_0:
type = 0xc000 (GNU_PROPERTY_AARCH64_FEATURE_1_AND),
datasz = 4
data = feature_1_and
Note that the current section offset is 16,
and there has been no padding so far. */
assemble_integer (GEN_INT (0xc000), 4, 32, 1);
assemble_integer (GEN_INT (4), 4, 32, 1);
assemble_integer (GEN_INT (feature_1_and), 4, 32, 1);
/* Pad the size of the note to the required alignment. */
assemble_align (POINTER_SIZE);
r~
[PATCH, PR d/89255][2/3] Replace libphobos check programs with dg-runtest
Following on from the first patch, this removes the unittest.exp
script, and splits the druntime/phobos and static/shared combinations
into four separate test scripts.
By using dg-runtest, the unittest tests now honour `--target_board`.
It should also resolve the first part of PR d/88654 where there was a
concern that the timeout for unittest.exp wasn't working.
Assuming that the first is OK, this is a pretty obvious change.
--
Iain
---
libphobos/ChangeLog:
2019-03-29 Iain Buclaw
PR d/89255
* configure.ac (ENABLE_SHARED, ENABLE_STATIC): Remove conditionals.
* configure: Rebuild.
* d_rules.am (%.t.lo, %.t.o): Remove rules.
(unittest_static_LINK, unittest_LINK, libgdruntime_t_la_LINK,
libgphobos_t_la_LINK): Remove variables.
* libdruntime/Makefile.am (DRUNTIME_TEST_LOBJECTS,
DRUNTIME_TEST_OBJECTS, check_PROGRAMS, check_LTLIBRARIES,
unittest_static_SOURCES, unittest_static_LIBTOOLFLAGS,
unittest_static_LDFLAGS, unittest_static_LDADD,
EXTRA_unittest_static_DEPENDENCIES, libgdruntime_t_la_SOURCES,
libgdruntime_t_la_LIBTOOLFLAGS, libgdruntime_t_la_LDFLAGS,
libgdruntime_t_la_LIBADD, EXTRA_libgdruntime_t_la_DEPENDENCIES,
unittest_SOURCES, unittest_LIBTOOLFLAGS, unittest_LDFLAGS,
unittest_LDADD): Remove variables.
(clean-local): Remove rule.
* libdruntime/Makefile.in: Rebuild.
* src/Makefile.am (PHOBOS_TEST_LOBJECTS,
PHOBOS_TEST_OBJECTS, check_PROGRAMS, check_LTLIBRARIES,
unittest_static_SOURCES, unittest_static_LIBTOOLFLAGS,
unittest_static_LDFLAGS, unittest_static_LDADD,
EXTRA_unittest_static_DEPENDENCIES, libgdruntime_t_la_SOURCES,
libgdruntime_t_la_LIBTOOLFLAGS, libgdruntime_t_la_LDFLAGS,
libgdruntime_t_la_LIBADD, EXTRA_libgdruntime_t_la_DEPENDENCIES,
unittest_SOURCES, unittest_LIBTOOLFLAGS, unittest_LDFLAGS,
unittest_LDADD): Remove variables.
(clean-local): Remove rule.
* src/Makefile.in: Rebuild.
* testsuite/lib/libphobos.exp (filter_libphobos_unittests): New proc.
* testsuite/libphobos.druntime/druntime.exp: New file.
* testsuite/libphobos.druntime_shared/druntime_shared.exp: New file.
* testsuite/libphobos.phobos/phobos.exp: New file.
* testsuite/libphobos.phobos_shared/phobos_shared.exp: New file.
* testsuite/libphobos.unittests/unittests.exp: Remove.
* testsuite/test_runner.d: Remove.
* testsuite/testsuite_flags.in: Add phobos to --gdcpaths.
---
diff --git a/libphobos/configure b/libphobos/configure
index d86934b59a5..f359a6c9e3b 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -687,10 +687,6 @@ libphobos_builddir
get_gcc_base_ver
phobos_compiler_shared_flag
phobos_compiler_pic_flag
-ENABLE_STATIC_FALSE
-ENABLE_STATIC_TRUE
-ENABLE_SHARED_FALSE
-ENABLE_SHARED_TRUE
CPP
OTOOL64
OTOOL
@@ -11499,7 +11495,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11502 "configure"
+#line 11498 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -11605,7 +11601,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11608 "configure"
+#line 11604 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -13747,22 +13743,6 @@ GDCFLAGS=$lt_save_DFLAGS
GDCFLAGS=$gdc_save_DFLAGS
- if test "$enable_shared" = "yes"; then
- ENABLE_SHARED_TRUE=
- ENABLE_SHARED_FALSE='#'
-else
- ENABLE_SHARED_TRUE='#'
- ENABLE_SHARED_FALSE=
-fi
-
- if test "$enable_static" = "yes"; then
- ENABLE_STATIC_TRUE=
- ENABLE_STATIC_FALSE='#'
-else
- ENABLE_STATIC_TRUE='#'
- ENABLE_STATIC_FALSE=
-fi
-
# libtool variables for Phobos shared and position-independent compiles.
#
@@ -15190,14 +15170,6 @@ if test -z "${MAINTAINER_MODE_TRUE}" && test -z "${MAINTAINER_MODE_FALSE}"; then
as_fn_error $? "conditional \"MAINTAINER_MODE\" was never defined.
Usually this means the macro was only invoked conditionally." "$LINENO" 5
fi
-if test -z "${ENABLE_SHARED_TRUE}" && test -z "${ENABLE_SHARED_FALSE}"; then
- as_fn_error $? "conditional \"ENABLE_SHARED\" was never defined.
-Usually this means the macro was only invoked conditionally." "$LINENO" 5
-fi
-if test -z "${ENABLE_STATIC_TRUE}" && test -z "${ENABLE_STATIC_FALSE}"; then
- as_fn_error $? "conditional \"ENABLE_STATIC\" was never defined.
-Usually this means the macro was only invoked conditionally." "$LINENO" 5
-fi
if test -z "${DRUNTIME_GC_ENABLE_TRUE}" && test -z "${DRUNTIME_GC_ENABLE_FALSE}"; then
as_fn_error $? "conditional \"DRUNTIME_GC_ENABLE\" was never defined.
Usually this means the macro was only invoked conditionally." "$LINENO" 5
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index 8cc735563cb..362f7537ffb 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -7
[PATCH, PR d/89255][3/3] Parallelize the libphobos testsuite
Hi,
With second patch in the series applied, all unittests will now be
compiled and ran serially, causing a notable slowdown compared to the
previous method of testing.
This is just a copy-paste from libstdc++-v3 to enable parallelized
testing, with references appropriately fixed up to use libphobos, and
GCC_TEST_PARALLEL_SLOTS defaulted to 10.
--
Iain
---
libphobos/ChangeLog:
2019-03-29 Iain Buclaw
* testsuite/Makefile.am (AUTOMAKE_OPTIONS): Remove dejagnu.
(RUNTEST): Remove variable.
(RUNTESTDEFAULTFLAGS, check_p_subno, check_p_numbers0,
check_p_numbers1, check_p_numbers2, check_p_numbers3,
check_p_numbers4, check_p_numbers5, check_p_numbers6, check_p_numbers,
check_p_subdirs, check_DEJAGNU_libphobos_targets): New variables.
(site.exp, %/site.exp, check-DEJAGNU, check-am, clean-local): New
rules written so that all the *.exp files are ran parallelized.
(CLEANFILES): Add *.exe, *.o, and site.exp.
* testsuite/Makefile.in: Rebuild.
---
diff --git a/libphobos/testsuite/Makefile.am b/libphobos/testsuite/Makefile.am
index def102941a7..55b2ba42640 100644
--- a/libphobos/testsuite/Makefile.am
+++ b/libphobos/testsuite/Makefile.am
@@ -17,7 +17,7 @@
# Process this file with automake to produce Makefile.in.
-AUTOMAKE_OPTIONS = foreign dejagnu
+AUTOMAKE_OPTIONS = foreign
# Setup the testing framework, if you have one
EXPECT = $(shell if test -f $(top_builddir)/../expect/expect; then \
@@ -25,8 +25,110 @@ EXPECT = $(shell if test -f $(top_builddir)/../expect/expect; then \
_RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
-RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
+
+check_p_subno=$(word 2,$(subst _, ,$*))
+check_p_numbers0:=1 2 3 4 5 6 7 8 9
+check_p_numbers1:=0 $(check_p_numbers0)
+check_p_numbers2:=$(foreach i,$(check_p_numbers0),$(addprefix $(i),$(check_p_numbers1)))
+check_p_numbers3:=$(addprefix 0,$(check_p_numbers1)) $(check_p_numbers2)
+check_p_numbers4:=$(foreach i,$(check_p_numbers0),$(addprefix $(i),$(check_p_numbers3)))
+check_p_numbers5:=$(addprefix 0,$(check_p_numbers3)) $(check_p_numbers4)
+check_p_numbers6:=$(foreach i,$(check_p_numbers0),$(addprefix $(i),$(check_p_numbers5)))
+check_p_numbers:=$(check_p_numbers0) $(check_p_numbers2) $(check_p_numbers4) $(check_p_numbers6)
+check_p_subdirs=$(wordlist 1,$(if $(GCC_TEST_PARALLEL_SLOTS),$(GCC_TEST_PARALLEL_SLOTS),10),$(check_p_numbers))
+check_DEJAGNU_libphobos_targets = $(addprefix check-DEJAGNUlibphobos,$(check_p_subdirs))
+$(check_DEJAGNU_libphobos_targets): check-DEJAGNUlibphobos%: libphobos%/site.exp
+
+site.exp: Makefile $(EXTRA_DEJAGNU_SITE_CONFIG)
+ @echo 'Making a new site.exp file ...'
+ @echo '## these variables are automatically generated by make ##' >site.tmp
+ @echo '# Do not edit here. If you wish to override these values' >>site.tmp
+ @echo '# edit the last section' >>site.tmp
+ @echo 'set srcdir "$(srcdir)"' >>site.tmp
+ @echo "set objdir `pwd`" >>site.tmp
+ @echo 'set build_alias "$(build_alias)"' >>site.tmp
+ @echo 'set build_triplet $(build_triplet)' >>site.tmp
+ @echo 'set host_alias "$(host_alias)"' >>site.tmp
+ @echo 'set host_triplet $(host_triplet)' >>site.tmp
+ @echo 'set target_alias "$(target_alias)"' >>site.tmp
+ @echo 'set target_triplet $(target_triplet)' >>site.tmp
+ @list='$(EXTRA_DEJAGNU_SITE_CONFIG)'; for f in $$list; do \
+ echo "## Begin content included from file $$f. Do not modify. ##" \
+ && cat `test -f "$$f" || echo '$(srcdir)/'`$$f \
+ && echo "## End content included from file $$f. ##" \
+ || exit 1; \
+ done >> site.tmp
+ @echo "## End of auto-generated content; you can edit from here. ##" >> site.tmp
+ @if test -f site.exp; then \
+ sed -e '1,/^## End of auto-generated content.*##/d' site.exp >> site.tmp; \
+ fi
+ @-rm -f site.bak
+ @test ! -f site.exp || mv site.exp site.bak
+ @mv site.tmp site.exp
+
+%/site.exp: site.exp
+ -@test -d $* || mkdir $*
+ @srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
+ @objdir=`${PWD_COMMAND}`/$*; \
+ sed -e "s|^set srcdir .*$$|set srcdir $$srcdir|" \
+ -e "s|^set objdir .*$$|set objdir $$objdir|" \
+ site.exp > $*/site.exp.tmp
+ @-rm -f $*/site.bak
+ @test ! -f $*/site.exp || mv $*/site.exp $*/site.bak
+ @mv $*/site.exp.tmp $*/site.exp
+
+# Run the testsuite in normal mode.
+check-DEJAGNU $(check_DEJAGNU_libphobos_targets): check-DEJAGNU%: site.exp
+ $(if $*,@)AR="$(AR)"; export AR; \
+ RANLIB="$(RANLIB)"; export RANLIB; \
+ if [ -z "$*" ] && [ -n "$(filter -j%, $(MFLAGS))" ]; then \
+ rm -rf libphobos-parallel || true; \
+ mkdir libphobos-parallel; \
+ $(MAKE) $(AM_MAKEFLAGS) $(check_DEJAGNU_libphobos_targets); \
+ rm -rf libphobos-parallel || true; \
+ for idx in $(check_p_subdirs); do \
+ if [ -d libphobos$$idx ]; then \
+ mv -f libphobos$$idx/libphobos.sum libphobos$$idx/libphobos.sum.sep; \
+
Re: Implement C++20 constexpr , , and
On 3/29/19 12:39 PM, Jakub Jelinek wrote:
On Fri, Mar 29, 2019 at 12:02:48PM -0400, Ed Smith-Rowland wrote:
This differs from the previous patch in actually testing constexpr :-\ and
in the addition of wrappers for __builtin_memmove and __builtin_memcmp that
supply constexpr branches if C++20 and is_constant_evaluated().
+void*
+__memmove(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
+{
+#if __cplusplus > 201703L
+ if (is_constant_evaluated())
+ {
+ for(; __num > 0; --__num)
+ {
+ *__dst = *__src;
+ ++__src;
+ ++__dst;
+ }
+ return __dst;
+ }
+ else if (__num)
+#endif
+ return __builtin_memmove(__dst, __src, sizeof(_Tp) * abs(__num));
+ return __dst;
..
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
+ __memmove(__result, __first, _Num);
..
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
+ __memmove(__result - _Num, __first, _Num);
Why the abs in there, that is something that wasn't previously there and
if the compiler doesn't figure out that __last >= __first, it would mean
larger emitted code for the non-constexpr case. As memmove argument is
size_t, wouldn't it be better to make __num just size_t and remove this abs?
Also, wouldn't it be better to have on the other side the __num == 0
handling inside of __memmove, you already have it there for C++2a, but not
for older. You could then drop the if (_Num) guards around __memmove.
memmove needs to be able to work with __last < __first also.
I don't get it, you are replacing calls with __builtin_memmove with
__memmove, and the __builtin_memmove calls didn't do anything like that,
the last argument is size_t and didn't use any abs. So are you saying you
see crashes with the current code (when not in constexpr contexts) that your
patch fixes?
Jakub
If std::copy is intended to work with first < last then yes. OTOH, the
copy_move is just an impl detail for speed.
The std doesn't say that first >= last as a precondition but has
sentences like:
"For each non-negative integer n < (last - first), performs *(result +
n) = *(first + n)."
If this fixes a bug then I should make a pug report, a separate patch,
and probably backport it.
I also took out the else if (__num) in the __memmove since this check is
done at both call sites.
I made __memmove and __memcmp inline so that, certainly for C++ < 20
these don't pessimize.
Retesting.
Ed
int
main()
{
float arr[1000];
float brr[1000];
std::copy(arr + 500, arr, brr + 500);
}
Re: Implement C++20 constexpr , , and
Am Fr., 29. März 2019 um 19:08 Uhr schrieb Ed Smith-Rowland via libstdc++ : > > I made __memmove and __memcmp inline so that, certainly for C++ < 20 > these don't pessimize. Hmmh, are you sure? In my (not very up-to-date) code base I find that c++config.h defines #ifndef _GLIBCXX20_CONSTEXPR # if __cplusplus > 201703L # define _GLIBCXX20_CONSTEXPR constexpr # else # define _GLIBCXX20_CONSTEXPR # endif #endif So unless __cplusplus > 201703L, there is no inline in sight. - Daniel
Re: C++ PATCH for c++/89876 - ICE with deprecated conversion
On Fri, Mar 29, 2019 at 11:31 AM Marek Polacek wrote:
>
> Here a missing guard caused the usual "Error reporting routines re-entered."
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2019-03-29 Marek Polacek
>
> PR c++/89876 - ICE with deprecated conversion.
> * call.c (convert_like_real): Only give warnings with tf_warning.
OK.
> * g++.dg/warn/conv5.C: New test.
>
> diff --git gcc/cp/call.c gcc/cp/call.c
> index bc5179416a5..519dad9bf2c 100644
> --- gcc/cp/call.c
> +++ gcc/cp/call.c
> @@ -7446,7 +7446,8 @@ convert_like_real (conversion *convs, tree expr, tree
> fn, int argnum,
>
> case ck_qual:
>/* Warn about deprecated conversion if appropriate. */
> - string_conv_p (totype, expr, 1);
> + if (complain & tf_warning)
> + string_conv_p (totype, expr, 1);
>break;
>
> case ck_ptr:
> diff --git gcc/testsuite/g++.dg/warn/conv5.C gcc/testsuite/g++.dg/warn/conv5.C
> new file mode 100644
> index 000..e238f9f30b7
> --- /dev/null
> +++ gcc/testsuite/g++.dg/warn/conv5.C
> @@ -0,0 +1,11 @@
> +// PR c++/89876
> +// { dg-do compile { target c++11 } }
> +// { dg-prune-output "sorry" }
> +
> +template
> +T f (T, char*);
> +
> +template
> +decltype (f (T (), "")) g (T) { return ""; } // { dg-error "invalid
> conversion" }
> +
> +void h () { g (0); }
Re: [PATCH, RFC] Wrong warning message fix for gcc 9
On 3/29/19 6:31 AM, zhroma wrote: > Martin Sebor wrote 2019-03-28 22:44: >> On 3/28/19 11:49 AM, Roman Zhuykov wrote: >>> Ping >>> >>> A week ago I decided it is so minor that I can report here with a >>> patch without creating bugzilla PR. >>> Technically it is a "9 regression" in new functionality added back in >>> summer. >>> >>> Patch was succesfully bootstrapped and regtested on x86_64. >>> >>> Ok for trunk? >> > > Have found an option, which passes buggy function and all subsequent > checks: > "-fdiagnostics-minimum-margin-width=-1" gives an error, but > "-fdiagnostics-minimum-margin-width=42xyz" silently sets it to -1 :) > >> Thanks for the patch! The change makes sense to me. Can you >> please also add a test case to the test suite? > > Added the test, is such filename (and contents) ok ? > >> I can't approve patches, even obvious ones, so please wait for >> an approval from a maintainer before committing it. > > CC'ed to "option handling" maintainer here. > > -- > Roman > > > gcc/testsuite/ChangeLog: > > 2019-03-29 Roman Zhuykov > > * gcc.dg/diag-sanity.c: New test. > > > gcc/ChangeLog: > > 2019-03-29 Roman Zhuykov > > * opts-common.c (integral_argument): Set errno properly in one case. Thanks. I ran this through my tester (no regressions, as expected) and installed it on the trunk. Jeff
Re: [PATCH] fix ice in attribute copy (PR 89685)
On 3/14/19 7:47 PM, Martin Sebor wrote: > To copy type attributes from struct A, the copy attribute (new > in GCC 9) accepts a pointer argument such as (struct A*)0, but > it isn't prepared for anything much more complicated than that. > So for example when it's passed something like (struct A*)(0, 1) > as the test case in PR 89685 does (a P1 regression), it fails > with an ICE. > > The attached patch makes this handling more robust by letting > it accept all forms of type and member references. > > Tested on x86_64-linux. > > Martin > > gcc-89685.diff > > PR c/89685 - ICE on attribute copy with a compound expression > > gcc/c-family/ChangeLog: > > PR c/89685 > * c-attribs.c (handle_copy_attribute): Handle references and > non-constant expressions. > > gcc/testsuite/ChangeLog: > > PR c/89685 > * gcc.dg/attr-copy-8.c: New test. > * g++.dg/ext/attr-copy-2.C: New test. So after further review of the patch, the associated documentation and discussions, I'm going to ACK this for the trunk. The documentation on this is reasonably clear in specifying how it applies to expressions (by digging through the expression's type). It doesn't in any way imply the attribute is associated with the expression. Things like front-end folding of constant expressions and potentially array decaying could result in inconsistencies. I think we can reasonably address these if they turn out to be an issue in practice. Note I think the decision here impacts the decision around builtin_has_attribute. Martin has an update for that on the immediate horizon -- my inclination is to go forward with that, perhaps after some documentation clarifications. Jeff
Re: [PATCH] Fix PR71598, aliasing between enums and compatible types
On 3/29/19 9:09 AM, Jason Merrill wrote: > On Fri, Mar 29, 2019 at 4:48 AM Richard Biener wrote: >> >> On Thu, 28 Mar 2019, Jason Merrill wrote: >> >>> On 3/26/19 4:40 AM, Richard Biener wrote: On Mon, 18 Mar 2019, Richard Biener wrote: > On Fri, 15 Mar 2019, Jason Merrill wrote: > >> On 3/15/19 9:33 AM, Richard Biener wrote: >>> >>> The following is an attempt to fix PR71598 where C (and C++?) have >>> an implementation-defined compatible integer type for each enum >>> and the TBAA rules mandate that accesses using a compatible type >>> are allowed. >> >> This does not apply to C++; an enum does not alias its underlying type. > > Thus the following different patch, introducing c_get_alias_set and > only doing the special handling for C family frontends (I assume > that at least ObjC is also affected). > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? Ping. Also consider the additional testcase below to be added. Richard. 2019-03-18 Richard Biener PR c/71598 * gimple.c: Include langhooks.h. (gimple_get_alias_set): Treat enumeral types as the underlying integer type. >>> >>> Won't this affect all languages? >> >> It affects all languages during the LTO optimization phase, yes. >> There's unfortunately no way around that at the moment. > > Ah, well. Looks good to me, then. Likewise. And with Joseph largely offline right now, that's going to have to be sufficient :-) jeff
[PATCH] Add PSTL internal namespace qualifications
This patch adds additional internal namespace qualifications to the pstl
implementation.
>From 35dba02035ebb5fd44ac0f06e25a81dfef05898f Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 28 Mar 2019 17:23:49 -0700
Subject: [PATCH] Add namespace qualification for pstl-internal symbols
Prevent ADL related weirdness.
* include/pstl/algorithm_impl.h: Add namespace qualification.
* include/pstl/execution_defs.h: Add namespace qualification.
* include/pstl/execution_impl.h: Add namespace qualification.
* include/pstl/numeric_impl.h: Add namespace qualification.
* include/pstl/parallel_backend_tbb.h: Add namespace qualification.
* include/pstl/unseq_backend_simd.h: Add namespace qualification.
* include/pstl/parallel_backend_utils.h: Include .
---
libstdc++-v3/include/pstl/algorithm_impl.h| 427 +-
libstdc++-v3/include/pstl/execution_defs.h| 10 +-
libstdc++-v3/include/pstl/execution_impl.h| 22 +-
libstdc++-v3/include/pstl/numeric_impl.h | 30 +-
.../include/pstl/parallel_backend_tbb.h | 49 +-
.../include/pstl/parallel_backend_utils.h | 1 +
.../include/pstl/unseq_backend_simd.h | 8 +-
7 files changed, 275 insertions(+), 272 deletions(-)
diff --git a/libstdc++-v3/include/pstl/algorithm_impl.h b/libstdc++-v3/include/pstl/algorithm_impl.h
index 9d8242873ab..e06bf60151e 100644
--- a/libstdc++-v3/include/pstl/algorithm_impl.h
+++ b/libstdc++-v3/include/pstl/algorithm_impl.h
@@ -18,6 +18,7 @@
#include "execution_impl.h"
#include "memory_impl.h"
+#include "parallel_backend_utils.h"
#include "unseq_backend_simd.h"
#if __PSTL_USE_PAR_POLICIES
@@ -55,7 +56,7 @@ bool
__pattern_any_of(_ExecutionPolicy&&, _ForwardIterator __first, _ForwardIterator __last, _Pred __pred,
_IsVector __is_vector, /*parallel=*/std::false_type) noexcept
{
-return __brick_any_of(__first, __last, __pred, __is_vector);
+return __internal::__brick_any_of(__first, __last, __pred, __is_vector);
}
#if __PSTL_USE_PAR_POLICIES
@@ -64,10 +65,10 @@ bool
__pattern_any_of(_ExecutionPolicy&& __exec, _ForwardIterator __first, _ForwardIterator __last, _Pred __pred,
_IsVector __is_vector, /*parallel=*/std::true_type)
{
-return __except_handler([&]() {
-return __parallel_or(std::forward<_ExecutionPolicy>(__exec), __first, __last,
+return __internal::__except_handler([&]() {
+ return __internal::__parallel_or(std::forward<_ExecutionPolicy>(__exec), __first, __last,
[__pred, __is_vector](_ForwardIterator __i, _ForwardIterator __j) {
- return __brick_any_of(__i, __j, __pred, __is_vector);
+ return __internal::__brick_any_of(__i, __j, __pred, __is_vector);
});
});
}
@@ -111,7 +112,7 @@ __pattern_walk1(_ExecutionPolicy&&, _ForwardIterator __first, _ForwardIterator _
_IsVector __is_vector,
/*parallel=*/std::false_type) noexcept
{
-__brick_walk1(__first, __last, __f, __is_vector);
+__internal::__brick_walk1(__first, __last, __f, __is_vector);
}
#if __PSTL_USE_PAR_POLICIES
@@ -121,10 +122,10 @@ __pattern_walk1(_ExecutionPolicy&& __exec, _ForwardIterator __first, _ForwardIte
_IsVector __is_vector,
/*parallel=*/std::true_type)
{
-__except_handler([&]() {
+__internal::__except_handler([&]() {
__par_backend::__parallel_for(std::forward<_ExecutionPolicy>(__exec), __first, __last,
[__f, __is_vector](_ForwardIterator __i, _ForwardIterator __j) {
- __brick_walk1(__i, __j, __f, __is_vector);
+ __internal::__brick_walk1(__i, __j, __f, __is_vector);
});
});
}
@@ -144,7 +145,7 @@ void
__pattern_walk_brick(_ExecutionPolicy&& __exec, _ForwardIterator __first, _ForwardIterator __last, _Brick __brick,
/*parallel=*/std::true_type)
{
-__except_handler([&]() {
+__internal::__except_handler([&]() {
__par_backend::__parallel_for(std::forward<_ExecutionPolicy>(__exec), __first, __last,
[__brick](_ForwardIterator __i, _ForwardIterator __j) { __brick(__i, __j); });
});
@@ -158,7 +159,7 @@ template
_ForwardIterator
__brick_walk1_n(_ForwardIterator __first, _Size __n, _Function __f, /*_IsVectorTag=*/std::false_type)
{
-return __for_each_n_it_serial(__first, __n,
+return __internal::__for_each_n_it_serial(__first, __n,
[&__f](_ForwardIterator __it) { __f(*__it); }); // calling serial version
}
@@ -175,7 +176,7 @@ _ForwardIterator
__pattern_walk1_n(_ExecutionPolicy&&, _ForwardIterator __first, _Size __n, _Function __f, _IsVector __is_vector,
/*is_parallel=*/std::false_type) noexcept
{
-return __br
Re: [RS6000] PR89271, gcc.target/powerpc/vsx-simode2.c
On Fri, Mar 29, 2019 at 10:50:04PM +1030, Alan Modra wrote:
> On Fri, Mar 29, 2019 at 04:47:21AM -0500, Segher Boessenkool wrote:
> > On Fri, Mar 29, 2019 at 04:00:55PM +1030, Alan Modra wrote:
> > > On Thu, Mar 28, 2019 at 01:08:55PM -0500, Segher Boessenkool wrote:
> > > > TARGET_DIRECT_MOVE is always on for these CPUs. Should this also use
> > > > the
> > > > m*vsr* cost with say -mcpu=power7 -mtune=power9?
> > >
> > > No, because if we don't generate m*vsr*, and we shouldn't, then that
> > > would be telling a lie.
> >
> > Then should we have those "tune" things in this conditional? Just do it
> > for any direct move target?
>
> Oh, right. I think we still need to "tune" the cost to reflect
> actual hardware, but that shouldn't be in the outer condition. So
>
> if (TARGET_DIRECT_MOVE)
> {
> if (rs6000_tune != PROCESSOR_POWER9)
> ret = 4 * hard_regno_nregs (0, mode);
> else
> ret = 2 * hard_regno_nregs (0, mode);
> ...
>
> should be good enough.
Yes exactly.
Segher
[committed] Fix gimplification of volatile compound literals (PR c/89872)
Hi!
We shouldn't optimize volatile compound literals to their initializers, even
when they are not addressable.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.
2019-03-29 Jakub Jelinek
PR c/89872
* gimplify.c (gimplify_compound_literal_expr): Don't optimize a
non-addressable complit into its initializer if it is volatile.
* gcc.dg/tree-ssa/pr89872.c: New test.
--- gcc/gimplify.c.jj 2019-03-19 09:10:54.90420 +0100
+++ gcc/gimplify.c 2019-03-29 09:53:09.337256784 +0100
@@ -4665,6 +4665,7 @@ gimplify_compound_literal_expr (tree *ex
otherwise we'd generate a new temporary, and we can as well just
use the decl we already have. */
else if (!TREE_ADDRESSABLE (decl)
+ && !TREE_THIS_VOLATILE (decl)
&& init
&& (fallback & fb_lvalue) == 0
&& gimple_test_f (init))
--- gcc/testsuite/gcc.dg/tree-ssa/pr89872.c.jj 2019-03-29 10:09:55.789803295
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89872.c 2019-03-29 10:11:44.841018571
+0100
@@ -0,0 +1,27 @@
+/* PR c/89872 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-times " ={v} 1;" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " ={v} 2;" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " ={v} 3;" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " ={v} 4;" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " ={v} 0;" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " ={v} " 10 "optimized" } } */
+
+void
+foo (void)
+{
+ (volatile int){1} + (volatile int){2};
+}
+
+void
+bar (void)
+{
+ (volatile int){3};
+}
+
+void
+baz (void)
+{
+ (volatile int){4} / (volatile int){0};
+}
Jakub
[C++ PATCH] Fix assignment to lvalue COND_EXPR vs. ubsan (PR sanitizer/89869)
Hi!
The following testcase is miscompiled, because when cp_build_modify_expr
processes assignment into lvalue COND_EXPR, the rhs doesn't have
side-effects and so stabilize_expr doesn't do anything to it, then we
use that rhs in both COND_EXPR branches (but shared) and finally during
genericization we ubsan instrument that rhs, adding some SAVE_EXPRs in there
because we want to evaluate parts of it multiple times. Unfortunately,
the SAVE_EXPRs will be initialized only in one of the two COND_EXPR branches
and will just use uninitialized temporary in the other one.
Fixed by unsharing the rhs if we do this (but only for ubsan, so that
we don't waste compile time/memory on that when we don't need that).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-03-29 Jakub Jelinek
PR sanitizer/89869
* typeck.c: Include gimplify.h.
(cp_build_modify_expr) : Unshare rhs before using it
for second time. Formatting fixes.
* g++.dg/ubsan/vptr-14.C: New test.
--- gcc/cp/typeck.c.jj 2019-03-22 15:42:02.456993944 +0100
+++ gcc/cp/typeck.c 2019-03-29 11:23:36.823067316 +0100
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.
#include "stringpool.h"
#include "attribs.h"
#include "asan.h"
+#include "gimplify.h"
static tree cp_build_addr_expr_strict (tree, tsubst_flags_t);
static tree cp_build_function_call (tree, tree, tsubst_flags_t);
@@ -8129,8 +8130,6 @@ cp_build_modify_expr (location_t loc, tr
/* Produce (a ? (b = rhs) : (c = rhs))
except that the RHS goes through a save-expr
so the code to compute it is only emitted once. */
- tree cond;
-
if (VOID_TYPE_P (TREE_TYPE (rhs)))
{
if (complain & tf_error)
@@ -8145,13 +8144,21 @@ cp_build_modify_expr (location_t loc, tr
if (!lvalue_or_else (lhs, lv_assign, complain))
return error_mark_node;
- cond = build_conditional_expr
- (input_location, TREE_OPERAND (lhs, 0),
- cp_build_modify_expr (loc, TREE_OPERAND (lhs, 1),
-modifycode, rhs, complain),
- cp_build_modify_expr (loc, TREE_OPERAND (lhs, 2),
-modifycode, rhs, complain),
- complain);
+ tree op1 = cp_build_modify_expr (loc, TREE_OPERAND (lhs, 1),
+modifycode, rhs, complain);
+ /* When sanitizing undefined behavior, even when rhs doesn't need
+ stabilization at this point, the sanitization might add extra
+ SAVE_EXPRs in there and so make sure there is no tree sharing
+ in the rhs, otherwise those SAVE_EXPRs will have initialization
+ only in one of the two branches. */
+ if (sanitize_flags_p (SANITIZE_UNDEFINED
+ | SANITIZE_UNDEFINED_NONDEFAULT))
+ rhs = unshare_expr (rhs);
+ tree op2 = cp_build_modify_expr (loc, TREE_OPERAND (lhs, 2),
+modifycode, rhs, complain);
+ tree cond = build_conditional_expr (input_location,
+ TREE_OPERAND (lhs, 0), op1, op2,
+ complain);
if (cond == error_mark_node)
return cond;
--- gcc/testsuite/g++.dg/ubsan/vptr-14.C.jj 2019-03-29 11:25:19.634389671
+0100
+++ gcc/testsuite/g++.dg/ubsan/vptr-14.C2019-03-29 11:24:37.564076159
+0100
@@ -0,0 +1,18 @@
+// PR sanitizer/89869
+// { dg-do run }
+// { dg-options "-fsanitize=vptr -fno-sanitize-recover=vptr" }
+
+struct S { S *s = 0; virtual ~S () {} };
+
+void
+foo (S *x, S *y)
+{
+ (x->s ? y : x) = x->s;
+}
+
+int
+main ()
+{
+ S a;
+ foo (&a, 0);
+}
Jakub
[PATCH] Tweak i386/pr49095.c testcase (PR rtl-optimization/89865)
Hi!
The following patch adjusts the pr49095.c testcase, so that it counts only
the loads through the first argument of the function and thus doesn't care
how many spill/fills are done using stack saves/loads vs. pushes.
Regtested on x86_64-linux and i686-linux, ok for trunk?
2019-03-29 Jakub Jelinek
PR rtl-optimization/89865
* gcc.target/i386/pr49095.c: Include in scan-assembler-times patterns
the first argument register, so that occassional spills/fills are
ignored.
--- gcc/testsuite/gcc.target/i386/pr49095.c.jj 2018-10-08 15:18:22.074105125
+0200
+++ gcc/testsuite/gcc.target/i386/pr49095.c 2019-03-29 13:11:54.941597147
+0100
@@ -73,5 +73,5 @@ G (long)
/* { dg-final { scan-assembler-not "test\[lq\]" } } */
/* The {f,h}{char,short,int,long}xor functions aren't optimized into
a RMW instruction, so need load, modify and store. FIXME eventually. */
-/* { dg-final { scan-assembler-times "\\), %" 57 { target { ia32 } } } } */
-/* { dg-final { scan-assembler-times "\\), %" 45 { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler-times "\\(%eax\\), %" 12 { target { ia32 } } }
} */
+/* { dg-final { scan-assembler-times "\\(%\[re\]di\\), %" 8 { target { ! ia32
} } } } */
Jakub
[PATCH] Add peephole2s to improve pr49095.c f{char,short,int,long}minus on ia32 (PR rtl-optimization/89865)
Hi!
f{char,short,int,long}minus use a RMW instead of direct memory operation
(regression from 8.3) on ia32. The problem is an extra register copy, which
regcprop would fix up, but unfortunately peephole2 runs before regcprop.
Also, in one of the existing peephole2s I've renumbered the operands so that
we don't overwrite existing operands.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-03-29 Jakub Jelinek
PR rtl-optimization/89865
* config/i386/i386.md
(SWI12 peephole for mem {+,-,&,|,^}= x; mem != 0): Fix up operand
numbers not to clash with the additional operands[4].
(peepholes for mem {+,-,&,|,^}= x; mem != 0): New peephole2s
with extra register copy in the middle.
* gcc.target/i386/pr49095.c: Adjust number of expected RMW spots
on ia32.
--- gcc/config/i386/i386.md.jj 2019-03-28 23:32:26.466689322 +0100
+++ gcc/config/i386/i386.md 2019-03-29 15:58:05.350731242 +0100
@@ -18795,17 +18795,130 @@ (define_peephole2
(GET_CODE (operands[3]) == PLUS
|| GET_CODE (operands[3]) == MINUS)
? CCGOCmode : CCNOmode)"
- [(parallel [(set (match_dup 4) (match_dup 6))
- (set (match_dup 1) (match_dup 5))])]
+ [(parallel [(set (match_dup 5) (match_dup 7))
+ (set (match_dup 1) (match_dup 6))])]
{
- operands[4] = SET_DEST (PATTERN (peep2_next_insn (3)));
- operands[5]
+ operands[5] = SET_DEST (PATTERN (peep2_next_insn (3)));
+ operands[6]
= gen_rtx_fmt_ee (GET_CODE (operands[3]), mode,
copy_rtx (operands[1]),
gen_lowpart (mode, operands[2]));
+ operands[7]
+= gen_rtx_COMPARE (GET_MODE (operands[5]),
+ copy_rtx (operands[6]),
+ const0_rtx);
+})
+
+;; peephole2 comes before regcprop, so deal also with a case that
+;; would be cleaned up by regcprop.
+(define_peephole2
+ [(set (match_operand:SWI 0 "register_operand")
+ (match_operand:SWI 1 "memory_operand"))
+ (parallel [(set (match_dup 0)
+ (match_operator:SWI 3 "plusminuslogic_operator"
+[(match_dup 0)
+ (match_operand:SWI 2 "")]))
+ (clobber (reg:CC FLAGS_REG))])
+ (set (match_operand:SWI 4 "register_operand") (match_dup 0))
+ (set (match_dup 1) (match_dup 4))
+ (set (reg FLAGS_REG) (compare (match_dup 4) (const_int 0)))]
+ "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+ && peep2_reg_dead_p (3, operands[0])
+ && peep2_reg_dead_p (5, operands[4])
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && !reg_overlap_mentioned_p (operands[0], operands[2])
+ && !reg_overlap_mentioned_p (operands[4], operands[1])
+ && (mode != QImode
+ || immediate_operand (operands[2], QImode)
+ || any_QIreg_operand (operands[2], QImode))
+ && ix86_match_ccmode (peep2_next_insn (4),
+(GET_CODE (operands[3]) == PLUS
+ || GET_CODE (operands[3]) == MINUS)
+? CCGOCmode : CCNOmode)"
+ [(parallel [(set (match_dup 5) (match_dup 7))
+ (set (match_dup 1) (match_dup 6))])]
+{
+ operands[5] = SET_DEST (PATTERN (peep2_next_insn (4)));
+ operands[6]
+= gen_rtx_fmt_ee (GET_CODE (operands[3]), GET_MODE (operands[3]),
+ copy_rtx (operands[1]),
+ operands[2]);
+ operands[7]
+= gen_rtx_COMPARE (GET_MODE (operands[5]),
+ copy_rtx (operands[6]),
+ const0_rtx);
+})
+
+(define_peephole2
+ [(set (match_operand:SWI12 0 "register_operand")
+ (match_operand:SWI12 1 "memory_operand"))
+ (parallel [(set (match_operand:SI 4 "register_operand")
+ (match_operator:SI 3 "plusminuslogic_operator"
+[(match_dup 4)
+ (match_operand:SI 2 "nonmemory_operand")]))
+ (clobber (reg:CC FLAGS_REG))])
+ (set (match_operand:SWI12 5 "register_operand") (match_dup 0))
+ (set (match_dup 1) (match_dup 5))
+ (set (reg FLAGS_REG) (compare (match_dup 5) (const_int 0)))]
+ "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+ && REGNO (operands[0]) == REGNO (operands[4])
+ && peep2_reg_dead_p (3, operands[0])
+ && peep2_reg_dead_p (5, operands[5])
+ && (mode != QImode
+ || immediate_operand (operands[2], SImode)
+ || any_QIreg_operand (operands[2], SImode))
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && !reg_overlap_mentioned_p (operands[0], operands[2])
+ && !reg_overlap_mentioned_p (operands[5], operands[1])
+ && ix86_match_ccmode (peep2_next_insn (4),
+(GET_CODE (operands[3]) == PLUS
+ || GET_CODE (operands[3]) == MINUS)
+? CCGOCmode : CCNOmode)"
+ [(parallel [(set (match_dup 6) (match_dup 8))
+ (set (match_dup 1) (match_dup 7))
[PATCH] Improve {f,g}{char,short,int,long}xor in pr49095.c (PR rtl-optimization/89865)
Hi!
The following patch improves the last 8 cases (both -m64 and ia32)
that were using RMW cycle, for xor we actually emit
new = old ^ other; new != old
rather than
new = old ^ other; new != 0
and thus the peephole2 needs to recognize that too.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-03-29 Jakub Jelinek
PR rtl-optimization/89865
* config/i386/i386.md: Add peepholes for z = x; x ^= y; x != z.
* gcc.target/i386/pr49095.c: Don't expect any RMW sequences.
--- gcc/config/i386/i386.md.jj 2019-03-29 15:58:05.350731242 +0100
+++ gcc/config/i386/i386.md 2019-03-29 18:43:45.251208879 +0100
@@ -18922,6 +18922,100 @@ (define_peephole2
const0_rtx);
})
+;; Special cases for xor, where (x ^= y) != 0 is (misoptimized)
+;; into x = z; x ^= y; x != z
+(define_peephole2
+ [(set (match_operand:SWI 0 "register_operand")
+ (match_operand:SWI 1 "memory_operand"))
+ (set (match_operand:SWI 3 "register_operand") (match_dup 0))
+ (parallel [(set (match_operand:SWI 4 "register_operand")
+ (xor:SWI (match_dup 4)
+ (match_operand:SWI 2 "")))
+ (clobber (reg:CC FLAGS_REG))])
+ (set (match_dup 1) (match_dup 4))
+ (set (reg:CCZ FLAGS_REG)
+ (compare:CCZ (match_operand:SWI 5 "register_operand")
+(match_operand:SWI 6 "")))]
+ "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+ && (REGNO (operands[4]) == REGNO (operands[0])
+ || REGNO (operands[4]) == REGNO (operands[3]))
+ && (rtx_equal_p (operands[REGNO (operands[4]) == REGNO (operands[0])
+? 3 : 0], operands[5])
+ ? rtx_equal_p (operands[2], operands[6])
+ : rtx_equal_p (operands[2], operands[5])
+&& rtx_equal_p (operands[REGNO (operands[4]) == REGNO (operands[0])
+ ? 3 : 0], operands[6]))
+ && peep2_reg_dead_p (4, operands[4])
+ && peep2_reg_dead_p (5, operands[REGNO (operands[4]) == REGNO (operands[0])
+ ? 3 : 0])
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && !reg_overlap_mentioned_p (operands[0], operands[2])
+ && !reg_overlap_mentioned_p (operands[3], operands[0])
+ && !reg_overlap_mentioned_p (operands[3], operands[1])
+ && !reg_overlap_mentioned_p (operands[3], operands[2])
+ && (mode != QImode
+ || immediate_operand (operands[2], QImode)
+ || any_QIreg_operand (operands[2], QImode))"
+ [(parallel [(set (match_dup 7) (match_dup 9))
+ (set (match_dup 1) (match_dup 8))])]
+{
+ operands[7] = SET_DEST (PATTERN (peep2_next_insn (4)));
+ operands[8] = gen_rtx_XOR (mode, copy_rtx (operands[1]),
+operands[2]);
+ operands[9]
+= gen_rtx_COMPARE (GET_MODE (operands[7]),
+ copy_rtx (operands[8]),
+ const0_rtx);
+})
+
+(define_peephole2
+ [(set (match_operand:SWI12 0 "register_operand")
+ (match_operand:SWI12 1 "memory_operand"))
+ (set (match_operand:SWI12 3 "register_operand") (match_dup 0))
+ (parallel [(set (match_operand:SI 4 "register_operand")
+ (xor:SI (match_dup 4)
+ (match_operand:SI 2 "")))
+ (clobber (reg:CC FLAGS_REG))])
+ (set (match_dup 1) (match_operand:SWI12 5 "register_operand"))
+ (set (reg:CCZ FLAGS_REG)
+ (compare:CCZ (match_operand:SWI12 6 "register_operand")
+(match_operand:SWI12 7 "")))]
+ "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+ && (REGNO (operands[5]) == REGNO (operands[0])
+ || REGNO (operands[5]) == REGNO (operands[3]))
+ && REGNO (operands[5]) == REGNO (operands[4])
+ && (rtx_equal_p (operands[REGNO (operands[5]) == REGNO (operands[0])
+? 3 : 0], operands[6])
+ ? (REG_P (operands[2])
+ ? REG_P (operands[7]) && REGNO (operands[2]) == REGNO (operands[7])
+ : rtx_equal_p (operands[2], operands[7]))
+ : (rtx_equal_p (operands[REGNO (operands[5]) == REGNO (operands[0])
+ ? 3 : 0], operands[7])
+ && REG_P (operands[2])
+ && REGNO (operands[2]) == REGNO (operands[6])))
+ && peep2_reg_dead_p (4, operands[5])
+ && peep2_reg_dead_p (5, operands[REGNO (operands[5]) == REGNO (operands[0])
+ ? 3 : 0])
+ && !reg_overlap_mentioned_p (operands[0], operands[1])
+ && !reg_overlap_mentioned_p (operands[0], operands[2])
+ && !reg_overlap_mentioned_p (operands[3], operands[0])
+ && !reg_overlap_mentioned_p (operands[3], operands[1])
+ && !reg_overlap_mentioned_p (operands[3], operands[2])
+ && (mode != QImode
+ || immediate_operand (operands[2], SImode)
+ || any_QIreg_operand (operands[2], SImode))"
+ [(parallel [(set (match_dup 8) (match_dup 10))
+ (set (match_dup 1) (match_dup 9))])]
+{
+ operands[8] = SET_DEST (PATTERN (peep2_nex
Re: [C++ PATCH] Fix assignment to lvalue COND_EXPR vs. ubsan (PR sanitizer/89869)
On 3/29/19 3:39 PM, Jakub Jelinek wrote: Hi! The following testcase is miscompiled, because when cp_build_modify_expr processes assignment into lvalue COND_EXPR, the rhs doesn't have side-effects and so stabilize_expr doesn't do anything to it, then we use that rhs in both COND_EXPR branches (but shared) and finally during genericization we ubsan instrument that rhs, adding some SAVE_EXPRs in there because we want to evaluate parts of it multiple times. Unfortunately, the SAVE_EXPRs will be initialized only in one of the two COND_EXPR branches and will just use uninitialized temporary in the other one. Fixed by unsharing the rhs if we do this (but only for ubsan, so that we don't waste compile time/memory on that when we don't need that). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2019-03-29 Jakub Jelinek PR sanitizer/89869 * typeck.c: Include gimplify.h. (cp_build_modify_expr) : Unshare rhs before using it for second time. Formatting fixes. OK. Jason
Re: C++ PATCH for c++/89852 - ICE with C++11 functional cast with { }
On Thu, Mar 28, 2019 at 02:55:55PM -0400, Jason Merrill wrote:
> On 3/27/19 5:45 PM, Marek Polacek wrote:
> > Here we have a non-dependent constructor in a template:
> >
> >{ VIEW_CONVERT_EXPR(j) }
> >
> > In digest_init we call massage_init_elt, which calls digest_init_r on the
> > element. We convert the element, but we're in a template, so
> > perform_implicit_conversion added an IMPLICIT_CONV_EXPR around it. And then
> > massage_init_elt calls maybe_constant_init on the element and the usual
> > sadness
> > ensues.
>
> Only after fold_non_dependent_expr. Perhaps we want a
> fold_non_dependent_init?
Yeah, I recall we talked about adding fold_non_dependent_init a year ago.
Using it here works -- in a template, we won't call maybe_constant_*, so
there's no crash.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-03-29 Marek Polacek
PR c++/89852 - ICE with C++11 functional cast with { }.
* constexpr.c (fold_non_dependent_expr_template): New static function
broken out of...
(fold_non_dependent_expr): ...here.
(fold_non_dependent_init): New function.
* cp-tree.h (fold_non_dependent_init): Declare.
* typeck2.c (massage_init_elt): Call fold_non_dependent_init instead
of fold_non_dependent_expr. Don't call maybe_constant_init.
* g++.dg/cpp0x/initlist115.C: New test.
diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index daf34e10784..988b37b8ad8 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -5581,6 +5581,58 @@ clear_cv_and_fold_caches (void)
clear_fold_cache ();
}
+/* Internal function handling expressions in templates for
+ fold_non_dependent_expr and fold_non_dependent_init.
+
+ If we're in a template, but T isn't value dependent, simplify
+ it. We're supposed to treat:
+
+ template void f(T[1 + 1]);
+ template void f(T[2]);
+
+ as two declarations of the same function, for example. */
+
+static tree
+fold_non_dependent_expr_template (tree t, tsubst_flags_t complain,
+ bool manifestly_const_eval)
+{
+ gcc_assert (processing_template_decl);
+
+ if (is_nondependent_constant_expression (t))
+{
+ processing_template_decl_sentinel s;
+ t = instantiate_non_dependent_expr_internal (t, complain);
+
+ if (type_unknown_p (t) || BRACE_ENCLOSED_INITIALIZER_P (t))
+ {
+ if (TREE_OVERFLOW_P (t))
+ {
+ t = build_nop (TREE_TYPE (t), t);
+ TREE_CONSTANT (t) = false;
+ }
+ return t;
+ }
+
+ tree r = cxx_eval_outermost_constant_expr (t, true, true,
+manifestly_const_eval,
+NULL_TREE);
+ /* cp_tree_equal looks through NOPs, so allow them. */
+ gcc_checking_assert (r == t
+ || CONVERT_EXPR_P (t)
+ || TREE_CODE (t) == VIEW_CONVERT_EXPR
+ || (TREE_CONSTANT (t) && !TREE_CONSTANT (r))
+ || !cp_tree_equal (r, t));
+ return r;
+}
+ else if (TREE_OVERFLOW_P (t))
+{
+ t = build_nop (TREE_TYPE (t), t);
+ TREE_CONSTANT (t) = false;
+}
+
+ return t;
+}
+
/* Like maybe_constant_value but first fully instantiate the argument.
Note: this is equivalent to instantiate_non_dependent_expr_sfinae
@@ -5604,51 +5656,29 @@ fold_non_dependent_expr (tree t,
if (t == NULL_TREE)
return NULL_TREE;
- /* If we're in a template, but T isn't value dependent, simplify
- it. We're supposed to treat:
+ if (processing_template_decl)
+return fold_non_dependent_expr_template (t, complain,
+manifestly_const_eval);
- template void f(T[1 + 1]);
- template void f(T[2]);
+ return maybe_constant_value (t, NULL_TREE, manifestly_const_eval);
+}
- as two declarations of the same function, for example. */
- if (processing_template_decl)
-{
- if (is_nondependent_constant_expression (t))
- {
- processing_template_decl_sentinel s;
- t = instantiate_non_dependent_expr_internal (t, complain);
- if (type_unknown_p (t)
- || BRACE_ENCLOSED_INITIALIZER_P (t))
- {
- if (TREE_OVERFLOW_P (t))
- {
- t = build_nop (TREE_TYPE (t), t);
- TREE_CONSTANT (t) = false;
- }
- return t;
- }
+/* Like maybe_constant_init but first fully instantiate the argument. */
- tree r = cxx_eval_outermost_constant_expr (t, true, true,
-manifestly_const_eval,
-NULL_TREE);
- /* cp_tree_equal looks through NOPs, so allow them. */
- gcc_checking_assert (r == t
- || CONVERT_EXPR_P (t)
-
Re: [PATCH] Tweak i386/pr49095.c testcase (PR rtl-optimization/89865)
On 3/29/19 1:41 PM, Jakub Jelinek wrote: > Hi! > > The following patch adjusts the pr49095.c testcase, so that it counts only > the loads through the first argument of the function and thus doesn't care > how many spill/fills are done using stack saves/loads vs. pushes. > > Regtested on x86_64-linux and i686-linux, ok for trunk? > > 2019-03-29 Jakub Jelinek > > PR rtl-optimization/89865 > * gcc.target/i386/pr49095.c: Include in scan-assembler-times patterns > the first argument register, so that occassional spills/fills are > ignored. OK jeff
Re: [PATCH] Add peephole2s to improve pr49095.c f{char,short,int,long}minus on ia32 (PR rtl-optimization/89865)
On 3/29/19 1:44 PM, Jakub Jelinek wrote:
> Hi!
>
> f{char,short,int,long}minus use a RMW instead of direct memory operation
> (regression from 8.3) on ia32. The problem is an extra register copy, which
> regcprop would fix up, but unfortunately peephole2 runs before regcprop.
> Also, in one of the existing peephole2s I've renumbered the operands so that
> we don't overwrite existing operands.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2019-03-29 Jakub Jelinek
>
> PR rtl-optimization/89865
> * config/i386/i386.md
> (SWI12 peephole for mem {+,-,&,|,^}= x; mem != 0): Fix up operand
> numbers not to clash with the additional operands[4].
> (peepholes for mem {+,-,&,|,^}= x; mem != 0): New peephole2s
> with extra register copy in the middle.
>
> * gcc.target/i386/pr49095.c: Adjust number of expected RMW spots
> on ia32.
OK. One might ask if there's a way to share a bit of code here since
there's a fair amount of duplication. But I'll trust that you've
pondered that and decided it wasn't really worth the effort.
Jeff
Re: [PATCH] Improve {f,g}{char,short,int,long}xor in pr49095.c (PR rtl-optimization/89865)
On 3/29/19 1:47 PM, Jakub Jelinek wrote: > Hi! > > The following patch improves the last 8 cases (both -m64 and ia32) > that were using RMW cycle, for xor we actually emit > new = old ^ other; new != old > rather than > new = old ^ other; new != 0 > and thus the peephole2 needs to recognize that too. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2019-03-29 Jakub Jelinek > > PR rtl-optimization/89865 > * config/i386/i386.md: Add peepholes for z = x; x ^= y; x != z. > > * gcc.target/i386/pr49095.c: Don't expect any RMW sequences. E. But OK. jeff
Re: Implement C++20 constexpr , , and
On 29/03/19 12:02 -0400, Ed Smith-Rowland wrote:
On 3/29/19 9:23 AM, Jakub Jelinek wrote:
On Fri, Mar 29, 2019 at 09:10:26AM -0400, Ed Smith-Rowland via gcc-patches
wrote:
Greetings,
This patch implements C++20 constexpr for , , .
It's a large patch but only affects C++20 and the volume is mostly test
cases.
This differs from the previous patch in actually testing constexpr :-\ and
in the addition of wrappers for __builtin_memmove and __builtin_memcmp that
supply constexpr branches if C++20 and is_constant_evaluated().
+void*
+__memmove(_Tp* __dst, const _Tp* __src, ptrdiff_t __num)
+{
+#if __cplusplus > 201703L
+ if (is_constant_evaluated())
+ {
+ for(; __num > 0; --__num)
+ {
+ *__dst = *__src;
+ ++__src;
+ ++__dst;
+ }
+ return __dst;
+ }
+ else if (__num)
+#endif
+ return __builtin_memmove(__dst, __src, sizeof(_Tp) * abs(__num));
+ return __dst;
..
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
+ __memmove(__result, __first, _Num);
..
const ptrdiff_t _Num = __last - __first;
if (_Num)
- __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
+ __memmove(__result - _Num, __first, _Num);
Why the abs in there, that is something that wasn't previously there and
if the compiler doesn't figure out that __last >= __first, it would mean
larger emitted code for the non-constexpr case. As memmove argument is
size_t, wouldn't it be better to make __num just size_t and remove this abs?
Also, wouldn't it be better to have on the other side the __num == 0
handling inside of __memmove, you already have it there for C++2a, but not
for older. You could then drop the if (_Num) guards around __memmove.
memmove needs to be able to work with __last < __first also.
Why?
I was getting negative __num and when passed to __builtin_memmove
which takes size_t got blowups.
I'm not sure why it worked before. __builtin_memmove will work with
__last < __first and sensible positive __num.
When I tried to do what __builtin_memmove or ::memmove must do with
unsigned num I would need to branch on __last < __first
How can last < first be true for any algorithm?
and copy backwards. But pointer comparisons were getting caught as
non-constexpr.
I'll look at the __num==0 (noop) testing.
Also, shouldn't the is_constant_evaluated() calls be guarded with
_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED ? Without that it won't be
defined...
I am trying for a C++20-only patch (hoping to get it in for 9) so I
used the library function and tested __cplusplus > 201703L.
We could do _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED and then we
could use these for lower version. Maybe stage 1?
The reason to check _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED is
that std::is_constant_evaluated() is not available when compiling with
Clang, because it doesn't provide the built-in yet.
It's fine to make the algos not constexpr when the builtin isn't
available, it's not fine to just use something that won't compile.
Re: C++ PATCH for c++/89852 - ICE with C++11 functional cast with { }
On 3/29/19 4:25 PM, Marek Polacek wrote:
On Thu, Mar 28, 2019 at 02:55:55PM -0400, Jason Merrill wrote:
On 3/27/19 5:45 PM, Marek Polacek wrote:
Here we have a non-dependent constructor in a template:
{ VIEW_CONVERT_EXPR(j) }
In digest_init we call massage_init_elt, which calls digest_init_r on the
element. We convert the element, but we're in a template, so
perform_implicit_conversion added an IMPLICIT_CONV_EXPR around it. And then
massage_init_elt calls maybe_constant_init on the element and the usual sadness
ensues.
Only after fold_non_dependent_expr. Perhaps we want a
fold_non_dependent_init?
Yeah, I recall we talked about adding fold_non_dependent_init a year ago.
Using it here works -- in a template, we won't call maybe_constant_*, so
there's no crash.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-03-29 Marek Polacek
PR c++/89852 - ICE with C++11 functional cast with { }.
* constexpr.c (fold_non_dependent_expr_template): New static function
broken out of...
(fold_non_dependent_expr): ...here.
(fold_non_dependent_init): New function.
* cp-tree.h (fold_non_dependent_init): Declare.
* typeck2.c (massage_init_elt): Call fold_non_dependent_init instead
of fold_non_dependent_expr. Don't call maybe_constant_init.
@@ -5604,51 +5656,29 @@ fold_non_dependent_expr (tree t,
if (t == NULL_TREE)
return NULL_TREE;
+ if (processing_template_decl)
+return fold_non_dependent_expr_template (t, complain,
+manifestly_const_eval);
+ return maybe_constant_value (t, NULL_TREE, manifestly_const_eval);
+}
+tree
+fold_non_dependent_init (tree t,
+tsubst_flags_t complain /*=tf_warning_or_error*/,
+bool manifestly_const_eval /*=false*/)
+{
+ if (t == NULL_TREE)
+return NULL_TREE;
+ if (processing_template_decl)
+return fold_non_dependent_expr_template (t, complain,
+manifestly_const_eval);
Don't we still need the maybe_constant_init TARGET_EXPR stripping
behavior in a template?
Jason
Re: Ping Re: [PATCH] Add missing avx512dqintrin.h _mm_mask_fpclass_s[sd]_mask (PR target/897803)
On 3/28/19 1:38 AM, Uros Bizjak wrote: > On Thu, Mar 28, 2019 at 7:47 AM Hongtao Liu wrote: >> >> Hi Uros: >> would you help to review this patch? > > This is AVX512F patch, you will need the approval from the maintainer > first. I have no plans to maintain AVX512 beyond rubber-stamping OK > dead obvious regression from a reputable contributors. It is simply > too much involvment for me. If the appointed maintainer doesn't > respond anymore, then I suggest you raise the issue with GCC steering > committe. Also note, this is not fixing a regression relative to a prior release. I'd prefer to see this moved to gcc-10 unless there is a strong justification for pushing it into gcc-9. The subject like should also be changed to reference the right bz. I think the right one is 89803. jeff
Re: C++ PATCH for c++/89852 - ICE with C++11 functional cast with { }
On Fri, Mar 29, 2019 at 05:29:27PM -0400, Jason Merrill wrote:
> On 3/29/19 4:25 PM, Marek Polacek wrote:
> > On Thu, Mar 28, 2019 at 02:55:55PM -0400, Jason Merrill wrote:
> > > On 3/27/19 5:45 PM, Marek Polacek wrote:
> > > > Here we have a non-dependent constructor in a template:
> > > >
> > > > { VIEW_CONVERT_EXPR(j) }
> > > >
> > > > In digest_init we call massage_init_elt, which calls digest_init_r on
> > > > the
> > > > element. We convert the element, but we're in a template, so
> > > > perform_implicit_conversion added an IMPLICIT_CONV_EXPR around it. And
> > > > then
> > > > massage_init_elt calls maybe_constant_init on the element and the usual
> > > > sadness
> > > > ensues.
> > >
> > > Only after fold_non_dependent_expr. Perhaps we want a
> > > fold_non_dependent_init?
> >
> > Yeah, I recall we talked about adding fold_non_dependent_init a year ago.
> >
> > Using it here works -- in a template, we won't call maybe_constant_*, so
> > there's no crash.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2019-03-29 Marek Polacek
> >
> > PR c++/89852 - ICE with C++11 functional cast with { }.
> > * constexpr.c (fold_non_dependent_expr_template): New static function
> > broken out of...
> > (fold_non_dependent_expr): ...here.
> > (fold_non_dependent_init): New function.
> > * cp-tree.h (fold_non_dependent_init): Declare.
> > * typeck2.c (massage_init_elt): Call fold_non_dependent_init instead
> > of fold_non_dependent_expr. Don't call maybe_constant_init.
> >
> > @@ -5604,51 +5656,29 @@ fold_non_dependent_expr (tree t,
> > if (t == NULL_TREE)
> > return NULL_TREE;
> > + if (processing_template_decl)
> > +return fold_non_dependent_expr_template (t, complain,
> > +manifestly_const_eval);
> > + return maybe_constant_value (t, NULL_TREE, manifestly_const_eval);
> > +}
> > +tree
> > +fold_non_dependent_init (tree t,
> > +tsubst_flags_t complain /*=tf_warning_or_error*/,
> > +bool manifestly_const_eval /*=false*/)
> > +{
> > + if (t == NULL_TREE)
> > +return NULL_TREE;
> > + if (processing_template_decl)
> > +return fold_non_dependent_expr_template (t, complain,
> > +manifestly_const_eval);
>
> Don't we still need the maybe_constant_init TARGET_EXPR stripping behavior
> in a template?
It would seem that we don't need it, since nothing broke. But this patch
includes the stripping.
Bootstrap/regtest running on x86_64-linux, ok for trunk?
2019-03-29 Marek Polacek
PR c++/89852 - ICE with C++11 functional cast with { }.
* constexpr.c (fold_non_dependent_expr_template): New static function
broken out of...
(fold_non_dependent_expr): ...here.
(fold_non_dependent_init): New function.
* cp-tree.h (fold_non_dependent_init): Declare.
* typeck2.c (massage_init_elt): Call fold_non_dependent_init instead
of fold_non_dependent_expr. Don't call maybe_constant_init.
* g++.dg/cpp0x/initlist115.C: New test.
diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index daf34e10784..53854a8acd4 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -5581,6 +5581,58 @@ clear_cv_and_fold_caches (void)
clear_fold_cache ();
}
+/* Internal function handling expressions in templates for
+ fold_non_dependent_expr and fold_non_dependent_init.
+
+ If we're in a template, but T isn't value dependent, simplify
+ it. We're supposed to treat:
+
+ template void f(T[1 + 1]);
+ template void f(T[2]);
+
+ as two declarations of the same function, for example. */
+
+static tree
+fold_non_dependent_expr_template (tree t, tsubst_flags_t complain,
+ bool manifestly_const_eval)
+{
+ gcc_assert (processing_template_decl);
+
+ if (is_nondependent_constant_expression (t))
+{
+ processing_template_decl_sentinel s;
+ t = instantiate_non_dependent_expr_internal (t, complain);
+
+ if (type_unknown_p (t) || BRACE_ENCLOSED_INITIALIZER_P (t))
+ {
+ if (TREE_OVERFLOW_P (t))
+ {
+ t = build_nop (TREE_TYPE (t), t);
+ TREE_CONSTANT (t) = false;
+ }
+ return t;
+ }
+
+ tree r = cxx_eval_outermost_constant_expr (t, true, true,
+manifestly_const_eval,
+NULL_TREE);
+ /* cp_tree_equal looks through NOPs, so allow them. */
+ gcc_checking_assert (r == t
+ || CONVERT_EXPR_P (t)
+ || TREE_CODE (t) == VIEW_CONVERT_EXPR
+ || (TREE_CONSTANT (t) && !TREE_CONSTANT (r))
+ || !cp_tree_equal (r, t));
+ return r;
+}
+ else if (TREE_OVERFLOW_P (t))
+{
+ t = build_nop (TREE_TYPE (t), t);
+ TREE_CONSTANT (t) =
[PATCH] RISC-V: Fix __riscv_compressed regression.
This was accidentally broken by the patch adding ELF attribute support.
The __riscv_compressed predefined macro is not being defined when the
target supports the C extension. The fix adds testcases to verify that
all of the predefined macros are correct for various option combinations.
Tested with 32/64-bit elf/linux cross toolchain builds and checks. There
were no regressions. Two of the new testcases fail without the patch, but
all work with the patch.
Committed.
Jim
gcc/
* common/config/riscv/riscv-common.c (riscv_parse_arch_string):
Clear MASK_RVC and then set if C subset supported.
gcc/testsuite/
* gcc.target/riscv/predef-1.c: New.
* gcc.target/riscv/predef-2.c: New.
* gcc.target/riscv/predef-3.c: New.
* gcc.target/riscv/predef-4.c: New.
* gcc.target/riscv/predef-5.c: New.
* gcc.target/riscv/predef-6.c: New.
* gcc.target/riscv/predef-7.c: New.
* gcc.target/riscv/predef-8.c: New.
---
gcc/common/config/riscv/riscv-common.c| 4 ++
gcc/testsuite/gcc.target/riscv/predef-1.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-2.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-3.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-4.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-5.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-6.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-7.c | 66 +++
gcc/testsuite/gcc.target/riscv/predef-8.c | 66 +++
9 files changed, 532 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-1.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-2.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-4.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-5.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-6.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-7.c
create mode 100644 gcc/testsuite/gcc.target/riscv/predef-8.c
diff --git a/gcc/common/config/riscv/riscv-common.c
b/gcc/common/config/riscv/riscv-common.c
index 72c43c69b23..9452bd3a0ce 100644
--- a/gcc/common/config/riscv/riscv-common.c
+++ b/gcc/common/config/riscv/riscv-common.c
@@ -564,6 +564,10 @@ riscv_parse_arch_string (const char *isa, int *flags,
location_t loc)
if (subset_list->lookup ("d"))
*flags |= MASK_DOUBLE_FLOAT;
+ *flags &= ~MASK_RVC;
+ if (subset_list->lookup ("c"))
+*flags |= MASK_RVC;
+
if (current_subset_list)
delete current_subset_list;
diff --git a/gcc/testsuite/gcc.target/riscv/predef-1.c
b/gcc/testsuite/gcc.target/riscv/predef-1.c
new file mode 100644
index 000..70f121f15fa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/predef-1.c
@@ -0,0 +1,66 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=rv32i -mabi=ilp32 -mcmodel=medlow" } */
+
+int main () {
+#if !defined(__riscv)
+#error "__riscv"
+#endif
+
+#if defined(__riscv_compressed)
+#error "__riscv_compressed"
+#endif
+
+#if defined(__riscv_32e)
+#error "__riscv_32e"
+#endif
+
+#if defined(__riscv_atomic)
+#error "__riscv_atomic"
+#endif
+
+#if defined(__riscv_mul)
+#error "__riscv_mul"
+#endif
+#if defined(__riscv_div)
+#error "__riscv_div"
+#endif
+#if defined(__riscv_muldiv)
+#error "__riscv_muldiv"
+#endif
+
+#if __riscv_xlen != 32
+#error "__riscv_xlen"
+#endif
+
+#if defined(__riscv_fdiv)
+#error "__riscv_fdiv"
+#endif
+#if defined(__riscv_fsqrt)
+#error "__riscv_fsqrt"
+#endif
+
+#if defined(__riscv_abi_rve)
+#error "__riscv_abi_rve"
+#endif
+#if !defined(__riscv_float_abi_soft)
+#error "__riscv_float_abi_soft"
+#endif
+#if defined(__riscv_float_abi_single)
+#error "__riscv_float_abi_single"
+#endif
+#if defined(__riscv_float_abi_double)
+#error "__riscv_float_abi_double"
+#endif
+
+#if !defined(__riscv_cmodel_medlow)
+#error "__riscv_cmodel_medlow"
+#endif
+#if defined(__riscv_cmodel_medany)
+#error "__riscv_cmodel_medlow"
+#endif
+#if defined(__riscv_cmodel_pic)
+#error "__riscv_cmodel_medlow"
+#endif
+
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.target/riscv/predef-2.c
b/gcc/testsuite/gcc.target/riscv/predef-2.c
new file mode 100644
index 000..6f3c8c3864d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/predef-2.c
@@ -0,0 +1,66 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=rv32imaf -mabi=ilp32f -mcmodel=medany" } */
+
+int main () {
+#if !defined(__riscv)
+#error "__riscv"
+#endif
+
+#if defined(__riscv_compressed)
+#error "__riscv_compressed"
+#endif
+
+#if defined(__riscv_32e)
+#error "__riscv_32e"
+#endif
+
+#if !defined(__riscv_atomic)
+#error "__riscv_atomic"
+#endif
+
+#if !defined(__riscv_mul)
+#error "__riscv_mul"
+#endif
+#if !defined(__riscv_div)
+#error "__riscv_div"
+#endif
+#if !defined(__riscv_muldiv)
+#error "__riscv_muldiv"
+#endif
+
+#if __riscv_xlen != 32
+#error "__ris
Re: RFA: Patch to fix severe recursion in d_count_templates_scopes (PR 89394)
On 3/21/19 6:04 AM, Nick Clifton wrote: > Hi Ian, > > Attached is a proposed patch to fix PR 89394, which contains an > artificial mangled name that triggers excessive recursion in > d_count_templates_scopes. The patch uses the same recursion limit > that is already in place for d_print_comp, which I hope will be > acceptable. > > There is one frag in the patch which is not directly related to this > recursion problem however. It extends the check in > cplus_demangle_fill_name so that names with a negative length are > rejected. I had originally thought that the excessive recursion was > due to a negative length string, although further investigation proved > this guess to be wrong. I felt that leaving the check in however > would still be a good idea. > > Tested with no regressions with an x86_64-linux-gnu toolchain, as well > as against the testcase in PR 89394. > > OK to apply ? > > Cheers > Nick > > libiberty/ChangeLog > 2019-03-21 Nick Clifton > > PR 89394 > * cp-demangle.c (cplus_demangle_fill_name): Reject negative > lengths. > (d_count_templates_scopes): Replace num_templates and num_scopes > parameters with a struct d_print_info pointer parameter. Adjust > body of the function accordingly. Add recursion counter and check > that the recursion limit is not reached. > (d_print_init): Pass dpi parameter to d_count_templates_scopes. > Reset recursion counter afterwards, unless the recursion limit was > reached. > It's actually a fairly trivial patch once you know that d_print_init sets up dpi :-) Given some folks seem to think this is a security issue, I'm going to ACK for gcc-9 even though it's not a regression. Jeff
Re: [PATCH] Add target-zlib to top-level configure, use zlib from libphobos
On Mon, 18 Feb 2019 at 14:26, Matthias Klose wrote:
>
>
> sorry, I didn't mean to propose to rename the option, so
> --with-target-system-zlib=auto sounds fine.
OK, a bit belated, but here it is --with-target-system-zlib=auto.
--
Iain
---
ChangeLog:
2019-03-29 Iain Buclaw
* configure.ac: Add target-zlib to target_libraries.
* configure: Regenerate.
libphobos/ChangeLog:
2019-03-29 Iain Buclaw
* m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_ZLIB): Use
libz_convienience.a if not using system zlib.
* Makefile.in: Regenerate.
* configure: Regenerate.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am: Remove ZLIB_CSOURCES and AM_CFLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
---
diff --git a/configure b/configure
index adf4fda0f69..1c5f9b502a8 100755
--- a/configure
+++ b/configure
@@ -2813,7 +2813,8 @@ target_libraries="target-libgcc \
target-libobjc \
target-libada \
target-libgo \
- target-libphobos"
+ target-libphobos \
+ target-zlib"
# these tools are built using the target libraries, and are intended to
# run only in the target environment
diff --git a/configure.ac b/configure.ac
index 87f2aee0500..cffccd37805 100644
--- a/configure.ac
+++ b/configure.ac
@@ -163,7 +163,8 @@ target_libraries="target-libgcc \
target-libobjc \
target-libada \
target-libgo \
- target-libphobos"
+ target-libphobos \
+ target-zlib"
# these tools are built using the target libraries, and are intended to
# run only in the target environment
diff --git a/libphobos/Makefile.in b/libphobos/Makefile.in
index e7c156aa5eb..1cd4117f2ee 100644
--- a/libphobos/Makefile.in
+++ b/libphobos/Makefile.in
@@ -241,6 +241,7 @@ LIBBACKTRACE = @LIBBACKTRACE@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIBTOOL = @LIBTOOL@
+LIBZ = @LIBZ@
LIPO = @LIPO@
LN_S = @LN_S@
LTLIBOBJS = @LTLIBOBJS@
diff --git a/libphobos/configure b/libphobos/configure
index d86934b59a5..906d472c039 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -640,8 +640,7 @@ gdc_include_dir
libphobos_toolexeclibdir
libphobos_toolexecdir
gcc_version
-DRUNTIME_ZLIB_SYSTEM_FALSE
-DRUNTIME_ZLIB_SYSTEM_TRUE
+LIBZ
BACKTRACE_SUPPORTS_THREADS
BACKTRACE_USES_MALLOC
BACKTRACE_SUPPORTED
@@ -1484,7 +1483,7 @@ Optional Packages:
--without-libatomic Do not use libatomic in core.atomic (default: auto)
--without-libbacktrace Do not use libbacktrace in core.runtime (default:
auto)
- --with-target-system-zlib
+ --with-target-system-zlib={yes,no,auto}
use installed libz (default: no)
--with-cross-host=HOST configuring with a cross compiler
@@ -11499,7 +11498,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11502 "configure"
+#line 11501 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -11605,7 +11604,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11608 "configure"
+#line 11607 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -14864,79 +14863,94 @@ $as_echo "$druntime_cv_lib_sockets" >&6; }
LIBS="$LIBS $druntime_cv_lib_sockets"
+ ac_ext=c
+ac_cpp='$CPP $CPPFLAGS'
+ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
+ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5'
+ac_compiler_gnu=$ac_cv_c_compiler_gnu
+
+ LIBZ=""
+
# Check whether --with-target-system-zlib was given.
if test "${with_target_system_zlib+set}" = set; then :
withval=$with_target_system_zlib;
+else
+ with_target_system_zlib=no
fi
- system_zlib=false
- if test "x$with_target_system_zlib" = "xyes"; then :
+ case "$with_target_system_zlib" in
+yes|no|auto) ;;
+*) as_fn_error $? "Invalid argument for --with-target-system-zlib" "$LINENO" 5 ;;
+ esac
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for deflate in -lz" >&5
-$as_echo_n "checking for deflate in -lz... " >&6; }
-if ${ac_cv_lib_z_deflate+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-lz $LIBS"
-cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for system zlib" >&5
+$as_echo_n "checking for system zlib... " >&6; }
+ save_LIBS=$LIBS
+ LIBS="$LIBS -lz"
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-
-/* Override any GCC internal prototype to avoid an error.
- Use char because int might match the return type of a GCC
- builtin and then its argument prototype would still apply. */
-#ifdef __cplusplus
-extern "C"
-#endif
-char deflate ();
+#include
int
main ()
{
-return deflate ();
+gzopen("none", "rb")
;
return 0;
}
_ACEOF
if ac_fn_c_try_link "$LINENO"; then :
- ac_cv_lib_z_deflate=yes
-else
- ac_cv_lib_z_deflate=no
-fi
-rm -f
New French PO file for 'gcc' (version 9.1-b20190324)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: https://translationproject.org/latest/gcc/fr.po (This file, 'gcc-9.1-b20190324.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Ping Re: [PATCH] Add missing avx512dqintrin.h _mm_mask_fpclass_s[sd]_mask (PR target/89803)
On Sat, Mar 30, 2019 at 5:34 AM Jeff Law wrote: > > On 3/28/19 1:38 AM, Uros Bizjak wrote: > > On Thu, Mar 28, 2019 at 7:47 AM Hongtao Liu wrote: > >> > >> Hi Uros: > >> would you help to review this patch? > > > > This is AVX512F patch, you will need the approval from the maintainer > > first. I have no plans to maintain AVX512 beyond rubber-stamping OK > > dead obvious regression from a reputable contributors. It is simply > > too much involvment for me. If the appointed maintainer doesn't > > respond anymore, then I suggest you raise the issue with GCC steering > > committe. > Also note, this is not fixing a regression relative to a prior release. > I'd prefer to see this moved to gcc-10 unless there is a strong > justification for pushing it into gcc-9. > > The subject like should also be changed to reference the right bz. I > think the right one is 89803. > > jeff Yes, it's PR 89803, sorry for typo. And thank you for you explanation. -- BR, Hongtao
