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
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 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
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
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
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
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
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
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
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 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.
>
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 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
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/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 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 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
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),
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
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
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
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.
>>
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);
^
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_
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
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 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 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
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 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
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 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, 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'
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, 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
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
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
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
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-
40 matches
Mail list logo
