We get different code for libcpp/line-map.o in stage2 and stage3,
because stage2 is compiled with -gtoggle and stage3 is not. Bernd's
recent combine patch is being confused by debug insns. This is fixed
by changing a prev_nonnote_insn call to a prev_nonnote_nondebug_insn
call. There is also a re
Hi Kelvin,
On Fri, Mar 17, 2017 at 12:27:41PM -0600, Kelvin Nilsen wrote:
> This patch adds comments to clarify the automatic setting and clearing
> of target attribute flags in order to assure consistency between
> configuration settings and between multiple interrelated compilation
> target opti
On RISC-V we can't store integers in floating-point registers as this is
forbidden by the ISA. We've always disallowed this, but we were
setting the preferred mode to FP_REGS for some integer modes. This
caused the LRA to blow up with some hard to read error messages.
This patch removes the pref
The RISC-V memory model is still in the process of being formally
specified, so for now we're going to be safe and add the I/O bits to
userspace fences because there's no way to know if userspace is touching
memory-mapped I/O regions at compile time.
This will have no impact on existing microarchi
From: Andrew Waterman
The test is coupled to the branch cost model.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-thread-14.c: Adjust target selector.
---
gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-14.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gc
On 03/17/2017 04:14 PM, Segher Boessenkool wrote:
Thanks for not cc:ing me on any of this.
There's really no need for getting upset. Bernd posted the message to
the patches list. That's sufficient.
On Wed, Mar 15, 2017 at 04:00:21PM +0100, Bernd Schmidt wrote:
+/* Set up a set of register
On 03/17/2017 04:16 PM, Segher Boessenkool wrote:
On Wed, Mar 15, 2017 at 12:09:18AM +0100, Bernd Schmidt wrote:
I suppose at the moment we don't do 2->2 combinations, so we could
conditionalize this on having an i1.
You suppose wrong. If one of the resulting insns is set_noop_p then
2->2 is
On Wed, Mar 15, 2017 at 12:09:18AM +0100, Bernd Schmidt wrote:
> I suppose at the moment we don't do 2->2 combinations, so we could
> conditionalize this on having an i1.
You suppose wrong. If one of the resulting insns is set_noop_p then
2->2 is allowed, for example. Also in the hopefully not
Thanks for not cc:ing me on any of this.
On Wed, Mar 15, 2017 at 04:00:21PM +0100, Bernd Schmidt wrote:
> +/* Set up a set of registers used in an insn. Called through note_uses,
> + arguments as described for that function. */
> +
> +static void
> +record_used_regs (rtx *xptr, void *data)
> +
On Fri, 17 Mar 2017, Bill Schmidt wrote:
> Joseph, any further comments, or may I commit this?
Is there a current patch version somewhere reflecting all comments so far?
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, 17 Mar 2017, Marek Polacek wrote:
> This means precisely zilch, but hey, it's Friday. The references are mostly
> the same as C99, but they differ for e.g. declarators. I wish C had what C++
> has, i.e. references like [stmt.switch].
>
> Ok for trunk?
OK.
--
Joseph S. Myers
jos...@co
Am 17.03.2017 um 17:48 schrieb Markus Trippelsdorf:
You should use rdim not sdim in the GFC_ASSERT.
Fixed in rev 246248.
Sorry for the breakage.
Thomas
On 16/03/17 15:23 +, Jonathan Wakely wrote:
On 14/03/17 18:46 +, Jonathan Wakely wrote:
On 13/03/17 19:35 +, Jonathan Wakely wrote:
This is a series of patches to fix various bugs in the Unicode
character conversion facets.
Ther first patch fixes a silly < versus <= bug that meant
build_aggr_init was blithely passing most any initializer on to
build_vec_init, which saw a CONSTRUCTOR and assumed that it would be
of the right type, leading to an ICE. Fixed by not taking the
INIT_EXPR shortcut if the CONSTRUCTOR has the wrong type.
That returned us to the GCC 6 state, where w
On Tue, 14 Mar 2017 13:29:22 PDT (-0700), ger...@pfeifer.com wrote:
> On Mon, 13 Mar 2017, Palmer Dabbelt wrote:
>> A recent mailing list post about install.texi cleanup suggested I
>> take a look at ours, and there were a few problems:
>>
>> * No table of contents entries
>> * Not alphabetically
The code for setting CLASSTYPE_NON_AGGREGATE failed to consider
indirect virtual bases.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 18b4a698996d151d87e5db2084859c83facd798f
Author: Jason Merrill
Date: Fri Mar 17 13:14:42 2017 -0400
PR c++/80073 - C++17 ICE with virtual ba
This patch adds comments to clarify the automatic setting and clearing
of target attribute flags in order to assure consistency between
configuration settings and between multiple interrelated compilation
target options. Particular attention is given to the target options
that affect the C prepro
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80054 reports an ICE
in SSA validation after SLSR (definition does not dominate use).
The problem occurs within conditional strength reduction candidate
processing.
PRE creates a situation where a conditional SLSR candidate depends
on a PHI that is
Joseph, any further comments, or may I commit this?
Thanks!
Bill
> On Mar 13, 2017, at 6:31 PM, Segher Boessenkool
> wrote:
>
> Hi Bill,
>
> On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
>> Index: gcc/doc/extend.texi
>> =
> On Mar 17, 2017, at 9:52 AM, Bill Schmidt wrote:
>
> Hi,
>
>> On Mar 17, 2017, at 6:44 AM, Richard Biener
>> wrote:
>>
>> No, I was confused in thinking gimplify_expr would handle the case
>> properly. For
>> just gimplifying side-effects we should use the middle-end
>> gimplification mac
Fixes the reported typo in aarch64.opt (dummping -> dumping).
Committed as obvious.
* aarch64.opt(verbose-cost-dump): Fix typo.
diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
index
54368848bbb249949921a3018d927c4bd61b1fbd..942a7d558f26f0c8c18b0a94f4f92c575e06f057
1
On 2017.03.15 at 00:01 +0100, Thomas Koenig wrote:
> Hello world,
>
> well, here is the third attempt at fixing the second part of the PR.
> Glancing over the source, I think there are quite a few places where
> we currently issue a runtime error which we could replace by an
> assert, but that's s
This means precisely zilch, but hey, it's Friday. The references are mostly
the same as C99, but they differ for e.g. declarators. I wish C had what C++
has, i.e. references like [stmt.switch].
Ok for trunk?
2017-03-17 Marek Polacek
* c-parser.c: Add C11 references.
diff --git gcc/
On 03/15/2017 11:07 AM, Jeff Law wrote:
On 03/15/2017 09:00 AM, Bernd Schmidt wrote:
On 03/15/2017 12:09 AM, Bernd Schmidt wrote:
I'll retest with your
suggestion and with the bitmap creation conditional on i1 being nonnull.
Like this (also had to throw in a bitmap_empty_p). Retested as befo
This is the final patch which finally solves 71437. With the refactoring
in place, this patch is quite trivial.
All we do is record conditions implied by ASSERT_EXPRs we encounter
during the dominator walk. We also record implied conditions. So if we
had a == 12 in the ASSERT_EXPR, we'll r
On 03/17/2017 06:38 AM, Trevor Saunders wrote:
On Thu, Mar 16, 2017 at 01:17:13PM -0600, Jeff Law wrote:
+thread_outgoing_edges (basic_block bb, gcond *dummy_cond,
+ class const_and_copies *const_and_copies,
+ class avail_exprs_stack *avail_exprs_stack,
Hi,
> On Mar 17, 2017, at 6:44 AM, Richard Biener
> wrote:
>
> No, I was confused in thinking gimplify_expr would handle the case
> properly. For
> just gimplifying side-effects we should use the middle-end
> gimplification machinery:
>
> Index: tree-stdarg.c
> ===
Tested on Linux-x64.
2017-03-17 Ville Voutilainen
Implement LWG 2900, The copy and move constructors
of optional are not constexpr.
* include/std/optional (_Optional_payload): New.
(_Optional_base): Remove the bool parameter.
(_Optional_base<_Tp, false>): Remove.
(_Opti
Paolo recently added the perform_implicit_conversion_flags call in
build_must_not_throw_expr which means that COND might now be an
IMPLICIT_CONV_EXPR. That means we need to make sure that COND is instantiated
before we try to fold it, because we can get here while parsing a template.
Me & Paolo
The FP load and test instruction should not be used for a comparison if
the target operand is being used afterwards. It unfortunately turns
SNaNs into QNaNs.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
2017-03-17 Andreas Krebbel
* config/s390/s390.md ("cmp_ccs_0"): A
Hi Richard,
On 17/03/17 13:11, Richard Earnshaw (lists) wrote:
On 17/03/17 12:22, Kyrill Tkachov wrote:
Hi Sudi,
On 16/03/17 11:11, Sudi Das wrote:
Hi all
This is a cleanup patch to remove the macro TARGET_EITHER. This macro
seems to have become irrelevant in recent times since its previous
The following addresses PR80032 which reports that stack usage has gone
up since DCE got the ability to remove clobbers. (Control-dependent-)DCE
basically treats clobbers as not necessary and after eliminating
unnecessary stmts sees if it can retain them and if not, removes them.
This ability was
Uninitialized data are never good, especially with MALLOC_PERTURB_ set in
your environment. This patch from the PR fixes stuff for me.
Applying to trunk.
2017-03-17 Marek Polacek
Markus Trippelsdorf
PR tree-optimization/80079
* gimple-ssa-store-merging.c (class
On 17/03/17 12:22, Kyrill Tkachov wrote:
> Hi Sudi,
>
> On 16/03/17 11:11, Sudi Das wrote:
>>
>> Hi all
>>
>> This is a cleanup patch to remove the macro TARGET_EITHER. This macro
>> seems to have become irrelevant in recent times since its previous
>> definition had been commented out and replace
On Thu, Mar 16, 2017 at 01:17:13PM -0600, Jeff Law wrote:
> +thread_outgoing_edges (basic_block bb, gcond *dummy_cond,
> +class const_and_copies *const_and_copies,
> +class avail_exprs_stack *avail_exprs_stack,
nit picking, but what's the point in the class
Hi Sudi,
On 16/03/17 11:11, Sudi Das wrote:
Hi all
This is a cleanup patch to remove the macro TARGET_EITHER. This macro seems to
have become irrelevant in recent times since its previous definition had been
commented out and replaced with 1.
Bootstrapped and tested on arm-none-linux-gnueab
Ever since operation_could_trap_helper_p claimed that CONSTRUCTOR
(or COMPLEX_EXPR) cannot throw stmt_could_throw_1_p ignored whether
the LHS of an assignment possibly could. The following fixes this
by refactoring the code a bit and handling the LHS before the
RHS.
Bootstrapped on x86_64-unknow
Jakub Jelinek writes:
> On Fri, Mar 10, 2017 at 02:09:20PM +0100, Martin Liška wrote:
>> Hello.
>>
>> This is follow-up patch which I agreed on with Jakub.
>> It enables CHKP with LSAN and majority of UBSAN options.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
On Fri, Mar 17, 2017 at 12:54 PM, Tom de Vries wrote:
> On 14/03/17 13:30, Martin Liška wrote:
>>
>> Tested on my local machine that's properly installed.
>>
>> Ready for trunk?
>
>
> I'm guessing there's an invariant that installed tools mention a bug url
> with --help.
>
> Using attached patch,
On 14/03/17 13:30, Martin Liška wrote:
Tested on my local machine that's properly installed.
Ready for trunk?
I'm guessing there's an invariant that installed tools mention a bug url
with --help.
Using attached patch, we get:
...
$ gcov-dump --help
Usage: gcov-dump [OPTION] ... gcovfiles
Pr
On Tue, Mar 14, 2017 at 4:52 PM, Jeff Law wrote:
> On 03/14/2017 03:01 AM, Richard Biener wrote:
>>
>> On Tue, Mar 14, 2017 at 1:37 AM, Martin Sebor wrote:
>>>
>>> Ping: this a P3 regression targeted at 7.0.1. It was found
>>> on x86_64-apple-darwin10.8.0 but affects all targets (even
>>> if it
On Tue, Mar 14, 2017 at 10:36 PM, Bill Schmidt
wrote:
>
>> On Mar 14, 2017, at 11:07 AM, Bill Schmidt
>> wrote:
>>>
>>> Your suggestion failed bootstrap in libiberty on vprintf-support.c.
>>> Compilation failed with:
>>>
>>> /home/wschmidt/gcc/build/gcc-mainline-test2-debug/gcc/xgcc
>>> -B/ho
On Fri, Mar 17, 2017 at 11:55 AM, Martin Jambor wrote:
> Hi,
>
> I have noticed that -fipa-vrp was not documented in
> gcc/doc/invoke.texi so I propose the following. When at ti, I took
> the liberty of replacing "ipa" with "interprocedural" in the
> description of -fipa-bit-cp.
>
> Tested with m
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-03-17 Richard Biener
PR middle-end/80050
* genmatch.c (parser::next): Remove pointless check for CPP_EOF.
(parser::peek): Likewise.
Index: gcc/genmatch.c
=
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-03-17 Richard Biener
PR tree-optimization/80048
* sese.c (free_sese_info): Properly release rename_map and
copied_bb_map elements.
Index: gcc/sese.c
On Thu, Mar 16, 2017 at 08:26:42PM -0700, Jim Wilson wrote:
> On Thu, Mar 16, 2017 at 11:01 AM, Andrew Pinski wrote:
> > On Thu, Mar 16, 2017 at 10:22 AM, Wilco Dijkstra
> > wrote:
> >> Many supported cores implement fusion of AES instructions. When fusion
> >> happens it can give a significant
Hi,
I have noticed that -fipa-vrp was not documented in
gcc/doc/invoke.texi so I propose the following. When at ti, I took
the liberty of replacing "ipa" with "interprocedural" in the
description of -fipa-bit-cp.
Tested with make info, OK for trunk?
Thanks,
Martin
2017-03-17 Martin Jambor
When LTO was introduced, on macOS it needed darwin9 to work. Over time, most
tests for “*-apple-darwin9” in the toplevel configure were changed to also
include later darwin versions: *-darwin[[912]]* However, the check for LTO was
not updated. As far as I know, this is merely an oversight: LTO
On 09/03/17 14:42, Wilco Dijkstra wrote:
> Hi,
>
> Recently we've put a lot of effort into improving ifcvt to use CSEL on
> AArch64.
> In https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01639.html James determined
> the best value for AArch64 code generation. Although this setting is used
> when
This is a change I committed August 23rd last year, and now found
this mail to gcc-patches@ in my postponed folder. Ahem.
I'm not sure anyone still does any form of testing using this, but
at least the instructions (and links and how to build) are both more
up-to-date, general, and also shorter
50 matches
Mail list logo
