On Tue, 5 Nov 2019, Jan Hubicka wrote:
> Hi,
> here is updated patch. Now the hash is freed though it is not
> extraordinarily large (for firefox about 20k entries which roughly
> correspond to number of source files)
>
> Bootstrapped/regtested x86_64-linux. OK?
OK.
Note I was arguing that the
> Uh. Note it's not exactly helpful to change algorithms between
> reviews, that makes it
> just harder :/
>
> Btw, I notice you use post-dominance info. Note that we generally do
> not keep that
> up-to-date with CFG manipulations (and for dominators fast queries are
> disabled).
> Probably the
From: guojiufu
Hi,
Here is updated patch combining comments and suggestions from previous review.
In this patch, loop unroll adjust hook is introduced for powerpc. We can do
target related heuristic adjustment in this hook. In this patch, -funroll-loops
is enabled for small loops at O2 and O3.
On 2019/11/6 02:20, Joseph Myers wrote:
> On Tue, 5 Nov 2019, Kewen.Lin wrote:
>
>> Very good point! Since gcc doesn't pursue 100% testsuite pass rate, I
>> noticed
>> there are a few failures exposed/caused by some PRs all the time. Could we
>> just leave the test case there without any pre wo
On 2019/10/22 22:07, Martin Liška wrote:
On 9/27/19 9:13 AM, luoxhu wrote:
Thanks for your time of so many round of reviews.
You're welcome. One last request would be please to make
gimple_ic_transform a void function. See attached patch.
I'll remind the patch today to Honza.
Thanks, Marti
On 11/5/19 5:00 PM, Martin Sebor wrote:
> After considering more instances of the enhanced -Warray-bounds
> and the new -Wzero-length-array-bounds warnings I realized that
> there are some where the former is being issued for zero-length
> arrays but where the latter would be more appropriate.
>
>
The conbine pass is perfectly happy if a splitter splits to just one
instruction (instead of two).
Committing to trunk.
Segher
2019-11-05 Segher Boessenkool
* doc/md.texi (Insn Splitting): Fix combiner documentation.
---
gcc/doc/md.texi | 2 +-
1 file changed, 1 insertion(+), 1 d
After considering more instances of the enhanced -Warray-bounds
and the new -Wzero-length-array-bounds warnings I realized that
there are some where the former is being issued for zero-length
arrays but where the latter would be more appropriate.
The attached change tweaks the logic in component_
There are three major pieces to this support: scalar operator<=>,
synthesis of comparison operators, and rewritten/reversed overload
resolution (e.g. a < b becomes 0 > b <=> a).
Unlike other defaulted functions, where we use synthesized_method_walk to
semi-simulate what the definition of the funct
I'm applying this patch again now, this time with a tweak to expmed.c
to prevent the false positive warning from breaking bootstrap. I
don't see any problem in the gimple output, so the bug must be in the
middle-end somewhere.
On Thu, Sep 19, 2019 at 8:43 PM Jason Merrill wrote:
>
> I've reverte
My operator<=> patch wants to split up build_new_op_1, which makes using a
tree array as well as the vec inconvenient. build_new_op_1 already has a
vec, and build_conditional_expr_1 can release its vec right away, so this
doesn't increase garbage at all.
Tested x86_64-pc-linux-gnu, applying to tr
Wrappers for lookup_qualified_name and build_x_binary_op to make calling
them more convenient in places, and a function named contextual_conv_bool
for places that want contextual conversion to bool.
I noticed that we weren't showing the declaration location when we complain
about a call to a non-c
Hi Tobias!
On 2019-10-24T14:47:58+0200, Tobias Burnus wrote:
> The clause (new in OpenACC 2.6) makes any device code use the local
> memory address for each of the variables specified unless the given
> variable is already present on the current device. – Or in words of
> OpenACC 2.7 (in Sect.
Aside: This is my first time working in GCC's code base. I probably made
some mistakes. Please point them out. =]
When GCC encounters __attribute__((section("foo"))) on a function or
variable declaration, it adds an entry in the symbol table for the
declaration to remember its desired section. The
Hello
On 04/11/2019 04:22 pm, Georg-Johann Lay wrote:
> The avr port already uses 2 hard-reg frame pointer ever since...
>
> Does this patch has an impact on the avr port and its handling of
> the frame pointer?
I am not familiar with the AVR port, but looking at the source, it looks
like it pr
This patch makes can_duplicate_and_interleave_p cope with mixtures of
vector sizes, by using queries based on get_vectype_for_scalar_type
instead of directly querying GET_MODE_SIZE (vinfo->vector_mode).
int_mode_for_size is now the first check we do for a candidate mode,
so it seemed better to res
While looking at one of the issues under discussion at the meeting, I
noticed we weren't diagnosing a couple of cases of unsatisfied
un-overloaded functions.
It also seems to me that -fconcepts-ts ought to imply -fconcepts for
pre-C++20 modes.
Tested x86_64-pc-linux-gnu, applying to trunk.
c
Hi,
When investigating PR92317 I noticed that when we create the skip
epilogue condition, see ('if (skip_epilog)' in 'vect_do_peeling'), we
only copy phi-nodes that are not constants in
'slpeel_update_phi_nodes_for_guard2'. This can cause problems later
when we create the scalar epilogue for
Patch 12/n makes the AArch64 port add four entries to
autovectorize_vector_modes. Each entry describes a different
vector mode assignment for vector code that mixes 8-bit, 16-bit,
32-bit and 64-bit elements. But if (as usual) the vector code has
fewer element sizes than that, we could end up tryi
As explained in the comment, vectorizable_call needs more work to
support mixtures of sizes. This avoids testsuite fallout for
later SVE patches.
Was originally going to be later in the series, but applying it
before 11/n seems safer. As before each patch tested individually
on aarch64-linux-gnu
Dimitar Dimitrov writes:
> On Sat, 2 Nov 2019, 19:28:38 EET Kwok Cheung Yeung wrote:
>> The AMD GCN architecture uses 64-bit pointers, but the scalar registers
>> are 32-bit wide, so pointers must reside in a pair of registers.
> ...
>> Bootstrapped on x86_64 and tested with no regressions, which
>From f967ce2f155d50c8d28b9a7f5c7d10443131d940 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 5 Nov 2019 19:10:21 +0100
Subject: [PATCH 2/3] Reapply all revisions mentioned in LOCAL_PATCHES.
libsanitizer/ChangeLog:
2019-11-05 Martin Liska
* all source files: Reapply all revisions m
Hello.
As I was correctly notified, LLVM has moved to git mono repository
before 2 weeks ago. So that my last merge from trunk did point to
the tip of their repository. So that, I rewrote the merge.sh script
and made one more merge.
Patch can bootstrap on x86_64-linux-gnu and survives regression
Currently for hard float we need to check for
__ARC_FPU_SP__ || __ARC_FPU_DP__ and for soft float inverse of that.
So define single convenience macros for either cases
gcc/
-xx-xx Vineet Gupta
* config/arc/arc-c.c (arc_cpu_cpp_builtins): Add
__arc_hard_float__, __ARC_HAR
On 11/5/19 7:41 PM, Rainer Orth wrote:
Hi Martin,
libsanitizer/ChangeLog:
2019-11-05 Martin Liska
* asan/asan_globals.cpp (CheckODRViolationViaIndicator): Reapply from
LOCAL_PATCHES.
(CheckODRViolationViaPoisoning): Likewise.
(RegisterGlobal): Likewise.
On Tue, 5 Nov 2019, Szabolcs Nagy wrote:
> GCC currently supports two ways to declare the availability of vector
> variants of a scalar function:
>
> #pragma omp declare simd
> void f (void);
>
> and
>
> __attribute__ ((simd))
> void f (void);
>
> However neither can declare unambiguou
Hi Martin,
> libsanitizer/ChangeLog:
>
> 2019-11-05 Martin Liska
>
> * asan/asan_globals.cpp (CheckODRViolationViaIndicator): Reapply from
> LOCAL_PATCHES.
> (CheckODRViolationViaPoisoning): Likewise.
> (RegisterGlobal): Likewise.
> * asan/asan_interceptors.h
> (A
On Tue, 5 Nov 2019, Matthew Malcomson wrote:
> +DEFHOOK
> +(can_tag_addresses,
> + "True if backend architecture naturally supports ignoring the top byte of\
> + pointers. This feature means that -fsanitize=hwaddress can work.",
> + bool, (), default_memtag_can_tag_addresses)
@option{-fsanitize=
On Tue, 5 Nov 2019, Matthew Malcomson wrote:
> Hello,
>
> This patch series adds the LLVM hardware address sanitizer (HWASAN) to
> GCC. The document describing HWASAN can be found here
> http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
General observations on the patch se
On Tue, 5 Nov 2019, Kewen.Lin wrote:
> Very good point! Since gcc doesn't pursue 100% testsuite pass rate, I noticed
> there are a few failures exposed/caused by some PRs all the time. Could we
> just leave the test case there without any pre workaround till the PR get
> fixed?
Yes, leaving th
On 11/5/19 6:35 PM, Matthew Malcomson wrote:
On 05/11/2019 17:22, Martin Liška wrote:
On 11/5/19 5:11 PM, Matthew Malcomson wrote:
On 05/11/2019 15:10, Martin Liška wrote:
On 11/5/19 12:32 PM, Matthew Malcomson wrote:
Hello,
This patch series adds the LLVM hardware address sanitizer (HWASAN)
> On 11/5/19 3:48 PM, Jan Hubicka wrote:
> > > >
> > > > stringpool.c:63 (alloc_node)47M: 2.3%
> > > > 0 : 0.0%0 : 0.0%0 : 0.0% 1217k
> > > > ipa-prop.c:4480 (ipa_read_edge_info)51M: 2.4%
> > > > 0 : 0.0%
On Thu, Oct 24, 2019 at 06:19:03PM +, Segher Boessenkool wrote:
> We already had those in fact, just under other names. Use the standard
> names so that the vectorizer can use it.
>
> Committing to trunk; will backport to 9 and 8 later.
I've done those backports now.
Segher
> * con
On 05/11/2019 17:22, Martin Liška wrote:
> On 11/5/19 5:11 PM, Matthew Malcomson wrote:
>> On 05/11/2019 15:10, Martin Liška wrote:
>>> On 11/5/19 12:32 PM, Matthew Malcomson wrote:
Hello,
This patch series adds the LLVM hardware address sanitizer (HWASAN) to
GCC. The document
On Sat, Oct 26, 2019 at 04:35:04PM +, Segher Boessenkool wrote:
> When we have -fstack-limit-symbol with sysv we can end up with a non-
> existing instruction (you cannot add an immediate to register 0). Fix
> this by using register 11 instead. It might be used for something else
> already th
On 11/5/19 5:11 PM, Matthew Malcomson wrote:
On 05/11/2019 15:10, Martin Liška wrote:
On 11/5/19 12:32 PM, Matthew Malcomson wrote:
Hello,
This patch series adds the LLVM hardware address sanitizer (HWASAN) to
GCC. The document describing HWASAN can be found here
http://clang.llvm.org/docs/Ha
Hi Richard,
> Please investigate those - C++ has -fno-common already so it might be a mix
> of C/C++ required here. Note that secondary files can use dg-options
> with the same behavior as dg-additional-options (they append to
> dg-lto-options),
> so here in _1.c add { dg-options "-fcommon" }
T
This fixes 92370. cp_lexer_peek_token never returned NULL, so the check for
that was always irrelevant. However, prior to my r277514 patch, eof caused us
to point at the unique eof token, which had an UNKNOWN_LOCATION and hence we
fell out of the loop.
The lexer doesn't give the EOF token it
Ping
Richard Sandiford writes:
> One of the changes in r277281 was to make the typedef variant
> handling in strip_typedefs pass the raw DECL_ORIGINAL_TYPE to the
> recursive call, instead of applying TYPE_MAIN_VARIANT first.
> This PR shows that that interacts badly with the implementation
> of
Hi Thomas!
Here's a new version of the patch, with your comments below hopefully
addressed. In particular the check_base_and_compare_lt function
with the "weird" API has been replaced by a new, simpler
extract_base_bit_offset function. Going back and re-examining the code,
I think it makes more se
Hi,
here is updated patch. Now the hash is freed though it is not
extraordinarily large (for firefox about 20k entries which roughly
correspond to number of source files)
Bootstrapped/regtested x86_64-linux. OK?
* lto-streamer-in.c: Include alloc-pool.h.
(freeing_string_slot_hashe
Darn. I thought I had fixed all of them.
Committed as obvious.
commit 3420097161f9cdc1df27f6ffd058076df3f4f874
Author: Aldy Hernandez
Date: Tue Nov 5 17:16:47 2019 +0100
Fix indentation inconsistencies introduced by previous patch.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index d5e0f6
On 05/11/2019 15:10, Martin Liška wrote:
> On 11/5/19 12:32 PM, Matthew Malcomson wrote:
>> Hello,
>>
>> This patch series adds the LLVM hardware address sanitizer (HWASAN) to
>> GCC. The document describing HWASAN can be found here
>> http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDes
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-05 Richard Biener
PR tree-optimization/92371
* tree-vect-loop.c (vectorizable_reduction): Set STMT_VINFO_REDUC_DEF
on the original stmt of live stmts in the chain.
(vectorizable_li
On Tue, Nov 5, 2019 at 4:34 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Oct 25, 2019 at 2:41 PM Richard Sandiford
> > wrote:
> >>
> >> Some callers of get_same_sized_vectype were dealing with operands that
> >> are constant or defined externally, and so have no STMT_VINFO_
On Tue, Nov 5, 2019 at 4:31 PM Andrew MacLeod wrote:
>
> On 11/5/19 8:21 AM, Aldy Hernandez wrote:
> > The base class for ranges is currently value_range_base, which is
> > rather long and cumbersome. It also occurs more often than the
> > derived class of value_range. To avoid confusion, and sa
On Tue, Nov 5, 2019 at 4:22 PM Martin Liška wrote:
>
> On 11/5/19 3:13 PM, Richard Biener wrote:
> > On Thu, Oct 31, 2019 at 2:17 PM Martin Liška wrote:
> >>
> >> On 10/31/19 2:16 PM, Martin Liška wrote:
> >>> On 10/31/19 2:01 PM, Martin Liška wrote:
> Hi.
>
> Based on the discussi
* include/std/version [!_GLIBCXX_HOSTED]: Do not define feature test
macros for features that are only present in hosted builds.
Tested powerpc64le-linux, committed to trunk.
commit 05a2a8dc6c676595053571211796a53ceba5
Author: Jonathan Wakely
Date: Tue Nov 5 15:23:07 2019
The negative concept is required for subsumption to work, it's not a
bug.
* include/bits/iterator_concepts.h (__iter_without_nested_types):
Remove incorrect comment.
Tested powerpc64le-linux, committed to trunk.
commit 8a6c34baf551214cac8d328963b2fa58088785b7
Author: Jonathan W
Richard Biener writes:
> On Fri, Oct 25, 2019 at 2:41 PM Richard Sandiford
> wrote:
>>
>> Some callers of get_same_sized_vectype were dealing with operands that
>> are constant or defined externally, and so have no STMT_VINFO_VECTYPE
>> available. Under the current model, using get_same_sized_ve
On 11/5/19 8:21 AM, Aldy Hernandez wrote:
The base class for ranges is currently value_range_base, which is
rather long and cumbersome. It also occurs more often than the
derived class of value_range. To avoid confusion, and save typing,
this patch does a global rename from value_range to val
On 11/5/19 3:27 PM, Richard Biener wrote:
On Tue, Nov 5, 2019 at 2:15 PM Aldy Hernandez wrote:
The function range_int_cst_p only works with VR_RANGE's at the moment.
This is silly because VR_ANTI_RANGE and even VR_VARYING can contain
numeric bounds. I have fixed this oversight and have mad
On 11/5/19 3:13 PM, Richard Biener wrote:
On Thu, Oct 31, 2019 at 2:17 PM Martin Liška wrote:
On 10/31/19 2:16 PM, Martin Liška wrote:
On 10/31/19 2:01 PM, Martin Liška wrote:
Hi.
Based on the discussion with Honza and Richard I'm sending a proposal
for conversion of param machinery into th
On 11/5/19 9:27 AM, Richard Biener wrote:
On Tue, Nov 5, 2019 at 2:15 PM Aldy Hernandez wrote:
The function range_int_cst_p only works with VR_RANGE's at the moment.
This is silly because VR_ANTI_RANGE and even VR_VARYING can contain
numeric bounds. I have fixed this oversight and have made th
Hi.
When calling delete_function_version, we should also clear
version_info_node once it can be seen GGC collect.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-11-05 Martin Liska
PR c++/92354
On 11/5/19 12:32 PM, Matthew Malcomson wrote:
Hello,
This patch series adds the LLVM hardware address sanitizer (HWASAN) to
GCC. The document describing HWASAN can be found here
http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
Hello.
Thank you for the patch. I've just
Hi Thomas,
> On 07.10.19 20:41, Thomas Schwinge wrote:
> > On 2018-12-03T16:51:14+, "Maciej W. Rozycki"
> > wrote:
> > Add generic support for the OpenACC 2.6 `acc_get_property' and
> > `acc_get_property_string' routines [...]
>
> ..., which allow for user code to query the implementation fo
On 11/5/19 3:48 PM, Jan Hubicka wrote:
stringpool.c:63 (alloc_node)47M: 2.3%0 :
0.0%0 : 0.0%0 : 0.0% 1217k
ipa-prop.c:4480 (ipa_read_edge_info)51M: 2.4%0 :
0.0% 260k: 0.0% 404k: 0.3% 531k
Jiufu Guo writes:
Got message about fail to send to gcc-patches. Send again.
> Segher Boessenkool writes:
>
>> Hi!
>>
>> On Mon, Nov 04, 2019 at 02:31:43PM +0800, Jiufu Guo wrote:
>>> In this patch, loop unroll adjust hook is introduced for powerpc. We can do
>>> target related hueristic adjus
> >
> > stringpool.c:63 (alloc_node)47M: 2.3%0
> > : 0.0%0 : 0.0%0 : 0.0% 1217k
> > ipa-prop.c:4480 (ipa_read_edge_info)51M: 2.4%0
> > : 0.0% 260k: 0.0% 404k: 0.3% 531k
> > hash-table.h:801
For trunk, I needed the DECL_ARTIFICIAL fix, cf. Rev. 277661 of PR92277,
i.e. https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02148.html
When back-porting some patches, I did not include this part – only its
test case – as I couldn't trigger the ICE. Well, as the comments in PR
92208 show, the i
Hi Thomas,
after your last round of review, I realized that the bulk of the compiler
omp-low work was
simply a case of dumb over-engineering in the wrong direction :P
(although it did painstakingly function correctly)
Instead of making code changes for bias adjustment in the child function code
This patch enables vect-compare-loop-costs by default for SVE, both so
that we can compare SVE against Advanced SIMD and so that (with future
patches) we can compare multiple SVE vectorisation approaches against
each other.
I'll apply if the prerequisites are approved.
2019-11-05 Richard Sandif
We didn't take the cost of generating loop masks into account, and so
tended to underestimate the cost of loops that need multiple masks.
2019-11-05 Richard Sandiford
gcc/
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Include
the cost of generating loop masks.
gcc/
This patch adds a mode in which the vectoriser tries each available
base vector mode and picks the one with the lowest cost. For now
the behaviour is behind a default-off --param, but a later patch
enables it by default for SVE.
The patch keeps the current behaviour of preferring a VF of
loop->si
vect_analyze_loop_costing uses two profitability thresholds: a runtime
one and a static compile-time one. The runtime one is simply the point
at which the vector loop is cheaper than the scalar loop, while the
static one also takes into account the cost of choosing between the
scalar and vector lo
On Tue, Nov 5, 2019 at 2:15 PM Aldy Hernandez wrote:
>
> The function range_int_cst_p only works with VR_RANGE's at the moment.
> This is silly because VR_ANTI_RANGE and even VR_VARYING can contain
> numeric bounds. I have fixed this oversight and have made the function
> return the bounds in MIN
vectorizable_assignment handles true SSA-to-SSA copies (which hopefully
we don't see in practice) and no-op conversions that are required
to maintain correct gimple, such as changes between signed and
unsigned types. These cases shouldn't generate any code and so
shouldn't count against either the
This patch makes two tweaks to vectorizable_conversion. The first
is to use "modifier" to distinguish between promotion, demotion,
and neither promotion nor demotion, rather than using a code for
some cases and "modifier" for others. The second is to take ncopies
into account for the promotion an
This series adds a mode in which we try to vectorise loops once for
each supported vector mode combination and then pick the one with the
lowest cost. There are only really two patches for that: one to add the
feature and another to enable it by default for SVE. However, for it to
work as hoped,
Hi Frederik!
On 2019-10-29T13:20:53+0100, "Harwath, Frederik"
wrote:
> On 24.10.19 16:31, Thomas Schwinge wrote:
>> So just C/C++ testing, no Fortran at all. This is not ideal, but
>> probably (hopefully) acceptable given that this is working on the middle
>> end representation shared between a
On Thu, Oct 31, 2019 at 2:17 PM Martin Liška wrote:
>
> On 10/31/19 2:16 PM, Martin Liška wrote:
> > On 10/31/19 2:01 PM, Martin Liška wrote:
> >> Hi.
> >>
> >> Based on the discussion with Honza and Richard I'm sending a proposal
> >> for conversion of param machinery into the existing option mac
Richard Biener writes:
> On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford
> wrote:
>>
>> The BB vectoriser picked vector types in the same way as the loop
>> vectoriser: it picked a vector mode/size for the region and then
>> based all the vector types off that choice. This meant we could
>> en
On Thu, Oct 31, 2019 at 3:38 PM Feng Xue OS wrote:
>
> Hi, Richard
>
>This is a new patch to support more generalized semi-invariant condition,
> which uses
> control dependence analysis.
Uh. Note it's not exactly helpful to change algorithms between
reviews, that makes it
just harder :/
B
These tests check if loop peeling has been applied to avoid
having to vectorize unaligned loops. On Z we do not have any
alignment requirements for vectorization so we also don't need want
the loop peeling here.
2019-11-05 Andreas Krebbel
* gcc.dg/tree-ssa/gen-vect-26.c: Disable loop
In the Z backend we still set min-vect-loop-bound to 2 to work around
corner cases where awkward epilogue code gets generated in the
vectorizer. This has a particular bad impact when vectorizing loops
with a low iteration count. Due to this we do not vectorize the loop
in gen-vect-11/32 - what ac
This fixes an ICE in gcc.dg/attr-vector_size.c testcase.
gcc/ChangeLog:
2019-11-05 Andreas Krebbel
* config/s390/s390.c (s390_vector_alignment): Check if the value
fits into uhwi before using it.
---
gcc/config/s390/s390.c | 8 +++-
1 file changed, 7 insertions(+), 1 dele
This fixes various issues with the useable_hw check in s390.exp. The
check is supposed to verify whether a testcase can be run on the
current hardware.
- the test never returned true for -m31 because vzero is not available
in ESA mode and -m31 defaults to -mesa
- the missing v0 clobber on the v
Andreas Krebbel (4):
IBM Z: Use tree_fits_uhwi_p in vector_alignment hook
IBM Z: Fix testsuite useable_hw check
IBM Z: gen-vect-11/32: Set min-vect-loop-bound param back to default
IBM Z: gen-vect-26/28: Vectorizing without peeling is ok for Z
gcc/config/s390/s390.c |
This avoids folding
_1 = { _2, _3, _4, _5 };
_2 = BIT_FIELD_REF <_1, ..>;
to
_1 = { _2, _3, _4, _5 };
_2 = { _4, _5 };
when the first CTOR doesn't become dead. This in turn makes FRE
handle partial loads from
mem = _1;
by inserting BIT_FIELD_REFs on _1 (instead of CTORs which FRE refuses
On Tue, May 21, 2019 at 11:20 AM Uros Bizjak wrote:
>
> 2019-05-21 Uroš Bizjak
>
> * config/i386/cpuid.h (__cpuid): For 32bit targets, zero
> %ebx and %ecx bafore calling cpuid with leaf 1 or
> non-constant leaf argument.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,
On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford
wrote:
>
> The BB vectoriser picked vector types in the same way as the loop
> vectoriser: it picked a vector mode/size for the region and then
> based all the vector types off that choice. This meant we could
> end up trying to use vector types t
On Mon, 4 Nov 2019 at 17:54, Kyrill Tkachov wrote:
>
> Hi Christophe,
>
> On 10/18/19 2:18 PM, Christophe Lyon wrote:
> > Hi,
> >
> > All these tests fail when using -mpure-code:
> > * some force A or R profile
> > * some use Neon
> > * some use -fpic/-fPIC
> > all of which are not supported by th
The function range_int_cst_p only works with VR_RANGE's at the moment.
This is silly because VR_ANTI_RANGE and even VR_VARYING can contain
numeric bounds. I have fixed this oversight and have made the function
return the bounds in MIN/MAX. This simplifies a lot of code, because
there is no lo
On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson
wrote:
>
> These flags can't be used at the same time as any of the other
> sanitizers.
> We add an equivalent flag to -static-libasan in -static-libhwasan to
> ensure static linking.
>
> The -fsanitize=kernel-hwaddress option is for compiling targ
On Tue, Oct 29, 2019 at 6:04 PM Richard Sandiford
wrote:
>
> If the statements in an SLP node aren't similar enough to be vectorised,
> or aren't something the vectoriser has code to handle, the BB vectoriser
> tries building the vector from scalars instead. This patch does the
> same thing if we
On Tue, 5 Nov 2019 at 05:46, Prathamesh Kulkarni
wrote:
>
> On Mon, 4 Nov 2019 at 18:37, Christophe Lyon
> wrote:
> >
> > On Mon, 28 Oct 2019 at 16:03, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 28 Oct 2019 at 07:18, Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Oct 25, 2019 at
On Fri, Oct 25, 2019 at 2:51 PM Richard Sandiford
wrote:
>
> This patch adds AArch64 patterns for converting between 64-bit and
> 128-bit integer vectors, and makes the vectoriser and expand pass
> use them.
So on GIMPLE we'll see
v4si _1;
v4di _2;
_1 = (v4si) _2;
then, correct? Likewise for
On Fri, Oct 25, 2019 at 2:49 PM Richard Sandiford
wrote:
>
> Although a previous patch allowed mixed vector sizes within a vector
> region, we generally still required equal vector sizes within a vector
> stmt. Specifically, vect_get_vector_types_for_stmt computes two vector
> types: the vector t
On Fri, Oct 25, 2019 at 2:43 PM Richard Sandiford
wrote:
>
> After previous patches, it's now possible to make the vectoriser
> support multiple vector sizes in the same vector region, using
> related_vector_mode to pick the right vector mode for a given
> element mode. No port yet takes advantag
On 11/5/19 1:23 PM, Jakub Jelinek wrote:
On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote:
libsanitizer/ChangeLog:
2019-11-05 Martin Liska
* all source files: Merge from upstream r375507.
---
libsanitizer/BlocksRuntime/Block.h| 59 +
libsanitizer/Blocks
On Fri, Oct 25, 2019 at 2:41 PM Richard Sandiford
wrote:
>
> Some callers of get_same_sized_vectype were dealing with operands that
> are constant or defined externally, and so have no STMT_VINFO_VECTYPE
> available. Under the current model, using get_same_sized_vectype for
> that case is equival
On Fri, Oct 25, 2019 at 2:39 PM Richard Sandiford
wrote:
>
> This patch replaces vec_info::vector_size with vec_info::vector_mode,
> but for now continues to use it as a way of specifying a single
> vector size. This makes it easier for later patches to use
> related_vector_mode instead.
OK.
>
Hi.
It's a small refactoring patch that I've just tested.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-11-05 Martin Liska
* symbol-summary.h: Use ggc_delete.
---
gcc/symbol-summary.h | 10
On Mon, Nov 4, 2019 at 3:49 PM Jakub Jelinek wrote:
>
> On Mon, Nov 04, 2019 at 03:23:20PM +0100, Martin Liška wrote:
> > The patch adds a new pass that identifies a series of if-elseif
> > statements and transform then into a GIMPLE switch (if possible).
> > The pass runs right after tree-ssa pas
On Mon, Nov 4, 2019 at 3:39 PM Wilco Dijkstra wrote:
>
> Hi Richard,
>
> >> > Please don't add -fcommon in lto.exp.
> >>
> >> So what is the best way to add an extra option to lto.exp?
> >> Note dg-lto-options completely overrides the options from lto.exp, so I
> >> can't
> >> use that except in
On Mon, Nov 04, 2019 at 04:10:27PM +0100, Martin Liska wrote:
>
> libsanitizer/ChangeLog:
>
> 2019-11-05 Martin Liska
>
> * all source files: Merge from upstream r375507.
> ---
> libsanitizer/BlocksRuntime/Block.h| 59 +
> libsanitizer/BlocksRuntime/Block_private.h|
On 05.11.2019 15:09, Kyrylo Tkachov wrote:
On 11/5/19 11:54 AM, Anton Youdkevitch wrote:
Kyrill,
On 05.11.2019 14:43, Kyrylo Tkachov wrote:
> Hi Andrew, Anton,
>
> On 11/1/19 11:22 PM, Andrew Pinski wrote:
>> On Fri, Nov 1, 2019 at 7:03 AM Anton Youdkevitch
>> wrote:
>>>
>>> Hello,
>>>
>>>
libsanitizer/ChangeLog:
2019-11-05 Martin Liska
* asan/asan_globals.cpp (CheckODRViolationViaIndicator): Reapply from
LOCAL_PATCHES.
(CheckODRViolationViaPoisoning): Likewise.
(RegisterGlobal): Likewise.
* asan/asan_interceptors.h
(ASAN_INTERCEPT___CXA
gcc/testsuite/ChangeLog:
2019-11-05 Martin Liska
* c-c++-common/ubsan/ptr-overflow-2.c: Update based on changed
run-time reporting format.
---
gcc/testsuite/c-c++-common/ubsan/ptr-overflow-2.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/
1 - 100 of 162 matches
Mail list logo
