Hi.
This is small documentation fix, I'm going to install the patch
as obvious.
Now we display:
$ ./xg++ -B. --help=c++ | grep catch-value=
-Wcatch-value Warn about catch handlers of non-reference type.
Same as -Wcatch-value=.
-Wcatch-value=<0,3> Warn about catch ha
On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
> > It would help if you explained why you think it is a good idea
> > ignoring the other phi arguments if you have one (or more) where you can
> > determine length.
>
> It's a heuristic that was meant just for the -Wformat-overflow
> w
Hi.
This is equivalent patch for aarch64 target. I've tested that both as cross
compiler and native one.
Ready for trunk?
Thanks,
Martin
>From 4fbe17099f8618ddd6a4de2d269ecb6f99625927 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 20 Feb 2018 14:14:25 +0100
Subject: [PATCH 2/3] Add "native" as
Hi.
This is equivalent patch for ARM target.
Ready for trunk?
Thanks,
Martin
>From 656a883bc5239439ba80743f15a8df704501ee71 Mon Sep 17 00:00:00 2001
From: marxin
Date: Tue, 20 Feb 2018 14:09:22 +0100
Subject: [PATCH 1/3] Add "native" as a valid option value for -march= on arm
(PR driver/83193).
On 02/20/2018 05:26 PM, Martin Liška wrote:
> On 02/20/2018 05:19 PM, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>>> On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote:
Martin Liška writes:
> Hi.
>
> Following patch adds "native" as a possible option for -ma
Hello Richard,
On 14 фев 11:26, Richard Biener wrote:
>
> The following tries to account for the fact that when constructing
> AVX256 or AVX512 vectors from elements we can only use insertps to
> insert into the low 128bits of a vector but have to use
> vinserti128 or vinserti64x4 to build larger
On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
>> A safer and even more conservative alternative that should be
>> equivalent to your approach while avoiding the sprintf regressions
>> is to add another mode to the function and have it c
On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
>> A safer and even more conservative alternative that should be
>> equivalent to your approach while avoiding the sprintf regressions
>> is to add another mode to the function and have it c
On 02/20/2018 12:03 PM, Martin Sebor wrote:
>> The thing that isn't handled conservatively is PHIs and COND_EXPR.
>> The current code, if we can't figure one of the args out, for PHIs in
>> fuzzy mode increases the *maxval value to +INF, but doesn't touch
>> *minval, for COND_EXPR doesn't adjust th
On 02/20/2018 01:13 PM, Martin Sebor wrote:
> On 02/20/2018 12:03 PM, Martin Sebor wrote:
>> On 02/20/2018 10:17 AM, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> The following testcase distilled from pdftex is miscompiled on i?86,
>>> because gimple_fold_builtin_strlen sets incorrect value range on
>>> str
On 02/20/2018 05:14 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
>>> It would help if you explained why you think it is a good idea
>>> ignoring the other phi arguments if you have one (or more) where you can
>>> determine length.
>>
>> It's a heuristic t
On 02/20/2018 04:59 PM, Martin Sebor wrote:
>> It would help if you explained why you think it is a good idea
>> ignoring the other phi arguments if you have one (or more) where you can
>> determine length.
>
> It's a heuristic that was meant just for the -Wformat-overflow
> warning. When making
On 02/20/2018 05:00 PM, Joseph Myers wrote:
> Does this help with any of the cases in bug 80776 that weren't already
> fixed, or are those distinct despite looking similar?
>
I don't think so.
THe __builtin_unreachable markers are removed by vrp1 -- well before the
sprintf warning code gets run.
On 02/20/2018 05:14 PM, Jakub Jelinek wrote:
On Tue, Feb 20, 2018 at 04:59:12PM -0700, Martin Sebor wrote:
It would help if you explained why you think it is a good idea
ignoring the other phi arguments if you have one (or more) where you can
determine length.
It's a heuristic that was meant j
On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
> A safer and even more conservative alternative that should be
> equivalent to your approach while avoiding the sprintf regressions
> is to add another mode to the function and have it clear *minlen
> as an option. This lets the strlen
On 02/20/2018 05:48 AM, Nick Clifton wrote:
Hi Martin,
Since the class manages a resource it should ideally make sure it
doesn't try to release the same resource multiple times. I.e., its
copy constructor and assignment operators should either "do the right
thing" (whatever you think that is)
Does this help with any of the cases in bug 80776 that weren't already
fixed, or are those distinct despite looking similar?
--
Joseph S. Myers
jos...@codesourcery.com
It would help if you explained why you think it is a good idea
ignoring the other phi arguments if you have one (or more) where you can
determine length.
It's a heuristic that was meant just for the -Wformat-overflow
warning. When making decisions that affect code generation it's
obviously not
> Ping. Is this alright to apply now or should I wait for Stage 1?
>
> * plugin-api.h (ld_plugin_get_wrap_symbols): New
> plugin interface.
I'd say go ahead and apply the patch in binutils, and wait for Stage 1
to sync back to GCC, unless someone there OKs it sooner.
Nick, is that OK?
-cary
On 02/20/2018 02:34 PM, Jakub Jelinek wrote:
On Tue, Feb 20, 2018 at 01:13:13PM -0700, Martin Sebor wrote:
A safer and even more conservative alternative that should be
equivalent to your approach while avoiding the sprintf regressions
is to add another mode to the function and have it clear *mi
Hi!
This testcase got fixed in r257155 aka PR83942, but unlike
the PR83942 testcase which regressed during 8.x stage1 this one used
to fail before too, so I think it is worth adding another testcase for it.
Tested on x86_64-linux, committed to trunk as obvious.
2018-02-20 Jakub Jelinek
On Sat, Feb 17, 2018 at 7:08 PM, Kito Cheng wrote:
> Hi all:
>
> This patch is version 2 of FreeBSD supporting for RISC-V, Ruslan
> (RISC-V FreeBSD maintainer) and me has been tested on FreeBSD 12
> for building kernel and whole user space programs/libraries again :)
This looks OK.
> Copyright p
On Wed, Feb 7, 2018 at 2:10 PM, Max Filippov wrote:
> On Thu, Feb 1, 2018 at 9:12 AM, Max Filippov wrote:
>> On Wed, Jan 31, 2018 at 11:17 AM, Max Filippov wrote:
>>> On Wed, Jan 31, 2018 at 11:11 AM, augustine.sterl...@gmail.com
>>> wrote:
On Tue, Jan 30, 2018 at 8:02 PM, Max Filippov w
On 20/02/2018 20:59, Jonathan Wakely wrote:
On 8 February 2018 at 06:10, François Dumont wrote:
On 06/02/2018 20:16, François Dumont wrote:
On 05/02/2018 18:16, Jonathan Wakely wrote:
Wouldn't it make more sense to simply make __aligned_buffer identical
to __aligned_membuf for the versioned-na
On Tue, Feb 20, 2018 at 12:03:26PM -0700, Martin Sebor wrote:
> PR tree-optimization/84478 - [8 Regression] pdftex miscompilation on i386
>
> gcc/ChangeLog:
>
> PR tree-optimization/84478
> * gimple-fold.c (get_range_strlen): Set *MINLEN to zero.
> (get_range_strlen): Reset rang
On 02/20/2018 12:03 PM, Martin Sebor wrote:
On 02/20/2018 10:17 AM, Jakub Jelinek wrote:
Hi!
The following testcase distilled from pdftex is miscompiled on i?86,
because gimple_fold_builtin_strlen sets incorrect value range on
strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where
On 8 February 2018 at 06:10, François Dumont wrote:
> On 06/02/2018 20:16, François Dumont wrote:
>>
>> On 05/02/2018 18:16, Jonathan Wakely wrote:
>>>
>>> Wouldn't it make more sense to simply make __aligned_buffer identical
>>> to __aligned_membuf for the versioned-namespace? Then at least the
>>
Am 20.02.2018 um 20:10 schrieb Janne Blomqvist:
Shouldn't the second one be "stop 2"?
Corrected, r257859.
Regards
Thomas
On Mon, Feb 12, 2018 at 3:55 PM, Kugan Vivekanandarajah
wrote:
> Implements tree loop unroller using the infrastructure provided.
>
> gcc/ChangeLog:
>
> 2018-02-12 Kugan Vivekanandarajah
>
> * Makefile.in (OBJS): Add tree-ssa-loop-unroll.o.
> * common.opt (ftree-loop-unroll): New option
Const type promotion is the bane of embedded developers...
One thing to try is to use (subreg:QI in a define_expand, so that
there's a one_cmplhi2 pattern that expands to two QImode insns that
operate on HImode input/outputs via SUBREGs.
I don't have high hopes of gcc optimizing this properly in
On 02/20/2018 10:18 AM, Richard Sandiford wrote:
> r254302 tried to clean up find_widening_optab_handler_and_mode
> so that it really did only handle widening ops rather than
> simple single-mode ones. But this PR shows that I'd fluffed
> the MODE_PARTIAL_INT handling. It turns out that all four
On Tue, Feb 20, 2018 at 8:59 PM, Thomas Koenig wrote:
> Am 20.02.2018 um 08:51 schrieb Janne Blomqvist:
>
>> It's better to use gfc_mpz_get_hwi() instead of mpz_get_si().
>> mpz_get_si() returns a long, which is a 32-bit type on win64.
>>
>> Otherwise Ok with the spelling fix suggested by Steve.
>
On 02/20/2018 10:17 AM, Jakub Jelinek wrote:
Hi!
The following testcase distilled from pdftex is miscompiled on i?86,
because gimple_fold_builtin_strlen sets incorrect value range on
strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where
we can't determine anything about string len
The final patch, and the one that actually fixes 82123/81592. This
replaces the final query of global range information with a query into
the EVRP range analyzer and adds the new tests.
Bootstrapped and regression tested on x86_64-linux-gnu.
Jeff
* gimple-ssa-sprintf.c (format_integer):
Am 20.02.2018 um 08:51 schrieb Janne Blomqvist:
It's better to use gfc_mpz_get_hwi() instead of mpz_get_si().
mpz_get_si() returns a long, which is a 32-bit type on win64.
Otherwise Ok with the spelling fix suggested by Steve.
Committed as r257856.
Thanks to you and Steve for the review and
This is the 5th patch in the series. It updates another global range
query to instead use the EVRP range data. Bootstrapped and regression
tested on x86_64-linux-gnu.
Jeff
* gimple-ssa-sprintf.c (get_int_range): Query EVRP range analyzer for
range data rather than using global da
This is the 4th patch in the series. It doesn't change the analysis in
any way shape or form. It just arranges to pass around the range data
to the points where we're going to need it.
Bootstrapped and regression tested on x86_64-linux-gnu.
Jeff
commit e2b702e7bcb00c2197776691735ff8a599dce4
This is the 3rd patch in the series. It updates one of the 3 range
queries to start using the EVRP computed range data. This one is
trivial as it's occurring in a member function where we have direct
access to the range analyzer data.
Bootstrapped and regression tested on x86_64-linux-gnu.
Jef
This is the second patch in the series to fix 82123/81592. It generates
range information within the sprintf warning pass using the EVRP
analyzer. We don't use the range information in this patch.
This twiddles one test -- adding the calls into the analyzer from the
sprintf pass causes us to rec
This is part #1 of the patches to fix 81592/82123. The changes aren't
particularly large or invasive, but I already had them broken down
internally into distinct chunks, so I'm going to send them out that way.
This patch allows the EVRP range analyzer to be safely called even when
not optimizing.
So I'm finally getting back to this.
To recap, the issue here is the sprintf pass is querying global range
information. As a result the range for the key object is not narrowed
by the conditionals leading to the sprintf call and we get a false
positive (pr81592 and pr82123).
The plan for the las
Hi Andre,
Thanks for your latest work on CAF features. Could you let us know whether
this commit should be tested against the OpenCoarrays master branch or another
branch? With the master branch, I get one test failure (not counting two known
teams failures that are actually false negatives t
Hi!
The following testcase distilled from pdftex is miscompiled on i?86,
because gimple_fold_builtin_strlen sets incorrect value range on
strlen call on SSA_NAME with def_stmt of PHI <"mu", something> where
we can't determine anything about string length of something, so the
right value range is [
On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote:
> Martin Liška writes:
> > Hi.
> >
> > Following patch adds "native" as a possible option for -march value on
> > i386 target. I have similar patches for other targets. Would it be
> > possible to install the patch in current stag
Ping. Is this alright to apply now or should I wait for Stage 1?
* plugin-api.h (ld_plugin_get_wrap_symbols): New
plugin interface.
Thanks
Sri
On Thu, Feb 15, 2018 at 1:52 PM, Sriraman Tallam wrote:
> Ping, this patch was approved for binutils by Cary:
> https://sourceware.org/ml/binutils/2
While working on PR 83335 I proposed a change to a test case that
used __builtin_extend_pointer and Richared Earnshaw pointed out
that this builtin is not documented. Since I could not find any
other (reasonable) way to generate an extended address in inline
assembly other than this builtin I woul
r254302 tried to clean up find_widening_optab_handler_and_mode
so that it really did only handle widening ops rather than
simple single-mode ones. But this PR shows that I'd fluffed
the MODE_PARTIAL_INT handling. It turns out that all four
combinations of:
{MODE_INT,MODE_PARTIAL_INT}->{MODE_IN
This patch prevents pattern-matching of fold-left SLP reduction chains,
which the previous patch for 83965 didn't handle properly. It only
stops the last statement in the group from being matched, but that's
enough to cause the group to be dissolved later.
A better fix would be to put all the inf
On 02/20/2018 05:19 PM, Richard Sandiford wrote:
> Jakub Jelinek writes:
>> On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote:
>>> Martin Liška writes:
Hi.
Following patch adds "native" as a possible option for -march value on
i386 target. I have similar patch
Jakub Jelinek writes:
> On Tue, Feb 20, 2018 at 03:58:07PM +, Richard Sandiford wrote:
>> Martin Liška writes:
>> > Hi.
>> >
>> > Following patch adds "native" as a possible option for -march value on
>> > i386 target. I have similar patches for other targets. Would it be
>> > possible to in
Martin Liška writes:
> Hi.
>
> Following patch adds "native" as a possible option for -march value on
> i386 target. I have similar patches for other targets. Would it be
> possible to install the patch in current stage?
[...]
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> ind
Hi,
On Fri, 16 Feb 2018, Wilco Dijkstra wrote:
> > How so?
>
> I thought it is well-known for many years that the rtl unroller doesn't
> work properly. In practically all cases where LLVM beats GCC, it is due
> to unrolling small loops.
I thought it was because of vectorizing at -O2, not due
This libgo patch checks for preemption in the fast return path from a
system call. This helps with tight loops that make system calls, as
in BenchmarkSyscallExcessWork. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
On Tue, Feb 20, 2018 at 09:51:14AM +0200, Janne Blomqvist wrote:
> On Tue, Feb 20, 2018 at 12:41 AM, Thomas Koenig wrote:
> > Hello world,
> >
> > when putting in a seemingly innocent simplification for PR 56342,
> > I caused a regression in PR 82823, in PACK. The root cause of
> > this one turned
In Go, aliases are supposed to be identical to the type being aliased,
so questions about type compatibility need to always ignore aliases,
except for error messages involving the type name. This patch
implements that. This test case for this is
https://golang.org/cl/94995. This fixes
https://go
From: Claudiu Zissulescu
Cleanup unsed functions and macros.
OK to apply?
Claudiu
gcc/
2018-01-26 Claudiu Zissulescu
* config/arc/arc.c (arc_finalize_pic): Remove function.
(arc_must_save_register): We use single base PIC register, remove
checks to save/restore the P
On February 20, 2018 10:43:40 AM GMT+01:00, Richard Sandiford
wrote:
>expand_call_mem_ref checks for TARGET_MEM_REFs that have compatible
>type, but it didn't then go on to install the specific type we need,
>which might have different alignment due to:
>
> if (TYPE_ALIGN (type) != align)
>t
Hi.
Following patch adds "native" as a possible option for -march value on i386
target.
I have similar patches for other targets. Would it be possible to install the
patch in current stage?
Before:
$ ./xgcc -B. -march=abcdef /tmp/empty.c
cc1: error: bad value (‘abcdef’) for ‘-march=’ switch
cc1:
On February 19, 2018 11:02:50 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>While I've over-simplified the testcase and so this patch doesn't help
>the 628.pop2_s miscompare, I still believe it is beneficial to defer
>this
>folding until late for these reasons:
>1) if we propagate a constant into th
Hi Martin,
> Since the class manages a resource it should ideally make sure it
> doesn't try to release the same resource multiple times. I.e., its
> copy constructor and assignment operators should either "do the right
> thing" (whatever you think that is) or be made inaccessible (or declared
On Tue, Feb 20, 2018 at 01:05:33PM +0100, Martin Liška wrote:
> Hi.
>
> This is fix for one of multiple issues seen in the PR. Note that I also have
> some patches
> for the others, but it's not stage4 material in my opinion.
> This one is quite obvious and should land in GCC 8.
>
> Output befor
On Tue, Feb 20, 2018 at 11:05:50AM +0100, Martin Liška wrote:
> Thanks Jakub!
> Would it be possible to backport that to active branches?
Yes, but give it some time on the trunk first.
Jakub
On 02/20/2018 01:09 PM, Jakub Jelinek wrote:
> On Tue, Feb 20, 2018 at 01:05:33PM +0100, Martin Liška wrote:
>> Hi.
>>
>> This is fix for one of multiple issues seen in the PR. Note that I also have
>> some patches
>> for the others, but it's not stage4 material in my opinion.
>> This one is quite
Hello,
The following patch defines one_cmplhi2 pattern. The improvement does not
come from the two xor instructions used
(in fact for the second xor the pattern uses xor saddr , #byte is used which
is 1 bytes longer than xor a, #byte) it comes
from the fact that that the number of move instruct
Hi.
This is fix for one of multiple issues seen in the PR. Note that I also have
some patches
for the others, but it's not stage4 material in my opinion.
This one is quite obvious and should land in GCC 8.
Output before:
$ ./xgcc -B. -march=sparta /tmp/main.c
cc1: error: unknown value ‘sparta’ f
On Tuesday 20 February 2018 03:14 PM, Jakub Jelinek wrote:
> On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote:
>> The C++ frontend generates a break that results in the fallthrough
>> warning misfiring in nested switch blocks where cases in the inner
>> switch block return, render
On Feb 15 2018, Palmer Dabbelt wrote:
> On Mon, 12 Feb 2018 15:18:39 PST (-0800), Jim Wilson wrote:
>> On 02/12/2018 03:23 AM, Andreas Schwab wrote:
>>> On Feb 06 2017, Palmer Dabbelt wrote:
>>>
+/* Because RISC-V only has word-sized atomics, it requries libatomic where
+ others do n
On 02/20/2018 09:43 AM, Jakub Jelinek wrote:
> On Mon, Feb 12, 2018 at 01:09:43PM +0100, Martin Liška wrote:
>> Following patch fixes 2 issues with -falign-*:
>> 1) when using -malign-x=16 (or corresponding -falign-* value) then ICE
>> appeared
>> as code in final.c can deal just with limited alig
On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote:
> The C++ frontend generates a break that results in the fallthrough
> warning misfiring in nested switch blocks where cases in the inner
> switch block return, rendering the break pointless. The fallthrough
> detection in finish_
expand_call_mem_ref checks for TARGET_MEM_REFs that have compatible
type, but it didn't then go on to install the specific type we need,
which might have different alignment due to:
if (TYPE_ALIGN (type) != align)
type = build_aligned_type (type, align);
This was causing masked stores to be
On Monday 19 February 2018 09:59 PM, Siddhesh Poyarekar wrote:
> The C++ frontend generates a break that results in the fallthrough
> warning misfiring in nested switch blocks where cases in the inner
> switch block return, rendering the break pointless. The fallthrough
> detection in finish_break
On Mon, Feb 12, 2018 at 01:09:43PM +0100, Martin Liška wrote:
> Following patch fixes 2 issues with -falign-*:
> 1) when using -malign-x=16 (or corresponding -falign-* value) then ICE
> appeared
> as code in final.c can deal just with limited alignment.
> 2) thus I also documented and limited the
PING^1
On 02/12/2018 01:09 PM, Martin Liška wrote:
> Hi.
>
> Following patch fixes 2 issues with -falign-*:
> 1) when using -malign-x=16 (or corresponding -falign-* value) then ICE
> appeared
> as code in final.c can deal just with limited alignment.
> 2) thus I also documented and limited the m
73 matches
Mail list logo
