On Mon, Oct 24, 2016 at 7:15 PM, Jerry DeLisle wrote:
> On 10/24/2016 07:49 AM, Janne Blomqvist wrote:
>>
>> On Mon, Oct 24, 2016 at 2:53 PM, Jerry DeLisle
>> wrote:
>>>
>>> On 10/18/2016 04:48 PM, Jerry DeLisle wrote:
Hi Folks,
The attached patch does some minor cleanup
On Sun, Oct 16, 2016 at 7:59 AM, Prathamesh Kulkarni
wrote:
> Hi,
> After approval from Bernd Schmidt, I committed the patch to remove
> optab functions for
> sdivmod_optab and udivmod_optab in optabs.def, which removes the block
> for divmod patch.
>
> This patch is mostly the same as previous on
> Is the change to pass wi::to_widest really necessary? I think it has a
> runtime penalty.
Yes, because there is no == operator for a (tree, int) pair. Is there a cheap
way to convert a tree back into a wide_int? wi::to_wide? Or a combination
with decompose? Otherwise you can use eq_p, but
On Tue, Oct 25, 2016 at 10:17 AM, Eric Botcazou wrote:
>> Is the change to pass wi::to_widest really necessary? I think it has a
>> runtime penalty.
>
> Yes, because there is no == operator for a (tree, int) pair.
Ah, yes. But operator== simply maps to wi::eq_p, so ...
> Is there a cheap
> wa
Hi Janne,
> Ugh. Is is possible to un-break the ABI then, or is the plan to merge
> fortran-dev regardless and fix the performance issues later? Seems to
> me that breaking the ABI for GCC 7 and again for GCC 8 is the worst
> choice.
The ABI is broken without bumping the version. Bumping the ABI-
ping
From: Wilco Dijkstra
Sent: 12 September 2016 15:50
To: Richard Earnshaw; GCC Patches
Cc: nd
Subject: Re: [PATCH v2][AArch64] Fix symbol offset limit
Wilco wrote:
> The original example is from GCC itself, the fixed_regs array is small but
> due to
> optimization we can end up wit
ping
From: Wilco Dijkstra
Sent: 02 September 2016 12:31
To: Ramana Radhakrishnan; GCC Patches
Cc: nd
Subject: Re: [PATCH][AArch64 - v3] Simplify eh_return implementation
Ramana Radhakrishnan wrote:
> Can you please file a PR for this and add some testcases ? This sounds like
> a serious e
On 24/10/16 15:28, Wilco Dijkstra wrote:
> With -fpu=neon DI mode shifts are expanded after reload. DI mode registers
> can
> either fully or partially overlap. However the shift expansion code can only
> deal
> with the full overlap case, and generates incorrect code for partial overlaps.
> T
> It is nicely generic as well, but requires more insns than this if your
> ISA does not have a full complement of logical ops. Well, just an
> "andnot" is enough, you don't actually need eqv here.
Indeed, and it's rather spectacular for 64-bit operations on 32-bit machines
because the sign bit
On Thu, Oct 6, 2016 at 1:28 AM, Joseph Myers wrote:
> On Fri, 26 Aug 2016, Prasad Ghangal wrote:
>
>> >> Thanks for your feedback. I had missed removing some unwanted code
>> >> while code cleanup. I have updated the patch.
>> >> I am not sure if we should move all gimple parsing related functions
> I'm not sure what you mean with "all other callers of fits_to_tree_p
> are affected" - that was desired.
Affected by the from == to eq_p change:
+ if (TREE_CODE (type) == BOOLEAN_TYPE)
+return x == 0 || x == 1;
vs
+ if (TREE_CODE (type) == BOOLEAN_TYPE)
+return eq_p (x, 0) || eq_p (
On Tue, Oct 25, 2016 at 12:22 PM, Eric Botcazou wrote:
>> I'm not sure what you mean with "all other callers of fits_to_tree_p
>> are affected" - that was desired.
>
> Affected by the from == to eq_p change:
>
> + if (TREE_CODE (type) == BOOLEAN_TYPE)
> +return x == 0 || x == 1;
>
> vs
>
> +
On 25 October 2016 at 13:43, Richard Biener wrote:
> On Sun, Oct 16, 2016 at 7:59 AM, Prathamesh Kulkarni
> wrote:
>> Hi,
>> After approval from Bernd Schmidt, I committed the patch to remove
>> optab functions for
>> sdivmod_optab and udivmod_optab in optabs.def, which removes the block
>> for d
This improves a few things in change_zero_ext. Firstly, it should use
the passed in pattern in recog_for_combine, not the pattern of the insn
(they are not the same if the whole pattern was replaced). Secondly,
it handled zero_ext of a subreg, but with hard registers we do not get
a subreg, inste
On Tue, 25 Oct 2016, Prathamesh Kulkarni wrote:
> On 25 October 2016 at 13:43, Richard Biener
> wrote:
> > On Sun, Oct 16, 2016 at 7:59 AM, Prathamesh Kulkarni
> > wrote:
> >> Hi,
> >> After approval from Bernd Schmidt, I committed the patch to remove
> >> optab functions for
> >> sdivmod_optab
On 25 October 2016 at 15:49, Richard Biener wrote:
> On Thu, Oct 6, 2016 at 1:28 AM, Joseph Myers wrote:
>> On Fri, 26 Aug 2016, Prasad Ghangal wrote:
>>
>>> >> Thanks for your feedback. I had missed removing some unwanted code
>>> >> while code cleanup. I have updated the patch.
>>> >> I am not
On Tue, Oct 25, 2016 at 1:13 PM, Prasad Ghangal
wrote:
> On 25 October 2016 at 15:49, Richard Biener
> wrote:
>> On Thu, Oct 6, 2016 at 1:28 AM, Joseph Myers wrote:
>>> On Fri, 26 Aug 2016, Prasad Ghangal wrote:
>>>
>> Thanks for your feedback. I had missed removing some unwanted code
Hi,
This is a patch set adding various match.pd patterns in order to generate
simplified MIN/MAX_EXPR mostly from COND_EXPR. This is the first one
optimizing (convert1 (minmax ((convert2 (x) c to minmax (x c), if convert2
promotes x and convert1 demotes back to x's type. With this patch, g
Hi,
This is an update patch for
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00738.html . In this version,
existing pattern (convert (op:s (convert@2 @0) (convert?@3 @1))) is extended.
It allows narrowing of arithmetic operation which has constant integer as its
second operand. It also simp
Hi,
As commented in patch, this one simplifies (cond (cmp x c1) (op x c2) c3) into
(op (minmax x c1) c2) if:
1) OP is PLUS or MINUS.
2) CMP is LT, LE, GT or GE.
3) C3 == (C1 op C2), and the experation isn't undefined behavior.
This pattern also handles special cases like:
Hi,
Second patch optimizing (cond (cmp (convert (x), c1), x, c2)) into (minmax (x,
c)). As commented in patch, this is done if:
+ 1) Comparison's operands are promoted from smaller type.
+ 2) Const c1 equals to c2 after canonicalizing comparison.
+ 3) Comparison has tree code LT, LE,
I've moved (well, basically copied from the last sent patch) the
GIMPLE FE GSoC project to a public branch on gcc.gnu.org git
at remotes/origin/gimplefe (hopefully didn't mess stuff up too much).
I've addressed Josephs stylistic comments already, work left is
to move the GIMPLE parsing to a separ
Hi.
Simple fix for a typo in IPA ICF. It cant' cause a regression as
cl_target_option_eq
function is called in equals_wpa function.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ready to be installed?
Martin
>From e4f9f913c32109a2773145870333ae88fc9cdae2 Mon Sep 17
Hello.
While reading and trying to understand sanopt code, I've noticed that we can
possibly
optimize out a ASAN_CHECK when there's a BB in between DOM(BB) and BB which can
call a freeing function.
Ready to be installed after it survives regression tests?
Martin
>From d8ed43c1f8e29cfe63ebd7c40a7
On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng wrote:
> Hi,
> This is a patch set adding various match.pd patterns in order to generate
> simplified MIN/MAX_EXPR mostly from COND_EXPR. This is the first one
> optimizing (convert1 (minmax ((convert2 (x) c to minmax (x c), if
> convert2 promotes
On Tue, Oct 25, 2016 at 01:40:03PM +0200, Martin Liška wrote:
> While reading and trying to understand sanopt code, I've noticed that we can
> possibly
> optimize out a ASAN_CHECK when there's a BB in between DOM(BB) and BB which
> can
> call a freeing function.
>
> Ready to be installed after i
On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng wrote:
> Hi,
> This is an update patch for
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00738.html . In this version,
> existing pattern (convert (op:s (convert@2 @0) (convert?@3 @1))) is extended.
> It allows narrowing of arithmetic operation whi
On Tue, Oct 25, 2016 at 1:37 PM, Martin Liška wrote:
> Hi.
>
> Simple fix for a typo in IPA ICF. It cant' cause a regression as
> cl_target_option_eq
> function is called in equals_wpa function.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be install
On 25 October 2016 at 16:17, Richard Biener wrote:
> On Tue, 25 Oct 2016, Prathamesh Kulkarni wrote:
>
>> On 25 October 2016 at 13:43, Richard Biener
>> wrote:
>> > On Sun, Oct 16, 2016 at 7:59 AM, Prathamesh Kulkarni
>> > wrote:
>> >> Hi,
>> >> After approval from Bernd Schmidt, I committed th
On 10/25/2016 01:52 PM, Jakub Jelinek wrote:
> On Tue, Oct 25, 2016 at 01:40:03PM +0200, Martin Liška wrote:
>> While reading and trying to understand sanopt code, I've noticed that we can
>> possibly
>> optimize out a ASAN_CHECK when there's a BB in between DOM(BB) and BB which
>> can
>> call a
All,
Here is the library extension for uniform_inside _sphere_distribution.
It works from discs and has been tested up through 12-dimentional spheres.
The patch dispatches to rejection for Dim<8, transform otherwise as
discussed earlier.
Builds and tests cleanly on x86_64-linux.
OK?
Ed
Inde
On 10/21/2016 10:27 PM, David Malcolm wrote:
Thanks. I attemped to use those fields of recog_data, but it doesn't
seem to be exactly what's needed here.
Yeah, I may have been confused. I'm not sure that just looking at
SCRATCHes is the right thing either, but I think you're on the right
trac
On Tue, 25 Oct 2016, Prathamesh Kulkarni wrote:
> On 25 October 2016 at 16:17, Richard Biener wrote:
> > On Tue, 25 Oct 2016, Prathamesh Kulkarni wrote:
> >
> >> On 25 October 2016 at 13:43, Richard Biener
> >> wrote:
> >> > On Sun, Oct 16, 2016 at 7:59 AM, Prathamesh Kulkarni
> >> > wrote:
>
On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
> My memory is weak, but isn't this something the sanopt pass
> (sanopt_optimize) is already doing similarly for e.g. ASAN_CHECK, UBSAN_NULL
> and UBSAN_VPTR checks? For ASAN_MARK, you actually don't care about any
> calls, those shouldn't unpoison or p
Hi,
so I did the massaging to split out the GIMPLE parsing routines out
to a separate file (quite tricky to get the gengtype issues correctly
so I thought to help out here and get things started).
Tested on x86_64-unknown-linux-gnu, bootstrap is still in progress.
Will push to gimplefe soon.
I
On Tue, Oct 25, 2016 at 02:16:33PM +0200, Martin Liška wrote:
> 2016-10-25 Martin Liska
>
> PR sanitizer/78106
> * sanopt.c (imm_dom_path_with_freeing_call): Handle gasm
> statements as they can also contain possibly a freeing call.
>
> gcc/testsuite/ChangeLog:
>
> 2016-10-2
Hi!
SSE4.1 added PCMPEQQ instruction, but only SSE4.2 added PCMPGTQ, and
we've switched _mm_cmpeq_epi64 in r217608 from using __builtin_ia32_*
to generic vector comparison, which works fine for SSE4.2, but not for
SSE4.1. The following patch adds optabs etc. so that we can support
vector equality
On Mon, Oct 24, 2016 at 04:10:21PM +0200, Marek Polacek wrote:
> On Thu, Oct 20, 2016 at 12:28:36PM +0200, Marek Polacek wrote:
> > I found a problem with this patch--we can't call
> > do_warn_duplicated_branches in
> > build_conditional_expr, because that way the C++-specific codes might leak
>
Hi Paul,
Just one small nit and one idea remaining:
The nit: You've missed one "same_type" at:
> Index: gcc/fortran/trans-array.c
> ===
> *** gcc/fortran/trans-array.c (revision 241467)
> --- gcc/fortran/trans-array.c (working c
On 10/24/2016 03:51 PM, Richard Biener wrote:
> It's quite ad-hoc :/ The IFN will also be a memory optimization
> barrier unless you add special support
> for it in the alias oracle - so the performance measurement needs to
> be taken with a grain of salt
> (same is true for all atomics of course
It's not currently possible to build various crosses with the current
trunk due to warning issues. I suspect this is the first of many
patches to address those issues.
I'm not familiar with the code in question, but based on Maxim's comment
the gcc_unreachable ought to be safe. It could po
Two issues in the v850 port. One is just a comment tweak to make the
fallthru bits happy. The other appears to be a real bug caught by the
fallthru bits.
The v850 has various data sections and we have the ability to place
uninitialized commons in each of them. Of course to do that we have
Now that we have a GCC 7 changes.html file, shouldn't we make it easy to find?
Peter
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1027
diff -u -r1.1027 index.html
--- index.html 30 Sep
The fallthru warnings triggered a couple times in the SPU port. I'm not
at all familiar with the chip or the port, but based on the little
reading I've done and experience with GCC, I believe this patch is correct.
First, there's a missing fallthru comment in spu_sched_reorder for
TYPE_LOA
Hi,
these are ICEs by the loop splitting pass. Two problems: using
inconsistent types for operations and not dealing correctly with certain
loop forms.
First (78060 and 78088): I initially used an ideosyncratic way of
calculating the new loop bound, needing several type switches that I
haven
On 21/10/16 16:14, Jakub Jelinek wrote:
> On Fri, Oct 21, 2016 at 03:57:34PM +0100, Yao Qi wrote:
>> Hi Jakub,
>>
>> On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists)
>> wrote:
>>> <2><8f5>: Abbrev Number: 38 (DW_TAG_member)
>>> <8f6> DW_AT_specification: <0x8be>
>>> <8fa> DW_AT_l
On 10/24/2016 06:16 PM, Moritz Klammler wrote:
Jeff Law writes:
On 10/24/2016 02:44 AM, Richard Biener wrote:
On Fri, Oct 7, 2016 at 3:10 PM, Moritz Klammler wrote:
I would like to bump my patch that makes the
`contrib/download_prerequisites` script verify the checksums of the
downloaded pa
Two more fixes for the filesystem TS, and improved tests.
Handle negative times in filesystem::last_write_time
* src/filesystem/ops.cc
(last_write_time(const path&, file_time_type, error_code&)): Handle
negative times correctly.
* testsuite/experimental/filesyst
On 10/10/2016 08:06 AM, Fritz Reese wrote:
> --- a/gcc/fortran/intrinsic.texi
> +++ b/gcc/fortran/intrinsic.texi
> @@ -23,6 +23,9 @@ Some basic guidelines for editing this document:
> @end ignore
>
> @tex
> +\gdef\acosd{\mathop{\rm acosd}\nolimits}
> +\gdef\asind{\mathop{\rm asind}\nolimits}
>
On Tue, Oct 25, 2016 at 11:37 AM Cesar Philippidis
wrote:
>
> On 10/10/2016 08:06 AM, Fritz Reese wrote:
>
> > --- a/gcc/fortran/intrinsic.texi
> > +++ b/gcc/fortran/intrinsic.texi
> > @@ -23,6 +23,9 @@ Some basic guidelines for editing this document:
> > @end ignore
> >
> > @tex
> > +\gdef\acos
On October 25, 2016 3:48:41 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>SSE4.1 added PCMPEQQ instruction, but only SSE4.2 added PCMPGTQ, and
>we've switched _mm_cmpeq_epi64 in r217608 from using __builtin_ia32_*
>to generic vector comparison, which works fine for SSE4.2, but not for
>SSE4.1. The
On Mon, Oct 24, 2016 at 10:47 PM, Jerry DeLisle wrote:
> On 10/24/2016 07:23 AM, Fritz Reese wrote:
>>
>> https://gcc.gnu.org/ml/fortran/2016-10/msg00087.html et. al.
>>>
>>> On 12/10/16 13:30, Fritz Reese wrote:
Here I submit for review four small extensions to the GNU Fortran
fron
On Tue, Oct 25, 2016 at 11:46 AM, Fritz Reese wrote:
...
> Committed r241516, r241517, r241518, r241519.
... and r241520.
---
Fritz Reese
Hi Andre,
This patch is fine, apart from
s/whose length is no consistently/whose length is not consistently/
in the comment.
The testcase in comment #1 of PR78053 is invalid and now give the
correct message:
type is (character(len=:))
1
Error: The type-spec at (1) shall specify
On October 25, 2016 5:03:15 PM GMT+02:00, Michael Matz wrote:
>Hi,
>
>these are ICEs by the loop splitting pass. Two problems: using
>inconsistent types for operations and not dealing correctly with
>certain
>loop forms.
>
>First (78060 and 78088): I initially used an ideosyncratic way of
>cal
All,
Currently the '-finit-derived' flag does not handle UNIONs properly.
Specifically, a default initializer may not be appropriately generated
for BT_UNION components, leaving some memory in the middle of the
structure uninitialized even with -finit-derived. This patch ensures
UNION nodes receiv
Hello!
2016-10-25 Uros Bizjak
Backport from mainline
2016-10-21 Jakub Jelinek
PR target/78057
* config/i386/i386.c: Include fold-const-call.h, tree-vrp.h
and tree-ssanames.h.
(ix86_fold_builtin): Fold IX86_BUILTIN_[LT]ZCNT{16,32,64}
with INTEGER_CST argument.
On 24/08/16 12:00, Andre Vieira (lists) wrote:
> On 25/07/16 14:19, Andre Vieira (lists) wrote:
>> This patch adds the support of the '-mcmse' option to enable ARMv8-M's
>> Security Extensions and supports the following intrinsics:
>> cmse_TT
>> cmse_TT_fptr
>> cmse_TTT
>> cmse_TTT_fptr
>> cmse_TTA
On 24/08/16 12:00, Andre Vieira (lists) wrote:
> On 25/07/16 14:21, Andre Vieira (lists) wrote:
>> This patch adds support for the ARMv8-M Security Extensions
>> 'cmse_nonsecure_entry' attribute. In this patch we implement the
>> attribute handling and diagnosis around the attribute. See Section 5.
On 25/07/16 14:23, Andre Vieira (lists) wrote:
> This patch extends support for the ARMv8-M Security Extensions
> 'cmse_nonsecure_entry' attribute in two ways:
>
> 1) Generate two labels for the function, the regular function name and
> one with the function's name appended to '__acle_se_', this w
On 24/08/16 12:01, Andre Vieira (lists) wrote:
> On 25/07/16 14:23, Andre Vieira (lists) wrote:
>> This patch extends support for the ARMv8-M Security Extensions
>> 'cmse_nonsecure_entry' attribute to safeguard against leak of
>> information through unbanked registers.
>>
>> When returning from a n
On 24/08/16 12:01, Andre Vieira (lists) wrote:
> On 25/07/16 14:25, Andre Vieira (lists) wrote:
>> This patch adds support for the ARMv8-M Security Extensions
>> 'cmse_nonsecure_call' attribute. This attribute may only be used for
>> function types and when used in combination with the '-mcmse'
>>
On 24/08/16 12:01, Andre Vieira (lists) wrote:
> On 25/07/16 14:26, Andre Vieira (lists) wrote:
>> This patch extends support for the ARMv8-M Security Extensions
>> 'cmse_nonsecure_call' to use a new library function
>> '__gnu_cmse_nonsecure_call'. This library function is responsible for
>> (witho
All-
Proposed here is another compatibility extension to the GNU Fortran
frontend which allows logical operations on integer operands with the
-fdec flag. In this case the logical operator is replaced with its
bitwise equivalent.
For example, GNU Fortran by default (correctly) produces an error f
On 24/08/16 12:01, Andre Vieira (lists) wrote:
> On 25/07/16 14:28, Andre Vieira (lists) wrote:
>> This patch adds support ARMv8-M's Security Extension's
>> cmse_nonsecure_caller intrinsic. This intrinsic is used to check whether
>> an entry function was called from a non-secure state.
>> See Secti
Hi Michael,
The commit seems to be causing an ICE on aarch64 (just tested latest trunk).
I've created a Bugzilla ticket with a test input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78107
Regards,
Tamar
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>
This patch makes scheduling not reorder any RTX_FRAME_RELATED_P insns
(relative to each other), to fix PR78029. I originally was a bit worried
that this would degrade code quality, but it seems to even improve it:
more other insns are scheduled between the prologue insns.
The problem in PR78029:
Hi,
Currently when a user compiles for a thumb-only target (such as Cortex-M
processors) without specifying the -mthumb option GCC throws the error "target
CPU does not support ARM mode". This is suboptimal from a usability point of
view: the -mthumb could be deduced from the -march or -mcpu o
Hi Paul,
thanks for the review. The typo is corrected and another in the sentences
before that, too. Committed as r241528. I will see whether it make sense and is
possible to backport to gcc-6.
Note the PR78053 is considered a duplicate of pr72770 which now used for
tracking.
About the testcase
SHA1H instructions may be scheduled after a SHA1C instruction
that uses the same input register. However SHA1C updates its input,
so if SHA1H is scheduled after it, it requires an extra move.
Increase the priority of SHA1H to ensure it gets scheduled
earlier, avoiding the move.
Is this something
On Tue, 25 Oct 2016, Peter Bergner wrote:
> Now that we have a GCC 7 changes.html file, shouldn't we make it
> easy to find?
Good point, thanks.
Perhaps add a disclaimer at the top of changes.html that this
is still work in progress as part of that commit?
Gerald
On 10/25/2016 09:24 AM, Fritz Reese wrote:
All-
Proposed here is another compatibility extension to the GNU Fortran
frontend which allows logical operations on integer operands with the
-fdec flag. In this case the logical operator is replaced with its
bitwise equivalent.
For example, GNU Fortr
Jonathan recently noticed that 20_util/shared_ptr/cons/constexpr.cc
was failing in C++17 mode. This was due to the copy elision changes
introducing TARGET_EXPR that wasn't there before, and
maybe_constant_init deciding that it wasn't sufficiently constant. I
fixed that by looking through the TARG
On Fri, Oct 21, 2016 at 1:24 AM, Andrew Pinski wrote:
> On Fri, Oct 7, 2016 at 2:08 PM, Andrew Pinski wrote:
>> Hi,
>> This patch adds ilp32 multi-arch support. This is needed to support
>> multi-arch on Debian like systems.
>>
>> OK? Bootstrapped and tested on aarch64-linux-gnu with no regre
On 10/25/16 12:17 PM, Gerald Pfeifer wrote:
> On Tue, 25 Oct 2016, Peter Bergner wrote:
>> Now that we have a GCC 7 changes.html file, shouldn't we make it
>> easy to find?
>
> Good point, thanks.
>
> Perhaps add a disclaimer at the top of changes.html that this
> is still work in progress as pa
On Tue, Oct 25, 2016 at 04:05:30PM +0100, Andre Vieira (lists) wrote:
> I built gcc for the following:
> 1) revision r241135
> 2) revision r241135 + cherry-picked your patch in revision r241137
> (skipped the patch in revision r241136 because that gives a build failure).
> 3) trunk + patch in http
line_maps instances such as the global line_table are
GC-managed, but the htab within location_adhoc_data_map.htab
is not GC-managed.
Previously this was deleted manually by a call to
location_adhoc_data_fini within toplev::main.
However, on adding a call to forcibly_ggc_collect after the
selftes
All,
Here's the big one. This patch proposes an extension to both the GNU
Fortran front-end and runtime library (libgfortran) to support three
additional I/O specifiers: CARRIAGECONTROL, READONLY, and SHARE for
compatibility with legacy compilers/code.
Here's a summary of what the specifiers actu
Running "make selftest-valgrind" showed various leaks of the form:
408 bytes in 24 blocks are definitely lost in loss record 572 of 679
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x1B0D057: xmalloc (xmalloc.c:148)
by 0x1ACCAA1: append_file_to_dir(c
On 24/10/2016 13:03, Jonathan Wakely wrote:
On 12/10/16 22:36 +0200, François Dumont wrote:
On 10/10/2016 23:01, Tim Song wrote:
Trying again...with a few edits.
On Mon, Oct 10, 2016 at 3:24 PM, François Dumont
wrote:
@@ -602,24 +612,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct _
On Tue, Oct 25, 2016 at 08:06:12PM +0200, Jakub Jelinek wrote:
> I think this patch should fix it, will bootstrap/regtest it now:
>
> 2016-10-25 Jakub Jelinek
>
> * dwarf2out.c (gen_member_die): Only reparent_child instead of
> splice_child_die if child doesn't have DW_AT_specifica
On Tue, Oct 25, 2016 at 02:16:33PM +0200, Martin Liška wrote:
> 2016-10-25 Martin Liska
>
> PR sanitizer/78106
> * sanopt.c (imm_dom_path_with_freeing_call): Handle gasm
> statements as they can also contain possibly a freeing call.
>
> gcc/testsuite/ChangeLog:
>
> 2016-10-2
No functional changes.
Tested on SPARC/Solaris, applied on the mainline.
2016-10-25 Eric Botcazou
* config.gcc (sparc*-*-solaris2*): Adjust.
(sparc64-*-linux*): Likewise.
* config/sparc/default-64.h: Rename to...
* config/sparc/default64.h: ...this.
*
Committed as revision 241539.
Thanks for all the help, Andre and Dominique.
Paul
On 25 October 2016 at 16:09, Andre Vehreschild wrote:
> Hi Paul,
>
> Just one small nit and one idea remaining:
>
> The nit: You've missed one "same_type" at:
>
>> Index: gcc/fortran/trans-array.c
>> ==
On 10/25/2016 11:52 AM, Fritz Reese wrote:
All,
Here's the big one. This patch proposes an extension to both the GNU
Fortran front-end and runtime library (libgfortran) to support three
additional I/O specifiers: CARRIAGECONTROL, READONLY, and SHARE for
compatibility with legacy compilers/code.
Hi,
Adding myself to MAINTAINERS (Write After Approval).
(r241541)
Thanks,
-Will
Index: ChangeLog
===
--- ChangeLog (revision 241538)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2016-10-25 Will Schmidt
+
+ * MAI
On 07.10.2016 23:08, Andrew Pinski wrote:
> Hi,
> This patch adds ilp32 multi-arch support. This is needed to support
> multi-arch on Debian like systems.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> Also tested with ilp32 with a newly built toolchain that suppor
This adds /* FALLTHRU */ comments to the vax backend. It's the backend
changes necessary to build with the trunk. There's also a change for
lra-constraints, but I'll send that separately.
Applied to the trunk.
Jeff
commit 1af18c59cb158024a77068b99875cd7db9d8b8bf
Author: law
Date: Tue Oc
On Tue, Oct 25, 2016 at 5:29 PM, Jerry DeLisle wrote:
> On 10/25/2016 11:52 AM, Fritz Reese wrote:
>>
>> All,
>>
>> Here's the big one. This patch proposes an extension to both the GNU
>> Fortran front-end and runtime library (libgfortran) to support three
>> additional I/O specifiers: CARRIAGECON
This patch corrects an error introduced with commit 241314. That patch
introduced several new built-in functions to support Power9 string
instructions. The error that was found subsequent to the trunk commit
is that initialization of the built-in function tables encounters an
internal compiler e
On 10/25/2016 11:52 AM, Fritz Reese wrote:
All,
Here's the big one. This patch proposes an extension to both the GNU
Fortran front-end and runtime library (libgfortran) to support three
additional I/O specifiers: CARRIAGECONTROL, READONLY, and SHARE for
compatibility with legacy compilers/code.
91 matches
Mail list logo
