* Michael Kerrisk:
> Hi Florian,
>
> On 10/5/20 9:12 AM, Florian Weimer wrote:
>> * Paul Eggert:
>>
>>> On 10/2/20 12:01 PM, Alejandro Colomar wrote:
If you propose not to document the stdint types either,
>>>
>>> This is not a stdint.h issue. __int128 is not in stdint.h and is not a
>>> sys
On 10/6/20 7:34 PM, Ian Lance Taylor wrote:
On Tue, Oct 6, 2020 at 3:20 AM Martin Liška wrote:
On 10/6/20 10:00 AM, Richard Biener wrote:
On Tue, Oct 6, 2020 at 9:01 AM Martin Liška wrote:
On 10/5/20 6:34 PM, Ian Lance Taylor wrote:
On Mon, Oct 5, 2020 at 9:09 AM Martin Liška wrote:
Th
Hi Florian,
On 10/5/20 9:12 AM, Florian Weimer wrote:
> * Paul Eggert:
>
>> On 10/2/20 12:01 PM, Alejandro Colomar wrote:
>>> If you propose not to document the stdint types either,
>>
>> This is not a stdint.h issue. __int128 is not in stdint.h and is not a
>> system data type in any real sense;
Hello,
This patch fixes (PR97271) the wrong code-gen for mve scatter store with
writeback intrinsics with -O2.
$cat bug.c
#include "arm_mve.h"
void
foo (uint32x4_t * addr, const int offset, int32x4_t value)
{
vstrwq_scatter_base_wb_s32 (addr, 8, value);
}
$ arm-none-eabi-gcc bug.c -S -O2 -ma
On Tue, 6 Oct 2020, Qing Zhao wrote:
> Richard,
>
> On behalf of John Henning, I am sending the following simple documentation
> patch
> for an official approval. Hopefully this patch can get into gcc11.
>
> Per John, the wording of the documentation change was based on the discussion
> betw
On Tue, Oct 6, 2020 at 7:06 PM Andrew MacLeod via Gcc-patches
wrote:
>
> I have now checked in the hybrid EVRP pass.
>
> We have resolved all the issue we are aware of with a full Fedora build,
> but if any more issues arise, please let us know. (And Im sure you will :-)
>
> I made some minor twea
On Wed, 7 Oct 2020, Tom de Vries wrote:
> Hi,
>
> If we change gimple_can_duplicate_bb_p to return false instead of true, we run
> into a segfault in ch_base::copy_headers due to using dump_file while it's
> NULL:
> ...
> if (!gimple_duplicate_sese_region (entry, exit, bbs, n_bbs, copied_bb
Hi,
If we change gimple_can_duplicate_bb_p to return false instead of true, we run
into a segfault in ch_base::copy_headers due to using dump_file while it's
NULL:
...
if (!gimple_duplicate_sese_region (entry, exit, bbs, n_bbs, copied_bbs,
true))
Hi Maciej:
Thanks for sharing your experience on MIPS, that sounds like just
opposite derived directions to this scheme.
> The MIPS port used to have `-mcpu=' as well, which used to be roughly
> equivalent to modern `-mtune='; from your description I gather `-mcpu=' is
> going to be roughly equi
Hi Andreas:
Thanks for your review, writing the document is my weakness ...:P
On Tue, Oct 6, 2020 at 3:34 PM Andreas Schwab wrote:
>
> On Okt 06 2020, Kito Cheng wrote:
>
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index f623467b7637..c6ba738aa0b7 100644
> > --- a/gcc/doc/invo
On Tue, Oct 6, 2020 at 11:09 AM David Malcolm wrote:
>
> I've taken the liberty of pushing this website patch, having checked
> that it validates.
>
> It covers the changes by Lewis in 004bb936d6d5f177af26ad4905595e843d5665a5
> (PR 49973 and PR 86904).
>
Cool, thank you for mentioning it here! So
And as spotted by Thomas, Tom's patch also resolved an XFAIL in
gcc/testsuite.
Committed as r11-3687-ga9802204603616df14ed47d05f1b86f1bd08d8fb after
testing it on x86-64-gnu-linux.
Tobias
On 10/6/20 3:28 PM, Tom de Vries wrote:
...
[openacc] Fix acc declare for VLAs
gcc/ChangeLog:
2020-10-06
On 10/6/20 3:27 PM, Martin Sebor wrote:
On 10/5/20 8:18 PM, Andrew MacLeod wrote:
On 10/5/20 4:16 PM, Martin Sebor wrote:
Long term, I would expect we might have some sort of general
access... probably thru cfun. so any pass/routines would just ask
for
RANGE_INFO (cfun)->range_of_exp
On 9/25/20 2:58 PM, Martin Sebor wrote:
The C and C++ representations of zero-length arrays are different:
C uses a null upper bound of the type's domain while C++ uses
SIZE_MAX. This makes the middle end logic more complicated (and
prone to mistakes) because it has to be prepared for both. A r
On 10/5/20 7:07 PM, Marek Polacek wrote:
I was notified that our P0634R3 (Down with typename) implementation has
a flaw: when we have an out-of-class member function definition, we
still required 'typename' for its parameters. For example here:
template struct S {
int simple(T::type);
On 10/6/20 11:54 AM, Mark Wielaard wrote:
Hi,
On Fri, 2020-09-18 at 17:21 +0200, Mark Wielaard wrote:
On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
Ok, here it is in patch form.
I've briefly tested it, with the older binutils I have around (no --gdwarf-N
support), with latest gas (--
Richard,
On behalf of John Henning, I am sending the following simple documentation
patch
for an official approval. Hopefully this patch can get into gcc11.
Per John, the wording of the documentation change was based on the discussion
between him and you on 25-Aug-2020.
I created a gcc bugz
This Go frontend patch by Nikhil Benesch avoids undefined behavior in
Import::read. For some implementations of Stream, advancing the
stream will invalidate the previously-returned peek buffer. Copy the
peek buffer before
advancing in Import::read to avoid this undefined behavior.
Bootstrapped an
On 10/6/20 11:58 AM, Andrew MacLeod wrote:
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual documents the [
On 06/10/20 15:55 -0400, Daniel Lemire via Libstdc++ wrote:
The updated patch looks good to me. It is indeed cleaner to have a separate
(static) function.
It might be nice to add a comment to explain the _S_nd function maybe with
a comment like "returns a random value in [0,__range)
without any
The updated patch looks good to me. It is indeed cleaner to have a separate
(static) function.
It might be nice to add a comment to explain the _S_nd function maybe with
a comment like "returns a random value in [0,__range)
without any bias" (or something to that effect).
Otherwise, it is algorit
On 10/4/20 11:28 PM, Patrick Palka wrote:
cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957. In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(doub
On 10/5/20 4:30 PM, Patrick Palka wrote:
On Wed, 30 Sep 2020, Jason Merrill wrote:
On 9/29/20 5:01 PM, Patrick Palka wrote:
This patch fixes an "unguarded" call to coerce_template_parms in
build_standard_check: processing_template_decl could be zero if we
we get here during processing of the f
On 10/5/20 8:18 PM, Andrew MacLeod wrote:
On 10/5/20 4:16 PM, Martin Sebor wrote:
On 10/5/20 8:50 AM, Aldy Hernandez via Gcc-patches wrote:
[Martin, as the original author of this pass, do you have any concerns?]
@@ -1270,7 +1271,21 @@ get_size_range (tree exp, tree range[2], bool
allow_zer
On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote:
This work-in-progress patch generalizes the malloc/free problem-checking
in -fanalyzer so that it can work on arbitrary acquire/release API pairs.
It adds a new __attribute__((deallocated_by(FOO))) that could be used
like this in a library
>
> >The condition above checks that __urngrange == 2**64-1 which means
> >that U::max() - U::min() is the maximum 64-bit value, which means
> >means U::max()==2**64-1 and U::min()==0. So if U::min() is 0 we don't
> >need to subtract it.
>
That sounds correct.
On 10/6/20 2:41 PM, Andreas Schwab wrote:
On Okt 06 2020, Andrew MacLeod via Gcc-patches wrote:
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 7031a823138..02a952bf81f 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -668,13 +668,12 @@ irange_allocator::allocate (unsigned num
On Okt 06 2020, Andrew MacLeod via Gcc-patches wrote:
> diff --git a/gcc/value-range.h b/gcc/value-range.h
> index 7031a823138..02a952bf81f 100644
> --- a/gcc/value-range.h
> +++ b/gcc/value-range.h
> @@ -668,13 +668,12 @@ irange_allocator::allocate (unsigned num_pairs)
>if (num_pairs < 2)
>
On 10/6/20 2:18 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 02:09:42PM -0400, Andrew MacLeod wrote:
+ size_t nbytes = sizeof (tree) * 2 * num_pairs;
+
+ // Allocate the irnge and required memory for the vector
+ void *r = (irange *) obstack_alloc (&m_obstack, sizeof (irange));
Then eit
The following cast looks odd:
On 10/6/20 8:09 PM, Andrew MacLeod via Gcc-patches wrote:
+ // Allocate the irnge and required memory for the vector
+ void *r = (irange *) obstack_alloc (&m_obstack, sizeof (irange));
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 20
On Tue, Oct 06, 2020 at 02:09:42PM -0400, Andrew MacLeod wrote:
> + size_t nbytes = sizeof (tree) * 2 * num_pairs;
> +
> + // Allocate the irnge and required memory for the vector
> + void *r = (irange *) obstack_alloc (&m_obstack, sizeof (irange));
Then either
void *r = (void *) obstack_all
On 10/6/20 1:58 PM, Andrew MacLeod via Gcc-patches wrote:
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual
On 10/6/20 1:48 PM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual documents the [0] extension and mentions but discourages
us
On Tue, Oct 06, 2020 at 01:41:54PM -0400, Andrew MacLeod wrote:
> On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
> > > The manual documents the [0] extension and mentions but discourages
> > > using [1]. Nothing is said ab
On 10/6/20 1:32 PM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
The manual documents the [0] extension and mentions but discourages
using [1]. Nothing is said about other sizes and the warnings such
as -Warray-bounds have been increasingly
On Tue, Oct 6, 2020 at 3:20 AM Martin Liška wrote:
>
> On 10/6/20 10:00 AM, Richard Biener wrote:
> > On Tue, Oct 6, 2020 at 9:01 AM Martin Liška wrote:
> >>
> >> On 10/5/20 6:34 PM, Ian Lance Taylor wrote:
> >>> On Mon, Oct 5, 2020 at 9:09 AM Martin Liška wrote:
>
> The previous patch
On Tue, Oct 06, 2020 at 10:42:12AM -0600, Martin Sebor wrote:
> The manual documents the [0] extension and mentions but discourages
> using [1]. Nothing is said about other sizes and the warnings such
> as -Warray-bounds have been increasingly complaining about accesses
> past the declared constan
On 10/6/20 1:10 PM, Tobias Burnus wrote:
On 10/6/20 6:56 PM, Tobias Burnus wrote:
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
And now builds – as the "Hybrid EVRP and testcases" was pushed as well,
a bit more than a quarter of an ho
On 10/6/20 6:56 PM, Tobias Burnus wrote:
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
And now builds – as the "Hybrid EVRP and testcases" was pushed as well,
a bit more than a quarter of an hour later. (At least it finished
building t
On 10/6/20 12:56 PM, Tobias Burnus wrote:
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
Tobias
On 10/6/20 6:49 PM, Andrew MacLeod via Gcc-patches wrote:
I have checked in the ranger classes/files. They are being built
but not being
I have now checked in the hybrid EVRP pass.
We have resolved all the issue we are aware of with a full Fedora build,
but if any more issues arise, please let us know. (And Im sure you will :-)
I made some minor tweaks. the option to the new -fevrp-mode flag are now:
legacy : cl
Hi all,
This patch enables MVE vmin/vmax instructions for auto-vectorization.
MVE target is included in expander smin3, umin3, smax3
and umax3 for vectorization.
Related insns for vmin/vmax in mve.md are modified to use smin, umin,
smax and umax expressions instead of unspec to support the expan
Build fails here now with: gimple-range.h:168:59: error:
‘EVRP_MODE_DEBUG’ was not declared in this scope
Tobias
On 10/6/20 6:49 PM, Andrew MacLeod via Gcc-patches wrote:
I have checked in the ranger classes/files.They are being built
but not being invoked until the other passes are checked
Hi all,
This patch enables MVE vmul instructions for auto-vectorization.
It includes MVE in expander mul3 to enable vectorization for MVE
and modifies related vmul insns to support the expander by using 'mult'
instead of unspec.
The mul3 for vectorization in vec-common.md uses mode iterator
VDQ
I have checked in the ranger classes/files. They are being built but
not being invoked until the other passes are checked in.
there are 8 new files:
gimple-range-cache.{h,cc} : Various caches used by the ranger.
gimple-range-edge.{h,cc} : Outgoing edge range calculations,
particularly
Hi all,
On 8/17/20 6:41 PM, Dennis Zhang wrote:
>
> Hi all,
>
> This patch enables MVE vsub instructions for auto-vectorization.
> It adds RTL templates for MVE vsub instructions using 'minus' instead of
> unspec expression to make the instructions recognizable for vectorization.
> MVE target is
On 10/6/20 1:52 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 09:37:21AM +0200, Aldy Hernandez via Gcc-patches wrote:
Pushed as obvious.
gcc/ChangeLog:
* value-range.h (irange_allocator::allocate): Increase
newir storage by one.
---
gcc/value-range.h | 2 +-
Hi Tom,
On 10/6/20 6:20 PM, Tom de Vries wrote:
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none -O0 execution test
A PR was filed for this: PR92790 - "[OpenACC] declare device_resident -
Fortran common blocks not handled / libgomp.o
This inlines most members of std::exception_ptr so that all operations
on a null exception_ptr can be optimized away. This benefits code like
std::future and coroutines where an exception_ptr object is present to
cope with exceptional cases, but is usually not used and remains null.
Since those fu
Hi,
We're currently running into:
...
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none -O0 execution test
FAIL: libgomp.oacc-fortran/declare-5.f90 -DACC_DEVICE_TYPE_nvidia=1
-DACC_MEM_SHARED=0 -foffload=nvptx-none -O1 execution test
With gcc-patches on too.
Not sure why the reply-all function fails for your address
Kyrill
> -Original Message-
> From: Kyrylo Tkachov
> Sent: 06 October 2020 17:13
> To: Christophe Lyon
> Subject: RE: [PATCH v2] arm: [MVE] Remove illegal intrinsics
>
>
>
> > -Original Message-
On 10/6/20 4:51 PM, Martin Sebor wrote:
On 10/6/20 8:42 AM, Andrew MacLeod wrote:
On 10/6/20 10:30 AM, Martin Sebor wrote:
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst,
On 29/09/2020 20:50, Christophe Lyon via Gcc-patches wrote:
> When mi_delta is > 255 and -mpure-code is used, we cannot load delta
> from code memory (like we do without -mpure-code).
>
> This patch builds the value of mi_delta into r3 with a series of
> movs/adds/lsls.
>
> We also do some cleanu
A few MVE intrinsics had an unsigned variant implement while they are
supported by the hardware. This patch removes them:
__arm_vqrdmlashq_n_u8
__arm_vqrdmlahq_n_u8
__arm_vqdmlahq_n_u8
__arm_vqrdmlashq_n_u16
__arm_vqrdmlahq_n_u16
__arm_vqdmlahq_n_u16
__arm_vqrdmlashq_n_u32
__arm_vqrdmlahq_n_u32
__
This patch adds:
vqdmlashq_m_n_s16
vqdmlashq_m_n_s32
vqdmlashq_m_n_s8
vqdmlashq_n_s16
vqdmlashq_n_s32
vqdmlashq_n_s8
v2: rebased after Srinath's reorganization patch
2020-10-05 Christophe Lyon
gcc/
PR target/96914
* config/arm/arm_mve.h (vqdmlashq, vqdmlashq_m): Define
Hi,
On Fri, 2020-09-18 at 17:21 +0200, Mark Wielaard wrote:
> On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> > Ok, here it is in patch form.
> > I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> > support), with latest gas (--gdwarf-N that can be passed to a
This patch adds the part number for Neoverse V1 which was missing from
the initial AArch32 support in GCC 8.
Bootstrapped and regtested on arm-none-linux-gnueabihf, pushing as
obvious.
Thanks,
Alex
---
gcc/ChangeLog:
* config/arm/driver-arm.c (arm_cpu_table): Add neoverse-v1.
diff --gi
On 10/6/20 5:02 PM, Jakub Jelinek wrote:
> On Tue, Oct 06, 2020 at 04:48:40PM +0200, Tom de Vries wrote:
>> On 10/5/20 3:15 PM, Tom de Vries wrote:
>>> On 2/7/20 4:29 PM, Jakub Jelinek wrote:
On Fri, Feb 07, 2020 at 09:56:38AM +0100, Harwath, Frederik wrote:
> * {target-32.c, thread-limit-
On Mon, 2020-10-05 at 17:23 -0300, Tulio Magno Quites Machado Filho via
Gcc-patches wrote:
> Ping?
+cc Segher :-)
>
> Tulio Magno Quites Machado Filho via Gcc-patches
> writes:
>
> > Replace them with a whitespace in order to avoid artifacts in the HTML
> > document.
> >
> > 2020-08-19 Tul
I've taken the liberty of pushing this website patch, having checked
that it validates.
It covers the changes by Lewis in 004bb936d6d5f177af26ad4905595e843d5665a5
(PR 49973 and PR 86904).
---
htdocs/gcc-11/changes.html | 39 ++
1 file changed, 39 insertions(+)
On Tue, Oct 06, 2020 at 04:48:40PM +0200, Tom de Vries wrote:
> On 10/5/20 3:15 PM, Tom de Vries wrote:
> > On 2/7/20 4:29 PM, Jakub Jelinek wrote:
> >> On Fri, Feb 07, 2020 at 09:56:38AM +0100, Harwath, Frederik wrote:
> >>> * {target-32.c, thread-limit-2.c}:
> >>> no "usleep" implemented for nvpt
On 2020/9/29 6:16 PM, Jakub Jelinek wrote:
On Tue, Sep 01, 2020 at 09:16:23PM +0800, Chung-Lin Tang wrote:
this patch set implements parts of the target mapping changes introduced
in OpenMP 5.0, mainly the attachment requirements for pointer-based
list items, and the clause ordering.
The first
On 10/6/20 8:42 AM, Andrew MacLeod wrote:
On 10/6/20 10:30 AM, Martin Sebor wrote:
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, c
On 10/5/20 3:15 PM, Tom de Vries wrote:
> On 2/7/20 4:29 PM, Jakub Jelinek wrote:
>> On Fri, Feb 07, 2020 at 09:56:38AM +0100, Harwath, Frederik wrote:
>>> * {target-32.c, thread-limit-2.c}:
>>> no "usleep" implemented for nvptx. Cf. https://gcc.gnu.org/PR81690
>>
>> Please don't, I want to deal wi
LGTM.
Thanks,
Tobias
On 10/6/20 3:28 PM, Tom de Vries wrote:
Hi,
Consider test-case test.c, with VLA A:
...
int main (void) {
int N = 1000;
int A[N];
#pragma acc declare copy(A)
return 0;
}
...
compiled using:
...
$ gcc test.c -fopenacc -S -fdump-tree-all
...
At original, we have
On 10/6/20 10:30 AM, Martin Sebor wrote:
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, call, src, srcsize);
/* Create a descri
Backport of Joe's patch wit no changes.
This patch rearranges feature bits for MVE and FP to implement the
following flags for -mcpu=cortex-m55.
- +nomve:equivalent to armv8.1-m.main+fp.dp+dsp.
- +nomve.fp: equivalent to armv8.1-m.main+mve+fp.dp (+dsp is implied by +mve).
- +nofp: e
On 10/6/20 3:45 AM, Aldy Hernandez wrote:
- builtin_memref dstref (dst, dstsize);
- builtin_memref srcref (src, srcsize);
+ builtin_memref dstref (query, call, dst, dstsize);
+ builtin_memref srcref (query, call, src, srcsize);
/* Create a descriptor of the access. This may adjust both
On Tue, Oct 06, 2020 at 12:20:14PM +0200, Martin Liška wrote:
> On 10/6/20 10:00 AM, Richard Biener wrote:
> > On Tue, Oct 6, 2020 at 9:01 AM Martin Liška wrote:
> > >
> > > On 10/5/20 6:34 PM, Ian Lance Taylor wrote:
> > > > On Mon, Oct 5, 2020 at 9:09 AM Martin Liška wrote:
> > > > >
> > > >
Backport approved here
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555618.html .
To maintain consistency with other Arm Architectures backend, iterators and
iterator attributes are moved
from mve.md file to iterators.md. Also move enumerators for MVE unspecs from
mve.md file to unspe
On Tue, Oct 06, 2020 at 03:48:38PM +0200, Martin Liška wrote:
> On 10/6/20 9:47 AM, Richard Biener wrote:
> > But is it really extensible with the current implementation? I doubt so.
>
> I must agree with the statement. So let's make the pass properly.
> I would need a help with the algorithm whe
On 10/6/20 9:47 AM, Richard Biener wrote:
But is it really extensible with the current implementation? I doubt so.
I must agree with the statement. So let's make the pass properly.
I would need a help with the algorithm where I'm planning to do the following
steps:
1) for each BB ending with
Hi, Gcc team,
This is the 3rd version of the implementation of patch -fzero-call-used-regs.
We will provide a new feature into GCC:
Add
-fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]
command-line option
and
zero_call_used_regs("skip|used-gpr-arg|used-arg|a
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 06 October 2020 14:55
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][GCC] arm: Move iterators from mve.md to iterators.md
> to maintain consistency.
>
> Hi Kyrill,
>
> > -Original Message-
> > Fro
Hi Kyrill,
> -Original Message-
> From: Kyrylo Tkachov
> Sent: 06 October 2020 14:42
> To: Srinath Parvathaneni ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [PATCH][GCC] arm: Move iterators from mve.md to iterators.md
> to maintain consistency.
>
>
>
> > -Original Message-
> > F
Hi Dennis,
> -Original Message-
> From: Dennis Zhang
> Sent: 06 October 2020 14:37
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; nd ;
> Richard Earnshaw ; Ramana Radhakrishnan
>
> Subject: Ping: [PATCH][Arm] Enable MVE SIMD modes for vectorization
>
> On 9/16/20 4:00 PM, Dennis Z
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 06 October 2020 13:27
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC] arm: Move iterators from mve.md to iterators.md to
> maintain consistency.
>
> Hello,
>
> To maintain consistency with other Arm
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 06 October 2020 14:37
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC-10 backport] arm: Remove coercion from scalar
> argument to vmin & vmax intrinsics.
>
> Hello,
>
> Straight backport of Joe's patc
On Tue, Oct 6, 2020 at 3:09 PM Martin Liška wrote:
>
> On 10/6/20 2:56 PM, Andrew MacLeod wrote:
> > Ah, by just using the outgoing_range class, all you are getting is static
> > edges. so a TRUE edge is always a [1,1] and a false edge is [0,0]
> > I provided that class so you could get the cons
Hello,
Straight backport of Joe's patch with no changes.
This patch fixes an issue with vmin* and vmax* intrinsics which accept
a scalar argument. Previously when the scalar was of different width
to the vector elements this would generate __ARM_undef. This change
allows the scalar argument to be
On Tue, Oct 6, 2020 at 12:29 PM Martin Liška wrote:
>
> Hello.
>
> Motivation of the patch is to display debug counter values after a
> compilation.
> It's handy for bisection of a debug counter. The new output is printed to
> stderr
> (instead of stdout) and it works fine with LTO as well.
>
>
On 9/16/20 4:00 PM, Dennis Zhang wrote:
> Hi all,
>
> This patch enables SIMD modes for MVE auto-vectorization.
> In this patch, the integer and float MVE SIMD modes are returned by
> arm_preferred_simd_mode (TARGET_VECTORIZE_PREFERRED_SIMD_MODE hook) when
> MVE or MVE_FLOAT is enabled.
> Then the
On Tue, Oct 6, 2020 at 11:34 AM Alexandre Oliva wrote:
>
> On Oct 6, 2020, Richard Biener wrote:
>
> > OK, I see. mathfn_built_in expects a type inter-operating with
> > the C ABI types (float_type_node, double_type_node, etc.) where
> > "inter-operating" means having the same main variant.
>
>
On Tue, 6 Oct 2020, Richard Biener wrote:
> On Fri, 2 Oct 2020, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > This introduces a permute optimization phase for SLP which is
> > > intended to cover the existing permute eliding for SLP reductions
> > > plus handling commonizing the ea
On Tue, 6 Oct 2020, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Oct 06, 2020 at 11:28:22AM +0200, Andreas Schwab wrote:
> > options-save.c: In function 'void cl_target_option_save(cl_target_option*,
> > gcc_options*, gcc_options*)':
> > options-save.c:8526:26: error: unused variable 'mask'
> > [-Wer
Hi,
Consider test-case test.c, with VLA A:
...
int main (void) {
int N = 1000;
int A[N];
#pragma acc declare copy(A)
return 0;
}
...
compiled using:
...
$ gcc test.c -fopenacc -S -fdump-tree-all
...
At original, we have:
...
#pragma acc declare map(tofrom:A);
...
but at gimple, we have
On 10/6/20 9:09 AM, Martin Liška wrote:
On 10/6/20 2:56 PM, Andrew MacLeod wrote:
Ah, by just using the outgoing_range class, all you are getting is
static edges. so a TRUE edge is always a [1,1] and a false edge is [0,0]
I provided that class so you could get the constant edges on switches.
Hi!
On Tue, Oct 06, 2020 at 11:28:22AM +0200, Andreas Schwab wrote:
> options-save.c: In function 'void cl_target_option_save(cl_target_option*,
> gcc_options*, gcc_options*)':
> options-save.c:8526:26: error: unused variable 'mask'
> [-Werror=unused-variable]
> 8526 | unsigned HOST_WIDE_INT
On 10/6/20 2:56 PM, Andrew MacLeod wrote:
Ah, by just using the outgoing_range class, all you are getting is static
edges. so a TRUE edge is always a [1,1] and a false edge is [0,0]
I provided that class so you could get the constant edges on switches.
if you want to get actual ranges for ssa-
On 10/6/20 8:55 AM, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 08:47:53AM -0400, Andrew MacLeod wrote:
I think the proper alignment will be guaranteed if irange and tree[] are
obstack_alloc'd separately. They don't need to be adjacent, do they?
They do not, it just seemed wasteful to do 2
On 10/6/20 8:09 AM, Martin Liška wrote:
On 10/2/20 4:19 PM, Andrew MacLeod wrote:
On 10/2/20 9:26 AM, Martin Liška wrote:
Yes, you simply get all sorts of conditions that hold when a
condition is
true, not just those based on the SSA name you put in. But it occured
to me that the use-case is
On Tue, Oct 06, 2020 at 08:47:53AM -0400, Andrew MacLeod wrote:
> > I think the proper alignment will be guaranteed if irange and tree[] are
> > obstack_alloc'd separately. They don't need to be adjacent, do they?
> >
> >
> They do not, it just seemed wasteful to do 2 allocs each time, and it'd
On 10/6/20 6:22 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 06, 2020 at 11:20:52AM +0200, Aldy Hernandez wrote:
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 94b48e55e77..7031a823138 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -670,7 +670,7 @@ irange_allocator::
On 10/6/20 6:40 AM, Andreas Schwab wrote:
On Okt 06 2020, Jakub Jelinek wrote:
On Tue, Oct 06, 2020 at 10:47:34AM +0200, Andreas Schwab wrote:
On Okt 06 2020, Jakub Jelinek via Gcc-patches wrote:
I mean, we could just use:
size_t nbytes = sizeof (irange) + sizeof (tree) * 2 * num_pairs;
Hello,
To maintain consistency with other Arm Architectures backend, iterators and
iterator attributes are moved
from mve.md file to iterators.md. Also move enumerators for MVE unspecs from
mve.md file to unspecs.md file.
Regression tested on arm-none-eabi and found no regressions.
Ok for mast
On Tue, Oct 06, 2020 at 08:22:13AM +0200, Richard Biener wrote:
> > I was really hoping bbs 4 and 5 would be one loop (the one I set safelen
> > and force_vectorize etc. for) and that basic blocks 6 and 7 would be
> > together with that inner loop another loop, but apparently loop discovery
> > thi
On 10/2/20 4:19 PM, Andrew MacLeod wrote:
On 10/2/20 9:26 AM, Martin Liška wrote:
Yes, you simply get all sorts of conditions that hold when a condition is
true, not just those based on the SSA name you put in. But it occured
to me that the use-case is somewhat different - for switch-conversion
Hi,
I'd like to propose a new "retain" attribute, which can
be applied to function and variable declarations.
The attribute is used to protect the function or variable declaration it
is applied to from linker garbage collection, by applying the
SHF_GNU_RETAIN section flag to the section containin
On Okt 06 2020, Jakub Jelinek wrote:
> On Tue, Oct 06, 2020 at 10:47:34AM +0200, Andreas Schwab wrote:
>> On Okt 06 2020, Jakub Jelinek via Gcc-patches wrote:
>>
>> > I mean, we could just use:
>> > size_t nbytes = sizeof (irange) + sizeof (tree) * 2 * num_pairs;
>> > irange *r = (irange *) o
Hello.
Motivation of the patch is to display debug counter values after a compilation.
It's handy for bisection of a debug counter. The new output is printed to stderr
(instead of stdout) and it works fine with LTO as well.
Sample output:
counter name counter value closed
1 - 100 of 135 matches
Mail list logo
