2017-07-14 18:16 GMT+04:00 Georg-Johann Lay :
> Hi, this patch restores some of the divmod handling.
>
> It addresses two issues:
>
> 1) rtx_costs might be called with code = LSHIFTRT for a mul_highpart. This
> is the case when outer_code = TRUNCATE. This patch uses a new function to
> compute the
On Thu, Jul 13, 2017 at 5:12 PM, Andrew Pinski wrote:
> Hi,
> This patch adds Decimal floating point support to aarch64. It is
> the base support in that since there is no hardware support for DFP,
> it just defines the ABI. The ABI I chose is that _Decimal32 is
> treated like float, _Decimal6
On Fri, Jul 14, 2017 at 12:59 PM, Jim Wilson wrote:
> On Fri, Jul 14, 2017 at 1:35 AM, Martin Liška wrote:
>> May I ask Jim to test the patch?
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> I started an aarch64 bootstrap to test. My fast machine is busy with
>
On Fri, Jul 14, 2017 at 11:17 PM, Kostya Serebryany wrote:
> Hi
>
> I wrote a test for "-fsanitize-coverage=trace-cmp" .
>
> Is there anybody tells me if these codes could be merged into gcc ?
Nice!
We are currently working on Linux kernel fuzzing
On 07/14/2017 10:54 AM, Nathan Sidwell wrote:
> This was the most surprising check of TYPE_METHODS. When not optimizing
> we use the non-nullness of TYPE_METHODS to figure out if we want to
> place a non BLKmode structure into a register. On the grounds that one
> can't call a member function wit
PR 81449 reports a libgo problem with the definition semt in
runtime.inc on some systems. Since the C code in libgo/runtime doesn't
need semt, just don't copy it into runtime.inc. Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On Fri, Jul 14, 2017 at 11:41 AM, Uros Bizjak wrote:
> On Thu, Jul 13, 2017 at 9:56 PM, Ian Lance Taylor wrote:
>> On Thu, Jun 29, 2017 at 11:40 PM, Uros Bizjak wrote:
>>>
This patch to the gotools Makefile adds tests to `make check`. We now
test the runtime package using the newly bu
On Fri, Jul 14, 2017 at 5:23 AM, Dmitry Vyukov wrote:
> On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote:
>>> > Hi
>>> >
>>> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
>>> >
>>> > Is there anybody tells me if these codes could be merged into gcc ?
>>>
>>>
>>> Nice!
>>>
>>> We
Hi Carl,
On Fri, Jul 14, 2017 at 01:20:32PM -0700, Carl Love wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-4-p9-runnable.c
> @@ -0,0 +1,95 @@
> +/* { dg-do run { target { powerpc64*-*-* && { lp64 && p9vector_hw } } } } */
powerpc*-*-* instead.
> +/* { dg-skip-if "do no
GCC Maintainers:
The following patch add testcases and documentation for the
---
gcc/ChangeLog:
2017-07-14 Carl Love
* doc/extend.texi: Update the built-in documentation file for the
existing built-in functions
vec
On 07/14/2017 09:40 AM, Martin Sebor wrote:
On 07/14/2017 07:47 AM, Marek Polacek wrote:
On Fri, Jul 14, 2017 at 02:52:36PM +0200, Marek Polacek wrote:
On Thu, Jul 13, 2017 at 11:42:15AM -0600, Martin Sebor wrote:
On 07/13/2017 08:18 AM, Marek Polacek wrote:
This patch improves diagnostic in
On Fri, Jul 14, 2017 at 1:35 AM, Martin Liška wrote:
> May I ask Jim to test the patch?
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I started an aarch64 bootstrap to test. My fast machine is busy with
work tasks, so I have to use a slower machine, and hence this
Hi Carl,
> Also, per the note from Segher I could use xxperm instead of vperm, I
> stayed with the vperm instruction. I don't see any functional or
> performance advantage of the xxperm over vperm.
xxperm does the same as vperm, but for all vector registers instead
of only v0..v31. Since xvcvhp
This patch from Jason solves the problem pointed out at the end of
D0702R1 (not public yet):
std::variant v1(3);
std::variant v2 = v1;
Tested powerpc64le-linux, committed to trunk.
commit 54e520fc40bff5fe441715f23b64c2c788db23dc
Author: Jonathan Wakely
Date: Fri Jul 14 19:38:51 2017 +0100
On Thu, Jul 13, 2017 at 9:56 PM, Ian Lance Taylor wrote:
> On Thu, Jun 29, 2017 at 11:40 PM, Uros Bizjak wrote:
>>
>>> This patch to the gotools Makefile adds tests to `make check`. We now
>>> test the runtime package using the newly built go tool, and test that
>>> cgo works by running the misc
roke Ada bootstrap at on
> x86_64-pc-linux-gnu, sparc-sun-solaris2.12, and i386-pc-solaris2.12
> (probably everywhere) during stage2:
>
> +===GNAT BUG DETECTED==+
> | 8.0.0 20170714 (experimental) [trunk revision 250207] (x86_64-p
Hi,
PR81162 identifies a bug in SLSR involving overflow that occurs when
replacing a NEGATE_EXPR with a PLUS_EXPR. This is another example
of an unprofitable transformation that should be skipped anyway,
hence this simple patch. Bootstrapped and tested on
powerpc64le-unknown-linux-gnu, committed
On 07/14/2017 01:32 PM, Paolo Carlini wrote:
While working on the bug I also noticed that we can simplify a bit the code
generating the implicit deduction guides: if I'm not mistaken, when we pass
types as first argument of build_deduction_guide - for implicit guides, that is
- the deduction gui
-pc-solaris2.12
(probably everywhere) during stage2:
+===GNAT BUG DETECTED==+
| 8.0.0 20170714 (experimental) [trunk revision 250207] (x86_64-pc-linux-gnu)
GCC error:|
| in gimplify_save_expr, at gimplify.c:5805|
| Error
GCC Maintainers:
The following patch adds support for the vec_extract_fp_from_shorth()
and vec_extract_fp_from_short builtin functions has been updated per
Segher's comments. The patch has been re-tested on
powerpc64le-unknown-linux-gnu (Power 8 LE) and
powerpc64le-unknown-linux-gnu (Power 9 LE).
Hi,
in this C++17 ICE on invalid we crash when, in do_class_deduction,
build_new_function_call is called with a null first argument. What is
happening is pretty simple to analyze: for the broken snippet, there are
no cands and elided is false, because the issue isn't that candidates
are elide
> This patch changes ipa-devirt. It contains a loop checking all the member
> functions are 'the same'. However, as the comment says, we've already
> zapped TYPE_METHODS, so the loop is never entered. I've added equivalent
> zapping in this patch series, as the rationale appears to be reducing
And finally, this patch kills the TYPE_METHODS macro.
As I mentioned earlier, I have other patches to repurpose the now-unused slot in
records and unions.
nathan
--
Nathan Sidwell
2017-07-14 Nathan Sidwell
gcc/
* tree.h (TYPE_METHODS): Delete.
Index: gcc/tree.h
==
This bit of the objective C runtime already knows that TYPE_FIELDS might contain
non-FIELD_DECL things. But it has the delightful assumption that the first
thing is a FIELD_DECL, which apparently was fine until now. Fixed by
simplifying the loop.
nathan
--
Nathan Sidwell
2017-07-14 Nathan
This bit removes knowledge of TYPE_METHODS from the various tree dumpers,
allocators and deleters.
As mentioned before, the only reason we set TYPE_METHODS to error_mark_node when
handing over to the middle end is for the RTL check about register allocation.
But I'm deleting that check.
nath
This is the libcc1 change. When creating a clone, it needs to fiddle with
TYPE_FIELDS now.
nathan
--
Nathan Sidwell
2017-07-14 Nathan Sidwell
libcc1/
* libcp1plugin.cc (plugin_build_decl): Member fns are on TYPE_FIELDS.
Index: libcc1/libcp1plugin.cc
===
This is the biggest chunk, in the C++ FE.
The only quirk is a hopefully short-lived additional check when looking up a
non-function member in an incomplete type. We iterate over TYPE_FIELDS, and
should now ignore things that are functions -- because we'll find them as
overloads when looking a
This change to the ada-spec generation teaches it about looking at TYPE_FIELDS.
quite straight forwards.
nathan
--
Nathan Sidwell
2017-07-14 Nathan Sidwell
gcc/c-family/
* c-ada-spec.c (is_tagged_type, has_nontrivial_methods,
dump_ada_template, print_ada_methods,
This was the most surprising check of TYPE_METHODS. When not optimizing we use
the non-nullness of TYPE_METHODS to figure out if we want to place a non BLKmode
structure into a register. On the grounds that one can't call a member function
with a register-located object.
That seems overly en
On 07/14/2017 10:34 AM, Segher Boessenkool wrote:
> On Thu, Jul 13, 2017 at 10:35:55PM -0600, Jeff Law wrote:
There's -fstack-check and -fstack-clash-protection. I think with the
direction we're going they are fundamentally incompatible because
neither the compiler nor kernel do any
This patch changes ipa-devirt. It contains a loop checking all the member
functions are 'the same'. However, as the comment says, we've already zapped
TYPE_METHODS, so the loop is never entered. I've added equivalent zapping in
this patch series, as the rationale appears to be reducing memor
This changes dbxout and dwarf2out.
Rather than iterate over the TYPE_METHODS, they now need to deal with member fns
in the regular TYPE_FIELDS iteration.
dbxout was a little weirdly convoluted, apparently presuming that functions with
the same name are all together. That's not true, so other t
This is a series of patches that remove the TYPE_METHODS field used in records &
unions. Currently TYPE_METHODS hods a the member functions (be they static or
non-static), and TYPE_FIELDS holds everything else (be they FIELD_DECLS or
whatever). This distinction is unnecessary, and the patches
On Thu, Jul 13, 2017 at 10:35:55PM -0600, Jeff Law wrote:
> >> There's -fstack-check and -fstack-clash-protection. I think with the
> >> direction we're going they are fundamentally incompatible because
> >> neither the compiler nor kernel do anything to guarantee enough stack is
> >> available af
On 07/13/2017 04:54 PM, Jeff Law wrote:
> On 07/12/2017 07:44 PM, Segher Boessenkool wrote:
>>> /* The default is not to move the stack pointer. */
>>> +/* The default is not to move the stack pointer, unless we are using
>>> + stack clash prevention stack checking. */
>>> #ifndef STACK_CHECK
On 06/21/2017 01:59 AM, Volker Reichelt wrote:
On 20 Jun, Jason Merrill wrote:
On Tue, Jun 20, 2017 at 3:06 PM, David Malcolm wrote:
It's not clear to me what the issue alluded to with negative
obstack_blank is, but I chose to follow the above docs and use
obstack_blank_fast; am testing an upd
Jason, is this updated version of the patch OK?
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01580.html
Thanks
Dave
On Wed, 2017-06-21 at 10:32 -0400, David Malcolm wrote:
> On Tue, 2017-06-20 at 15:11 -0400, Jason Merrill wrote:
> > On Tue, Jun 20, 2017 at 3:06 PM, David Malcolm > >
> > wro
Hi,
We don't document the list of CPU names which can take a +crypto extension
in the ARM port. This patch fixes that oversight.
OK?
Thanks,
James
---
2017-14-07 James Greenhalgh
* doc/invoke.texi (arm/-mcpu): Document +crypto.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.tex
On 14/07/17 16:44, James Greenhalgh wrote:
Hi,
We don't document the list of CPU names which can take a +crypto extension
in the ARM port. This patch fixes that oversight.
OK?
Ok.
Thanks,
Kyrill
Thanks,
James
---
2017-14-07 James Greenhalgh
* doc/invoke.texi (arm/-mcpu): Docum
On 07/14/2017 07:47 AM, Marek Polacek wrote:
On Fri, Jul 14, 2017 at 02:52:36PM +0200, Marek Polacek wrote:
On Thu, Jul 13, 2017 at 11:42:15AM -0600, Martin Sebor wrote:
On 07/13/2017 08:18 AM, Marek Polacek wrote:
This patch improves diagnostic in the C FE by printing the types when reporting
Hi Richard,
I've committed the requested change as a separate patch to make it easier to
backport to earlier GCC versions.
Definition of __ARM_FEATURE_NUMERIC_MAXMIN checks for
TARGET_ARM_ARCH >= 8 and TARGET_NEON being true in addition to
TARGET_VFP5. However, instructions covered by this mac
On 07/14/2017 08:29 AM, Andreas Krebbel wrote:
> On 07/11/2017 11:21 PM, Jeff Law wrote:
>> 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 sta
On 14/07/17 09:20, Thomas Preudhomme wrote:
> Hi,
>
> fp-armv8 is currently defined as a double precision FPv5 with 32 D
> registers *and* a special FP_ARMv8 bit. However FP for ARMv8 should only
> bring 32 D registers on top of FPv5-D16 so this FP_ARMv8 bit is
> spurious. As a consequence, many i
Hi,
This is a followup patch for previous fix to PR81369. In that test case, GCC
tries to distribute infinite loop, which doesn't make much sense. This patch
works conservatively by skipping loops with unknown niters. It also simplifies
code a bit.
Bootstrap and test on x86_64 and AArch64, is it
Hi,
This patch fixes ICE reported by PR81369. It simply sinks call to
sort_partitions_by_post_order so that it's executed for all cases.
This is necessary to schedule reduction partition as the last one.
Bootstrap and test on x86_64 and AArch64. Is it OK?
Thanks,
bin
2017-07-12 Bin Cheng
ping
Wilco Dijkstra wrote:
> James Greenhalgh wrote:
>
> > I note this is still marked as an RFC, are you now proposing it as a
> > patch to be merged to trunk?
>
> Absolutely. It was marked as an RFC to get some comments - I thought it
> may be controversial to separate the frame pointe
On 07/11/2017 11:21 PM, Jeff Law wrote:
> 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 of
ping
From: Wilco Dijkstra
Sent: 17 January 2017 15:14
To: Richard Earnshaw; GCC Patches; James Greenhalgh
Cc: nd
Subject: Re: [PATCH v3][AArch64] Fix symbol offset limit
Here is v3 of the patch - tree_fits_uhwi_p was necessary to ensure the size of a
declaration is an integer. So the q
ping
This patch further improves aarch64_legitimate_constant_p. Allow all
integer, floating point and vector constants. Allow label references
and non-anchor symbols with an immediate offset. This allows such
constants to be rematerialized, resulting in smaller code and fewer stack
spills.
ping
As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
may be used to avoid generating ADRP/ADD or ADRP/LDR. However both
trunk and GCC7 may still emit ADRP for some constant pool literals.
Fix this by adding a aarch64_pcrelative_literal_loads check.
OK for trunk/GCC7 back
Hi, this patch restores some of the divmod handling.
It addresses two issues:
1) rtx_costs might be called with code = LSHIFTRT for a mul_highpart.
This is the case when outer_code = TRUNCATE. This patch uses a new
function to compute the costs for that case (also used for code = TRUNCATE).
This patch teaches the fortran FE to allow deferred-shape pointers to be
used in OpenACC data clauses. While the spec states that arrays must be
contiguous, I believe that is a run-time requirement, not a compile
time. The intent behind OpenACC is to have the programmer sprinkle a
minimum amount of
On Fri, Jul 14, 2017 at 02:52:36PM +0200, Marek Polacek wrote:
> On Thu, Jul 13, 2017 at 11:42:15AM -0600, Martin Sebor wrote:
> > On 07/13/2017 08:18 AM, Marek Polacek wrote:
> > > This patch improves diagnostic in the C FE by printing the types when
> > > reporting
> > > a problem with a convers
Hi,
On Thu, 13 Jul 2017, Martin Liška wrote:
> Hopefully following patch will fix that. I returned to the first version
> and saved/restored static_chain register before/after
> __asan_stack_malloc.
It should also work if you emit the parm_birth_note after the static chain
is set up (not befo
I think David might be able to approve this one, so CCing.
On Tue, Jul 11, 2017 at 03:23:16PM +0200, Marek Polacek wrote:
> 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
On Thu, Jul 13, 2017 at 04:59:20PM -0400, David Malcolm wrote:
> On Thu, 2017-07-13 at 16:39 -0400, Eric Gallager wrote:
> > On 7/13/17, David Malcolm wrote:
> > > On Thu, 2017-07-13 at 18:33 +0200, Marek Polacek wrote:
> > > > A tiny patch for -Wsign-compare so that is also prints the types
> > >
On 14/07/17 09:33, Thomas Preudhomme wrote:
Hi,
On 29/06/17 16:13, Thomas Preudhomme wrote:
Please ignore this patch. I'll respin the patch on a more recent GCC.
Please find an updated patch in attachment.
This patch adds support for the ARM Cortex-R52 processor rencently
announced.
[1] ht
On Thu, Jul 13, 2017 at 11:42:15AM -0600, Martin Sebor wrote:
> On 07/13/2017 08:18 AM, Marek Polacek wrote:
> > This patch improves diagnostic in the C FE by printing the types when
> > reporting
> > a problem with a conversion. E.g., instead of
> >
> >warning: assignment from incompatible
On Thu, Jul 13, 2017 at 11:18 PM, Kostya Serebryany wrote:
>> > Hi
>> >
>> > I wrote a test for "-fsanitize-coverage=trace-cmp" .
>> >
>> > Is there anybody tells me if these codes could be merged into gcc ?
>>
>>
>> Nice!
>>
>> We are currently working on Linux kernel fuzzing that use the
>> comp
Jakub Jelinek wrote:
> On Wed, Jul 12, 2017 at 12:20:32AM +, Wilco Dijkstra wrote:
> > Therefore even when using a tiny 4K probe size we can safely adjust SP by
> > 3KB
> > before needing an explicit probe - now only 0.6% of functions need a probe.
> > If we choose a proper minimum probe dist
On Fri, Jul 7, 2017 at 5:56 PM, H.J. Lu wrote:
> On Fri, Jul 07, 2017 at 09:58:42AM -0700, H.J. Lu wrote:
>> On Fri, Dec 20, 2013 at 8:06 AM, Jakub Jelinek wrote:
>> > Hi!
>> >
>> > Honza recently changed the i?86 backend, so that it often doesn't
>> > do -maccumulate-outgoing-args by default on
Replace MULTILIB_EXCEPTIONS with MULTILIB_REQUIRED for readability.
-mfix-gr712rc and -mfix-ut700 are currently equivalent.
2017-07-14 Daniel Cederman
* config/sparc/t-rtems: Add mfix-gr712rc multilibs. Replace
MULTILIB_EXCEPTIONS with MULTILIB_REQUIRED. Match -mfix-gr712rc
On Wed, Jul 12, 2017 at 03:15:04PM +, Bin Cheng wrote:
> Hi,
> After change @236817, AArch64 backend could avoid unnecessary conversion
> instructions for register between different modes now. As a result, GCC
> could initialize register in larger mode and use it later in smaller mode.
> such
In case the LEON3FT back-to-back store workaround is active
(sparc_fix_b2bst), then define the builtin define __FIX_LEON3FT_B2BST on
RTEMS. The intended use case for this is operating system code in
assembly language. See also:
https://lists.rtems.org/pipermail/devel/2017-July/018463.html
gcc/
On Fri, Jul 14, 2017 at 10:11:51AM +0100, Jackson Woodruff wrote:
> Hi James,
>
> I have addressed the issues below.
>
> OK for trunk?
This looks good to me, thanks for the patch.
I've committed this to trunk on your behalf as revision 250202.
Thanks,
James
Hi!
glibc recently changed a couple of headers. One change was
that typedef struct sigaltstack { ... } stack_t; is now
typedef struct { ... } stack_t;
and the other change is that resolv.h now ignores the former (private glibc
macro) __need_res_state macro and after
struct __res_state { ... };
ty
On 14/07/17 09:56, Jakub Jelinek wrote:
On Fri, Jul 14, 2017 at 09:45:39AM +0100, Thomas Preudhomme wrote:
+ else if (!bswap)
+{
Would it make sense to add an assert right here checking that this is a
cmpnop operation?
The earlier bswap_replace code to handle n->base_addr && !bswap do
Hi James,
I have addressed the issues below.
OK for trunk?
Jackson
On 07/13/2017 05:14 PM, James Greenhalgh wrote:
On Thu, Jul 13, 2017 at 04:35:55PM +0100, Jackson Woodruff wrote:
Hi James,
I've addressed the issues discussed below.
OK for trunk?
I one last comment, otherwise, this looks
Hi all,
Jakub replaced the simple loop zeroing parts of the array in a previous patch.
This patchlet just adjusts the comment to be a bit more accurate.
Committed as obvious.
Thanks,
Kyrill
2017-07-14 Kyrylo Tkachov
* gimple-ssa-store-merging.c (clear_bit_region): Replace reference to
On Fri, Jul 14, 2017 at 09:45:39AM +0100, Thomas Preudhomme wrote:
> > + else if (!bswap)
> > +{
>
> Would it make sense to add an assert right here checking that this is a
> cmpnop operation?
The earlier bswap_replace code to handle n->base_addr && !bswap doesn't
have anything like that eit
Hi Jakub,
On 13/07/17 21:51, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, the following testcase started using recently
BIT_FIELD_REFs instead of MEM_REFs and thus the bswap pass, while it
properly determines the very long sequence of stmts is a nop transformation,
throws that away and does
On 05/01/2017 09:13 PM, Jason Merrill wrote:
> On Wed, Apr 26, 2017 at 6:58 AM, Martin Liška wrote:
>> On 04/25/2017 01:58 PM, Jakub Jelinek wrote:
>>> On Tue, Apr 25, 2017 at 01:48:05PM +0200, Martin Liška wrote:
Hello.
This is patch that was originally installed by Jason and later
Hi,
On 29/06/17 16:13, Thomas Preudhomme wrote:
Please ignore this patch. I'll respin the patch on a more recent GCC.
Please find an updated patch in attachment.
This patch adds support for the ARM Cortex-R52 processor rencently
announced.
[1] https://developer.arm.com/products/processors/co
Hi,
fp-armv8 is currently defined as a double precision FPv5 with 32 D
registers *and* a special FP_ARMv8 bit. However FP for ARMv8 should only
bring 32 D registers on top of FPv5-D16 so this FP_ARMv8 bit is
spurious. As a consequence, many instruction patterns which are guarded
by TARGET_FPU_ARM
On Wed, Jul 12, 2017 at 12:20:32AM +, Wilco Dijkstra wrote:
> No - like I mentioned before that's not correct nor acceptable as it would
> imply
> that ~70% of functions need a probe at entry. I did a quick run across SPEC
> and
> found the outgoing argument size is > 1024 in just 9 functions
On 07/03/2017 05:09 PM, David Malcolm wrote:
> On Fri, 2017-06-30 at 09:40 -0600, Jeff Law wrote:
>> On 05/26/2017 01:54 PM, David Malcolm wrote:
>>> Ping:
>>> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00321.html
>>>
>>> On Thu, 2017-05-04 at 12:36 -0400, David Malcolm wrote:
As of r2475
On 07/14/2017 01:40 AM, Jakub Jelinek wrote:
> On Thu, Jul 13, 2017 at 04:32:02PM -0500, Segher Boessenkool wrote:
>> I don't think it should be inside -fstack-check at all. Sure, the
>> mechanisms implementing it overlap a bit (more on some targets, less
>> on others), but how will a user ask for
On 07/14/2017 09:23 AM, Jeff Law wrote:
> On 07/13/2017 07:51 AM, Martin Liška wrote:
>> Hi.
>>
>> It's request for comment where I mechanically moved attribute-related
>> function to attribs.[hc].
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Thoughts?
> S
On Thu, Jul 13, 2017 at 04:32:02PM -0500, Segher Boessenkool wrote:
> I don't think it should be inside -fstack-check at all. Sure, the
> mechanisms implementing it overlap a bit (more on some targets, less
> on others), but how will a user ask for clash protection _and_ for
> stack checking?
Are
On 07/10/2017 06:07 AM, 吴潍浠(此彼) wrote:
> Hi
>
> I write some codes to make gcc support comparison-guided fuzzing.
> It is very like
> http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow .
> With -fsanitize-coverage=trace-cmp the compiler will insert extra
> instrumentation around
On 07/11/2017 08:30 AM, Martin Liška wrote:
> Hello.
>
> Patch removes some remaining references in gcc/ subfolder.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
>
> Martin
>
> gcc/ChangeLog:
>
> 2017-07-11 Martin Liska
>
> *
On 07/13/2017 07:51 AM, Martin Liška wrote:
> Hi.
>
> It's request for comment where I mechanically moved attribute-related
> function to attribs.[hc].
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Thoughts?
Seems reasonable. We don't like to move things ar
On 07/14/2017 01:00 AM, Martin Liška wrote:
> Hi.
>
> There's a small follow up that I've just tested.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?
> Martin
>
>
> 0001-Add-additional-quotes-to-opts.c.patch
>
>
> From 712746caf299546f2
On 07/13/2017 06:06 PM, Pedro Alves wrote:
> On 07/13/2017 03:59 PM, Jeff Law wrote:
>
>> The only concern I'd have here is the bits in dbxout.[ch] might
>> effectively be the best documentation of the dbxout format that exists.
>> Thus, dropping something like N_SO_PASCAL loses that historical
>>
Hi.
There's a small follow up that I've just tested.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From 712746caf299546f2e643e9e371c077643c46ad6 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 13 Jul 2017 14:22:50 +0200
Subject: [PATCH
85 matches
Mail list logo
