On Thu, 3 Aug 2017, Jeff Law wrote:
> On 08/03/2017 03:32 AM, Jakub Jelinek wrote:
> > On Thu, Aug 03, 2017 at 10:58:07AM +0200, Richard Biener wrote:
> >>> The reason why we punt is the unexpected _4 != 1 condition, the code
> >>> is prepared to handle just _4 == 0 (or _4 != 0) where _4 == 0 is
On Jul 27, 2017, at 2:07 AM, Pierre-Marie de Rodat wrote:
> On 07/27/2017 09:52 AM, Richard Biener wrote:
>>> I'm fine with the direction if a reviewer wants to go in that
>>> direction. I wish python didn't have a built-in speed penalty,
>>> that's the only downside I don't like about it. Aside
Ping
Richard Sandiford writes:
> Richard Sandiford writes:
>> Eric Botcazou writes:
>>> [Sorry for missing the previous messages]
>>>
Thanks. Just been retesting, and I think I must have forgotten
to include Ada last time. It turns out that the patch causes a dg-scan
regression
Hi,
Here's v2 of the patch with Jakub's suggestions incorporated. Bootstrapped
and tested on powerpc64le-linux-gnu with no regressions. Is this ok for
trunk?
Eventually this should be backported to all active releases as well.
Ok for that after a week or so of burn-in? (And after 7.2, I imagine
On 03.08.2017 18:04, Florian Weimer wrote:
* Yuri Gribov:
I've rebased the previous patch to trunk per Andrew's suggestion.
Original patch description/motivation/questions are in
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html
What about the remaining TODOs?
Yes, need to be fixed.
> On Aug 3, 2017, at 11:40 AM, David Miller wrote:
>
> From: Qing Zhao
> Date: Thu, 3 Aug 2017 10:37:15 -0500
>
>> all the special handling on STRICT_ALIGNMENT or
>> SLOW_UNALIGNMENT_ACCESS in these codes have the following common
>> logic:
>>
>> if the memory access is known to be not-aligne
> On Aug 2, 2017, at 6:43 PM, Segher Boessenkool
> wrote:
>
> Hi Bill,
>
> On Wed, Aug 02, 2017 at 10:29:20AM -0500, Bill Schmidt wrote:
>> I don't anticipate backporting any of this.
>
> Good :-)
>
>> @@ -6802,7 +6802,7 @@ altivec_resolve_overloaded_builtin (location_t loc
>> if (unsupp
This patch to libgo changes the mksigtab script to recognize the glibc
2.26 NSIG expression. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline. Will commit to GCC 7
branch when it reopens. This fixes GCC PR 81617 and
https://golang.org/issue/21147.
Ian
Index: gcc/
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Aug 3, 2017, at 11:39 AM, Jakub Jelinek wrote:
>
> On Thu, Aug 03, 2017 at 11:29:44AM -0500, Bill Schmidt wrote:
>>> And, wouldn't it be more readable to us
On 07/03/2017 11:32 AM, David Malcolm wrote:
> On Mon, 2017-07-03 at 10:25 -0600, Jeff Law wrote:
>> On 05/05/2017 11:51 AM, David Malcolm wrote:
>>> In various places we use lookup_name_fuzzy to provide a hint,
>>> and can report messages of the form:
>>> error: unknown foo named 'bar'
>>> or:
>
On 08/01/2017 02:21 PM, David Malcolm wrote:
> Changed in v2:
>
> * Renamed template argument to traits_t; eliminated subclasses, just
> using traits struct.
> * Moved enum constants into struct bodies (string constants can't be
> without constexpr, which isn't available in C++98).
> * Fixed t
On Thu, Aug 03, 2017 at 10:01:41AM -0500, Segher Boessenkool wrote:
> Hi Mike,
>
> On Wed, Aug 02, 2017 at 10:28:55AM -0400, Michael Meissner wrote:
> > On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote:
> > > I think calling this with the rtx elementN args makes this only more
>
On 08/01/2017 02:21 PM, David Malcolm wrote:
> (Unchanged since v1; already approved by Marek, assuming 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_pa
On 08/03/2017 11:03 AM, Florian Weimer wrote:
> * Jeff Law:
>
>>> If speed is not a concern, but reliability is, call fork (the system
>>> call, not glibc's wrapper which calls fork handlers) and do the work
>>> in a single-threaded copy of the process. There, you can set up
>>> signal handlers a
> On 03 Aug 2017, at 17:30, Jeff Law wrote:
>
>>* Makefile.in (install-mkheaders): Fix typo, where the multi_dir
>>variable was referenced as multidir in command.
>>
> OK.
Great, Thanks Jeff!
* Yuri Gribov:
> I've rebased the previous patch to trunk per Andrew's suggestion.
> Original patch description/motivation/questions are in
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html
What about the remaining TODOs?
> + if (__builtin_expect (msync ((void *)page, len, MS_ASYNC), 0
On Thu, Aug 3, 2017 at 6:51 AM, Richard Biener wrote:
> On Wed, 2 Aug 2017, Jason Merrill wrote:
>
>> On Wed, Aug 2, 2017 at 6:35 AM, Richard Biener wrote:
>> > On Wed, 2 Aug 2017, Jason Merrill wrote:
>> >
>> >> On 05/19/2017 06:42 AM, Richard Biener wrote:
>> >> > + /* ??? In some cases th
* Jeff Law:
>> If speed is not a concern, but reliability is, call fork (the system
>> call, not glibc's wrapper which calls fork handlers) and do the work
>> in a single-threaded copy of the process. There, you can set up
>> signal handlers as you see fit, and the VM layout won't change
>> unexp
Jeff Law:
> On 08/02/2017 08:06 PM, Ximin Luo wrote:
>> Jeff Law:
>>> On 07/21/2017 10:15 AM, Ximin Luo wrote:
(Please keep me on CC, I am not subscribed)
Proposal
This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP.
When
th
On 08/02/2017 10:07 AM, Tom de Vries wrote:
> Hi,
>
> I.
>
> for target nvptx we recently ran into PR81442, an ICE in verify_flow_info:
> ...
> error: verify_flow_info: REG_BR_PROB is set but cfg probability is not
> ...
>
> We start out with a jump instruction:
> ...
> (jump_insn 18 17 31 2 (se
From: Qing Zhao
Date: Thu, 3 Aug 2017 10:37:15 -0500
> all the special handling on STRICT_ALIGNMENT or
> SLOW_UNALIGNMENT_ACCESS in these codes have the following common
> logic:
>
> if the memory access is known to be not-aligned well during
> compilation time, if the targeted platform does NOT
On Thu, Aug 03, 2017 at 11:29:44AM -0500, Bill Schmidt wrote:
> > And, wouldn't it be more readable to use:
> > && (TYPE_UNSIGNED (target_type)
> > ? (wi::eq_p (bump, wi::zext (bump, prec))
> > || wi::eq_p (bump + wi::to_widest (maxval) + 1,
> > wi::zext (b
On Thu, 2017-08-03 at 19:31 +0300, Alexander Monakov wrote:
>
> My mistake, but the main point remains: STL uses 'sort' without the
> 'q'.
I think it'd be better if GCC's custom containers somewhat tried to
follow C++ standard container idioms. Chopping off the 'q' is one step
towards it.
Cheer
On Fri, 4 Aug 2017, Oleg Endo wrote:
> > Note that with vec::qsort -> vec::sort renaming (which should be less
> > controversial, STL also has std::vector::sort)
>
> No it doesn't? One uses std::sort from on a pair of random
> access iterators to sort a std::vector.
My mistake, but the main poi
On Aug 3, 2017, at 11:20 AM, Jakub Jelinek wrote:
>
> On Thu, Aug 03, 2017 at 11:05:54AM -0500, Bill Schmidt wrote:
>> --- gcc/gimple-ssa-strength-reduction.c (revision 250791)
>> +++ gcc/gimple-ssa-strength-reduction.c (working copy)
>> @@ -2074,6 +2074,10 @@ replace_mult_candidate (sl
On Thu, Aug 03, 2017 at 07:23:31PM +0300, Alexander Monakov wrote:
> On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> > Do we really need to rename and poison anything? qsort () in the source is
> > something that is most obvious to developers, so trying to force them to use
> > something different will
On Thu, 2017-08-03 at 19:23 +0300, Alexander Monakov wrote:
>
> Note that with vec::qsort -> vec::sort renaming (which should be less
> controversial, STL also has std::vector::sort)
No it doesn't? One uses std::sort from on a pair of random
access iterators to sort a std::vector.
Cheers,
Oleg
On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> Do we really need to rename and poison anything? qsort () in the source is
> something that is most obvious to developers, so trying to force them to use
> something different will just mean extra thing to learn.
Yep, I'd prefer to have a solution that k
On Thu, Aug 03, 2017 at 11:05:54AM -0500, Bill Schmidt wrote:
> --- gcc/gimple-ssa-strength-reduction.c (revision 250791)
> +++ gcc/gimple-ssa-strength-reduction.c (working copy)
> @@ -2074,6 +2074,10 @@ replace_mult_candidate (slsr_cand_t c, tree basis_
> {
>tree target_type = TRE
On 08/03/2017 02:27 AM, Pierre-Marie de Rodat wrote:
> On 08/02/2017 05:43 PM, Jeff Law wrote:
>> I hate to throw in a wrench at this point, but has anyone looked at
>> dwgrep from Petr Machata? He's not doing much with it anymore, but it
>> might provide enough of a dwarf scanning framework to be
On 08/03/2017 03:02 AM, Jan Hubicka wrote:
>> On 08/02/2017 01:51 PM, Richard Biener wrote:
>>> On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška wrote:
Hello.
After some discussions with Honza, I've decided to convert current code in
stmt.c that
is responsible for switch expa
On 08/03/2017 03:32 AM, Jakub Jelinek wrote:
> On Thu, Aug 03, 2017 at 10:58:07AM +0200, Richard Biener wrote:
>>> The reason why we punt is the unexpected _4 != 1 condition, the code
>>> is prepared to handle just _4 == 0 (or _4 != 0) where _4 == 0 is equivalent
>>> to _4 != 1 for boolean type.
>>
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81503 identifies a problem in
SLSR where an invalid replacement is made because the desired value doesn't
fit in the target type. This patch addresses that issue. The signed case
is simple, as we require the value not to change when restricted to
On 08/02/2017 08:06 PM, Ximin Luo wrote:
> Jeff Law:
>> On 07/21/2017 10:15 AM, Ximin Luo wrote:
>>> (Please keep me on CC, I am not subscribed)
>>>
>>>
>>> Proposal
>>>
>>>
>>> This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP.
>>> When
>>> this is set, GCC will tre
On 08/02/2017 10:47 PM, Yury Gribov wrote:
> On 03.08.2017 3:06, Ximin Luo wrote:
>> Jeff Law:
>>> On 07/21/2017 10:15 AM, Ximin Luo wrote:
(Please keep me on CC, I am not subscribed)
Proposal
This patch series adds a new environment variable
BUILD_P
On Thu, Aug 03, 2017 at 09:48:47AM -0600, Jeff Law wrote:
> > If speed is not a concern, but reliability is, call fork (the system
> > call, not glibc's wrapper which calls fork handlers) and do the work
> > in a single-threaded copy of the process. There, you can set up
> > signal handlers as you
On Thu, Aug 03, 2017 at 09:33:13AM -0600, Jeff Law wrote:
> On 08/03/2017 08:24 AM, Alexander Monakov wrote:
> > On Wed, 2 Aug 2017, Jeff Law wrote:
> Well, there's not *that* many qsort calls. My quick grep shows 94 and
> its a very mechanical change. Then a poison in system.h to ensur
On Thu, Aug 3, 2017 at 4:28 PM, H.J. Lu wrote:
> On Thu, Aug 3, 2017 at 8:25 AM, Jeff Law wrote:
>> On 08/03/2017 08:17 AM, Yury Gribov wrote:
>>> On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
wrote:
> On Thu, Aug 3, 2017 at 1:22 PM, H
On 08/02/2017 03:36 PM, Florian Weimer wrote:
> * Jeff Law:
>
>> Something like setup a signal handler when we first start unwinding that
>> flags the error and tear it down when we're done unwinding?Obviously
>> we can't do setup/tear down each time for each address. Anyway, just
>> thinking
To be more specified, when reading all the codes corresponding to
“STRICT_ALIGNMENT” and “SLOW_UNALIGNMENT_ACCESS” in gcc
(NOTE, SLOW_UNALIGNMENT_ACCESS is the same as STRICT_ALIGNMENT when it is NOT
defined explicitly, this is the case for SPARC)
We can get the following summary:
all the spe
On 08/03/2017 08:24 AM, Alexander Monakov wrote:
> On Wed, 2 Aug 2017, Jeff Law wrote:
Well, there's not *that* many qsort calls. My quick grep shows 94 and
its a very mechanical change. Then a poison in system.h to ensure raw
calls to qsort don't return.
>
> Note that poisoning q
On 08/03/2017 08:41 AM, Olivier Hainque wrote:
> Hello,
>
> The attached patch fixes a typo in a Makefile rule, which
> we noticed while working on fixincludes for a specific target.
>
> Bootstrapped and regression tested fine on x86_64-linux.
>
> OK to commit ?
>
> Thanks much in advance for y
On 08/03/2017 06:52 AM, Yury Gribov wrote:
> On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
>> On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov
>> wrote:
>>> On 02.08.2017 23:04, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 1:56 PM, Yury Gribov
wrote:
>
> On 02.08.2017 21:48, H.J. Lu
On Thu, Aug 3, 2017 at 8:25 AM, Jeff Law wrote:
> On 08/03/2017 08:17 AM, Yury Gribov wrote:
>> On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
>>> On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
>>> wrote:
On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
> On Wed, Aug 2, 2017 at 9:29 PM, Yu
On 08/03/2017 08:17 AM, Yury Gribov wrote:
> On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
>> On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
>> wrote:
>>> On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov
wrote:
> On 02.08.2017 23:04, H.J.
On Thu, Aug 3, 2017 at 8:07 AM, Yury Gribov wrote:
> On Thu, Aug 3, 2017 at 3:55 PM, H.J. Lu wrote:
>> On Thu, Aug 3, 2017 at 7:17 AM, Yury Gribov
>> wrote:
>>> On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
wrote:
> On Thu, Aug 3, 20
On Thu, Aug 3, 2017 at 3:55 PM, H.J. Lu wrote:
> On Thu, Aug 3, 2017 at 7:17 AM, Yury Gribov
> wrote:
>> On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
>>> On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
>>> wrote:
On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
> On Wed, Aug 2, 2017 at
Description:
* This patch provides the 2nd part of the support for DWARF debug sections in
XCOFF.
ImportedSymbols() and ImportedLibraries() functions are not implemented.
Tests:
* AIX: Build: SUCCESS
- build made by means of gmake in trunk.
- patch generated by:
cd gcc-svn-t
Hi Mike,
On Wed, Aug 02, 2017 at 10:28:55AM -0400, Michael Meissner wrote:
> On Fri, Jul 28, 2017 at 04:08:50PM -0500, Segher Boessenkool wrote:
> > I think calling this with the rtx elementN args makes this only more
> > complicated (the function comment doesn't say what they are or what
> > NULL
On Thu, Aug 3, 2017 at 7:17 AM, Yury Gribov wrote:
> On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
>> On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
>> wrote:
>>> On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov
wrote:
> On 02.08.2017 23:
On Thu, Aug 03, 2017 at 02:38:35PM +, Joseph Myers wrote:
> On Thu, 3 Aug 2017, Jakub Jelinek wrote:
>
> > In any case, you should probably investigate all the locales say in glibc or
> > some other big locale repository whether tolower/toupper have the expected
> > properties there.
>
> They
Hello,
The attached patch fixes a typo in a Makefile rule, which
we noticed while working on fixincludes for a specific target.
Bootstrapped and regression tested fine on x86_64-linux.
OK to commit ?
Thanks much in advance for your feedback,
With Kind Regards,
Olivier
2017-08-04 Douglas Rup
On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> In any case, you should probably investigate all the locales say in glibc or
> some other big locale repository whether tolower/toupper have the expected
> properties there.
They don't. In tr_TR.UTF-8, toupper ('i') == 'i', because 'İ', the
correct upp
On Wed, 2 Aug 2017, Jeff Law wrote:
> >> Well, there's not *that* many qsort calls. My quick grep shows 94 and
> >> its a very mechanical change. Then a poison in system.h to ensure raw
> >> calls to qsort don't return.
Note that poisoning qsort outlaws vec::qsort too; it would need to be mass-
On Thu, Aug 3, 2017 at 2:01 PM, H.J. Lu wrote:
> On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov
> wrote:
>> On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
>>> On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov
>>> wrote:
On 02.08.2017 23:04, H.J. Lu wrote:
>
> On Wed, Aug 2, 2017 at 1:56 P
> On Aug 2, 2017, at 6:17 PM, David Miller wrote:
>
> From: Qing Zhao
> Date: Wed, 2 Aug 2017 14:41:51 -0500
>
>> so, could you please specify what kind of side effects will have
>> when set STRICT_ALIGNMENT to true on TARGET_MISALIGN?
>
> Why don't you read the code rather than just relying
On Thu, Aug 3, 2017 at 2:56 PM, Richard Biener wrote:
> I think the main reason for not doing it early is the benefit is small
> (unless it is GIMPLE optimizations triggering)
Agree.
> and we can't get rid of
> switches completely because we eventually have to support casei RTL expansion.
> (and
> On Thu, Aug 3, 2017 at 2:52 PM, Steven Bosscher wrote:
> > On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška wrote:
> >> Hello.
> >>
> >> After some discussions with Honza, I've decided to convert current code in
> >> stmt.c that
> >> is responsible for switch expansion. More precisely, I would like
On Thu, Aug 3, 2017 at 5:52 AM, Yury Gribov wrote:
> On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
>> On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov
>> wrote:
>>> On 02.08.2017 23:04, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 1:56 PM, Yury Gribov
wrote:
>
> On 02.08.2017 21:48
On Thu, Aug 3, 2017 at 2:52 PM, Steven Bosscher wrote:
> On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška wrote:
>> Hello.
>>
>> After some discussions with Honza, I've decided to convert current code in
>> stmt.c that
>> is responsible for switch expansion. More precisely, I would like to convert
>
On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška wrote:
> Hello.
>
> After some discussions with Honza, I've decided to convert current code in
> stmt.c that
> is responsible for switch expansion. More precisely, I would like to convert
> the code
> to expand gswitch statements on tree level. Current
On Thu, Aug 3, 2017 at 1:22 PM, H.J. Lu wrote:
> On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov
> wrote:
>> On 02.08.2017 23:04, H.J. Lu wrote:
>>>
>>> On Wed, Aug 2, 2017 at 1:56 PM, Yury Gribov
>>> wrote:
On 02.08.2017 21:48, H.J. Lu wrote:
>
>
> On Wed, Aug 2, 2017 at 1:39
On Wed, Aug 2, 2017 at 9:29 PM, Yury Gribov wrote:
> On 02.08.2017 23:04, H.J. Lu wrote:
>>
>> On Wed, Aug 2, 2017 at 1:56 PM, Yury Gribov
>> wrote:
>>>
>>> On 02.08.2017 21:48, H.J. Lu wrote:
On Wed, Aug 2, 2017 at 1:39 PM, Yury Gribov
wrote:
>
>
> On 02.08.
On Wed, Aug 2, 2017 at 1:51 PM, Richard Biener wrote:
> On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška wrote:
>> Hello.
>>
>> After some discussions with Honza, I've decided to convert current code in
>> stmt.c that
>> is responsible for switch expansion. More precisely, I would like to convert
>>
$subject because if we put anything decl-ish there
(set_decl_origin_self...) then we run into lto_fixup_prevailing_decls
ICEing as the state is now no longer the same as during the
time we called mentions_vars_p.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-08-03 Ric
The following makes reassoc also break up subtracts for values used
on the positive side of a MINUS_EXPR.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2017-08-03 Richard Biener
* tree-ssa-reassoc.c (should_break_up_subtract): Also break
up if the use i
This tries to fix all the UBSAN issues in the reassoc case of fold_binary
by never generating any NEGATE_EXPRs from split_tree or association.
This means we have to track minus_var/minus_con and appropriately
transform.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
This
Yury Gribov:
> On 03.08.2017 3:06, Ximin Luo wrote:
>> Jeff Law:
>>> On 07/21/2017 10:15 AM, Ximin Luo wrote:
(Please keep me on CC, I am not subscribed)
Proposal
This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP.
When
thi
[ was: Re: [testsuite, PR81662, committed] Skip
fpatchable-function-entry tests for nvptx ]
On 08/03/2017 09:17 AM, Tom de Vries wrote:
Hi,
fpatchable-function-entry requires nop, which nvptx does not have.
I've disabled the corresponding test for nvptx.
This patch errors out on nvptx for f
On Thu, Aug 03, 2017 at 04:13:38PM +0530, Prathamesh Kulkarni wrote:
> > You are hardcoding here host characters and using it for target.
> > I think you need to use
> > lang_hooks.to_target_charset
> > (really no idea how it works or doesn't in LTO, but gimple-fold.c is already
> > using it among
On Wed, 2 Aug 2017, Jason Merrill wrote:
> On Wed, Aug 2, 2017 at 6:35 AM, Richard Biener wrote:
> > On Wed, 2 Aug 2017, Jason Merrill wrote:
> >
> >> On 05/19/2017 06:42 AM, Richard Biener wrote:
> >> > + /* ??? In some cases the C++ FE (at least) fails to
> >> > +set DECL_CONTEXT p
On 3 August 2017 at 13:21, Jakub Jelinek wrote:
> On Thu, Aug 03, 2017 at 12:58:06PM +0530, Prathamesh Kulkarni wrote:
>> --- a/gcc/tree-vrp.c
>> +++ b/gcc/tree-vrp.c
>> @@ -3778,6 +3778,19 @@ extract_range_basic (value_range *vr, gimple *stmt)
>> return;
>> }
>>
Hello,
On top of the correction for fallouts proposed in
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00271.html
the attached patch is needed to support targets still
resorting to DWARF2 unwinding on ARM, such as VxWorks6
(VxWorks7 has moved to ARM EH).
Tested by verifying that a build with
Hi All,
this patch implements a optimization rewriting
x * copysign (1.0, y)
to:
x ^ (y & (1 << sign_bit_position))
This is only done when not honoring signaling NaNs.
This transormation is done at ssa mult widening time and
is gated on the a check for the optab "xorsign".
If the optab is not
On Thu, Aug 03, 2017 at 10:58:07AM +0200, Richard Biener wrote:
> > The reason why we punt is the unexpected _4 != 1 condition, the code
> > is prepared to handle just _4 == 0 (or _4 != 0) where _4 == 0 is equivalent
> > to _4 != 1 for boolean type.
>
> Hmm, I thought we had code to canonicalize b
On Thu, Aug 03, 2017 at 11:02:51AM +0200, Richard Biener wrote:
> On Thu, 3 Aug 2017, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following testcase ICEs on s390x. The problem is that the bbpart pass
> > calls
> > df_set_flags (DF_DEFER_INSN_RESCAN);
> > because it wants to defer rescanning, but
> On 03 Aug 2017, at 11:02, Olivier Hainque wrote:
> The attached patch is a proposal to fix this by setting MEM_VOLATILE_P on
> the store destination mem instead of setting RTX_FRAME_RELATED_P on the insn,
> which alleviates the .cfi complications and is as effective in preventing
> the store r
On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on s390x. The problem is that the bbpart pass
> calls
> df_set_flags (DF_DEFER_INSN_RESCAN);
> because it wants to defer rescanning, but doesn't actually df_finish_pass
> (it does in one case, but then calls df_set_fl
Hello,
Activating dwarf2 based eh for real on VxWorks6 (patch to come) triggers a
libgcc build failure, where most functions resorting to __builtin_eh_return
fail this check from maybe_record_trace_start in dwarf2cfi.c:
/* We ought to have the same state incoming to a given trace no
> On 08/02/2017 01:51 PM, Richard Biener wrote:
> > On Wed, Aug 2, 2017 at 1:20 PM, Martin Liška wrote:
> >> Hello.
> >>
> >> After some discussions with Honza, I've decided to convert current code in
> >> stmt.c that
> >> is responsible for switch expansion. More precisely, I would like to
> >>
On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to fix some overflows during computation of the size
> and then effectively uses MIN (SSIZE_MAX, user_specified_value) as the
> bound.
>
> Not really sure what exact behavior we want, whether that, or default
> to SSIZE_MAX (
On Thu, 3 Aug 2017, Jakub Jelinek wrote:
> Hi!
>
> For the PR81588 testcase, on targets with branch cost 1, we end up with:
> b.0_1 = b;
> _2 = (long long int) b.0_1;
> a.1_3 = a;
> _4 = _2 > a.1_3;
> _5 = (int) _4;
> if (a.1_3 < 0)
> goto ; [36.00%] [count: INV]
> else
> go
On Wed, Aug 2, 2017 at 7:10 PM, Jeff Law wrote:
> On 08/01/2017 03:25 AM, Richard Biener wrote:
>> On Tue, Aug 1, 2017 at 11:23 AM, Richard Biener
>> wrote:
>>> On Tue, Aug 1, 2017 at 4:27 AM, Martin Sebor wrote:
Richard,
in discussing this work Jeff mentioned that your comments o
Hi!
The following testcase ICEs on s390x. The problem is that the bbpart pass
calls
df_set_flags (DF_DEFER_INSN_RESCAN);
because it wants to defer rescanning, but doesn't actually df_finish_pass
(it does in one case, but then calls df_set_flags with another changeable flag,
so it has the same iss
Hi!
This patch attempts to fix some overflows during computation of the size
and then effectively uses MIN (SSIZE_MAX, user_specified_value) as the
bound.
Not really sure what exact behavior we want, whether that, or default
to SSIZE_MAX (note the documentation mistakenly talks about SIZE_MAX / 2
Hi!
The (mini)pass to diagnose invalid OpenMP/OpenACC/Cilk+ constructs wasn't
mistakenly run for -fopenmp-simd, so non-conforming simd constructs weren't
diagnosed, but could easily ICE later on, because we assume the body of the
loop is a structured block (single entry, single exit, no branches i
On Wed, 2 Aug 2017, Ian Lance Taylor wrote:
> On Wed, Aug 2, 2017 at 4:17 AM, Richard Biener wrote:
> >
> > Status
> > ==
> >
> > The GCC 7 branch is now frozen for the upcoming release candidate
> > and release. All changes require release manager approval.
>
> Whoops, I committed a patch
On 08/02/2017 08:43 PM, Jeff Law wrote:
If it was trivial, then let's support 2.6. But if it's nontrivial, I'd
support stepping to something more modern.
It is trivial. I’ve done it locally. :-)
--
Pierre-Marie de Rodat
On 08/02/2017 05:43 PM, Jeff Law wrote:
I hate to throw in a wrench at this point, but has anyone looked at
dwgrep from Petr Machata? He's not doing much with it anymore, but it
might provide enough of a dwarf scanning framework to be useful for
testing purposes.
Sure, no problem: I first star
Hi!
For the PR81588 testcase, on targets with branch cost 1, we end up with:
b.0_1 = b;
_2 = (long long int) b.0_1;
a.1_3 = a;
_4 = _2 > a.1_3;
_5 = (int) _4;
if (a.1_3 < 0)
goto ; [36.00%] [count: INV]
else
goto ; [64.00%] [count: INV]
[64.00%] [count: INV]:
if (_4 !=
On Thu, Aug 03, 2017 at 12:58:06PM +0530, Prathamesh Kulkarni wrote:
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -3778,6 +3778,19 @@ extract_range_basic (value_range *vr, gimple *stmt)
> return;
> }
> break;
> + case CFN_BUILT_IN_TOUPPER:
> + case CF
Hi,
The attached patch adds value-range info for __builtin_tolower and
__builtin_toupper.
In the patch, I have just settled for anti-range ~['a', 'z'] for
return value of toupper.
Would that be correct albeit imprecise ?
A more precise range would be:
[0, UCHAR_MAX] intersect ~['a', 'z'] union EOF
Hi,
this patch requires alias support for gcc.dg/pr56727-2.c.
Committed.
Thanks,
- Tom
Require alias for gcc.dg/pr56727-2.c
2017-08-02 Tom de Vries
* gcc.dg/pr56727-2.c: Require alias.
---
gcc/testsuite/gcc.dg/pr56727-2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite
Hi,
this patch requires effective target alloca for gcc.dg/attr-noipa.c.
Committed.
Thanks,
- Tom
Require alloca for gcc.dg/attr-noipa.c
2017-08-02 Tom de Vries
* gcc.dg/attr-noipa.c: Require alloca.
---
gcc/testsuite/gcc.dg/attr-noipa.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi,
this patch requires effective target label_values for
gcc.dg/torture/pr80163.c.
Committed.
Thanks,
- Tom
Require label_values for gcc.dg/torture/pr80163.c
2017-08-02 Tom de Vries
* gcc.dg/torture/pr80163.c: Require label_values.
---
gcc/testsuite/gcc.dg/torture/pr80163.c | 1 +
1
Hi,
fpatchable-function-entry requires nop, which nvptx does not have.
I've disabled the corresponding test for nvptx.
I suppose I could add an effective target has_nop, but I'm not sure if
it's worth the trouble.
Committed.
Thanks,
- Tom
Skip fpatchable-function-entry tests for nvptx
2017
96 matches
Mail list logo
