This is just a straight cut-n-paste pulling the evrp_range_analyzer
methods out of gimple-ssa-evrp.c into gimple-ssa-evrp-analyze.[ch].
Bootstrapped and regression tested on x86_64.
OK for the trunk?
Jeff
* Makefile.in (OBJS): Add gimple-ssa-evrp-analyze.o.
* gimple-ssa-evrp-
I didn't want to rebase my patchset yet again to fix this minor goof. I
moved initialization of BB_VISITED into the range analyzer, but forgot
to move setting it as we visit each block into the analyzer.
This fixes that oversight.
Bootstrapped and regression tested on x86.
OK for the trunk?
J
A batch of random cleanups in the various vrp related bits.
The goal here is to start banging some of the classes into shape.
Included in this patch:
For evrp_folder:
Accepts vr_values in its ctor to attach.
Uses DISABLE_COPY_AND_ASSIGN
For evrp_dom_walker:
Has the evrp_folder attached t
Not as extensive as the last set. Just getting a couple data members
privatized as well as one method within vr_values.
I'd really like to just get values_propagated out of vr_values and bury
it in tree-vrp.c, but we're not to that point yet.
Bootstrapped and regression tested on x86.
OK for t
On Fri, 17 Nov 2017, Jason Merrill wrote:
It's not clear to me that cp_build_binary_op needs to handle
POINTER_DIFF_EXPR, it should get MINUS_EXPR and produce
POINTER_DIFF_EXPR.
Indeed, I added POINTER_DIFF_EXPR in many places by looking for
MINUS_EXPR, but this one is useless, regtesting pass
And a WIP. I can justify continuing work on this during stage3 for
pr78496. But I thought it was worth giving folks a looksie.
The goal here is to make tree-vrp's threading obsolete and remove it and
at the same time pick up all the missed jump threads in pr78496.
Essentially this patch embeds
On Fri, 17 Nov 2017, DJ Delorie wrote:
Richard Biener writes:
The question is what ptrdiff_t is for a specific address space. Or
rather if that type may be dependent on the address space or if we can
always use that of the default address space.
Some targets have a "far" address space that'
On Fri, 17 Nov 2017, Richard Biener wrote:
On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse wrote:
The exact undefined-behavior status should probably be clarified more.
First, I'd like to say that POINTER_DIFF_EXPR may only take 2 pointers into
the same "object" (like in C/C++), so they differ
On Fri, 17 Nov 2017, Joseph Myers wrote:
On Fri, 17 Nov 2017, DJ Delorie wrote:
Richard Biener writes:
The question is what ptrdiff_t is for a specific address space. Or
rather if that type may be dependent on the address space or if we can
always use that of the default address space.
Som
On 2017.11.18 at 00:39 +0100, Jan Hubicka wrote:
> Hi,
> this patch fixes remaining IPA profile updating issues I am aware of. With
> this change there is 1 profile mismatch after inlining for tramp3d -Ofast
> and 112 of them in .optimized dump which is about 10 times less than before.
> I did not
This is accomplished by making the NEXTREC specifier be a 8 byte
integer where supported.
I wasn't able to come up with a testcase that does not create a large
file that could be added to the testsuite, but here's one which
creates a 2 GB file:
program nextrec
implicit none
integer(8) :: ii,
On Sat, Nov 18, 2017 at 12:34 PM, Janne Blomqvist
wrote:
> This is accomplished by making the NEXTREC specifier be a 8 byte
> integer where supported.
>
> I wasn't able to come up with a testcase that does not create a large
> file that could be added to the testsuite, but here's one which
> creat
On November 18, 2017 11:20:42 AM GMT+01:00, Marc Glisse
wrote:
>On Fri, 17 Nov 2017, Richard Biener wrote:
>
>> On Sat, Nov 11, 2017 at 12:44 AM, Marc Glisse
>wrote:
>>
>>> The exact undefined-behavior status should probably be clarified
>more.
>>> First, I'd like to say that POINTER_DIFF_EXPR m
On 18 November 2017 at 04:25, Jeff Law wrote:
> On 11/15/2017 11:58 PM, Nathan Rossi wrote:
>> Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and
>> use the default.
>>
>> This resolves issues associated with the use of the .sdata2 operation in
>> cases where emitted assembly a
On 18 November 2017 at 04:30, Michael Eager wrote:
> On 11/15/2017 10:58 PM, Nathan Rossi wrote:
>>
>> Remove the MicroBlaze specific TARGET_ASM_OUTPUT_IDENT definition, and
>> use the default.
>>
>> This resolves issues associated with the use of the .sdata2 operation in
>> cases where emitted as
Dear Dominique,
Please find attached a revised patch that I believe fixes the problem
that you found. The changes are the additions in trans-decl.c.
OK for trunk and 7-branch?
Paul
2017-11-18 Paul Thomas
PR fortran/78990
* expr.c (gfc_is_class_array_function): Renamed from
'gfc_
In file included from ../../../libgcc/config/ia64/unwind-ia64.c:2448:
../../../libgcc/unwind.inc: In function '_Unwind_RaiseException':
../../../libgcc/unwind.inc:140:3: error: too many arguments to function
'uw_install_context'
uw_install_context (&this_context, &cur_context, frames);
^
Jeff Law writes:
> On 10/23/2017 11:00 AM, Richard Sandiford wrote:
>> This patch adds a tree representation for poly_ints. Unlike the
>> rtx version, the coefficients are INTEGER_CSTs rather than plain
>> integers, so that we can easily access them as poly_widest_ints
>> and poly_offset_ints.
>>
FAIL: g++.dg/pr82836.C (test for excess errors)
Excess errors:
/opt/gcc/gcc-20171118/gcc/testsuite/g++.dg/pr82836.C:13:3: error: '__float128'
does not name a type; did you mean '__Float16x8_t'?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA
Steve,
+ for (r = expr->ref; r; r = r->next)
+ if (r->type == REF_COMPONENT)
+ rc = r;
Should you have a break here? As I understand it, you're walking a
list, so you could have r, r->next, r->next->next, and so on. Is
it possible to have r->next->type = REF_CO
Hi Janne,
This is a straightforward change that we can do now that the ABI has
been bumped (again!).
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
OK, and thanks.
Regards
Thomas
Hi Janne,
This is accomplished by making the NEXTREC specifier be a 8 byte
integer where supported.
I wasn't able to come up with a testcase that does not create a large
file that could be added to the testsuite, but here's one which
creates a 2 GB file:
I think the patch is OK (even obvious),
On Sat, Nov 18, 2017 at 5:56 PM, Thomas Koenig wrote:
> Hi Janne,
>
>> This is a straightforward change that we can do now that the ABI has
>> been bumped (again!).
>>
>> Regtested on x86_64-pc-linux-gnu, Ok for trunk?
>
>
> OK, and thanks.
>
> Regards
>
> Thomas
Thanks, committed as r254
On 11/18/2017 12:53 AM, Jeff Law wrote:
On 11/17/2017 12:36 PM, Martin Sebor wrote:
The attached patch enhances -Wstringop-overflow to detect more
instances of buffer overflow at compile time by handling non-
constant offsets into the destination object that are known to
be in some range. The s
On 11/17/2017 03:54 PM, Jonathan Wakely wrote:
Hmm, you're probably right. I'd be tempted to though.
I had an idea. What about a macro _GLIBCXX_ELLINT_3_POS_NU or something
that:
1. would allow users to detect which convention is on by default.
2. They could set or unset to get the other c
On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig wrote:
> Hi Janne,
>
>> This is accomplished by making the NEXTREC specifier be a 8 byte
>> integer where supported.
>>
>> I wasn't able to come up with a testcase that does not create a large
>> file that could be added to the testsuite, but here's o
On 11/18/17 12:16 AM, Jeff Law wrote:
> You might wander a bit and see if/how cse handles other similar
> circumstances. For example (not (not (x)) (neg (neg x)) and (bswap
> (bswap (x))
I actually tried examples like that to see what CSE would do, but I
could never come up with a test case, whe
Dear All,
This is not quite an 'obvious' patch but it does speak for itself. If
there are no objections in the meantime, I will commit it tomorrow
evening.
Bootstraps and regtests on FC23/x86_64 - OK for trunk? What about 7-branch?
Cheers
Paul
2017-11-18 Paul Thomas
PR fortran/79072
> On 2017.11.18 at 00:39 +0100, Jan Hubicka wrote:
> > Hi,
> > this patch fixes remaining IPA profile updating issues I am aware of. With
> > this change there is 1 profile mismatch after inlining for tramp3d -Ofast
> > and 112 of them in .optimized dump which is about 10 times less than before.
>
On 11/18/2017 08:59 AM, Janne Blomqvist wrote:
> On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig wrote:
>> Hi Janne,
>>
>>> This is accomplished by making the NEXTREC specifier be a 8 byte
>>> integer where supported.
>>>
>>> I wasn't able to come up with a testcase that does not create a large
>>>
On Sun, 29 Oct 2017, Sandra Loosemore wrote:
I've checked in this patch to document my recent flurry of Nios II
patches in the release notes for GCC 8.
Thank you!
The Nios II back end has been improved to generate better-optimized
code. Changes include switching to LRA, more accurate
We could consider setting up an automatic testing machine somewhere that not
only does the usual test-suite, but also tests the unusual things like this. For
example, I had a test case which died when launched with more than 32 threads
for example. Not every machine or architecture could do that
Now that the ABI supports large record lengths, there's a few places
in libgfortran where we need to use larger types. For internal units
which by definition are in-memory, it's enought to use ptrdiff_t, for
external units gfc_offset.
Regtested on x86_64-pc-linux-gnu, Ok for trunk?
libgfortran/Ch
I propose the following changes. I do not have ia64 to test. Ok for trunk?
bash-4.2$ svn diff
Index: libgcc/config/cr16/unwind-cr16.c
===
--- libgcc/config/cr16/unwind-cr16.c(revision 254908)
+++ libgcc/config/cr16/unwind-cr16.c
On 11/18/2017 11:55 AM, Janne Blomqvist wrote:
> Now that the ABI supports large record lengths, there's a few places
> in libgfortran where we need to use larger types. For internal units
> which by definition are in-memory, it's enought to use ptrdiff_t, for
> external units gfc_offset.
>
> Regt
Hi,
atm, any build for vms os will fail early in libgcc.
dwarf2_debug_hooks.early_finish needs to be called before
dwarf2_debug_hooks.finish.
However, while vmsdbgout_finish calls dwarf2_debug_hooks.finish there's
no vmsdbgout_early_finish, and dwarf2_debug_hooks.early_finish is not
called
The issue submission talks about ranges that have InputIterators
as their iterator type. Even without any such range types, the added
test more or less shows that it's draconian to require a ForwardIterator
in std::next, since it seems perfectly reasonable to be able to std::next()
an iterator of a
On 19 November 2017 at 02:40, Ville Voutilainen
wrote:
> The issue submission talks about ranges that have InputIterators
> as their iterator type. Even without any such range types, the added
> test more or less shows that it's draconian to require a ForwardIterator
> in std::next, since it seems
Here is the final patch fir libstdc++ Airy functions...
2017-11-18 Edward Smith-Rowland <3dw...@verizon.net>
* include/bits/specfun.h: Expose airy_ai and airy_bi.
* include/tr1/modified_bessel_func.tcc: Treat NaN and inf arg, return.
* testsuite/ext/special_functions/ai
On 11/17/2017 12:12 PM, Wilco Dijkstra wrote:
GCC currently defaults to -fcommon. This is an optional C feature dating
back to early C implementations. On many targets this means global variable
accesses having an unnecessary codesize and performance penalty in C code
(the same source generates
40 matches
Mail list logo
