On Sat, 6 Jul 2019 at 06:12, Ed Smith-Rowland via libstdc++
wrote:
> By my reckoning, you have a constexpr source array, an output array that
> is initialized as it must be for constexpr.?? You have to have a
> deterministic result after the copy.?? In the local array version the
> actual iterator
Hi!
I've noticed I got the order of arguments in the last UDR combine operation
of worksharing scan wrong, var2 contains either the neutral element (first
thread) or the prefix sum from the original value up to the last iteration
before what the current thread handles and rprivb array contains the
Hi!
Apparently on arm we force -ffast-math in gcc.dg/vect/ but that changes
behavior, as we don't want to insert with -ffinite-math-only infinities
when the user didn't use them, for exclusive scan we get -__FLT_MAX__
in the first element rather than -inf.
Fixed thusly, bootstrapped/regtested on
Hi!
The following patch handles the last yet unsupported scan case,
composite #pragma omp {,parallel }for simd ... reduction(inscan, ...) ...
where we want to both parallelize and vectorize; in the first worksharing
loop use normal scan support we have for
#pragma omp simd ... reduction(inscan, ..
On 7/3/19 7:12 PM, Jeff Law wrote:
On 7/1/19 4:24 AM, Aldy Hernandez wrote:
This is completely unrelated to range-ops itself, but may yield better
results in value_range intersections. It's just something I found while
working on VRP, and have been dragging around on our branch.
If we know t
This problem was caused by the code for scalarized array references to
subref arrays and deferred length variables not obtaining the correct
array descriptor and so getting the array span wrong. As it happens,
the lines, following the deleted part, correctly identify when the
info descriptor is a p
As anticipated, 8-branch required a different patch but the difference
was much smaller than anticipated.
Bootstrapped and regetested on FC29/x86_64 - OK for 8-branch?
Paul
2019-07-06 Paul Thomas
PR fortran/91077
* trans-array.c (gfc_conv_scalarized_array_ref) Delete code
that ga
On 7/5/19 2:48 AM, Richard Sandiford wrote:
> While testing the fix for PR91068, I hit an rtl checking failure
> while building newlib. mips_split_move was decomposing an address that
> happened to be symbolic and then tried to access the REGNO of the base
> register field, which wasn't initialise
On 7/5/19 2:51 AM, Richard Sandiford wrote:
> PR91068 is a case in which we have (ignoring non-LRA alternatives):
>
> [(set (match_operand:SI 0 "register_operand" "=l,d?")
> (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "d,d")
> (match_operand:SI 2 "regis
On Sat, Jul 06, 2019 at 02:29:06PM +0100, Paul Richard Thomas wrote:
> As anticipated, 8-branch required a different patch but the difference
> was much smaller than anticipated.
>
> Bootstrapped and regetested on FC29/x86_64 - OK for 8-branch?
>
OK for both patches.
--
Steve
On 7/4/19 9:27 AM, Christophe Lyon wrote:
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for the "noinit" attribute.
It is convenient for embedded targets where the user wants to keep the
value of some data when the program is restarted: suc
On 05/07/19 19:44 +0100, Jonathan Wakely wrote:
On 05/07/19 20:23 +0200, Daniel Krügler wrote:
Am Fr., 5. Juli 2019 um 18:13 Uhr schrieb Jonathan Wakely :
[..]
I decided against the simplification in the second patch, and
committed the attached one which is closer to the first patch I sent
(
Hi!
It isn't entirely clear to me why all the tests in the testsuite happen to
pass, but in the simdlen(1)/if(simd:0) for simd loops lastprivate
conditional variables private in the simd need to be copied to the private
variables in the worksharing loop unconditionally at the end of the simd
loop,
Hi!
lastprivate or conditional lastprivate could be modified either in the input
phase, or in the scan phase (but not both), and as we don't really know in
which one it is, we need to copy the value from the first simd into simd
lanes of the second simd.
Bootstrapped/regtested on x86_64-linux and
14 matches
Mail list logo
