On Mon, Jan 8, 2018 at 11:48 PM, Thomas Koenig wrote:
> Hi Janne,
>
>> If I understand it correctly, in the library the back argument is
>> always a LOGICAL(kind=4). But in the frontend, the back argument is
>> coerced to gfc_default_logical_kind. So this doesn't work if one uses
>> the -fdefault-
On 18 November 2017 at 22:13, Nathan Rossi wrote:
> On 18 November 2017 at 04:25, Jeff Law wrote:
>> On 11/15/2017 11:58 PM, Nathan Rossi wrote:
>>> Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and
>>> use the default.
>>>
>>> This resolves issues associated with the use of
Hi,
this patch fixes ICE in somewhat rare situation when thunk is inlined and
later promoted into a comdat group. The reduced testcase in the PR no longer
reproduces as it relies on quite fragile inlining decisions, but it would
be nice to have re-reduced one.
Bootstrapped/regtested x86_64-linux,
Hi,
as noticed by Richi, I have accidentally comitted a hack I was experimenting
with.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* ipa-inline.c (edge_badness): Revert accidental checkin.
Index: ipa-inline.c
===
-
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-01-09 Richard Biener
PR tree-optimization/83572
* graphite.c: Include cfganal.h.
(graphite_transform_loops): Connect infinite loops to exit
and remove fake edges at the end.
*
Ping,
Is the fix ok for trunk?
Thanks,
Tamar
> -Original Message-
> From: Christophe Lyon [mailto:christophe.l...@linaro.org]
> Sent: Thursday, December 21, 2017 21:39
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.co
On 09/01/18 10:16, Tamar Christina wrote:
Ping,
Is the fix ok for trunk?
Hi Tamar,
Yes, thanks for pinging this.
I had reviewed it before the break but had forgotten to send an ok out.
Please commit.
Kyrill
Thanks,
Tamar
> -Original Message-
> From: Christophe Lyon [mailto:chris
On 08/01/18 16:01, Bill Schmidt wrote:
> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists)
> wrote:
>>
>> On 08/01/18 02:20, Bill Schmidt wrote:
>>> Hi Richard,
>>>
>>> Unfortunately, I don't see any way that this will be useful for the ppc
>>> targets. We don't
>>> have a way to force resol
Hi,
gather instructions are rather hard to implement in hardware and except for
skylake+ chips (i.e. haswell and Zen) they seems to be rather slow; to the
degree I did not find real world loop where gather would help on Zen.
This patch simply adds a knob to disable its autogeneration (builtin still
On Tue, Jan 9, 2018 at 11:26 AM, Jan Hubicka wrote:
> Hi,
> gather instructions are rather hard to implement in hardware and except for
> skylake+ chips (i.e. haswell and Zen) they seems to be rather slow; to the
> degree I did not find real world loop where gather would help on Zen.
> This patch
Hi All,
This patch makes the Dot Product extension mandatory on Armv8.4-A.
Regtested on aarch64-none-elf and no regressions.
gcc/
2018-01-09 Tamar Christina
* config/aarch64/aarch64.h
(AARCH64_FL_FOR_ARCH8_4): Add AARCH64_FL_DOTPROD.
gcc/testsuite/
2018-01-09 Tamar Christi
Hi.
Folowing static assert is added as we may potentially adjust
ASAN_SHADOW_GRANULARITY
(via ASAN_SHADOW_SHIFT). The assert ensures stack variables will have sufficient
alignment.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/Chan
On 05/01/18 13:08, Alexander Monakov wrote:
> On Fri, 5 Jan 2018, Richard Earnshaw (lists) wrote:
>> This is quite tricky. For ARM we have to have a speculated load.
>
> Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence
> wouldn't work (applying CSEL to the address rathe
On Tue, Jan 09, 2018 at 11:41:17AM +0100, Martin Liška wrote:
> Folowing static assert is added as we may potentially adjust
> ASAN_SHADOW_GRANULARITY
> (via ASAN_SHADOW_SHIFT). The assert ensures stack variables will have
> sufficient
> alignment.
>
> Patch can bootstrap on ppc64le-redhat-linux
> On Tue, Jan 9, 2018 at 11:26 AM, Jan Hubicka wrote:
> > Hi,
> > gather instructions are rather hard to implement in hardware and except for
> > skylake+ chips (i.e. haswell and Zen) they seems to be rather slow; to the
> > degree I did not find real world loop where gather would help on Zen.
> >
On 08.01.2018 18:39, Denis Chertykov wrote:
2018-01-08 20:19 GMT+04:00 Georg-Johann Lay :
This PR skips saving of any registers in main.
Attribute OS_main can do this as well, however we can just drop
any saves / restores in all optimized compilation -- not even
the test suite needs these saves
Hello.
In current stage1 Honza spent a significant amount of time to improve profiling
infrastructure.
New classes profile_count and profile_probability have been added and we hope
the profile
is maintained more sensitively among various optimization passes.
My patch series makes adjustments to
First patch from the series simplifies how we dump and post-process statistics.
I switched to use ';' separated values instead of a complex human language.
Changes
to analyze_brprob.py add possibility to filter out dominant edges. Having that
one
can see how predictor values change if a dominant
Second patch cleans up predictors that do not use a value from predict.def,
but their value is derived from e.g. number of iterations of a loop.
These predictors have set probability to PROB_UNINITIALIZED and
analyze_branch.py
does not compare statistics to values defined in predict.def.
The patc
On Tue, Jan 9, 2018 at 11:58 AM, Jan Hubicka wrote:
>> On Tue, Jan 9, 2018 at 11:26 AM, Jan Hubicka wrote:
>> > Hi,
>> > gather instructions are rather hard to implement in hardware and except for
>> > skylake+ chips (i.e. haswell and Zen) they seems to be rather slow; to the
>> > degree I did no
On Mon, 2018-01-08 at 19:08 +0100, Jakub Jelinek wrote:
> On Mon, Jan 08, 2018 at 01:02:37PM -0500, David Malcolm wrote:
> > Thanks Nathan and Jakub: a quick smoketest using TREE_LANG_FLAG_0
> > worked, and fixes this issue.
> >
> > However, should I be using a TREE_LANG_FLAG for something that's
As mentioned in https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01575.html ,
the scatter handling in vectorizable_store seems to be dead code at the
moment. Enabling it with the vect_analyze_data_ref_access part of
that patch triggered an ICE in the avx512f-scatter-*.c tests (which
previously didn't
Third part changes predictors values:
1) PRED_LOOP_EXIT: no dominant branch; value simply taken from statistics
2) PRED_LOOP_EXIT_WITH_RECURSION: there are 4 dominant edges; value taken w/o
these edges
3) PRED_LOOP_EXTRA_EXIT: there's one really dominant edge; value taken w/o the
edge; note that
On 05/01/18 17:24, Jeff Law wrote:
> On 01/04/2018 06:58 AM, Richard Earnshaw wrote:
>>
>> Recently, Google Project Zero disclosed several classes of attack
>> against speculative execution. One of these, known as variant-1
>> (CVE-2017-5753), allows explicit bounds checks to be bypassed under
>> s
On Tue, Jan 9, 2018 at 12:34 PM, Richard Sandiford
wrote:
> As mentioned in https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01575.html ,
> the scatter handling in vectorizable_store seems to be dead code at the
> moment. Enabling it with the vect_analyze_data_ref_access part of
> that patch trigger
These predictors are in my opinion not reliable and thus I decided to remove
them:
1) PRED_NEGATIVE_RETURN: probability is ~51%
2) PRED_RECURSIVE_CALL: there are 2 dominant edges that influence value to 63%;
w/o these edges it goes down to 52%
3) PRED_POLYMORPHIC_CALL: having very low coverage, p
Last patch from the series it clean up of test-suite.
Martin
>From e76a4544e236d7d586380f33e20431f854436ce4 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 9 Jan 2018 10:52:36 +0100
Subject: [PATCH 5/5] Fix test-suite fallout.
gcc/testsuite/ChangeLog:
2018-01-09 Martin Liska
* gcc.dg/pred
On 01/09/2018 11:47 AM, Jakub Jelinek wrote:
> On Tue, Jan 09, 2018 at 11:41:17AM +0100, Martin Liška wrote:
>> Folowing static assert is added as we may potentially adjust
>> ASAN_SHADOW_GRANULARITY
>> (via ASAN_SHADOW_SHIFT). The assert ensures stack variables will have
>> sufficient
>> alignme
On Mon, 2018-01-08 at 16:59 -0500, Jason Merrill wrote:
> On 01/08/2018 04:49 PM, Jason Merrill wrote:
> > On 01/08/2018 04:01 PM, David Malcolm wrote:
> > > On Fri, 2018-01-05 at 15:29 -0500, Jason Merrill wrote:
> > > >
> > > > I'd rather handle location wrappers separately, and abort if
> > > >
This fixes another case of bogus initial schedule generated by GRAPHITE.
Rather than adding my own RPO computation routine I am swapping the
edges in the edge vector containing loop exits... not exactly nice
but sufficient.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
This patch fixes various parts of the code to use a larger type than
int for the character length. Depending on the situation,
HOST_WIDE_INT, size_t, or gfc_charlen_t is appropriate.
Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu, Ok for trunk?
gcc/fortran/ChangeLog:
2018-01-09 Janne Bl
Hello,
The AP4 tool team have agreed with this change and are willing to update their
tool.
So I would like to drop this patch.
Best Regards,
Sebastian
-Original Message-
From: Sebastian Perta [mailto:sebastian.pe...@renesas.com]
Sent: 05 January 2018 13:46
To: 'Oleg Endo' ; gcc-patch
Hello,
So I would like to drop this patch.
Oleg Endo has proposed a better solution:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00305.html
Best Regards,
Sebastian
-Original Message-
From: Sebastian Perta [mailto:sebastian.pe...@renesas.com]
Sent: 15 December 2017 09:25
To: 'gcc-patch
Hello.
This is patch for i586 bootstrap that is triggered by bug in detail described
in the PR.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2018-01-09 Martin Liska
PR bootstrap/82831
* basic-block.h
On Thu, Jan 04, 2018 at 11:27:56AM +, Richard Sandiford wrote:
> Ping**2
This is OK.
It took me a while to get the hang of the interface - a worked example
in the comment in vec-perm-indices.c would probably have been helpful.
It took until your code for REV for this to really make sense to m
On Thu, Jan 04, 2018 at 06:15:58PM +, Richard Sandiford wrote:
> The aarch64_legitimate_constant_p tests for HIGH and CONST seem
> to be the wrong way round: (high (const ...)) is valid rtl that
> could be passed in, but (const (high ...)) isn't. As it stands,
> we disallow anchor+offset but a
Segher Boessenkool wrote:
> On Mon, Jan 08, 2018 at 0:25:47PM +, Wilco Dijkstra wrote:
>> > Always pairing two registers together *also* degrades code quality.
>>
>> No, while it's not optimal, it means smaller code and fewer memory accesses.
>
> It means you execute *more* memory accesses. A
On 7 January 2018 at 12:28, Prathamesh Kulkarni
wrote:
> On 5 January 2018 at 00:20, Jeff Law wrote:
>> On 01/03/2018 12:08 AM, Prathamesh Kulkarni wrote:
>>> On 3 January 2018 at 12:33, Prathamesh Kulkarni
>>> wrote:
On 2 January 2018 at 17:49, Jakub Jelinek wrote:
> On Tue, Jan 02, 2
On 3 January 2018 at 18:58, Jan Hubicka wrote:
>
>> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
>> index 09ca3590039..0406d5588d2 100644
>> --- a/gcc/ipa-pure-const.c
>> +++ b/gcc/ipa-pure-const.c
>> @@ -910,7 +910,8 @@ malloc_candidate_p (function *fun, bool ipa)
>> #define DUMP_AND
On 08/01/18 22:31 +0100, François Dumont wrote:
Hi
Bug confirmed, limited to range insertion on unordered_set and
unordered_map.
I had to specialize _M_insert_range for those containers. Now this
method maintains the theoretical number of elements to insert which is
used only if an
On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote:
> > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence
> > wouldn't work (applying CSEL to the address rather than loaded value), and
> > if it wouldn't, then ARM-specific lowering of the builtin can handle that
> > anyhow
On 09/01/18 13:27, Alexander Monakov wrote:
> On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote:
>> > Sorry, I don't follow. On ARM, it is surprising that CSEL-CSDB-LDR sequence
>> > wouldn't work (applying CSEL to the address rather than loaded value), and
>> > if it wouldn't, then ARM-specific l
On 07/01/18 20:55 +, Mike Crowe wrote:
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 chang
Hi,
Looks like this is the last chance for this patch to make GCC 8
so I would like to ping it one last time:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01451.html
It has been reviewed (with thanks) by David Malcolm[1] and
Martin Sebor[2]. Their concerns are addressed in the latest
revision o
On 07/01/18 20:55 +, 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 | 36
On Tue, 9 Jan 2018, Richard Earnshaw (lists) wrote:
> Read condition 1 i) again.
>
>
> i) the conditional select instruction has a register data dependency on
> a load R1, that has been executed speculatively, for one of its input
> registers, and
Sorry - I don't know how I missed that. I unders
On 01/09/2018 06:53 AM, David Malcolm wrote:
+case NON_LVALUE_EXPR:
+case VIEW_CONVERT_EXPR:
+ {
+ /* Handle location wrappers by substituting the wrapped node
+first,*then* reusing the resulting type. Doing the type
+first ensures that we handle te
On Tue, Jan 09, 2018 at 09:36:58AM -0500, Jason Merrill wrote:
> On 01/09/2018 06:53 AM, David Malcolm wrote:
> > +case NON_LVALUE_EXPR:
> > +case VIEW_CONVERT_EXPR:
> > + {
> > + /* Handle location wrappers by substituting the wrapped node
> > +first,*then* reusing the resul
Richard Biener writes:
> On Tue, Nov 7, 2017 at 7:04 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Fri, Nov 3, 2017 at 5:32 PM, Richard Sandiford
>>> wrote:
A general TARGET_MEM_REF is:
BASE + STEP * INDEX + INDEX2 + OFFSET
After classifying the ad
On 07/01/18 20:55 +, Mike Crowe wrote:
This patch series was originally submitted back in September at
https://gcc.gnu.org/ml/libstdc++/2017-09/msg00083.html which ended up
as https://patchwork.ozlabs.org/cover/817379/ . The patches received
no comments at all, which may mean that they are pe
On 09/20/2017 05:00 PM, Jeff Law wrote:
> On 09/20/2017 01:24 AM, Martin Liška wrote:
>
>>
>> Hello.
>>
>> Thank you Jeff for very verbose explanation what's happening. I'm planning
>> to do
>> follow-up of this patch that will include clustering for bit-tests and jump
>> tables.
>> Maybe that w
Hello,
In recent versions of GCC the define_expand "movsicc" has stopped being used
by GCC (approx. 4.7.x/4.8.x onwards)
The reason for this is that the first operand of if_then_else has SI mode
and it shouldn't have. If we take a look at movsicc for all other targets we
see this is true.
The fix
On Tue, Jan 09, 2018 at 12:23:42PM +, Wilco Dijkstra wrote:
> Segher Boessenkool wrote:
> > On Mon, Jan 08, 2018 at 0:25:47PM +, Wilco Dijkstra wrote:
> >> > Always pairing two registers together *also* degrades code quality.
> >>
> >> No, while it's not optimal, it means smaller code and
On 01/09/2018 06:37 AM, David Malcolm wrote:
+ /* We should only be adding wrappers for constants and for decls,
+ or for some exceptional tree nodes (e.g. BASELINK in the C++ FE). */
+ gcc_assert (CONSTANT_CLASS_P (expr)
+ || DECL_P (expr)
+ || EXCEPTIONAL_CLASS_P
On 04/01/18 11:22 +0100, Juraj Oršulić wrote:
Hi Jonathan (and the libstdc++ list). Can we revive this? I sent the
patches for improving the smart pointer pretty printers in March. They
haven't been reviewed.
Thanks for the reminder. I'm testing the attached patch, which has
been rebased on tru
On 09/01/18 14:59 +, Jonathan Wakely wrote:
On 04/01/18 11:22 +0100, Juraj Oršulić wrote:
Hi Jonathan (and the libstdc++ list). Can we revive this? I sent the
patches for improving the smart pointer pretty printers in March. They
haven't been reviewed.
Thanks for the reminder. I'm testing
> Third part changes predictors values:
>
> 1) PRED_LOOP_EXIT: no dominant branch; value simply taken from statistics
> 2) PRED_LOOP_EXIT_WITH_RECURSION: there are 4 dominant edges; value taken w/o
> these edges
> 3) PRED_LOOP_EXTRA_EXIT: there's one really dominant edge; value taken w/o
> the e
> Hello.
>
> This is patch for i586 bootstrap that is triggered by bug in detail described
> in the PR.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-01-09 Martin Liska
>
> PR bootstrap/8
Richard Biener writes:
> On Mon, Nov 20, 2017 at 12:31 PM, Bin.Cheng wrote:
>> On Fri, Nov 17, 2017 at 3:03 PM, Richard Sandiford
>> wrote:
>>> ivopts previously treated pointer arguments to internal functions
>>> like IFN_MASK_LOAD and IFN_MASK_STORE as normal gimple values.
>>> This patch make
On 05/01/18 17:26, Jeff Law wrote:
> On 01/04/2018 11:20 AM, Joseph Myers wrote:
>> On Thu, 4 Jan 2018, Richard Earnshaw wrote:
>>
>>> 1 - generic modifications to GCC providing the builtin function for all
>>> architectures and expanding to an implementation that gives the
>>> logical beha
On Mon, Jan 8, 2018 at 6:55 PM, Jakub Jelinek wrote:
> The assert there assumes we never evaluate a statement list to
> DEBUG_BEGIN_STMT, but it breaks appart when a BIND_EXPR with a typedef in it
> has some DEBUG_BEGIN_STMTs in it and nothing else (without -g it is just
> empty STATEMENT_LIST ins
Richard Biener wrote:
>On Thu, Jan 4, 2018 at 10:27 PM, Marc Glisse wrote:
>> I don't understand how the check you added helps.
It simply blocks the transformation for infinity:
+ (if (!REAL_VALUE_ISINF (TREE_REAL_CST (@0)))
+ (switch
+ (if (real_less (&dconst0, TREE_REAL_CST_P
Possible ping: wasn't sure whether this one needed more work or whether
it was OK to go in. I've attached the patch with the improved comment
above early_remat::emit_copy_before.
Thanks,
Richard
Richard Sandiford writes:
> Jeff Law writes:
>> On 11/17/2017 08:58 AM, Richard Sandiford wrote:
>>
On 02/03/17 19:10 +0100, Juraj Oršulić wrote:
On Fri, Feb 24, 2017 at 5:36 PM, Jonathan Wakely wrote:
For a patch this size we do, so I'm not going to look at your patch.
It will probably be simpler to just do it myself, and not worry about
paperwork.
If you want to contribue in future then pl
Ping
Richard Sandiford writes:
> Richard Biener writes:
>> On Mon, Nov 20, 2017 at 1:54 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Fri, Nov 17, 2017 at 5:53 PM, Richard Sandiford
wrote:
> This patch adds support for in-order floating-point addition reductions,
Hi
This patch is only adding the missing LTGT to plug the ICE. This is a
backport to r255625 of trunk.
Testing done: Checked for regressions on bootstrapped
aarch64-none-linux-gnu and added a new compile time test case that gives
out LTGT to make sure it doesn't ICE.
Is this ok for trunk?
On Tue, Jan 09, 2018 at 10:30:31AM -0500, Jason Merrill wrote:
> On Mon, Jan 8, 2018 at 6:55 PM, Jakub Jelinek wrote:
> > The assert there assumes we never evaluate a statement list to
> > DEBUG_BEGIN_STMT, but it breaks appart when a BIND_EXPR with a typedef in it
> > has some DEBUG_BEGIN_STMTs i
James Greenhalgh writes:
> On Thu, Jan 04, 2018 at 11:27:56AM +, Richard Sandiford wrote:
>> Ping**2
>
> This is OK.
Thanks.
> It took me a while to get the hang of the interface - a worked example
> in the comment in vec-perm-indices.c would probably have been helpful.
> It took until your
Hi!
On Mon, Jan 08, 2018 at 08:41:55PM +0100, Uros Bizjak wrote:
> Attached patch corrects wrong mode argument in the call to
> force_to_mode call for ASHIFT operator. The patch uses "mode" mode,
> the same as for all binop and unop operators in the force_int_to_mode
> function.
>
> Also, the unp
On Jan 9, 2018, at 4:21 AM, Richard Earnshaw (lists)
wrote:
>
> On 08/01/18 16:01, Bill Schmidt wrote:
>> On Jan 8, 2018, at 8:06 AM, Richard Earnshaw (lists)
>> wrote:
>>>
>>> On 08/01/18 02:20, Bill Schmidt wrote:
Hi Richard,
Unfortunately, I don't see any way that this will
On Mon, Jan 08, 2018 at 06:51:06PM -0800, Jerry DeLisle wrote:
> On 01/08/2018 04:58 PM, Steve Kargl wrote:
> >
> > Boostrapped and regression tested on x86_64-*-freebsd.
> > OK to commit?
> >
>
> Yes, Looks good Steve. So all we need is a run test with actual =lib case.
>
Just realized that
This patch by Cherry Zhang fixes a case in the Go frontend that was
using std::unodered_map where it should use the macro Unordered_map
for more portability. Bootstrapped on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
Richard Earnshaw wrote:
> Let me give an example, we use the generic code expansion if we
> encounter the builtin when generating code for Thumb on pre-ARMv7
> devices. We don't have instructions in 'thumb1' to guard against
> speculation and we really want to warn users that they've done this
On Wed, Jan 03, 2018 at 05:21:27PM +, Michael Collison wrote:
> Hi all,
>
> This patch adds two new command line options for the legacy cryptographic
> extensions AES (+aes) and SHA-1/SHA-2 (+sha2). Backward compatibility is
> retained by modifying the +crypto feature modifier to enable +aes a
On 09/01/18 17:36, Bernd Edlinger wrote:
> Richard Earnshaw wrote:
> > Let me give an example, we use the generic code expansion if we
> > encounter the builtin when generating code for Thumb on pre-ARMv7
> > devices. We don't have instructions in 'thumb1' to guard against
> > speculation and
On Wed, Jan 03, 2018 at 05:25:17PM +, Michael Collison wrote:
> Hi all,
>
> This patch adds support for the Arm architecture v8.4. A new command line
> option, -march=armv8.4-a, is added as well as documentation.
>
> Bootstrapped on aarch64-none-elf. Tested with new binutils and verified all
On Tuesday 09 January 2018 at 13:50:54 +, Jonathan Wakely wrote:
> On 07/01/18 20:55 +, Mike Crowe wrote:
> > 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 gett
On Wed, Jan 03, 2018 at 05:25:57PM +, Michael Collison wrote:
> Hi All,
>
> This patch adds support for the SM3/SM4 cryptographic instructions added in
> Armv8.4-a. Support for the new instructions is in the form of new ACLE
> intrinsics. A new command line feature modifier, +sm4, is added to
On 01/09/18 18:50, Richard Earnshaw (lists) wrote:
> On 09/01/18 17:36, Bernd Edlinger wrote:
>> Richard Earnshaw wrote:
>> > Let me give an example, we use the generic code expansion if we
>> > encounter the builtin when generating code for Thumb on pre-ARMv7
>> > devices. We don't have ins
On 09/01/18 17:57, Bernd Edlinger wrote:
> On 01/09/18 18:50, Richard Earnshaw (lists) wrote:
>> On 09/01/18 17:36, Bernd Edlinger wrote:
>>> Richard Earnshaw wrote:
>>> > Let me give an example, we use the generic code expansion if we
>>> > encounter the builtin when generating code for Thumb
On Wed, Jan 03, 2018 at 05:30:33PM +, Michael Collison wrote:
> Hi All,
>
> This patch adds support for the SHA-512 and SHA-3 instructions added in
> Armv8.4-a. Support for the new instructions is in the form of new ACLE
> intrinsics. A new command line feature modifier, +sha3, is added to ena
On Tue, Jan 09, 2018 at 10:36:23AM +, Tamar Christina wrote:
> Hi All,
>
> This patch makes the Dot Product extension mandatory on Armv8.4-A.
>
> Regtested on aarch64-none-elf and no regressions.
OK.
Thanks,
James
> gcc/
> 2018-01-09 Tamar Christina
>
> * config/aarch64/aarch64.h
On 01/07/2018 12:32 AM, Jeff Law wrote:
On 01/06/2018 01:01 AM, Jeff Law wrote:
On 01/05/2018 01:59 PM, Aldy Hernandez wrote:
I went ahead and fixed up the empty block test, and the invalidation
code above. Bootstrapped and regression tested on x86_64. Installing
on the trunk.
Thanks.
On 09/01/18 18:00, Richard Earnshaw (lists) wrote:
> On 09/01/18 17:57, Bernd Edlinger wrote:
>> On 01/09/18 18:50, Richard Earnshaw (lists) wrote:
>>> On 09/01/18 17:36, Bernd Edlinger wrote:
Richard Earnshaw wrote:
> Let me give an example, we use the generic code expansion if we
On 01/09/18 19:08, Richard Earnshaw (lists) wrote:
>
> But we probably don't need to.
>
> int x __attribute__((mode(TI))) = 0;
>
> $ arm-none-elf-gcc timode.c
>
> /tmp/ti.c:1:1: error: unable to emulate ‘TI’
> int x __attribute__((mode(TI))) = 0;
> ^~~
>
Yes, good, then you should proba
PR83399 shows a problem where we emit an altivec load using a builtin
that forces us to use a specific altivec load pattern. The generated
rtl pattern has a use of sfp (frame pointer) and during LRA, we eliminate
it's use to the sp (lra-eliminations.c:process_insn_for_elimination).
During this pro
I used a generic statement that applied to all five patches. The patch was
bootstrapped and the test suite executed along with the other patches together.
As you correctly point out there are no new instruction, but backward
compatibility was tested as existing patterns had their pattern conditi
Patch updated per Richard's comments. Ok for trunk?
-Original Message-
From: Richard Sandiford [mailto:richard.sandif...@linaro.org]
Sent: Thursday, January 4, 2018 8:02 AM
To: Michael Collison
Cc: GCC Patches ; nd
Subject: Re: [PATCH 5/5][AArch64] fp16fml support
Hi Michael,
Not a re
On 01/09/2018 07:43 AM, Martin Liška wrote:
> On 09/20/2017 05:00 PM, Jeff Law wrote:
>> On 09/20/2017 01:24 AM, Martin Liška wrote:
>>
>>>
>>> Hello.
>>>
>>> Thank you Jeff for very verbose explanation what's happening. I'm planning
>>> to do
>>> follow-up of this patch that will include clusteri
On Tue, 2018-01-09 at 15:39 +0100, Jakub Jelinek wrote:
> On Tue, Jan 09, 2018 at 09:36:58AM -0500, Jason Merrill wrote:
> > On 01/09/2018 06:53 AM, David Malcolm wrote:
> > > +case NON_LVALUE_EXPR:
> > > +case VIEW_CONVERT_EXPR:
> > > + {
> > > + /* Handle location wrappers by substituti
This patch generalises various places that used hwi rtx accessors
so that they can handle poly_ints instead. Earlier patches did
this while updating interfaces; this patch just mops up some
left-over pieces that weren't necessary to make things compile,
but that still make sense.
In many cases th
This patch generalises various places that used hwi tree accessors
so that they can handle poly_ints instead. Earlier patches did
this while updating interfaces; this patch just mops up some
left-over pieces that weren't necessary to make things compile,
but that still make sense.
In many cases t
On 01/09/2018 08:34 AM, Richard Sandiford wrote:
> Possible ping: wasn't sure whether this one needed more work or whether
> it was OK to go in. I've attached the patch with the improved comment
> above early_remat::emit_copy_before.
>
You answered all the questions I had. I should have explicit
On 09/01/18 15:02 +, Jonathan Wakely wrote:
On 09/01/18 14:59 +, Jonathan Wakely wrote:
On 04/01/18 11:22 +0100, Juraj Oršulić wrote:
Hi Jonathan (and the libstdc++ list). Can we revive this? I sent the
patches for improving the smart pointer pretty printers in March. They
haven't been
On 01/07/2018 05:29 PM, H.J. Lu wrote:
> On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>>> execution
>>> vulnerabilities on x86 processors identified by CVE-2017-5715, aka Spectre
On 01/08/2018 03:01 AM, Martin Liška wrote:
> On 01/08/2018 01:29 AM, H.J. Lu wrote:
>> 1. They need to be backportable to GCC 7/6/5/4.x.
>
> I must admit this is very important constrain. To be honest, we're planning
> to backport the patchset to GCC 4.3.
Red Hat would likely be backporting a way
On 01/08/2018 03:10 AM, Martin Liška wrote:
> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>> +static void
>> +output_indirect_thunk_function (bool need_bnd_p, int regno)
>> +{
>> + char name[32];
>> + tree decl;
>> +
>> + /* Create __x86_indirect_thunk/__x86_indirect_thunk_bnd. */
>> + indirect_thu
On Tue, Jan 9, 2018 at 10:55 AM, Jeff Law wrote:
> On 01/08/2018 03:10 AM, Martin Liška wrote:
>> On 01/07/2018 11:59 PM, H.J. Lu wrote:
>>> +static void
>>> +output_indirect_thunk_function (bool need_bnd_p, int regno)
>>> +{
>>> + char name[32];
>>> + tree decl;
>>> +
>>> + /* Create __x86_ind
On Tue, Jan 9, 2018 at 10:52 AM, Jeff Law wrote:
> On 01/07/2018 05:29 PM, H.J. Lu wrote:
>> On Sun, Jan 7, 2018 at 3:36 PM, Jeff Law wrote:
>>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
This set of patches for GCC 8 mitigates variant #2 of the speculative
execution
vulnerabilities o
On 01/09/2018 01:35 PM, David Malcolm wrote:
On Tue, 2018-01-09 at 15:39 +0100, Jakub Jelinek wrote:
On Tue, Jan 09, 2018 at 09:36:58AM -0500, Jason Merrill wrote:
On 01/09/2018 06:53 AM, David Malcolm wrote:
+case NON_LVALUE_EXPR:
+case VIEW_CONVERT_EXPR:
+ {
+ /* Handle
1 - 100 of 141 matches
Mail list logo
