Hi Thomas,
On 10/15/19 3:07 PM, Thomas Schwinge wrote:
(Of cause, it is also run-time checkable
OK, I was about to ask for that, if that makes sense to do.
The question is for what. One could add it for run-time checking (e.g.
for gfortran "-fcheck=…). Or for actions like "omp update",
On Tue, Oct 15, 2019 at 04:10:34PM +0200, Tobias Burnus wrote:
> But for "omp update" with noncontiguous memory, it is not clear what's
> faster:
> * Simply updating one contiguous memory block, enclosing the gaps
> * Doing multiple updates of contiguous memory to take advantage of memory
> gaps.
Hi Richard,
> Sure, the "extern array of unknown size" case isn't about section anchors.
> But this part of my message (snipped above) was about the other case
> (objects of known size), and applied to individual objects as well as
> section anchors.
>
> What I was trying to say is: yes, we need
On Tue, Oct 15, 2019 at 12:47:02PM -0500, Peter Bergner wrote:
> On 10/15/19 4:56 AM, Segher Boessenkool wrote:
> > On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
> >> And another issue: Behavior is still inconsistent between "-mno-vsx
> >> -flto" and "-mno-vsx" for user code. Previous
On 10/15/19 6:49 AM, Jozef Lawrynowicz wrote:
> On Mon, 14 Oct 2019 15:18:08 -0600
> Jeff Law wrote:
>
>> On 10/8/19 4:34 AM, Jozef Lawrynowicz wrote:
>>> In the large memory model, MSP430 instructions have some useful properties
>>> when
>>> performing byte, word or address-word writes to
Hi all,
While working on implementing lowering of bit-field accesses in
gimple, I ran into an ICE which was not covered by the current
testsuite.
Committed these two new testcases as obvious.
Thanks,
Andrew Pinski
ChangeLog:
* gcc.c-torture/compile/20191015-1.c: New test.
* gcc.c-torture
The main fix here is to load the relocation offset before the function pointer
during
function pointer canonicalization. There is still a small race in
multi-threaded applications
because the dynamic linker currently updates the relocation offset before the
function pointer
when doing lazy
On 10/15/19 1:21 PM, Segher Boessenkool wrote:
> On Tue, Oct 15, 2019 at 12:47:02PM -0500, Peter Bergner wrote:
>> I'd say this is user error, telling the compiler it has to inline the callee
>> function, but then using incompatible options on the caller and the callee,
>> so that it cannot. I
This updates the description of the support for fix and continue debugging.
No functional change intended.
tested on x86_64-darwin16,
applied to mainline,
Iain
gcc/ChangeLog:
2019-10-15 Iain Sandoe
* config/darwin.c: Update description of fix and continue.
diff --git
As PR92107 shows, genattrtab doesn't parenthesize expressions correctly
(or at all, even). This fixes it.
I'll commit it as trivial and obvious if my bootstrap with it shows no
problems (or someone tells me not to, of course).
Segher
2019-10-15 Segher Boessenkool
PR
On Tue, Oct 15, 2019 at 07:34:31PM +0200, Jakub Jelinek wrote:
> On Tue, Oct 15, 2019 at 01:17:17PM -0400, Marek Polacek wrote:
> > 2019-10-15 Marek Polacek
> >
> > PR c++/92106 - ICE with structured bindings and -Wreturn-local-addr.
> > * typeck.c
Certain errors encountered during constraint satisfaction render the
program ill-formed. Emit those as errors during satisfaction and not
when diagnosing constraint errors.
The errors should include the full context for failure (i.e., when
satisfying X, when satisfying Y, this failed), but we
Hi
I completed this overload before noticing that the Standard do not
expect anything when 'advancing' an output iterator.
But as I've done it consistenly with the istreambuf_iterator here
it is with samples about how to use it.
Let me know if acceptable.
François
diff --git
The attached patch removes a FIXME added recently to the strlen
pass as a reminder to extend the handling of multi-byte stores
of characters copied from non-constant strings with constant
lengths to strings with non-constant lengths in some known range.
For the string length range information it
Hi,
On Tue, 15 Oct 2019, Philipp Tomsich wrote:
> This looks good from our side and has shown useful (combined with the other 2
> patches) in
> our testing with SPEC2017.
> Given that this looks final: what is the plan for getting this merged?
I'll get to review this v3 version this week.
On 10/15/19 10:44 AM, Richard Biener wrote:
> On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
> wrote:
>> If the user explicitly said not to compile a function with a particular
>> option, how can we justify ignoring that request just because we're
>> inlining it? We don't do that for
glibc v2.30 added the pthread_mutex_clocklock,
pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock
functions. These accept CLOCK_MONOTONIC, so they can be used to
implement proper steady_clock support in timed_mutex,
recursive_timed_mutex and shared_timed_mutex that is immune to the
system
* testsuite/30_threads/shared_timed_mutex/try_lock/3.cc: Convert
existing test to templated function so that it can be called with
both system_clock and steady_clock.
---
libstdc++-v3/testsuite/30_threads/shared_timed_mutex/try_lock/3.cc | 17
-
1 file
Here is an update to set _M_sbuf to null if the user advance too much.
Note that in this case the streambuf remains un-modified which is
different from the current implementation. I think it is another
enhancement.
I also change the Debug assertion message for something more dedicated
to
The use of default_binds_local_p had got out of sync with the varasm
changes, this restores the call to be direct. In practice, we add some
further tests to determine local binding - but this callback is used for
the initial assessments made by default_encode_section_info().
tested on
On Tue, Oct 15, 2019 at 08:35:07AM -0400, Aldy Hernandez wrote:
> > I'm seeing this on 32-bit i386-pc-solaris2.11 and sparc-sun-solaris2.11,
> > with more reports for armv8l, pru, and s390x.
> >
> > Comparing the dumps between 64 and 32-bit, I see
> >
> > -_1: int * [1B, -1B]
> > +_1: int * [1B,
On Tue, Oct 15, 2019 at 02:28:12PM -0400, Marek Polacek wrote:
> --- /dev/null
> +++ gcc/testsuite/g++.dg/cpp1z/decomp50.C
> @@ -0,0 +1,51 @@
> +// PR c++/92106 - ICE with structured bindings and -Wreturn-local-addr.
> +// { dg-do compile { target c++17 } }
> +
> +template struct B;
> +template
This OpenACC-only patch extends the support for /common/ blocks.
[In OpenMP (4.0 to 5.0, unchanged) and gfortran, common blocks are supported in
copyin/copyprivate, in firstprivate/lastprivate/private/shared, in
threadprivate and in declare target.]
For OpenACC, gfortran already supports
Hi Julian!
On 2019-10-03T09:35:04-0700, Julian Brown wrote:
> This patch has been broken out of the patch supporting OpenACC 2.6 manual
> deep copy last posted here:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01084.html
Thanks.
> a couple of
> tests need fixing also
Let's look at
On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
wrote:
>On 10/15/19 4:32 AM, Richard Biener wrote:
>> I believe this is going to bite you exactly in the case you want the
>> opposite behavior. If you have CUs compiled with defaults and
>> a specialized one with VSX that calls into
On Mon, 14 Oct 2019, Kyrill Tkachov wrote:
>> Surely would be fine with me.
> I see, thanks. Here's a proposed patch then.
My previous mail was meant to pre-approve your patch. ;-)
Yes, this is okay.
Thanks,
Gerald
> >> + if (unmodified_parm_or_parm_agg_item (fbi, stmt, expr, index_p,
> >> ,
> >> + aggpos))
> >> + {
> >> + tree type = TREE_TYPE (expr);
> >> +
> >> + /* Stop if found bit-field whose size does not equal any natural
> >> +
On 9 Oct 2019, Indu Bhagat told this:
> Yes, CTF does not support C++ at this time. To cover all of C (including
> GNU C extensions), we need to add representation for things like Vector type,
> non IEEE float etc. (somewhat infrequently occurring constructs)
One note: adding C++ support will
Feng,
This looks good from our side and has shown useful (combined with the other 2
patches) in
our testing with SPEC2017.
Given that this looks final: what is the plan for getting this merged?
Thanks,
Philipp.
> On 12.09.2019, at 12:23, Feng Xue OS
> wrote:
>
> ---
> diff --git
Hi!
The following patch implements P1073R3, i.e. consteval, except that
virtual consteval is not supported (I think support for that would need to
include the consteval virtual methods at the end of the binfo structures
after all non-consteval virtual methods, but make sure we don't actually
emit
On Tue, Oct 15, 2019 at 01:17:17PM -0400, Marek Polacek wrote:
> 2019-10-15 Marek Polacek
>
> PR c++/92106 - ICE with structured bindings and -Wreturn-local-addr.
> * typeck.c (maybe_warn_about_returning_address_of_local): Avoid
> recursing on null initializer.
>
> *
The user-defined clock used with shared_mutex::try_lock_for and
shared_mutex::try_lock_shared_for may have higher precision than
__clock_t. We may need to round the duration up to ensure that the timeout
is long enough. (See __timed_mutex_impl::_M_try_lock_for)
* include/std/shared_mutex:
This is the equivalent to PR libstdc++/91906, but for shared_mutex.
A non-standard clock may tick more slowly than std::chrono::steady_clock.
This means that we risk returning false early when the specified timeout
may not have expired. This can be avoided by looping until the timeout time
as
I was unable to find an existing tests for timed_mutex::try_lock_until and
recursive_timed_mutex::try_lock_until timing out. It would have been easier
to add a single templated test, but since these classes are tested in
separate directories I've created two separate tests.
*
The pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock functions
were added to glibc in v2.30. They have also been added to Android
Bionic. If these functions are available in the C library then they can be
used to implement shared_timed_mutex::try_lock_until,
* testsuite/30_threads/unique_lock/locking/4.cc: Wrap call to
timed_mutex::try_lock_until in VERIFY macro to check its return
value.
---
libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
* testsuite/30_threads/timed_mutex/try_lock_until/57641.cc:
Template test functions and use them to test both steady_clock
and system_clock.
---
libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc | 18
+-
1 file changed, 13 insertions(+), 5
On 10/15/19 4:56 AM, Segher Boessenkool wrote:
> On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
>> And another issue: Behavior is still inconsistent between "-mno-vsx
>> -flto" and "-mno-vsx" for user code. Previous patch makes it consistent
>> between "-mvsx -flto" and "-mvsx".
>
>>
Feng,
this now looks fine to me: what is the current schedule to get this merged?
Thanks,
Philipp.
> On 19.09.2019, at 16:30, Feng Xue OS
> wrote:
>
> Fix a bug on unary/binary operation check.
>
> Feng
> ---
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 33d52fe5537..f218f1093b8 100644
Joseph Myers writes:
> On Mon, 14 Oct 2019, Martin Sebor wrote:
>
>> On 10/14/19 4:03 PM, Joseph Myers wrote:
>> > How does this interact with translation?
>> >
>> > My expectation would be that in user code, the message is taken literally
>> > as-is; it is not looked up in the GCC message
Here we are returning the address of a structure binding and since it's a
reference, we recursed on its initializer, but in this case there was none
and we crashed in cp_fold. So don't recurse when we don't have an init to
recurse on.
Bootstrapped/regtested on x86_64-linux, ok for trunk/9?
Move slow_clock test class into a header file so that it can be used by
other tests in the future.
* testsuite/util/slow_clock.h: New file. Move implementation of
slow_clock test class.
* testsuite/30_threads/condition_variable/members/2.cc: Include
slow_clock
The pthread_mutex_clocklock function is available in glibc since the 2.30
release. If this function is available in the C library it can be used to
fix PR libstdc++/78237 by supporting steady_clock properly with
timed_mutex.
This means that code using timed_mutex::try_lock_for or
* testsuite/30_threads/unique_lock/locking/4.cc: Template test
functions so they can be used to test both steady_clock and
system_clock.
---
libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc | 12 +--
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
A non-standard clock may tick more slowly than std::chrono::steady_clock.
This means that we risk returning false early when the specified timeout
may not have expired. This can be avoided by looping until the timeout time
as reported by the non-standard clock has been reached.
Unfortunately, we
On 10/15/19 4:32 AM, Richard Biener wrote:
> I believe this is going to bite you exactly in the case you want the
> opposite behavior. If you have CUs compiled with defaults and
> a specialized one with VSX that calls into generic compiled functions
> you _do_ want to allow inlining into the VSX
This patch finishes moving concepts-related functionality out of pt.c
and into constraint.cc an logic.cc, and adds logic.cc to gtfiles.
As part of that cleanup, I reimplemented and reenabled the subsumption
caching. It's not clear if this provides any significant performance
benefits, but it will
On Sat, 12 Oct 2019 at 02:52, Ramana Radhakrishnan
wrote:
>
> On Fri, Oct 11, 2019 at 6:19 PM Wilco Dijkstra wrote:
> >
> > Hi Ramana,
> >
> > > Can you see what happens with the Cortex-A8 or Cortex-A9 schedulers to
> > > spread the range across some v7-a CPUs as well ? While they aren't that
>
Attached is a patch for p1301 that improves in the way Jason Merrill
specified earlier
(https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00858.html), but it
keeps segfaulting on my build of GCC. I don't know what changes I've
made that cause it to segfault: it does so whenever the error()
function is
I am also not very smart, wherein I attach patches that do not have the tests.
Sorry!
diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index e3c602fbb8d..fb05b5f8af0 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -353,13 +353,14 @@ c_common_has_attribute (cpp_reader
Segher Boessenkool writes:
> So what should we do about this? There are arguments for *both*
> behaviours, and apparently with LTO we do not know which flags are
> explicit?
Actually, from my testing, it seems the rs6000_isa_flags_explicit
flags are set correctly in LTO!
On 10/15/19 7:45 AM,
On Tue, Oct 15, 2019 at 12:49:18PM -0600, Jeff Law wrote:
> There aren't many that use PSImode. In general we don't handle partial
> modes well in the optimizers -- largely because they're just not that
> common and the exact size is unspecified. PSImode for example can be
> anywhere between 16
Hi Philipp,
This is an updated patch based on comments form Michael, and if he think
this is ok, we will merge it into trunk. Thanks,
Feng
From: Philipp Tomsich
Sent: Tuesday, October 15, 2019 11:49 PM
To: Feng Xue OS
Cc: Michael Matz; Richard
On 10/15/19 11:12 AM, Peter Bergner wrote:
> On 10/15/19 10:44 AM, Richard Biener wrote:
>> On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
>> wrote:
>>> If the user explicitly said not to compile a function with a particular
>>> option, how can we justify ignoring that request just
* src/c++11/debug.cc (print_field): Replace constness_names
entry with . Replace state_names entry
with
.
Committed as trivial.
François
Index: src/c++11/debug.cc
===
--- src/c++11/debug.cc (révision 277048)
+++
On Tue, 15 Oct 2019, Richard Sandiford wrote:
> > No. I'd expect the code generating the IR from GCC diagnostics should
> > arrange for the message to be translated first (while in the case of
> > __builtin_warning in user code, it would not be translated), and the code
> > subsequently using
Ping:
Attachment: v5-0001-Missed-function-specialization-partial-devirtuali.patch:
https://gcc.gnu.org/ml/gcc-patches/2019-09/txtuTT17jV7n5.txt
Thanks,
Xiong Hu
On 2019/9/27 15:13, luoxhu wrote:
Hi Martin,
Thanks for your time of so many round of reviews.
It really helped me a lot.
Peter Bergner writes:
> Segher Boessenkool writes:
>> So what should we do about this? There are arguments for *both*
>> behaviours, and apparently with LTO we do not know which flags are
>> explicit?
>
> Actually, from my testing, it seems the rs6000_isa_flags_explicit
> flags are set
On Wed, 9 Oct 2019 at 08:14, Prathamesh Kulkarni
wrote:
>
> On Tue, 8 Oct 2019 at 13:21, Richard Sandiford
> wrote:
> >
> > Leaving the main review to Richard, just some comments...
> >
> > Prathamesh Kulkarni writes:
> > > @@ -9774,6 +9777,10 @@ vect_is_simple_cond (tree cond, vec_info *vinfo,
On Mon, Oct 14, 2019 at 03:24:02PM -0700, Prathamesh Kulkarni wrote:
> The patch fixes this by simply putting gsi_next in else, which avoids
> the above issue.
> Bootstrap+test in progress on x86_64-unknown-linux-gnu.
> OK to commit if passes ?
No ChangeLog entry.
--- a/gcc/tree-if-conv.c
+++
Thanks for all your reviews and comments, very helpful!
Peter Bergner writes:
> I think we just need to fix the bug in the current logic when checking
> whether the caller's ISA flags supports the callee's ISA flags. ...and
> for that, I think we just need to add a test that enforces that the
On Mon, 14 Oct 2019 at 17:51, Richard Biener wrote:
>
> On October 14, 2019 4:53:02 PM GMT+02:00, Christophe Lyon
> wrote:
> >On Fri, 11 Oct 2019 at 12:43, Richard Biener wrote:
> >
> >> On Fri, 11 Oct 2019, Rainer Orth wrote:
> >>
> >> > Hi Christophe,
> >> >
> >> > > On Thu, 10 Oct 2019 at
Peter Bergner writes:
>
> I think we just need to fix the bug in the current logic when checking
> whether the caller's ISA flags supports the callee's ISA flags. ...and
> for that, I think we just need to add a test that enforces that the
> caller's ISA flags match exactly the callee's
Yes, it is. :)
On Mon, Oct 14, 2019 at 10:09 PM Nathan Sidwell wrote:
>
> On 10/14/19 3:46 PM, Jeff Law wrote:
> > On 10/14/19 6:09 AM, Nathan Sidwell wrote:
> >> On 10/14/19 7:16 AM, Richard Biener wrote:
> >>> On Sun, Oct 13, 2019 at 4:45 PM Nathan Sidwell wrote:
>
> In constifying
Hi!
On Mon, Oct 14, 2019 at 07:18:11PM -0500, Peter Bergner wrote:
> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> > On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> >> The general case should be that if the caller ISA supports the callee one
> >> then inlining is OK. If this
On Tue, Oct 15, 2019 at 09:17:00AM +0200, Richard Biener wrote:
>
> This makes allow-store-data-races adjustable per function by making it
> a regular option rather than a --param.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
LGTM.
> 2019-10-15 Richard Biener
>
> PR
Jiufu Guo writes:
> Thanks for all your reviews and comments, very helpful!
>
> Peter Bergner writes:
>
>> I think we just need to fix the bug in the current logic when checking
>> whether the caller's ISA flags supports the callee's ISA flags. ...and
>> for that, I think we just need to add a
On Mon, Oct 14, 2019 at 10:25 PM Jason Merrill wrote:
>
> The comment for get_formal_tmp_var says that it shouldn't be used for
> expressions whose value might change between initialization and use, and in
> this case we're creating a temporary precisely because the value might
> change, so we
On 10/14/19 4:25 PM, Jason Merrill wrote:
The comment for get_formal_tmp_var says that it shouldn't be used for
expressions whose value might change between initialization and use, and in
this case we're creating a temporary precisely because the value might
change, so we should use
This makes allow-store-data-races adjustable per function by making it
a regular option rather than a --param.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
2019-10-15 Richard Biener
PR middle-end/92046
* common.opt (fallow-store-data-races):
On Mon, 14 Oct 2019 at 23:23, Jakub Jelinek wrote:
>
> On Mon, Oct 14, 2019 at 03:24:02PM -0700, Prathamesh Kulkarni wrote:
> > The patch fixes this by simply putting gsi_next in else, which avoids
> > the above issue.
> > Bootstrap+test in progress on x86_64-unknown-linux-gnu.
> > OK to commit
On 11.10.19 18:35, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.
>
> gcc/ChangeLog:
>
> 2019-10-10 Ilya Leoshkevich
>
> * config/s390/s390.md: Run %a0:DI splitters only after reload.
>
> gcc/testsuite/ChangeLog:
>
> 2019-10-10 Ilya Leoshkevich
>
>
On Tue, Oct 15, 2019 at 2:18 AM Peter Bergner wrote:
>
> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
> > On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
> >> The general case should be that if the caller ISA supports the callee one
> >> then inlining is OK. If this is not
Segher Boessenkool wrote:
> Hi!
>
> On Mon, Oct 14, 2019 at 07:18:11PM -0500, Peter Bergner wrote:
>> On 10/14/19 2:57 PM, Segher Boessenkool wrote:
>>> On Mon, Oct 14, 2019 at 06:35:06PM +0200, Richard Biener wrote:
The general case should be that if the caller ISA supports the callee one
Permit more valid code by removing a too tight constraint – simple
patch, very long background & history (feel free to skip).
Arrays in Fortran are classified as:
* assumed-size: "… :: var(*)" – and array but only the caller knows the
size, which usually gets passed as some additional
Hi!
On Tue, Oct 15, 2019 at 05:15:07PM +0800, Jiufu Guo wrote:
> And another issue: Behavior is still inconsistent between "-mno-vsx
> -flto" and "-mno-vsx" for user code. Previous patch makes it consistent
> between "-mvsx -flto" and "-mvsx".
> $GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc novsx.c -O2
On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > I think we just need to fix the bug in the current logic when checking
> > whether the caller's ISA flags supports the callee's ISA flags. ...and
> > for that, I think we just need to add a test that enforces that the
> > caller's
Richard Biener writes:
> On October 14, 2019 2:32:43 PM GMT+02:00, Richard Sandiford
> wrote:
>>Richard Biener writes:
>>> On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
>>> wrote:
The range-tracking code has a pretty hard-coded assumption that
is_gimple_min_invariant is
Committed.
Richard.
2019-10-15 Richard Biener
PR testsuite/92048
* gcc.dg/vect/fast-math-vect-pr29925.c: Avoid unrolling of
inner loop.
Index: gcc/testsuite/gcc.dg/vect/fast-math-vect-pr29925.c
===
---
On Tue, Oct 15, 2019 at 11:42:12AM +0200, Tobias Burnus wrote:
> OpenMP – OpenMP 4.0 and 4.5 are based on Fortran 2003 (hence: no
> 'contiguous' attribute), OpenMP 5.0 is based on Fortran 2008. Hence, it
> explicitly uses the contiguous attribute. It also introduces 'simply
> contiguous array
Hi,
I have changed the name to make the target hook more general and not
create the illusion it is related to sanitizers.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-10-15 Andre Vieira
* cgraphclones.c(create_clone): Call new target hook when
creating a new
Hi,
Just some minor changes after name changes in the first patch. I'll
assume this is also OK.
gcc/ChangeLog:
2019-10-15 Andre Vieira
* config/arm/arm.c (TARGET_MODIFY_CLONE_CGRAPH_NODE): Define.
(arm_modify_clone_cgraph_node): New.
gcc/testsuite/ChangeLog:
2019-10-15
build_clone is recursive when applied to a template, but I found the
control flow confusing. this makes it clearer and moves some decls to
their initializers.
Applying to trunk.
nathan
--
Nathan Sidwell
2019-10-15 Nathan Sidwell
* class.c (build_clone): Refactor to clarify
On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
wrote:
>
> On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > I think we just need to fix the bug in the current logic when checking
> > > whether the caller's ISA flags supports the callee's ISA flags. ...and
> > > for that,
On Okt 15 2019, Segher Boessenkool wrote:
> Please use
> /* { dg-final { scan-assembler "\mbl vadd_no_vsx\M" } } */
ITYM
/* { dg-final { scan-assembler {\mbl vadd_no_vsx\M} } } */
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE
Hi Richard,
On 10/15/19 8:17 AM, Richard Biener wrote:
This makes allow-store-data-races adjustable per function by making it
a regular option rather than a --param.
Note that the kernel has --param=allow-store-data-races=0 in its build
flags.
I guess that will break unless they rename
On Tue, 15 Oct 2019, Kyrill Tkachov wrote:
> Hi Richard,
>
> On 10/15/19 8:17 AM, Richard Biener wrote:
> >
> > This makes allow-store-data-races adjustable per function by making it
> > a regular option rather than a --param.
>
>
> Note that the kernel has --param=allow-store-data-races=0 in
On Tue, Oct 15, 2019 at 01:21:12PM +0200, Richard Biener wrote:
> On Tue, 15 Oct 2019, Kyrill Tkachov wrote:
>
> > Hi Richard,
> >
> > On 10/15/19 8:17 AM, Richard Biener wrote:
> > >
> > > This makes allow-store-data-races adjustable per function by making it
> > > a regular option rather than
On Tue, Oct 15, 2019 at 8:07 AM Prathamesh Kulkarni
wrote:
>
> On Wed, 9 Oct 2019 at 08:14, Prathamesh Kulkarni
> wrote:
> >
> > On Tue, 8 Oct 2019 at 13:21, Richard Sandiford
> > wrote:
> > >
> > > Leaving the main review to Richard, just some comments...
> > >
> > > Prathamesh Kulkarni
On Tue, Oct 15, 2019 at 11:52:26AM +0200, Andreas Schwab wrote:
> On Okt 15 2019, Segher Boessenkool wrote:
>
> > Please use
> > /* { dg-final { scan-assembler "\mbl vadd_no_vsx\M" } } */
>
> ITYM
>
> /* { dg-final { scan-assembler {\mbl vadd_no_vsx\M} } } */
Ha yes, thanks :-) That's
The following fixes vectorization of nested cycles when the nested
cycle only constists of a PHI node. As in the previous fix a
nested cycle only consists of the PHI, it doesn't necessarily have
another stmt only participating in that cycle (in this case it
participates in another nested
Hi Tobias,
What about using gfc_is_not_contigous? This would allow to issue an error when
we can prove the user made an error.
Regards
Thomas
On Tue, Oct 15, 2019 at 12:35 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On October 14, 2019 2:32:43 PM GMT+02:00, Richard Sandiford
> > wrote:
> >>Richard Biener writes:
> >>> On Fri, Oct 11, 2019 at 4:42 PM Richard Sandiford
> >>> wrote:
>
> The range-tracking
Hi Thomas,
On 10/15/19 12:59 PM, Thomas König wrote:
What about using gfc_is_not_contigous? This would allow to issue an error when
we can prove the user made an error.
Most clauses take only an identifiers (i.e. "sym" not "expr"). The
gfc_is_not_contiguous check only returns true if there
On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote:
> On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
> wrote:
> > On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > > I think we just need to fix the bug in the current logic when checking
> > > > whether the
On Tue, Oct 15, 2019 at 1:33 PM Segher Boessenkool
wrote:
>
> On Tue, Oct 15, 2019 at 01:19:51PM +0200, Richard Biener wrote:
> > On Tue, Oct 15, 2019 at 12:07 PM Segher Boessenkool
> > wrote:
> > > On Tue, Oct 15, 2019 at 11:32:27AM +0200, Richard Biener wrote:
> > > > > I think we just need to
> Hi,
>
> I have changed the name to make the target hook more general and not create
> the illusion it is related to sanitizers.
>
> Is this OK for trunk?
Can't you just go via IPA symbol summary or add_cgraph_duplication_hook?
Honza
Hi Aldy,
>>> ~[0,0] has been the accepted way for a long time, I'd really prefer to
>>> keep that (for now).
>> It has. Very true. But I don't necessarily think that means we should
>> be introducing even more of 'em.
[...]
> Happily, normalizing into ~0 for signed and [1,MAX] for unsigned,
>
looking up a line map takes a non-constant line_maps object, which is
confusing.
This makes the caching fields mutable, so permits a constant object, as
one might expect for a lookup.
The linemaps_info_{ordinary,macro} structures are crying out to be
templatized, but that kind of turns into
On Fri, 11 Oct 2019, Joel Hutton wrote:
> Hi Richard,
>
> Thanks for your help, I've reworked my SLP RFC based on your feedback.
> > I think a better place for the loop searching for CONSTRUCTORs is
> > vect_slp_analyze_bb_1 where I'd put it before the check you remove,
> > and I'd simply
1 - 100 of 110 matches
Mail list logo
