> 2017-07-07 Daniel Cederman
>
> * config/sparc/sparc.c (sparc_do_work_around_errata): Insert NOP
> instructions to prevent sequences that can trigger the store-store
> errata for certain LEON3FT processors.
> (sparc_option_override): -mfix-ut699, -mfix-ut700, and
>
James,
The subtract instruction only reliably sets the N and Z flags. We convey this
information in aarch64_seelct_cc_mode.
Regards,
Michael Collison
-Original Message-
From: James Greenhalgh [mailto:james.greenha...@arm.com]
Sent: Monday, July 10, 2017 10:12 AM
To: Michael Collison
Hi all,
This is an updated version of patch in
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00409.html . It prevents
optimization in presense of sNaNs (and qNaNs when comparison operator
is > >= < <=) to preserve FP exceptions.
Note that I had to use -fsignaling-nans in pr57371-5.c test because
> From the above doc, the major difference between a memory_constraint and a
> special_memory_constraint is: whether "reload can or cannot make them match
> by reloading the address".
Right, i.e. by just changing the form of the address (instead of the address
itself).
> For memory_constraint,
On 2017-07-11 09:21, Eric Botcazou wrote:
Applied without the undocumented tweaks to the divdf3_fix and sqrtdf2_fix
patterns. Why are 2 nops necessary here? The stored value doesn't matter.
And the length attribute should be adjusted if nops are added to the pattern.
The first nop was added
Ping #4
This small addition improves costs of PARALLELs in
rtlanal.c:seq_cost(). Up to now, these costs are
assumed to be 1 which gives gross inexact costs for,
e.g. divmod which is represented as PARALLEL.
The patch just forwards cost computation to insn_rtx_cost
which uses the cost of the 1st
The errata fix for the UT699 fdivd and fsqrtd might cause a sequence
that can trigger the b2bst errata. Adding a NOP prevents this.
gcc/ChangeLog:
2017-07-11 Daniel Cederman
* config/sparc/sparc.md (divdf3_fix): Add NOP to prevent back
to back store errata sensitive sequence f
On 02/06/17 00:54, Michael Collison wrote:
> This patch improves code generation for relational compares against zero that
> are not merged into a subtract instruction. This patch improves the >= and <
> cases.
>
> An example of the '<' case:
>
> int lt (int x, int y)
> {
> if ((x - y) < 0)
>
Michael Collison wrote:
>
> The subtract instruction only reliably sets the N and Z flags. We convey this
> information in
> aarch64_seelct_cc_mode.
The SUBS and CMP set the N and Z flags identically - although they also set C
and V, they
are different if there is overflow. CC_NZmode is used af
On 3 July 2017 at 11:21, Yvan Roux wrote:
> On 23 June 2017 at 15:44, Yvan Roux wrote:
>> Hello,
>>
>> Fortran parts of libgomp (omp_lib.mod, openacc.mod, etc...) are
>> missing in a canadian cross build, at least when target gfortran
>> compiler comes from PATH and not from GFORTRAN_FOR_TARGET.
On 3 July 2017 at 12:48, Yvan Roux wrote:
> On 27 June 2017 at 13:14, Yvan Roux wrote:
>> Hi Wilco
>>
>> On 27 June 2017 at 12:53, Wilco Dijkstra wrote:
>>> Hi Yvan,
>>>
Here is the backport of Wilco's patch (r237607) along with Kyrill's
one (r244643, which removed the remaining occure
texinfo is shredding external links.
Applied the following patch to prevent uses from 404 not found.
Johann
gcc/
* doc/extend.texi (AVR Function Attributes): Remove weblink to
Binutils doc as TEXI will mess them up.
* doc/invoke.texi (AVR Options): Same here.
Index: do
Hello.
This fixes majority of autoFDO test-cases.
Patch can boostrap and survives regression tests.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2017-07-11 Martin Liska
* auto-profile.c (afdo_annotate_cfg): Assign zero counts to
BBs and edges seen by autoFDO.
---
gcc/au
Hello.
Following is a typo fix which nobody has noticed during testing of
e.g. gcc/testsuite/gcc.dg/tree-prof/indir-call-prof.c.
Patch can bootstrap and survives regression tests.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2017-07-11 Martin Liska
* auto-profile.c (autofdo_so
* doc/xml/faq.xml: Update several old entries. Improve
cross-references.
* doc/xml/manual/intro.xml: Add anchors to each DR.
* doc/html/*: Regenerate.
Committed to trunk.
commit c59da1a826c9fa0ffa4cd5b89db88581d481489e
Author: Jonathan Wakely
Date: Tue Jul 11 1
On 21/04/17 15:54 +0100, Jonathan Wakely wrote:
On 4 April 2017 at 20:44, Jonathan Wakely wrote:
We got a bug report from a customer pointing out that calling
promise::set_value on a moved-from promise crashes instead of throwing
an exception with error code future_errc::no_state.
This fixes it
Hi
I wrote a test for "-fsanitize-coverage=trace-cmp" .
Is there anybody tells me if these codes could be merged into gcc ?
Index: gcc/testsuite/gcc.dg/sancov/basic3.c
===
--- gcc/testsuite/gcc.dg/sancov/basic3.c (nonexistent)
+++ g
In killing TYPE_METHODS I discovered this useless check. We already cull these
ctors from the methods just after creating the struct.
bootstrap with the continue turned into gcc_unreachable worked just fine.
applied to trunk.
nathan
--
Nathan Sidwell
2017-07-11 Nathan Sidwell
* dw
On 13 June 2017 at 01:47, Joseph Myers wrote:
> This is OK with one fix:
>
>> +C ObjC Var(warn_enum_conversion) Init(0) Warning LangEnabledBy(C Objc,Wall)
>
> I believe the LangEnabledBy arguments are case-sensitive, so you need to
> have ObjC not Objc there for it to work correctly. (*.opt parsi
We no longer need to frob the ctor name here, and indeed the name lookup stuff
I'm working on would really rather it didn't.
Applied to trunk
nathan
--
Nathan Sidwell
2017-07-11 Nathan Sidwell
* decl2.c (reset_type_linkage_2): Dont't change ctor name.
Index: decl2.c
===
Hi,
we've run into a PTX JIT bug with cuda driver version 381.22 for sm_61
at -O1 and higher. This patch adds a workaround, guarded by a macro,
enabling the workaround by default.
Tested on x86_64 with nvidia accelerator.
Committed.
Thanks,
- Tom
Add extra initialization of broadcasted con
On 11/07/17 12:53 +0100, Jonathan Wakely wrote:
On 21/04/17 15:54 +0100, Jonathan Wakely wrote:
On 4 April 2017 at 20:44, Jonathan Wakely wrote:
We got a bug report from a customer pointing out that calling
promise::set_value on a moved-from promise crashes instead of throwing
an exception with
This patch fixes a bogus -Wmultistatement-macros warning. The code didn't
notice that what came after a guard such as else was actually wrapped in { }
which is a correct use. This bogus warning only triggered when the body of
a conditional was coming from a different expansion than the conditiona
On 07/10/2017 05:08 PM, Martin Sebor wrote:
On 07/10/2017 02:35 AM, Martin Liška wrote:
On 07/07/2017 09:20 PM, Martin Sebor wrote:
A conflict in my patch for bug 81345 made me notice that r249734
recently added a new option property, IntegerRange. The change
below adds brief documentation of
On 07/10/2017 09:35 PM, Martin Sebor wrote:
On 07/10/2017 03:36 AM, Martin Liška wrote:
Hi.
This adds missing quotes to various error messages related to AddressSanitizer.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
On 07/03/2017 11:00 PM, Jason Merrill wrote:
On Mon, Jul 3, 2017 at 5:52 AM, Martin Liška wrote:
On 06/30/2017 09:34 PM, Jason Merrill wrote:
On Fri, Jun 30, 2017 at 5:23 AM, Martin Liška wrote:
This is v2 of the patch, where just names of attributes are canonicalized.
Patch can bootstrap on
thanks for the replying.
> On Jul 11, 2017, at 2:44 AM, Eric Botcazou wrote:
>
>> From the above doc, the major difference between a memory_constraint and a
>> special_memory_constraint is: whether "reload can or cannot make them match
>> by reloading the address".
>
> Right, i.e. by just chan
PING^1
Martin
On 06/30/2017 10:47 AM, Martin Liška wrote:
Hello.
Following patch does refactoring of make_resolver_func where ifunc
alias and resolver were probably confused.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
i386.exp tests work on x86_64-linux-gnu.
R
TYPE_MODE (pointer_sized_int_node), bot,
> - TYPE_MODE (pointer_sized_int_node));
> + ptr_mode, bot, ptr_mode);
There is another similar occurence:
/opt/gcc/gcc-20170711/gcc/testsuite/gcc.dg/asan/pr80168.c:7:1: internal
compil
On Mon, 2017-07-03 at 19:57 +0100, Richard Sandiford wrote:
> [Thanks for all your diagnostic work btw.]
>
> David Malcolm writes:
> > clang can also print notes about matching opening symbols
> > e.g. the note here:
> >
> > missing-symbol-2.c:25:22: error: expected ']'
> > const char test
On 10 July 2017 at 10:01, Christophe Lyon wrote:
> Hi,
>
>
> On 6 July 2017 at 06:50, Jeff Law wrote:
>> On 07/04/2017 02:50 AM, Christophe Lyon wrote:
>>> On 3 July 2017 at 17:30, Jeff Law wrote:
On 07/03/2017 09:00 AM, Christophe Lyon wrote:
> Hi,
>
> This is a follow-up to
>>
TYPE_MODE (pointer_sized_int_node), bot,
-TYPE_MODE (pointer_sized_int_node));
+ptr_mode, bot, ptr_mode);
There is another similar occurence:
/opt/gcc/gcc-20170711/gcc/testsuite/gcc.dg/asan/pr80168.c:7:1: internal
compiler
Hi.
Similar for GNU Pascal language.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
gcc/ChangeLog:
2017-07-11 Martin Liska
* dbxout.c (get_lang_number): Do not handle GNU Pascal.
* dbxout.h (extern void dbxout_stab
Hi.
There's a small follow-up with remaining occurrences:
1) dwarf2out.c:
20213 origin_die = lookup_type_die (origin);
20214else if (TREE_CODE (origin) == BLOCK)
20215 origin_die = BLOCK_DIE (origin);
20216
20217/* XXX: Functions that are never lowered don't always have
And there are remaining references of Pascal:
1) dbxout.c:
1661 {
1662stabstr_C ('r');
1663if (TREE_TYPE (type))
1664 dbxout_type (TREE_TYPE (type), 0);
1665else if (TREE_CODE (type) != INTEGER_TYPE)
1666 dbxout_type (type, 0); /* E.g. Pascal's ARRAY [BOOLEAN]
On 07/11/2017 07:23 AM, Paul Richard Thomas wrote:
> Well, a bit earlier than anticipated, here is the final version that
> puts right all the wrinkles that I know about.
>
> Bootstraps and regtests - OK for trunk?
>
> Paul
Somewhere in the threads on this, there was mentioned ABI breakage/chang
[This patch kit is effectively just one patch; I've split it up into
3 parts, in the hope of making it easier to review:
the c-family parts, the C parts, and the C++ parts]
This patch adds a hint to the user to various errors generated
in the C frontend by:
c_parser_require (parser, CPP_CLOSE
OK for trunk? (assuming the rest is approved)
gcc/c-family/ChangeLog:
* c-common.c (c_parse_error): Add rich_location * param, using it
rather implicitly using input_location.
* c-common.h (c_parse_error): Add rich_location * param.
gcc/testsuite/ChangeLog:
* c-c++
OK for trunk? (assuming the rest is approved)
gcc/c/ChangeLog:
* c-parser.c (c_parser_error): Rename to...
(c_parser_error_richloc): ...this, making static, and adding
"richloc" parameter, passing it to the c_parse_error call,
rather than calling c_parser_set_source
OK for trunk? (assuming the rest is approved)
gcc/cp/ChangeLog:
* parser.c (cp_parser_error): Update for new param to
c_parse_error.
(class token_pair): New class.
(class matching_parens): New class.
(class matching_braces): New class.
(cp_parser_sta
On 07/11/2017 07:32 AM, Martin Liška wrote:
On 07/10/2017 05:08 PM, Martin Sebor wrote:
On 07/10/2017 02:35 AM, Martin Liška wrote:
On 07/07/2017 09:20 PM, Martin Sebor wrote:
A conflict in my patch for bug 81345 made me notice that r249734
recently added a new option property, IntegerRange.
On Jul 11 2017, Maxim Ostapenko wrote:
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 608993a..6437979 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -4976,9 +4976,7 @@ expand_asan_emit_allocas_unpoison (tree exp)
>EXPAND_NORMAL);
>rtx ret = init_one
On Tue, Jul 11, 2017 at 9:37 AM, Martin Liška wrote:
> On 07/03/2017 11:00 PM, Jason Merrill wrote:
>> On Mon, Jul 3, 2017 at 5:52 AM, Martin Liška wrote:
>>> On 06/30/2017 09:34 PM, Jason Merrill wrote:
On Fri, Jun 30, 2017 at 5:23 AM, Martin Liška wrote:
>
> This is v2 of the
On Tue, Jul 11, 2017 at 10:42 AM, Martin Liška wrote:
> And there are remaining references of Pascal:
>
> 1) dbxout.c:
>
> 1661 {
> 1662stabstr_C ('r');
> 1663if (TREE_TYPE (type))
> 1664 dbxout_type (TREE_TYPE (type), 0);
> 1665else if (TREE_CODE (type) != INTEGER_TYPE
On 11/07/17 17:56, Andreas Schwab wrote:
On Jul 11 2017, Maxim Ostapenko wrote:
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 608993a..6437979 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4976,9 +4976,7 @@ expand_asan_emit_allocas_unpoison (tree exp)
EXPAN
Hi all,
This patch refactors comments in config/aarch64/aarch64.c
aarch64_print_operand
to provide a table of aarch64 specific formating options.
I've tested the patch with a bootstrap and testsuite run on aarch64.
OK for trunk?
Changelog:
gcc/
2017-07-04 Jackson Woodruff
* config
On 07/11/2017 09:24 AM, David Malcolm wrote:
[This patch kit is effectively just one patch; I've split it up into
3 parts, in the hope of making it easier to review:
the c-family parts, the C parts, and the C++ parts]
This patch adds a hint to the user to various errors generated
in the C fron
David Malcolm writes:
> On Mon, 2017-07-03 at 19:57 +0100, Richard Sandiford wrote:
>> [Thanks for all your diagnostic work btw.]
>>
>> David Malcolm writes:
>> > clang can also print notes about matching opening symbols
>> > e.g. the note here:
>> >
>> > missing-symbol-2.c:25:22: error: expe
On Mon, 2017-07-10 at 11:36 +0200, Martin Liška wrote:
> Hi.
>
> This adds missing quotes to various error messages related to
> AddressSanitizer.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression
> tests.
>
> Ready to be installed?
LGTM, with my "diagnostic messages" maintai
Am 11.07.2017 um 16:48 schrieb Jerry DeLisle:
Somewhere in the threads on this, there was mentioned ABI breakage/change.
That was me.
Does it really do this?
Yes. Look at this part:
Index: libgfortran/libgfortran.h
===
*** li
On Tue, 2017-07-11 at 11:28 -0600, Martin Sebor wrote:
> On 07/11/2017 09:24 AM, David Malcolm wrote:
> > [This patch kit is effectively just one patch; I've split it up
> > into
> > 3 parts, in the hope of making it easier to review:
> > the c-family parts, the C parts, and the C++ parts]
> >
>
On Thu, 8 Jun 2017, Alexander Monakov wrote:
> Ping^3.
Ping^4: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00782.html
This is a wrong-code issue with C11 atomics: even if no machine barrier is
needed for a given fence type on this architecture, a compiler barrier must
be present in RTL.
Altern
Core DR 393 in C++17 removed the restriction on parameters with
pointer to array of unknown bound type; accordingly, I've reduced the
diagnostic for earlier standards to a pedwarn.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a89d6192b65fc0eef3d95592c212a389928b6cba
Author: Jason Merrill
> the problem I had is:
>
> 1. we added a new special_memory_constraint for misaligned memory access,
> one important requirement for this new special_memory_constraint is, the
> address of the memory access is misaligned.
OK, it's the other way around from the usage of special_memory_constraint
> On Jul 11, 2017, at 2:00 PM, Eric Botcazou wrote:
>
>> the problem I had is:
>>
>> 1. we added a new special_memory_constraint for misaligned memory access,
>> one important requirement for this new special_memory_constraint is, the
>> address of the memory access is misaligned.
>
> OK, it'
On 07/11/2017 12:32 PM, David Malcolm wrote:
On Tue, 2017-07-11 at 11:28 -0600, Martin Sebor wrote:
On 07/11/2017 09:24 AM, David Malcolm wrote:
[This patch kit is effectively just one patch; I've split it up
into
3 parts, in the hope of making it easier to review:
the c-family parts, the C p
Hi Jerry and Thomas,
As Thomas noted, the span field is added in the middle of the
descriptor because the caf token field makes the descriptor variable
length. This is reflected in the change in libgfortran.h.
It has crossed my mind in the last twenty four hours that I should add
some more fields
Ping.
Jim
On Thu, Jun 29, 2017 at 1:53 PM, Jim Wilson wrote:
> Falkor is an ARMV8-A part, but also includes the RDMA extension from
> ARMV8.1-A.
> I'd like to enable support for the RDMA instructions when -mcpu=falkor is
> used,
> and also make the RDMA intrisics available. To do that, I need
This patch series is designed to mitigate the problems exposed by the
stack-clash exploits. As I've noted before, the way to address this
class of problems is via a good stack probing strategy.
This has taken much longer than expected to pull together for
submission. Sorry about that. However,
This is the first patch in the stack-clash mitigation patches.
It introduces a new style of stack probing -fstack-check=clash,
including documentation of the new option, how it differs from
-fstack-check=specific, etc.
FWIW -fstack-check=specific is dreadfully named. I haven't tried to
address t
One of the painful aspects of all this code is the amount of target
dependent bits that have to be written and tested.
I didn't want to be scanning assembly code or RTL for prologues. Each
target would have to have its own scanner which was too painful to
contemplate.
So instead I settled on hav
The key goal in this patch is to introduce the new probing style for
dynamically allocated stack space and indirect uses of
STACK_CHECK_PROTECT via get_stack_check_protect().
Those two changes accomplish two things. First it gives most targets
protection of dynamically allocated space (exception
The prior patch introduced -fstack-check=clash prologues for the x86.
And yet we still saw large allocations in our testing.
It turns out combine-stack-adjustments would take
allocate PROBE_INTERVAL
probe
allocate PROBE_INTERVAL
probe
allocate PROBE_INTERVAL
probe
allocate RESIDUAL
And turn tha
This patch introduces x86 target specific bits to mitigate stack clash
attacks.
The key differences relative to the -fstack-check=specific expander are
that it never allocates more than PROBE_INTERVAL bytes at a time, it
probes into each allocated hunk immediately after allocation, and it
exploit
This patch introduces -fstack-check=clash prologue support for the PPC.
PPC is interesting in that its ABIs requires *sp to always contain the
backchain. That implicit probe is very useful in eliminating many
explicit probes. In fact, from the standpoint of avoiding explicit
probes it's probably
This patch introduces aarch64 -fstack-check=clash prologue support.
aarch64 is the first target that does not have any implicit probes in
the caller. Thus at prologue entry it must make conservative
assumptions about the offset of the most recent probed address relative
to the stack pointer.
Ho
This patch adds s390 support for stack-clash mitigation.
s390's most interesting property is that the caller allocates space for
the callee to save registers into.
So much like aarch64, we start with a very conservative assumption about
the offset between SP and the most recent stack probe. As w
> we need to generate misaligned load/store insns ONLY for misaligned memory
> access, therefore need a new constraints for misaligned address.
Why? What happens exactly if the memory access turns out to be aligned?
--
Eric Botcazou
Andrew, this seems like the sort of rs6000 patch likely to be relevant to
the powerpcspe port. (Of course all rs6000 patches since the ports
separated need to be monitored to spot such patches that need merging as
they go in.)
--
Joseph S. Myers
jos...@codesourcery.com
On 07/11/2017 03:51 PM, Joseph Myers wrote:
> Andrew, this seems like the sort of rs6000 patch likely to be relevant to
> the powerpcspe port. (Of course all rs6000 patches since the ports
> separated need to be monitored to spot such patches that need merging as
> they go in.)
Yes. My hope w
I would like to backport the following patches to the GCC 6 branch.
PR9: Fix failure of gcc.dg/loop-8.c on Power
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01788.html
PR68972: g++.dg/cpp1y/vla-initlist1.C test case fails on power
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00541.htm
> On Jul 11, 2017, at 4:24 PM, Eric Botcazou wrote:
>
>> we need to generate misaligned load/store insns ONLY for misaligned memory
>> access, therefore need a new constraints for misaligned address.
>
> Why? What happens exactly if the memory access turns out to be aligned?
we add this new c
> we add this new constraint as:
>
> ;; We need a special memory constraint for the misaligned memory access
> ;; This is only for TARGET_MISALIGN target
> (define_special_memory_constraint "B"
> "Memory reference whose address is misaligned"
> (and (match_code "mem")
> (match_test "TARGET
Jeff Law wrote:
> aarch64 is the first target that does not have any implicit probes in
> the caller. Thus at prologue entry it must make conservative
> assumptions about the offset of the most recent probed address relative
> to the stack pointer.
No - like I mentioned before that's not correct
From: Eric Botcazou
Date: Wed, 12 Jul 2017 01:19:03 +0200
>> we add this new constraint as:
>>
>> ;; We need a special memory constraint for the misaligned memory access
>> ;; This is only for TARGET_MISALIGN target
>> (define_special_memory_constraint "B"
>> "Memory reference whose address is
On 07/11/2017 06:20 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> aarch64 is the first target that does not have any implicit probes in
>> the caller. Thus at prologue entry it must make conservative
>> assumptions about the offset of the most recent probed address relative
>> to the stack pointe
GCC Maintainers:
The following patch adds support for the some additional vec_revb
builtin functions. It also adds a missing testcase. The
patch has been tested on powerpc64le-unknown-linux-gnu (Power 8 LE),
powerpc64-unknown-linux-gnu (Power 8 BE), powerpc64-unknown-linux-gnu
(Power 7).
Please
77 matches
Mail list logo
