* 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)
+++ sr
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 correctl
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.
Updated
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 *pfile
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 Biener
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,
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
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 becau
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 a
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
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 bind
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 rtl-optimizati
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 commo
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 r
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
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 a
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 a/gcc/config/da
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 x86_64-da
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 std
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 don'
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 regis
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
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 (maybe_warn_about_returning_address_of
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 thi
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 b
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 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,
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
>
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 h
* 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
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
timed_mutex::wait
* 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 d
* 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 a/libstdc++-
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.
* testsuite/30_
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 repo
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,
shared_timed_mutex::try_lock_fo
* 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 changed,
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 cl
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 from
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".
>
>>
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.
>
> * g+
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 catalo
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?
2019-
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
> >> + if (unmodified_parm_or_parm_agg_item (fbi, stmt, expr, index_p,
> >> &size,
> >> + aggpos))
> >> + {
> >> + tree type = TREE_TYPE (expr);
> >> +
> >> + /* Stop if found bit-field whose size does not equal any natural
> >> +
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
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 th
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
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.
Cia
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 a/gcc/doc/in
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 generi
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 the
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 not
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 e
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 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", which
Hi Tobias!
On 2019-10-15T11:42:12+0200, Tobias Burnus wrote:
> Permit more valid code by removing a too tight constraint – simple
> patch, very long background & history (feel free to skip).
Thanks for writing that down, that's helpful to have in the archives.
(Certainly helps me, learning Fort
Hi Aldy,
Rainer Orth wrote:
>>
>> On 10/15/19 7:58 AM, Rainer Orth wrote:
>>> 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
On Mon, Oct 14, 2019 at 10:22 PM Jeff Law wrote:
>
> On 10/8/19 4:39 AM, Jozef Lawrynowicz wrote:
> > This patch has the functional changes to optimize zero_extend insns and
> > pointer
> > manipulation in the large memory model.
> >
> >
> > 0002-MSP430-PSImode-pointer-manipulation-and-zero-exten
The test case added for PR91275 fails on big-endian because
__builtin_crypto_vpmsumd
is not a bi-endian intrinsic; source code must account for endian differences
when
calling this intrinsic. Fixed this and a type issue that only shows up on
32-bit.
I thought I had previously tested this on P8
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 registers or memory:
> > - Byte-writes to registers clear
Segher Boessenkool writes:
> 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
Hi Aldy,
> On 10/15/19 7:58 AM, Rainer Orth wrote:
>> 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.
>> [...]
>>>
On 10/15/19 7:58 AM, Rainer Orth wrote:
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 sign
This patch, from the modules branch, breaks out function cloning from
the method vector updating. We have a new function, build_clones, which
does the building, returning a count of the number of clones (2 or 3).
clone_function_decl separately adds them to the method vector, if they
should be
Honza figured that variably_modified_type_p uses TREE_VISITED
to not run into an Ada abdomination. That causes havoc during
WPA streaming which happens in multiple forked processes and
thus causes a lot of COW faulting and resident memory usage.
It also stands in the way of using threads here.
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 appe
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
> 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,
> si
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
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 writes
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 call
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 a
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 i
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 code
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 i
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, I
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 recursiveness
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 it
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 n
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 An
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 secti
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
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
===
---
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 equi
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 cycle).
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
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 t
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 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 1748
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 argumen
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
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 wanted
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 i
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 sho
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 s
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
>
>
1 - 100 of 107 matches
Mail list logo
