Ping?
On 13/07/2018 18:10, christophe.l...@st.com wrote:
From: Christophe Lyon
Hello,
This patch series implements the GCC contribution of the FDPIC ABI for
ARM targets.
This ABI enables to run Linux on ARM MMU-less cores and supports
shared libraries to reduce the memory footprint.
Hi!
This patch adds just the parsing and diagnostics of task reduction modifier.
Such reductions behave then differently, like task_reduction clause on
taskgroup construct when used on parallel or for/sections.
Tested on x86_64-linux, committed to gomp-5_0-branch.
2018-08-01 Jakub Jelinek
This adds RPO finding on SEME regions, marking backedges in the
region on-the-fly. RPO value-numbering uses this first and foremost
in region mode but also for whole-function since it has a way
to visit non-loop-exit edges first leading to a more local
iteration order.
2018-07-04 Richard
On Wed, 1 Aug 2018, Bernd Edlinger wrote:
> On 07/30/18 17:49, Joseph Myers wrote:
> > On Mon, 30 Jul 2018, Bernd Edlinger wrote:
> >
> >> Hi,
> >>
> >> this is how I would like to handle the over length strings issue in the C
> >> FE.
> >> If the string constant is exactly the right length and
On Wed, 1 Aug 2018, Allan Sandfeld Jensen wrote:
> gcc/
> * gcc.c: Correct default specs for -r
I don't follow why your changes (which would need describing for each
individual spec changed) are corrections.
> /* config.h can define LIB_SPEC to override the default libraries. */
>
PR libstdc++/60555
* src/c++11/system_error.cc
(system_error_category::default_error_condition): New override to
check for POSIX errno values.
* testsuite/19_diagnostics/error_category/generic_category.cc: New
*
On 08/01/2018 05:25 AM, Marc Glisse wrote:
Throwing new is returns_nonnull (errors are reported with exceptions) so
that's fine, but non-throwing new is not:
int* p1 = new(std::nothrow) int;
Here errors are reported by returning 0, so it is common to test if p1
is 0 and this is precisely
After Segher's recent combine change, these tests now use a single
instruction to do the "and" and "lsl 10". This is a good thing,
so the patch updates the expected output accordingly.
Tested on aarch64-linux-gnu and applied.
Richard
2018-08-01 Richard Sandiford
gcc/testsuite/
*
On 08/01/2018 04:01 AM, Tom de Vries wrote:
> On 07/31/2018 05:12 PM, Cesar Philippidis wrote:
>> This is an old patch which removes the struct map from the nvptx plugin.
>> I believe at one point this was supposed to be used to manage async data
>> mappings, but in practice that never worked out.
Hi,
this defines new target hook TARGET_HAVE_SPECULATION_SAFE_VALUE for nvptx.
Since AFAIK nvidia claims the related security issue does not exist on their
video hardware, we set it to speculation_safe_value_not_needed.
Build and reg-tested on x86_64 with nvptx accelerator.
Committed.
Thanks,
On Wed, Aug 1, 2018 at 1:20 AM, Joseph Myers wrote:
> On Wed, 1 Aug 2018, Bogdan Harjoc wrote:
>
>> So array[0] < component < array[2], which loops (I removed the gdb p
>> commands for field_array[1] and so on).
>
> Is the key thing here that you end up with DECL_NAME (field) == NULL_TREE,
> but
On 08/01/2018 03:43 PM, Cesar Philippidis wrote:
> On 08/01/2018 04:01 AM, Tom de Vries wrote:
>> On 07/31/2018 05:12 PM, Cesar Philippidis wrote:
>>> This is an old patch which removes the struct map from the nvptx plugin.
>>> I believe at one point this was supposed to be used to manage async
On 08/01/2018 03:18 AM, Tom de Vries wrote:
> On 07/31/2018 04:58 PM, Cesar Philippidis wrote:
>> The attached patch teaches libgomp how to use the CUDA thread occupancy
>> calculator built into the CUDA driver. Despite both being based off the
>> CUDA thread occupancy spreadsheet distributed with
On Tue, 2018-07-31 at 13:06 -0600, Martin Sebor wrote:
> The GCC internal %G directive takes a gcall* argument and prints
> the call's inlining stack in diagnostics. The argument type makes
> it unsuitable for gimple expressions such as those diagnosed by
> -Warray-bounds.
>
> As the first step
If you care about detecting bugs I would expect you to be
supportive rather than dismissive of this work, and helpful
in bringing it to fruition rather that putting it down or
questioning my priorities. Especially since the work was
prompted by your own (valid) complaint that GCC doesn't
PING^1
On 07/18/2018 05:48 PM, Martin Liška wrote:
> Hi.
>
> This is aarch64 fix for PR83193. It's about setting of default options
> so that --help=target -Q prints proper numbers:
>
> Now this is seen on my cross-compiler:
>
> --- /home/marxin/Downloads/options-2-before.txt 2018-07-18
This patch was tested to build binutils-gdb on GNU/Linux and macOS. It can be
applied to the gcc repo too, after fixing some trivial merge conflicts (someone
else will need to do it, as I don't have push access to gcc). Although I think
it is relatively low-risk, building gcc on macOS was not
Richard Biener writes:
> This should be 4/4 but I have the main patch on top, so...
>
> This uses the region-based VN from GIMPLE unrolling which means
> we better approximate the effects optimizations on unrolled inner
> loops when evaluating whether to unroll outer ones.
Great! Sounds like it
On 08/01/2018 04:27 AM, Bernd Edlinger wrote:
Hi,
this makes too long string constants shorter,
and fixes one place where a string constant is created
non-zero terminated. This is a cleanup in preparation
of a more thorough check on the STRING_CST objects
in the middle-end.
Bootstrapped and
On 20/07/18 17:49 +0100, Mike Crowe wrote:
As currently implemented, condition_variable always ultimately waits
against std::chrono::system_clock. This clock can be changed in arbitrary
ways by the user which may result in us waking up too early or too late
when measured against the
On 20/07/18 17:49 +0100, Mike Crowe wrote:
I believe[1][2] that the C++ standard says that
std::condition_variable::wait_for should be implemented to be equivalent
to:
return wait_until(lock, chrono::steady_clock::now() + rel_time);
But the existing implementation uses chrono::system_clock.
The option has existed and been working for years,
make sure it implies the right extra options, and list
it in the documentation.
2018-08-01 Allan Sandfeld Jensen
gcc/doc
* invoke.texi: Document -r
gcc/
* gcc.c: Correct default specs for -r
---
gcc/doc/invoke.texi | 7 ++-
v2 of this series was originally posted back in January (see
https://gcc.gnu.org/ml/libstdc++/2018-01/msg00035.html )
Apart from minor log message tweaks, the changes since that version are:
* [1/6] Improve libstdc++-v3 async test
Speed up the tests at the risk of more sporadic failures on
The futex system call supports waiting for an absolute time if
FUTEX_WAIT_BITSET is used rather than FUTEX_WAIT. Doing so provides two
benefits:
1. The call to gettimeofday is not required in order to calculate a
relative timeout.
2. If someone changes the system clock during the wait then
Add tests for waiting for the future using both std::chrono::steady_clock
and std::chrono::system_clock in preparation for dealing with those clocks
properly in futex.cc.
---
libstdc++-v3/testsuite/30_threads/async/async.cc | 33
1 file changed, 33 insertions(+)
diff
This should be 4/4 but I have the main patch on top, so...
This uses the region-based VN from GIMPLE unrolling which means
we better approximate the effects optimizations on unrolled inner
loops when evaluating whether to unroll outer ones.
* tree-ssa-loop-ivcanon.c: Include
On 01/08/18 14:19 +0100, Mike Crowe wrote:
Add tests for waiting for the future using both std::chrono::steady_clock
and std::chrono::system_clock in preparation for dealing with those clocks
properly in futex.cc.
---
libstdc++-v3/testsuite/30_threads/async/async.cc | 33
Hi Allan,
> The option has existed and been working for years,
> make sure it implies the right extra options, and list
> it in the documentation.
this is way incomplete: you are only fixing the default versions of the
various specs in gcc.c, while there are many others that also need
fixing in
The user-visible effect of this change is for std::future::wait_until to
use CLOCK_MONOTONIC when passed a timeout of std::chrono::steady_clock
type. This makes it immune to any changes made to the system clock
CLOCK_REALTIME.
Add an overload of
These tests show that changing the system clock has an effect on
std::future::wait_until when using std::chrono::system_clock but not when
using std::chrono::steady_clock. Unfortunately these tests have a number of
downsides:
1. Nothing that is attempting to keep the clock set correctly (ntpd,
If std::future::wait_until is passed a time point measured against a clock
that is neither std::chrono::steady_clock nor std::chrono::system_clock
then the generic implementation of
__atomic_futex_unsigned::_M_load_when_equal_until is called which
calculates the timeout based on __clock_t and
The user-visible effect of this change is that std::future::wait_for now
uses std::chrono::steady_clock to determine the timeout. This makes it
immune to changes made to the system clock. It also means that anyone using
their own clock types with std::future::wait_until will have the timeout
Hi,
This factors out the cuda library calls list into a seperate .def file.
Build and reg-tested on x86_64 with nvptx accelerator.
Committed.
Thanks,
- Tom
[libgomp, nvptx] Add cuda-lib.def
2018-08-01 Tom de Vries
* plugin/cuda-lib.def: New file. Factor out of ...
*
On 07/31/18 05:51, Martin Sebor wrote:
> On 07/30/2018 03:11 PM, Bernd Edlinger wrote:
>> Hi,
>>
>>> @@ -621,6 +674,12 @@ c_strlen (tree src, int only_value)
>>> maxelts = maxelts / eltsize - 1;
>>> }
>>>
>>> + /* Unless the caller is prepared to handle it by passing in a non-null
>>> +
I've posted this previously and didn't change it, the discussion went
down bikeshedding on C++.
* cfg.h (struct control_flow_graph): Add edge_flags_allocated and
bb_flags_allocated members.
(auto_flag): New RAII class for allocating flags.
(auto_edge_flag): New
>>> We expect that
>>> C-SKY will also be providing a public link to the processor and ABI
>>> documentation at some point.
>>
>> The ABI manual has been posted, but not the ISA documentation yet. (I'd
>> guess
>> that when it does show up it will be in the same place, though.)
>>
>>
See PR 86753 for details.
Tested on aarch64-linux-gnu and applied.
Richard
2018-08-01 Richard Sandiford
gcc/testsuite/
PR target/86753
* gcc.target/aarch64/sve/vcond_4.c: XFAIL positive tests.
* gcc.target/aarch64/sve/vcond_5.c: Likewise.
Index:
Adds the ability to match movss and movsd as blend patterns,
implemented in a new method to be able to match these before shuffles,
while keeping other blends after.
2018-07-29 Allan Sandfeld Jensen
gcc/config/i386
* i386.cc (expand_vec_perm_movs): New method matching movs
patterns.
On Wed, 1 Aug 2018, Martin Liška wrote:
On 08/01/2018 02:25 PM, Marc Glisse wrote:
On Wed, 1 Aug 2018, Martin Liška wrote:
On 07/27/2018 02:38 PM, Marc Glisse wrote:
On Fri, 27 Jul 2018, Martin Liška wrote:
So answer is yes, the builtin can be then removed.
Good, thanks. While looking
On 19/07/18 11:03, Jackson Woodruff wrote:
> Hi Richard,
>
>
> On 07/12/2018 05:35 PM, Richard Earnshaw (lists) wrote:
>> On 11/07/18 17:48, Jackson Woodruff wrote:
>>> Hi Sudi,
>>>
>>> On 07/10/2018 02:29 PM, Sudakshina Das wrote:
Hi Jackson
On Tuesday 10 July 2018 09:37 AM,
Hi all,
This patch adds an optimisation that exploits the AArch64 BFXIL
instruction when or-ing the result of two bitwise and operations
with non-overlapping bitmasks
(e.g. (a & 0x) | (b & 0x)).
Example:
unsigned long long combine(unsigned long long a, unsigned long
long b) {
> The change to have all STRING_CSTs NUL terminated (but that NUL
> termination not necessarily inclided in STRING_LENGTH) is a good
> one.
>
> I'm not sure how we can reliably verify NUL termination after the
> fact though and build_string already makes sure to NUL terminate
> STRING_CSTs. So
On Wed, 1 Aug 2018, Bernd Edlinger wrote:
> > The change to have all STRING_CSTs NUL terminated (but that NUL
> > termination not necessarily inclided in STRING_LENGTH) is a good
> > one.
> >
> > I'm not sure how we can reliably verify NUL termination after the
> > fact though and build_string
On Wed, Aug 01, 2018 at 09:48:50AM +0100, Richard Earnshaw (lists) wrote:
> Sorry about that, I did run a full bootstrap on x86, but I had the x86
> mitigation patch applied, so it didn't trip this.
Also, I see
FAIL: c-c++-common/spec-barrier-1.c -Wc++-compat (test for excess errors)
FAIL:
On Wed, Aug 01, 2018 at 12:35:09AM +1000, Jason Merrill wrote:
> On Mon, Jul 23, 2018 at 8:50 PM, Richard Biener
> wrote:
> > On Mon, Jul 23, 2018 at 12:28 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Jul 23, 2018 at 12:17:42PM +0200, Richard Biener wrote:
> >> > > Bootstrapped/regtested on
The following fixes build with ISL 0.20, tested by building with
ISL 0.20 and 0.15 (the oldest supported ISL).
Applied to trunk, will commit to the branches as well.
Richard.
2018-08-01 Richard Biener
PR bootstrap/86724
* graphite.h: Include isl/id.h and isl/space.h to
On 31/07/18 21:51, Ian Lance Taylor via gcc-patches wrote:
> On Tue, Jul 31, 2018 at 12:25 PM, H.J. Lu wrote:
>> On Mon, Jul 30, 2018 at 6:16 AM, Richard Biener wrote:
>>> On Fri, 27 Jul 2018, Richard Earnshaw wrote:
>>>
This patch defines a new intrinsic function
On Tue, 31 Jul 2018, Tamar Christina wrote:
> Hi Richard,
>
> The 07/31/2018 11:21, Richard Biener wrote:
> > On Tue, 31 Jul 2018, Tamar Christina wrote:
> >
> > > Ping
> > >
> > > > -Original Message-
> > > > From: gcc-patches-ow...@gcc.gnu.org
> > > > On Behalf Of Tamar Christina
On Tue, 31 Jul 2018, Ian Lance Taylor wrote:
> On Tue, Jul 31, 2018 at 9:19 AM, Bernd Edlinger
> wrote:
> > On 07/31/18 16:40, Ian Lance Taylor wrote:
> >> On Tue, Jul 31, 2018 at 5:14 AM, Bernd Edlinger
> >> wrote:
> >>>
> >>> could someone please review this patch and check it in into the GO
On Wed, Aug 01, 2018 at 09:19:43AM +0200, Richard Biener wrote:
> > And if so, what makes it well defined?
>
> The fact that strlen takes a char * argument and thus inline-expansion
> of a trivial implementation like
>
> int len = 0;
> for (; *p; ++p)
>++len;
>
> will have
>
> p =
>
>
> Certainly not every "strlen" has these semantics. For example,
> this open-coded one doesn't:
>
>int len = 0;
>for (int i = 0; s.a[i]; ++i)
> ++len;
>
> It computes 2 (with no warning for the out-of-bounds access).
>
yes, which is questionable as well, but that happens only
if
On Tue, 31 Jul 2018, Martin Sebor wrote:
> On 07/31/2018 09:48 AM, Jakub Jelinek wrote:
> > On Tue, Jul 31, 2018 at 09:17:52AM -0600, Martin Sebor wrote:
> > > On 07/31/2018 12:38 AM, Jakub Jelinek wrote:
> > > > On Mon, Jul 30, 2018 at 09:45:49PM -0600, Martin Sebor wrote:
> > > > > Even without
On Tue, 31 Jul 2018 at 15:57, Segher Boessenkool
wrote:
>
> Hi Christophe,
>
> On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote:
> > Since this was committed, I've noticed regressions
> > on aarch64:
> > FAIL: gcc.dg/zero_bits_compound-1.c scan-assembler-not \\(and:
>
> This went
On 07/31/2018 11:16 PM, James Greenhalgh wrote:
On Thu, Jul 26, 2018 at 11:52:15AM -0500, Sam Tebbs wrote:
Thanks for making the changes and adding more test cases. I do however
see that you are only covering 2 out of 4 new
*aarch64_get_lane_zero_extenddi<> patterns. The
Hi.
As requested in the PR, I would like to add value profiling for
BUILT_IN_MEMMOVE.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-07-31 Martin Liska
PR value-prof/35543
* value-prof.c
On 07/31/2018 04:58 PM, Cesar Philippidis wrote:
> The attached patch teaches libgomp how to use the CUDA thread occupancy
> calculator built into the CUDA driver. Despite both being based off the
> CUDA thread occupancy spreadsheet distributed with CUDA, the built in
> occupancy calculator
Hi.
This is format clean-up of value transformations that can happen.
It makes it easier to grep them and find how many were actually
applied.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-07-31 Martin Liska
Richard Biener writes:
> On Mon, Jul 30, 2018 at 7:47 PM Richard Sandiford
> wrote:
>>
>> [Sorry, somehow missed this till now]
>>
>> Richard Biener writes:
>> > On Mon, Jul 23, 2018 at 5:05 PM Richard Sandiford
>> > wrote:
>> >>
>> >> Marc Glisse writes:
>> >> > On Fri, 20 Jul 2018, Richard
Marc Glisse writes:
> On Tue, 31 Jul 2018, Richard Biener wrote:
>
Also, when @2 == @0 + (@1+1) then the original condition is true but
((sizetype) @0 - (sizetype) @2 + @1) > (@1 * 2) is not?
(sizetype) @0 - (sizetype) (@0 + @1 + 1) + @1 > @1 * 2
-> -1 > @1 * 2
On 07/27/2018 02:38 PM, Marc Glisse wrote:
> On Fri, 27 Jul 2018, Martin Liška wrote:
>
>> So answer is yes, the builtin can be then removed.
>
> Good, thanks. While looking at how widely it is going to apply, I noticed
> that the default, throwing operator new has attribute malloc and
This PR is a wrong-code bug caused by the over-widening support.
The minimum input precisions for a COND_EXPR are supposed to apply
only to the "then" and "else" values, but here we were applying
them to the operands of a nested COND_EXPR comparison instead.
Tested on aarch64-linux-gnu (with and
vectorizable_simd_clone_call was trying to remove a pattern statement
instead of the original statement, Fixes existing tests
gcc.dg/pr84452.c and gcc.target/i386/pr84309.c on x86.
This relies on a function added by:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01825.html
which can be applied
On 01/08/18 09:54, Jakub Jelinek wrote:
> On Wed, Aug 01, 2018 at 09:48:50AM +0100, Richard Earnshaw (lists) wrote:
>> Sorry about that, I did run a full bootstrap on x86, but I had the x86
>> mitigation patch applied, so it didn't trip this.
>
> Also, I see
> FAIL: c-c++-common/spec-barrier-1.c
On Wed, 1 Aug 2018, Bernd Edlinger wrote:
> >> > The change to have all STRING_CSTs NUL terminated (but that NUL
> >> > termination not necessarily inclided in STRING_LENGTH) is a good
> >> > one.
> >> >
> >> > I'm not sure how we can reliably verify NUL termination after the
> >> > fact though
Hi.
Attempt of the patch is to remove all histograms right after
"profile_estimate" pass. Then nobody should use them. That
will simplify code we'll not need verification and currently
we leaked some histograms till the end of compilation.
Patch can bootstrap on x86_64-linux-gnu and survives
> Hi.
>
> As requested in the PR, I would like to add value profiling for
> BUILT_IN_MEMMOVE.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-31 Martin Liska
>
> PR value-prof/35543
>
Hi.
This one is forgotten removal as we call __gcov_indirect_call_profiler_v2
only in situations where __gcov_indirect_call_callee is non-null.
I'm going to install that.
libgcc/ChangeLog:
2018-07-31 Martin Liska
* libgcov-profiler.c (__gcov_indirect_call_profiler_v2): Do not
Hi Sam
On 01/08/18 10:12, Sam Tebbs wrote:
On 07/31/2018 11:16 PM, James Greenhalgh wrote:
On Thu, Jul 26, 2018 at 11:52:15AM -0500, Sam Tebbs wrote:
Thanks for making the changes and adding more test cases. I do however
see that you are only covering 2 out of 4 new
Hi
On 31/07/18 22:48, Andrew Pinski wrote:
On Tue, Jul 31, 2018 at 2:43 PM James Greenhalgh
wrote:
On Thu, Jul 12, 2018 at 12:01:09PM -0500, Sudakshina Das wrote:
Hi Eric
On 27/06/18 12:22, Wilco Dijkstra wrote:
Eric Botcazou wrote:
This test can easily be changed not to use optimize
Hello!
The testcase fails with:
FAIL: g++.dg/pr83239.C -std=gnu++11 scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
FAIL: g++.dg/pr83239.C -std=gnu++14 scan-tree-dump-not optimized
"_ZNSt6vectorIiSaIiEE17_M_default_appendEm"
the test depends on _M_default_append to
On 07/26/2018 11:00 AM, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 10:44 AM Martin Liška wrote:
>>
>> On 07/25/2018 03:50 PM, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 3:38 PM Martin Liška wrote:
Hi.
Target clones have DECL_ARTIFICIAL set to 1, but we want to
>> > The change to have all STRING_CSTs NUL terminated (but that NUL
>> > termination not necessarily inclided in STRING_LENGTH) is a good
>> > one.
>> >
>> > I'm not sure how we can reliably verify NUL termination after the
>> > fact though and build_string already makes sure to NUL terminate
>>
On Wed, Aug 01, 2018 at 10:27:31AM +0200, Christophe Lyon wrote:
> On Tue, 31 Jul 2018 at 15:57, Segher Boessenkool
> wrote:
> > On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote:
> > > Since this was committed, I've noticed regressions
> > > on aarch64:
> > > FAIL:
On 08/01/2018 12:14 PM, Jan Hubicka wrote:
> OK, thanks!
> We have other builtins that may fold into string function which we expand
> internally (str variants comes to mind) perhaps they could be instrumented,
> too.
Sure, as mentioned here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35543#c5,
> Hi.
>
> This is format clean-up of value transformations that can happen.
> It makes it easier to grep them and find how many were actually
> applied.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
>
On Mon, Jul 30, 2018 at 9:09 AM Aldy Hernandez wrote:
>
> ...well, most of them anyhow...
>
> I got tired of submitting these piecemeal, and it's probably easier to
> review them in one go.
>
> There should be no difference in functionality, barring an extra call to
>
On Tue, Jul 31, 2018 at 7:40 PM Michael Ploujnikov
wrote:
>
> On 2018-07-26 01:27 PM, Michael Ploujnikov wrote:
> > On 2018-07-24 09:57 AM, Michael Ploujnikov wrote:
> >> On 2018-07-20 06:05 AM, Richard Biener wrote:
> /* Return a new assembler name for a clone with SUFFIX of a decl named
>
Hi,
thus, as you may or may not have noticed I reverted my first try, when
Tobias noticed that in his large codebase we were rejecting code like:
class Matrix;
Matrix rot90 (const Matrix& a, int k = 1);
class Matrix {
friend Matrix rot90 (const Matrix&, int);
};
Matrix rot90 (const
On Wed, 1 Aug 2018 at 11:40, Segher Boessenkool
wrote:
>
> On Wed, Aug 01, 2018 at 10:27:31AM +0200, Christophe Lyon wrote:
> > On Tue, 31 Jul 2018 at 15:57, Segher Boessenkool
> > wrote:
> > > On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote:
> > > > Since this was committed,
On 07/31/2018 05:12 PM, Cesar Philippidis wrote:
> This is an old patch which removes the struct map from the nvptx plugin.
> I believe at one point this was supposed to be used to manage async data
> mappings, but in practice that never worked out.
I don't quite understand what rationale you're
On 07/31/2018 05:27 PM, Cesar Philippidis wrote:
> At present, libgomp is using CUDA unified memory only as a buffer pass
> to the struct containing the pointers to the data mappings to the
> offloaded functions. I'm not sure why unified memory is needed here if
> it is still being managed
2018-08-01 Uros Bizjak
* gcc.dg/tree-ssa/pr84512.c: Xfail on alpha*-*-*.
Tested on alphaev68-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.dg/tree-ssa/pr84512.c
===
--- gcc.dg/tree-ssa/pr84512.c (revision 263193)
Hi,
this makes too long string constants shorter,
and fixes one place where a string constant is created
non-zero terminated. This is a cleanup in preparation
of a more thorough check on the STRING_CST objects
in the middle-end.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for
On 07/27/2018 02:38 PM, Marc Glisse wrote:
> On Fri, 27 Jul 2018, Martin Liška wrote:
>
>> So answer is yes, the builtin can be then removed.
>
> Good, thanks. While looking at how widely it is going to apply, I noticed
> that the default, throwing operator new has attribute malloc and
On 07/31/2018 11:25 AM, Jan Hubicka wrote:
>> Hi.
>>
>> Following patch implements new predictors that annotates malloc-like
>> functions.
>> These almost every time return a non-null value.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be
Hi,
this completes the previous patches, and adds a check in varasm.c
that ensures that all string constants are NUL terminated,
And that varasm does not strip anything but _exactly_ one NUL
character.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
On Wed, Aug 1, 2018 at 11:16 AM Richard Sandiford
wrote:
>
> This PR is a wrong-code bug caused by the over-widening support.
> The minimum input precisions for a COND_EXPR are supposed to apply
> only to the "then" and "else" values, but here we were applying
> them to the operands of a nested
On Wed, Aug 01, 2018 at 01:33:09PM +0200, Tom de Vries wrote:
> On 07/31/2018 05:55 PM, Cesar Philippidis wrote:
> > Way back in the GCC 5 days when support for OpenACC was in its infancy,
> > we used to rely on having various GOACC_ thread functions in the runtime
> > to implement the execution
On Wed, Aug 1, 2018 at 11:20 AM Richard Sandiford
wrote:
>
> vectorizable_simd_clone_call was trying to remove a pattern statement
> instead of the original statement, Fixes existing tests
> gcc.dg/pr84452.c and gcc.target/i386/pr84309.c on x86.
>
> This relies on a function added by:
>
This removes an odd CSE failure of invariant addresses vs. non-invariant
ones.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2018-08-01 Richard Biener
* tree-ssa-sccvn.c (visit_phi): Compare invariant addresses
as base and offset.
Hi,
when I lately changed a couple of permerrors to permerror + warning and
accurate location for the first call, I went for the simple choice of
using DECL_SOURCE_LOCATION for the first call and keeping location_of in
the second call. Turns out we consistently want location_of for both,
Hi Steve,
On 31/07/18 23:24, Steve Ellcey wrote:
Here is a new version of my patch to support the Aarch64 SIMD ABI [1]
in GCC. I think this is complete enought to be considered for check
in. I wrote a few new tests and put them in a new gcc.target/torture
directory so they would be run with
On 31/07/18 22:48, James Greenhalgh wrote:
On Fri, Jul 20, 2018 at 04:37:34AM -0500, Vlad Lazar wrote:
Hi,
The patch adds implementations for the NEON intrinsics vabsd_s64 and vnegd_s64.
On Wed, 1 Aug 2018, Richard Sandiford wrote:
+/* For pointers @0 and @2 and nonnegative constant offset @1, look for
+ expressions like:
+
+ A: (@0 + @1 < @2) | (@2 + @1 < @0)
+ B: (@0 + @1 <= @2) | (@2 + @1 <= @0)
Once this is in, we may want to consider the opposite:
(@0 + @1 > @2) &
On 07/30/18 17:49, Joseph Myers wrote:
> On Mon, 30 Jul 2018, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this is how I would like to handle the over length strings issue in the C FE.
>> If the string constant is exactly the right length and ends in one explicit
>> NUL character, shorten it by one
On 07/31/2018 05:55 PM, Cesar Philippidis wrote:
> Way back in the GCC 5 days when support for OpenACC was in its infancy,
> we used to rely on having various GOACC_ thread functions in the runtime
> to implement the execution model, or there lack of (that version of GCC
> only supported vector
Hi,
this patch changes the Fortan FE to create NUL terminated STRING_CST
objects. This is a cleanup in preparation of a more thorough check
on the STRING_CST objects in the middle-end.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2018-08-01 Bernd
On 31/07/18 22:48, James Greenhalgh wrote:
On Fri, Jul 20, 2018 at 04:37:34AM -0500, Vlad Lazar wrote:
> Hi,
>
> The patch adds implementations for the NEON intrinsics vabsd_s64 and
vnegd_s64.
>
On Wed, Aug 1, 2018 at 12:25 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Jul 30, 2018 at 7:47 PM Richard Sandiford
> > wrote:
> >>
> >> [Sorry, somehow missed this till now]
> >>
> >> Richard Biener writes:
> >> > On Mon, Jul 23, 2018 at 5:05 PM Richard Sandiford
> >> >
... as is the case with all other
gcc.dg/plugin/poly-int-0{1,2,3,4,5,6}_plugin.c testcases. This lowers
testcase wall time from 4min 45 sec to 1min 17sec on a slow target.
2018-08-01 Uros Bizjak
* gcc.dg/plugin/poly-int-07_plugin.c (dg-options): Use -O0.
Tested on alphaev68-linux-gnu,
1 - 100 of 155 matches
Mail list logo
