Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

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.

[PATCH] PR78056: Fix build failure on Power7

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

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

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

Make vax backend -Wfallthru compliant

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

Re: [PATCH/AARCH64] Handle ILP32 multi-arch

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

MAINTAINERS update

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

Re: [PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

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.

Re: [patch, fortran] PR45516 - [F08] allocatable components of recursive type

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 >>

[SPARC] Housekeeping work

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... *

Re: [PATCH] Fix not caught use-after-scope with -O1 (PR sanitize/78106)

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. > >

[PATCH] Fix dwarf2out regression from C++17 inline variables changes

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

Re: [PATCH] 77864 Fix noexcept conditions for map/set default constructors

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 @@

[committed] input.c/libcpp: fix lifetimes of path buffers

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:

[PATCH, Fortran] DEC Compatibility: New I/O Specifiers CARRIAGECONTROL, READONLY, SHARE with -fdec

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

[committed] Implement ~line_maps ()

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

Re: [C++ PATCH] RFC: implement P0386R2 - C++17 inline variables

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

Re: [PATCH, wwwdocs] Add link to GCC 7 changes.html

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

Re: [PATCH/AARCH64] Handle ILP32 multi-arch

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

Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec

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

C++ PATCH for libstdc++ test failure in C++17 mode

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

Re: [PATCH, wwwdocs] Add link to GCC 7 changes.html

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

[PATCH][AArch64] Improve SHA1 scheduling

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

Re: [Fortran, patch, pr78053, v1] [OOP] SELECT TYPE on CLASS(*) component for deferred length char arrays ICEs for -O > 0

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

[PATCH, GCC/ARM] Optional -mthumb for Thumb only targets

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

[PATCH] sched: Do not reorder RTX_FRAME_RELATED_P insns (PR78029)

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:

RE: Gimple loop splitting v2

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- >

Re: [PATCH 7/7, GCC, ARM, V8M] Added support for ARMV8-M Security Extension cmse_nonsecure_caller intrinsic

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

[PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec

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

Re: [PATCHv2 6/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_call: use __gnu_cmse_nonsecure_call

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 >>

Re: [PATCHv2 5/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_call attribute

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' >>

Re: [PATCHv2 4/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_entry: clear registers

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

Re: [PATCH 3/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_entry: __acle_se label and bxns return

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

Re: [PATCHv2 2/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_entry attribute

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

Re: [PATCHv2 1/7, GCC, ARM, V8M] Add support for ARMv8-M's Secure Extensions flag and intrinsics

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 >>

[PATCH, i386]: Backport fixes for PR 78057 and PR 78037 to gcc-6 branch

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

[PATCH, Fortran] Fix initialization of UNIONs with -finit-derived

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

Re: Fix PR78060, PR78061, PR78088

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

Re: [Fortran, patch, pr78053, v1] [OOP] SELECT TYPE on CLASS(*) component for deferred length char arrays ICEs for -O > 0

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

Re: [PATCH, Fortran] Four small DEC extensions

On Tue, Oct 25, 2016 at 11:46 AM, Fritz Reese wrote: ... > Committed r241516, r241517, r241518, r241519. ... and r241520. --- Fritz Reese

Re: [PATCH, Fortran] Four small DEC extensions

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

Re: [PATCH] Improve vector equality comparisons with SSE4.1 (PR target/78102)

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

Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

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 > >

Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

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}

Re: [PATCH] Five patches for std::experimental::filesystem

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. *

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

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

Re: [C++ PATCH] RFC: implement P0386R2 - C++17 inline variables

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>

Fix PR78060, PR78061, PR78088

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

[RFA] Patch to allow SPU port to build with current trunk

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

[PATCH, wwwdocs] Add link to GCC 7 changes.html

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

Fix v850 builds with current trunk

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

Fix m68k so it builds with current trunk

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

Re: [RFC] Speed-up -fprofile-update=atomic

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

Re: [patch, fortran] PR45516 - [F08] allocatable components of recursive type

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

Re: Implement -Wduplicated-branches (PR c/64279) (v3)

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 >

[PATCH] Improve vector equality comparisons with SSE4.1 (PR target/78102)

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

Re: [PATCH] Fix not caught use-after-scope with -O1 (PR sanitize/78106)

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. > >

[PATCH][GIMPLE FE] Split out parser into separate file

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.

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

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

Re: RFC [1/3] divmod transform v2

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

Re: [PATCH] print_rtx: implement support for reuse IDs

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

Re: Add uniform_inside_sphere_distribution

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

Re: [PATCH] Fix not caught use-after-scope with -O1 (PR sanitize/78106)

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

Re: RFC [1/3] divmod transform v2

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 >> >

Re: [PATCH] Fix 2 typos in IPA ICF pass

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. > >

Re: [PATCH GCC][3/4]Add support for constant operand in pattern (convert (op:s (convert@2 @0) (convert?@3 @1)))

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

Re: [PATCH] Fix not caught use-after-scope with -O1 (PR sanitize/78106)

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

Re: [PATCH GCC][1/4]Simplify (convert1 (minmax ((convert2 (x) c)))) into minmax (x c)

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

[PATCH] Fix not caught use-after-scope with -O1 (PR sanitize/78106)

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

[PATCH] Fix 2 typos in IPA ICF pass

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

GIMPLE FE GSoC project now on gcc.gnu.org/git

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

[PATCH GCC][2/4]Simplify (cond (cmp (convert (x), c1), x, c2)) into (minmax (x, c))

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,

[PATCH GCC][4/4]Simplify (cond (cmp x c1) (op x c2) c3) -> (op (minmax x c1) c2)

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:

[PATCH GCC][3/4]Add support for constant operand in pattern (convert (op:s (convert@2 @0) (convert?@3 @1)))

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

[PATCH GCC][1/4]Simplify (convert1 (minmax ((convert2 (x) c)))) into minmax (x c)

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,

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

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: >>>

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

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

Re: RFC [1/3] divmod transform v2

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

[PATCH] combine: Improve change_zero_ext (fixes PR71847)

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,

Re: RFC [1/3] divmod transform v2

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

Re: [patch] Fix PHI optimization issue with boolean types

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

Re: [patch] Fix PHI optimization issue with boolean types

> 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

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

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

Re: [rs6000] Add support for signed overflow arithmetic

> 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

Re: [PATCH][ARM] Avoid partial overlaps in DImode shifts

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. >

Re: [PATCH][AArch64 - v3] Simplify eh_return implementation

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

Re: [PATCH v2][AArch64] Fix symbol offset limit

  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

Re: [patch, fortran] PR77828 Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes

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

Re: [patch] Fix PHI optimization issue with boolean types

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 ...

Re: [patch] Fix PHI optimization issue with boolean types

> 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,

Re: RFC [1/3] divmod transform v2

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

Re: [patch, fortran] PR77828 Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes

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,

Re: [patch,avr] Fix PR71676 / PR71678: casesi not working for SImode / Dimode

2016-10-24 13:33 GMT+03:00 Georg-Johann Lay : > This fixes issues with casesi that originate from taking hard coded > subreg:HI of the SImode switch value: > > * The subreg is cutting away the upper bytes which is wrong code if the > switch actually operates on a value > 16 bits. >