Working on iterator == operator I noticed that a comparison in
_Safe_iterator was inconsistent.
* include/debug/debug.h
(_Safe_iterator<>(const _Safe_iterator<_MutableIterator,>& __x)):
Compare __x base iterator with a default initialized iterator of the
same type.
Tested under
On Wed, Jun 20, 2018 at 10:25:36AM -0400, Michael Meissner wrote:
> This code disables the automatic multilib creation unless you use the
> --with-advance-toolchain= option and the Advance Toolchain directoy has
> been modified to have the lib64/ieee128 and/or lib64/ibm128 directories for
>
Segher:
I believe I have addressed all of your concerns with the patch.
I have retested it and it looks good.
Please let me know if the patch looks OK for GCC mainline.
Carl Love
>From
All/most of the jit.dg testcases are segfaulting on cleanup of
the 2nd in-process iteration:
PATH=.:$PATH LD_LIBRARY_PATH=. LIBRARY_PATH=. \
gdb --args \
testsuite/jit/test-factorial.c.exe
Starting program:
On 06/20/2018 11:59 PM, Cesar Philippidis wrote:
> Now it follows the formula contained in
> the "CUDA Occupancy Calculator" spreadsheet that's distributed with CUDA.
Any reason we're not using the cuda runtime functions to get the
occupancy (see PR85590 - [nvptx, libgomp, openacc] Use cuda
At present, the nvptx libgomp plugin does not take into account the
amount of shared resources on GPUs (mostly shared-memory are register
usage) when selecting the default num_gangs and num_workers. In certain
situations, an OpenACC offloaded function can fail to launch if the GPU
does not have
On Wed, Jun 20, 2018 at 2:11 PM, Ian Lance Taylor wrote:
> On Wed, Jun 20, 2018 at 12:02 PM, Than McIntosh wrote:
>>
>> Please find below a patch to fix PR 86213. This changes the runtime
>> code for -fsplit-stack to move a couple of calls (getenv, etc) from
>> the routine called by __morestack
On 06/20/2018 03:14 PM, Tom de Vries wrote:
Hi,
Consider the test-case from the patch. When compiled with "-O2 -fno-dce
-fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" and
run, we get:
...
$ ./a.out
Floating point exception
...
The problem is introduced by
Hi,
Consider the test-case from the patch. When compiled with "-O2 -fno-dce
-fno-isolate-erroneous-paths-dereference -fno-tree-dce -fno-tree-vrp" and
run, we get:
...
$ ./a.out
Floating point exception
...
The problem is introduced by -ftree-tail-merge (enabled by -O2), so it
executes fine
On Wed, Jun 20, 2018 at 12:02 PM, Than McIntosh wrote:
>
> Please find below a patch to fix PR 86213. This changes the runtime
> code for -fsplit-stack to move a couple of calls (getenv, etc) from
> the routine called by __morestack to a function called on startup,
> so as to avoid having the
Construct the program-wide resource objects using placement new. This
means they have dynamic storage duration and won't be destroyed during
termination.
PR libstdc++/70966
* include/experimental/memory_resource (__resource_adaptor_imp): Add
static assertions to enforce
On 06/20/2018 10:33 AM, Nathan Sidwell wrote:
This patch fixes 85634, an ice during tsubst where we encounter an
unmarked lookup. Such lookups could be mutated by declarations added
after the template definition containing them. That would be bad.
This patch is needed on trunk, to handle
Hi all,
Please find below a patch to fix PR 86213. This changes the runtime
code for -fsplit-stack to move a couple of calls (getenv, etc) from
the routine called by __morestack to a function called on startup,
so as to avoid having the calls clobber SSE input regs.
Thanks, Than
---
On 06/20/2018 10:03 AM, Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote:
>> If it means anything, we have a significant async change that removes
>> the async_refcount field in that struct.
>
> Wasn't async_refcount removed 2 years ago?
You're right. I
On Wed, Jun 20, 2018 at 09:59:29AM -0700, Cesar Philippidis wrote:
> > I'm not entirely happy about this, it grows the structure for not just
> > OpenACC, but also OpenMP which will never use it. Are there any fields
> > not used by OpenACC? E.g. is link_key used?
> > Or could the dynamic
On 06/20/2018 09:45 AM, Jakub Jelinek wrote:
> On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote:
>> >From 53ee03231c5e6e4747b4ef01335079a2d4a98480 Mon Sep 17 00:00:00 2001
>> From: Cesar Philippidis
>> Date: Tue, 19 Jun 2018 09:33:04 -0700
>> Subject: [PATCH 7/7] runtime changes
And here's the patch for gcc-8.
nathan
--
Nathan Sidwell
2018-06-20 Nathan Sidwell
PR c++/85634 - tsubst ICE on unmarked lookup
* parser.c (cp_parser_primary_expression): Keep lookup in template.
PR c++/85634 - tsubst ICE on unmarked lookup
* g++.dg/lookup/pr85634.C: New.
Index:
On Tue, Jun 19, 2018 at 10:01:20AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in libgomp.
>
> Is it OK for trunk?
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> libgomp/
> * libgomp.h
On Tue, Jun 19, 2018 at 10:00:37AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the
> middle end.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
>
On Tue, Jun 19, 2018 at 09:59:57AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the
> Fortran FE.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
>
Committed to CVS.
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.8
diff -u -r1.8 changes.html
--- htdocs/gcc-9/changes.html 8 Jun 2018 15:28:59 - 1.8
+++
On Tue, Jun 19, 2018 at 09:58:26AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the C++ FE.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> gcc/cp/
>
On Tue, Jun 19, 2018 at 09:59:09AM -0700, Cesar Philippidis wrote:
> This patch implements the OpenACC 2.5 data clause semantics in the C FE.
>
> Is it OK for trunk?
>
> Cesar
> 2018-06-19 Chung-Lin Tang
> Thomas Schwinge
> Cesar Philippidis
>
> gcc/c/
> *
On 18/06/18 19:00 +0100, Jonathan Wakely wrote:
This issue hasn't been voted into the working draft yet, but it's been
approved by LWG and is obviously correct.
* include/std/chrono (duration, operator*, operator/, operator%): Use
const-qualified type as source type in
On Tue, Jun 19, 2018 at 4:55 PM, Paolo Carlini wrote:
> Hi,
>
> the below implements a couple of independent ideas. First, adds a const
> cp_decl_specifier_seq * parameter, similarly to grokvardecl: this way the
> function has available locations[ds_inline], locations[ds_constexpr],
>
OK.
On Wed, Jun 20, 2018 at 11:34 AM, Marek Polacek wrote:
> The recent change introducing ABSU_EXPR neglected to also handle this code
> in cxx_eval_constant_expression so this patch puts it there. Also two
> other spots for good measure. It's possible we'll find out that we need
> to fix
The recent change introducing ABSU_EXPR neglected to also handle this code
in cxx_eval_constant_expression so this patch puts it there. Also two
other spots for good measure. It's possible we'll find out that we need
to fix other spots too.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
On Wed, Jun 20, 2018 at 10:32 AM, Jakub Jelinek wrote:
> Hi!
>
> This patch fixes a regression caused by C++ delayed folding, when
> check_nonnull_arg is called, the arguments aren't folded yet and so unlike
> GCC 4.8 and earlier we don't report -Wnonnull warning unless the argument is
> literal
On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
> Main part where I still need to write ChangeLog file and
> gcc.sh needs to be moved to bash-completions project.
>
> Martin
As before, I'm not an official reviewer for it, but it touches code
that I wrote, so here goes.
Overall looks good
On 06/20/2018 09:20 AM, Jakub Jelinek wrote:
> On Wed, Jun 20, 2018 at 09:15:08AM -0600, Jeff Law wrote:
>>> Thank you for the trust. I tried to split it into multiple patches, but
>>> it wasn't readable enough.
>> Yea, it can be painful to find the right way to structure a series. In
>> fact,
On Wed, Jun 20, 2018 at 09:15:08AM -0600, Jeff Law wrote:
> > Thank you for the trust. I tried to split it into multiple patches, but
> > it wasn't readable enough.
> Yea, it can be painful to find the right way to structure a series. In
> fact, I'm going to be faced with that shortly for a
On 06/20/2018 05:25 AM, Steven Bosscher wrote:
> On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
>> On 06/05/2018 01:15 AM, marxin wrote:
>>>
>>> + The definition of "much bigger" depends on whether we are
>>> + optimizing for size or for speed. If the former, the maximum
>>> +
On 06/20/2018 02:47 AM, Martin Liška wrote:
> On 06/12/2018 10:44 PM, Jeff Law wrote:
>> On 06/05/2018 01:15 AM, marxin wrote:
>>> gcc/ChangeLog:
>>>
>>> 2018-06-07 Martin Liska
>>>
>>> * tree-switch-conversion.c (switch_conversion::collect):
>>> Record m_uniq property.
>>>
On 06/20/2018 02:38 AM, Martin Liška wrote:
> On 06/12/2018 09:41 PM, Jeff Law wrote:
>> On 06/04/2018 07:32 AM, marxin wrote:
>>> gcc/ChangeLog:
>>>
>>> 2018-06-07 Martin Liska
>>>
>>> * tree-switch-conversion.c (MAX_CASE_BIT_TESTS): Remove.
>>> (hoist_edge_and_branch_if_true):
On Wed, Jun 20, 2018 at 7:41 AM, Andreas Krebbel
wrote:
> When turning a user-defined numerical literal into an operator
> invocation the literal needs to be translated to the execution
> character set.
>
> Bootstrapped and regtested on s390x. x86_64 still running.
> Ok to apply if x86_64 is
On Mon, 2018-05-14 at 14:51 +0200, Martin Liška wrote:
> Second part refactors function from gcc.c into a new class
> option_proposer.
>
> Martin
[...snip...]
diff --git a/gcc/c-family/cppspec.c b/gcc/c-family/cppspec.c
index 1e0a8bcd294..66540239f53 100644
--- a/gcc/c-family/cppspec.c
+++
This patch fixes the tests in the testsuite that implicitly were expecting long
double to be IBM extended double to use __ibm128 if long double is configured
to be IEEE 128-bit floating point.
Note, test pr70117.c will still fail due to bugs in isnormal code generation
for __ibm128. However,
These patches fix the tests in the testsuite that check whether -mno-float128
works properly. In these cases, I explicitly run them with long double being
set to IBM extended double.
I have tested these on a little endian power8 system using two builds with long
double being set to IEEE and IBM
This patch fixes a thinko that I had that prevented negation of __ibm128 values
if long double is IEEE 128-bit binary floating point.
I have checked this on a little endian power8 system with builds where the long
double is set to IEEE and IBM 128-bit binary floating point, and it fixes some
This patch prevents the special overriding of the complex float128
multiply/divide functions from being run twice if there are clone or target
attributes. I wasn't aware that the hook used to initialize the built-in
functions is run each time you change the target options. The built-in
function
On Mon, 2018-05-14 at 14:50 +0200, Martin Liška wrote:
> First part with introduction of auto_string_vec class.
>
FWIW, I'm fine with the changes to the jit subdir, but I don't think I
have approval rights on the vec.h changes.
BTW, was the move of vec_alloc in vec.h intentional? (I take it
On Wed, 20 Jun 2018, Tom de Vries wrote:
> Hi,
>
> Consider the test-case from the patch. When compiled with "-O2
> -ftree-parallelize-loops=2 -fno-tree-dce", it ICEs like this:
> ...
> error: mismatching comparison operand types
> signed int
> unsigned int
> if (ivtmp_32 < 3)
> during GIMPLE
On Wed, 20 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> In PR65321 I've added lower_subreg call on the last argument of ASHIFT, but
> as the following testcase shows, use_narrower_mode_test has not been updated
> correspondingly to verify lower_subreg will actually work.
> On the testcase
This patch fixes the tests that use IEEE 128-bit float complex to use long
double _Complex on systems where the default is IEEE 128-bit. Due to needing
to use the same internal type for long double and __float128 (to get the
mangling correct and make templates work), you can't really use KF or KC
> There are fixes in this patch together with the new functionality -
> can you split
> those out? I'm thinking of the copy_edges_for_bb hunks as well as
> the expand_call_inline ones.
Like this?
* tree-inline.c (copy_edges_for_bb): Minor tweak.
Hi,
Consider the test-case from the patch. When compiled with "-O2
-ftree-parallelize-loops=2 -fno-tree-dce", it ICEs like this:
...
error: mismatching comparison operand types
signed int
unsigned int
if (ivtmp_32 < 3)
during GIMPLE pass: parloops
pr86097.c:4:1: internal compiler error:
On Wed, 20 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> On the second following testcase, we call vrp_meet on [1B, 2B] and ~[0B, 1B]
> and instead of computing the right ~[0B, 0B], we compute invalid ~[0B, -1B].
>
> Similarly, on the first testcase, vrp_meet on [4, 8] and ~[2, 6] computes
> ~[2, 1]
This patch fixes 85634, an ice during tsubst where we encounter an
unmarked lookup. Such lookups could be mutated by declarations added
after the template definition containing them. That would be bad.
I had originally wanted to mark these lookups once we knew we were
saving them, but this
Hi!
This patch fixes a regression caused by C++ delayed folding, when
check_nonnull_arg is called, the arguments aren't folded yet and so unlike
GCC 4.8 and earlier we don't report -Wnonnull warning unless the argument is
literal NULL without any folding.
Fixed thusly, bootstrapped/regtested on
In reworking the ordering of the 128-bit floating point modes (June 18th, 2018
patch), I missed one conversion insn. This meant the compiler would generate a
conversion to using the IF name.
I have tested this on a little endian power8 system with long double set to
IEEE 128-bit and IBM
When we started down the road of transitioning long double to IEEE 128-bit, we
thought the only way to do it was to add multi-lib support. Since then with
work underway in both GLIBC and libstdc++ we no longer feel that we need to use
multilibs.
The code as it is now for GCC 8.x and trunk will
Hi!
In PR65321 I've added lower_subreg call on the last argument of ASHIFT, but
as the following testcase shows, use_narrower_mode_test has not been updated
correspondingly to verify lower_subreg will actually work.
On the testcase validate_subreg actually is happy about it, but because op1
is
Hi!
On the second following testcase, we call vrp_meet on [1B, 2B] and ~[0B, 1B]
and instead of computing the right ~[0B, 0B], we compute invalid ~[0B, -1B].
Similarly, on the first testcase, vrp_meet on [4, 8] and ~[2, 6] computes
~[2, 1] which is invalid and is canonicalized into VARYING,
> This also passes bootstrap/regtest for me (dwarf exceptions only though).
> So is this ok for trunk instead?
>
> 2018-06-20 Jakub Jelinek
>
> * cfgrtl.c (rtl_verify_edges): Formatting fix. If bb->preds has any
> EDGE_EH edges, verify they are all EDGE_EH.
OK, thanks. I'll
I'm going to post long double transition fixes that fix most of the problems
when you switch the long double format as follow-ups to this message. A few of
the fixes to the tests were previously posted, but I've added some comments.
Here are the remaining failures in the C/C++ tests after these
On Sat, Jun 16, 2018 at 02:13:32PM +0200, Eric Botcazou wrote:
> > Now committed after successful bootstrap/regtest on x86_64-linux and
> > i686-linux. Is the cfgrtl.c change ok for trunk too?
> > http://gcc.gnu.org/ml/gcc-patches/2018-06/msg00967.html
>
> Don't we actually need to verify that
Hi,
the fix for PR target/81736 unconditionally overrules -fno-omit-frame-pointer,
including at -O0 where it is implicit. That seems brutal and unnecessary so
the attached patch reverts it at -O0 and thus fixes 135 failures in the GDB
testsuite:
=== gdb Summary ===
-# of
> Hi.
>
> This is second part of IPA summaries clean-up. It removes some not needed
> ::get_create in ipa-pure.const.c.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
OK, thanks!
Honza
> Martin
> From
On 20/06/18 11:33, Tamar Christina wrote:
Hi Kyrill,
Many thanks for the review!
The 06/20/2018 09:43, Kyrill Tkachov wrote:
Hi Tamar,
On 19/06/18 15:14, Tamar Christina wrote:
Hi All,
This patch requires https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to
work,
it has been
Hi James,
Many thanks for the review!
The 06/19/2018 22:23, James Greenhalgh wrote:
> On Tue, Jun 19, 2018 at 09:09:27AM -0500, Tamar Christina wrote:
> > Hi All,
> >
> > This changes the movmem code in AArch64 that does copy for data between 4
> > and 7
> > bytes to use the smallest possible
On 06/20/2018 02:19 PM, Tom de Vries wrote:
> Hi,
>
> for make check-fixincludes I'm seeing:
> ...
> cmp: EOF on
> /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
> *** ioLib.h 2018-06-20 14:14:40.035956737 +0200
> ---
Hi,
for make check-fixincludes I'm seeing:
...
cmp: EOF on
/home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
*** ioLib.h 2018-06-20 14:14:40.035956737 +0200
--- /home/vries/gcc_versions/devel/src/fixincludes/tests/base/ioLib.h
2018-06-20 14:14:28.183925247 +0200
Hi.
This is second part of IPA summaries clean-up. It removes some not needed
::get_create in ipa-pure.const.c.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From 932bcf9d0247189700edf86e2b07301ba1fa1f87 Mon Sep 17 00:00:00 2001
From:
PING^1 (for the whole series).
On 05/14/2018 02:41 PM, Martin Liška wrote:
> On 04/26/2018 01:13 AM, David Malcolm wrote:
>> [moving from gcc to gcc-patches mailing list]
>>
>> On Wed, 2018-04-25 at 15:12 +0200, Martin Liška wrote:
>>> On 04/24/2018 06:27 PM, David Malcolm wrote:
On Tue,
PING^1
On 05/16/2018 01:53 PM, Martin Liška wrote:
> On 12/21/2017 10:13 AM, Martin Liška wrote:
>> On 12/20/2017 06:45 PM, Jakub Jelinek wrote:
>>> Another thing is that the "/" in there is wrong, so
>>> const char dir_separator_str[] = { DIR_SEPARATOR, '\0' };
>>> char *b = concat
When turning a user-defined numerical literal into an operator
invocation the literal needs to be translated to the execution
character set.
Bootstrapped and regtested on s390x. x86_64 still running.
Ok to apply if x86_64 is clean?
Bye,
-Andreas-
gcc/cp/ChangeLog:
2018-06-20 Andreas Krebbel
On Tue, Jun 12, 2018 at 10:44 PM, Jeff Law wrote:
> On 06/05/2018 01:15 AM, marxin wrote:
>>
>> + The definition of "much bigger" depends on whether we are
>> + optimizing for size or for speed. If the former, the maximum
>> + ratio range/count = 3, because this was found to be the
The main over-widening patch can introduce quite a few extra casts,
and in many cases those casts simply "tap into" an intermediate
point in an existing extension. E.g. if we have:
unsigned char a;
int ax = (int) a;
and a later operation using ax is shortened to "unsigned short",
we
This patch is the main part of PR85694. The aim is to recognise at least:
signed char *a, *b, *c;
...
for (int i = 0; i < 2048; i++)
c[i] = (a[i] + b[i]) >> 1;
as an over-widening pattern, since the addition and shift can be done
on shorts rather than ints. However, it ended up being
Hi Kyrill,
Many thanks for the review!
The 06/20/2018 09:43, Kyrill Tkachov wrote:
> Hi Tamar,
>
> On 19/06/18 15:14, Tamar Christina wrote:
> > Hi All,
> >
> > This patch requires
> > https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to work,
> > it has been accepted once already but
vect_recog_rotate_pattern had code to prevent operations
on invariants being vectorised unnecessarily:
if (dt == vect_external_def
&& TREE_CODE (oprnd1) == SSA_NAME
&& is_a (vinfo))
{
struct loop *loop = as_a (vinfo)->loop;
ext_def = loop_preheader_edge (loop);
This patch adds helper functions for detecting widened operations and
generalises the existing code to handle more cases.
One of the main changes is to recognise multi-stage type conversions,
which are possible even in the original IR and can also occur as a
result of earlier pattern matching
Although the first pattern match wins in the sense that no later
function can match the *old* gimple statement, it still seems worth
letting them match the *new* gimple statements, just like we would if
the original IR had included that sequence from the outset.
This is mostly true after the
Richard Biener writes:
> On Mon, Jun 18, 2018 at 5:04 PM Richard Sandiford
> wrote:
>>
>> When following the definitions of SSA names, some recognisers
>> already cope with statements that have been replaced by patterns.
>> This patch makes that happen automatically for users of
>>
Hi Kyrill,
Many thanks for the review!
The 06/19/2018 16:47, Kyrill Tkachov wrote:
> Hi Tamar,
>
> On 19/06/18 15:07, Tamar Christina wrote:
> > Hi All,
> >
> > This fixes a regression where we don't have an instruction for pre Armv8.2-a
> > to do a move of an fp16 value from a GP reg to a SIMD
On 06/19/2018 09:11 PM, James Greenhalgh wrote:
On Mon, Jun 18, 2018 at 08:43:04AM -0500, Siddhesh Poyarekar wrote:
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Is the second
On 06/12/2018 10:44 PM, Jeff Law wrote:
> On 06/05/2018 01:15 AM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2018-06-07 Martin Liska
>>
>> * tree-switch-conversion.c (switch_conversion::collect):
>> Record m_uniq property.
>> (switch_conversion::expand): Bail out for special
Hi Tamar,
On 19/06/18 15:14, Tamar Christina wrote:
Hi All,
This patch requires https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01145.html to
work,
it has been accepted once already but caused a regression on certain
configuratoins.
I am re-submitting it with the required mid-end change and
On 06/12/2018 09:41 PM, Jeff Law wrote:
> On 06/04/2018 07:32 AM, marxin wrote:
>> gcc/ChangeLog:
>>
>> 2018-06-07 Martin Liska
>>
>> * tree-switch-conversion.c (MAX_CASE_BIT_TESTS): Remove.
>> (hoist_edge_and_branch_if_true): Likewise.
>> (expand_switch_using_bit_tests_p):
On Wed, Jun 20, 2018 at 10:03 AM Martin Liška wrote:
>
> On 06/13/2018 01:21 PM, Richard Biener wrote:
> > On Fri, Jun 8, 2018 at 1:10 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> Second follow-up patch uses flags_from_decl_or_type in LTO merging
> >> of declarations. Hope it's more cleaner
Hi Andre,
On 18/06/18 10:38, Andre Simoes Dias Vieira wrote:
Hi,
This patch teaches the AArch64 backend that the AESE and AESD unspecs are
commutative (which correspond to the vaeseq_u8 and vaesdq_u8 intrinsics). This
improves register allocation around their corresponding instructions
Richard Biener writes:
> On Mon, Jun 18, 2018 at 4:53 PM Richard Sandiford
> wrote:
>>
>> A pattern's PATTERN_DEF_SEQ was attached to both the original statement
>> and the main pattern statement, which made it harder to update later.
>> This patch attaches it to just the original statement. In
On Wed, Jun 20, 2018 at 12:25 AM Eric Botcazou wrote:
>
> Hi,
>
> the Ada compiler uses small functions defined in its runtime to implement
> various intrinsic operations and it always inlines them, even at -O0. But it
> doesn't want location information from the runtime files to appear in the
>
On 06/13/2018 01:21 PM, Richard Biener wrote:
> On Fri, Jun 8, 2018 at 1:10 PM Martin Liška wrote:
>>
>> Hi.
>>
>> Second follow-up patch uses flags_from_decl_or_type in LTO merging
>> of declarations. Hope it's more cleaner approach.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives
On Tue, 19 Jun 2018, Cary Coutant wrote:
> > On testcases like that from PR60243 CFG build is dominated by
> > assign_discriminators because it expands locations again and again
> > and this got more expensive over the time.
> >
> > Cary - can you explain the overall logic of
85 matches
Mail list logo
