[Bug fortran/79157] gfortran crashed on sparc with openmpi build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #10 from Eric Botcazou --- gfortran -S conftestf.f -g -O2 -wrapper gdb,--args

[Bug rtl-optimization/79125] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79125 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: Another cprop trap_if fix, PR79125

On 01/20/2017 05:24 AM, Bernd Schmidt wrote: This is essentially the same patch I sent for the previous instance of this problem, but this time applied to local_cprop_pass. Bootstrapped and tested on x86_64-linux, and it seems to fix the testcase with a ppc cross. Ok? Bernd pr79125.diff

[Bug rtl-optimization/79125] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79125 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Sat Jan 21 07:23:47 2017 New Revision: 244741 URL: https://gcc.gnu.org/viewcvs?rev=244741=gcc=rev Log: 2017-01-21 Bernd Schmidt rtl-optimization/79125

Re: [PR 79108] Put ipa_node_params to GC memory

On Fri, Jan 20, 2017 at 1:58 PM, Martin Jambor wrote: > Hi, > > when I fixed PR 78365 by streaming types of parameters that might not > have been anywhere else, I forgot that I was holding them in non-GC > memory and so I caused PR 79108. The following patch fixes it by >

Re: [PATCH 3/6] RISC-V Port: libgcc

On 01/11/2017 06:30 PM, Palmer Dabbelt wrote: +__riscv_save_12: + addi sp, sp, -112 + li t1, 0 + sd s11, 8(sp) + j .Ls10 + +__riscv_save_11: +__riscv_save_10: + addi sp, sp, -112 + li t1, -16 No unwind info? r~

Re: [PATCH 2/6] RISC-V Port: gcc

On 01/17/2017 01:16 PM, Andrew Waterman wrote: We went with the /libXX/YY/ approach because, on a multilib system, the system libraries also need to be distinguished by ABI. It seemed most natural to us to handle ld.so and e.g. libc.so in a consistent manner. However, something along the lines

Re: [PATCH 2/6] RISC-V Port: gcc

On 01/11/2017 06:30 PM, Palmer Dabbelt wrote: +(define_register_constraint "f" "TARGET_HARD_FLOAT ? FP_REGS : NO_REGS" + "A floating-point register (if available).") + I know this is the Traditional Way, but I do wonder if using the new enable attribute on the alternatives would be better.

A + B CMP A -> A CMP' CST' match.pd patterns [was [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)]

On 01/20/2017 04:30 PM, Jeff Law wrote: Going to work from the self-contained test... Here's a test case that's closer to the one from the bug. It also ends up with the out of bounds memset even at -O1, during PRE. typedef __SIZE_TYPE__ size_t; struct S int *p0, *p1, *p2; size_t size

[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850 --- Comment #1 from Segher Boessenkool --- Author: segher Date: Sat Jan 21 03:11:49 2017 New Revision: 244740 URL: https://gcc.gnu.org/viewcvs?rev=244740=gcc=rev Log: rs6000: Small varargs for BE SVR4 (PR61729, PR77850) The varargs code for

[Bug target/61729] FAIL: g++.dg/abi/scoped1.C -std=gnu++11 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61729 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Sat Jan 21 03:11:49 2017 New Revision: 244740 URL: https://gcc.gnu.org/viewcvs?rev=244740=gcc=rev Log: rs6000: Small varargs for BE SVR4 (PR61729, PR77850) The varargs code for

Re: [PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c

On 01/11/2017 06:30 PM, Palmer Dabbelt wrote: +/* The largest number of operations needed to load an integer constant. + The worst case is LUI, ADDI, SLLI, ADDI, SLLI, ADDI, SLLI, ADDI, + but we may attempt and reject even worse sequences. */ +#define RISCV_MAX_INTEGER_OPS 32 Why would

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/65608] [meta-bug] friend issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 60860, which changed state. Bug 60860 Summary: Friend function declaration incorrectly hides function in outer namespace https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 What|Removed

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53012 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 Jonathan Wakely changed: What|Removed |Added CC||kalaxy at gmail dot com --- Comment

[Bug fortran/79157] gfortran crashed on sparc with openmpi build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #9 from Igor Kozhukhov --- $ gdb --version GNU gdb (DilOS 7.11.1-2-5) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you

[Bug target/79173] New: add-with-carry and subtract-with-borrow support (x86_64 and others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 Bug ID: 79173 Summary: add-with-carry and subtract-with-borrow support (x86_64 and others) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

Re: How to configure a bi-arch PowerPC GCC?

On Fri, Jan 20, 2017 at 08:35:14AM +0100, Sebastian Huber wrote: > >so you seem to have 64-bit ABI_V4? I wonder how well tested that is, > >you are likely to run into more problems. Either stack_restore_tie or > >the above code will need a tweak. > > thanks for your help. I would had a hard

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 --- Comment #5 from Jonathan Wakely --- It seems to have been fixed before the r235368 commit that fixed bug 70522, I'm trying to find the right commit.

[Bug c++/79172] New: -Wunused-but-set-parameter gone nuts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79172 Bug ID: 79172 Summary: -Wunused-but-set-parameter gone nuts Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

Re: [PATCH,rs6000] Correct argument and result types for binary floating point built-in functions

On Thu, Jan 19, 2017 at 04:07:47PM -0700, Kelvin Nilsen wrote: > > This patch corrects several errors in a patch originally committed on > 2016-08-10. The following corrections are required to maintain > compliance with "Power Architecture 64-Bit ELF V2 ABI Specification", > also known as

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

On 01/20/2017 04:34 PM, Jakub Jelinek wrote: On Fri, Jan 20, 2017 at 04:32:19PM -0700, Jeff Law wrote: then the loop does the same thing as will memset (p, 6, 3U * 1024 * 1024 * 1024); do. On such large objects some operations may not work properly, e.g. [i] - [0] might be negative etc., but

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On Fri, Jan 20, 2017 at 01:37:13PM -0700, Jeff Law wrote: > > > Which is best will depend on what the front/mid ends might have done to > > > apply the documented limit. > > > > Here I know not enough to give a decision. In tree the priority_type is > > unsigned short. In varasm priority is an

[PATCH] Some further --with-gcc-major-version-only fixes

Hi! I've discovered today that while I've handled all */Makefile* and toplevel, in the */*/Makefile* files there are some cat .../BASE-VER constructs left (for NVPTX offloading testing it actually caused the accel compiler not being found with --with-gcc-major-version-only). The following patch

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

On Fri, Jan 20, 2017 at 04:32:19PM -0700, Jeff Law wrote: > > then the loop does the same thing as will memset (p, 6, 3U * 1024 * 1024 * > > 1024); > > do. On such large objects some operations may not work properly, e.g. > > [i] - [0] might be negative etc., but that is not something the above

[PATCH] Fix Fortran FE -Wformat-security warnings

Hi! The Fortran FE has huge amounts of -Wformat-security warnings everywhere, but in the end they are only a result of a few commonly used things: 1) gfc_get_string uses a printf-like format string, so calling it with a variable is something -Wformat-security warns about (and would be a bad bug

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

On 01/18/2017 01:10 AM, Jakub Jelinek wrote: On Tue, Jan 17, 2017 at 10:59:43PM -0700, Jeff Law wrote: I agree that breaking those applications would be bad. It could be dealt with by adding an option to let them disable the insertion of the trap. With the warning, programmers would get a

Re: [PATCH] avoid calling memset et al. with excessively large sizes (PR 79095)

On 01/18/2017 10:45 AM, Martin Sebor wrote: On 01/18/2017 01:10 AM, Jakub Jelinek wrote: On Tue, Jan 17, 2017 at 10:59:43PM -0700, Jeff Law wrote: I agree that breaking those applications would be bad. It could be dealt with by adding an option to let them disable the insertion of the trap.

[PATCH] Fix -Wformat-security warnings in dwarf2out.c

Hi! When building gcc with -Wformat -Werror=format-security, there are various warnings->errors. This set has been introduced by me :( in the DWARF5 work, thus it is a 7 Regression. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2017-01-20 Jakub Jelinek

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 --- Comment #4 from Nathan Ridge --- (In reply to Nathan Ridge from comment #3) > This appears to have been fixed in gcc 6. Perhaps by bug 70522?

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53012 --- Comment #3 from Nathan Ridge --- (In reply to Nathan Ridge from comment #2) > This appears to be fixed in gcc 6, possibly by the same change that fixed > bug 60860 as well. Perhaps by bug 70522?

[Bug c++/53012] unrelated friend operators in same namespace interfere with operator resolution outside of namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53012 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot com ---

[Bug c++/60860] Friend function declaration incorrectly hides function in outer namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60860 Nathan Ridge changed: What|Removed |Added CC||zeratul976 at hotmail dot com ---

[Bug target/70179] PPC64 ICE with -mabi=ieeelongdouble and long double complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70179 --- Comment #3 from Michael Meissner --- I suspect the bug was fixed in a check in on May 2nd, 2016, when the complex float128 was supported.

[Bug c/79171] I can't able to create static link of dynamic object.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79171 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/79171] New: I can't able to create static link of dynamic object.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79171 Bug ID: 79171 Summary: I can't able to create static link of dynamic object. Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug target/70179] PPC64 ICE with -mabi=ieeelongdouble and long double complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70179 Michael Meissner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [RFC] Further LRA subreg handling issues

> I'll run testing for at least x86_64, MIPS and another > WORD_REGISTER_OPERATIONS target and try to get this committed in the next > couple of days so it can get into everyone's testing well before release. No issues found on SPARC. -- Eric Botcazou

[Bug ipa/79108] [7 Regression] ICE on some fortran code with -flto -Ofast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79108 --- Comment #3 from Martin Jambor --- I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01643.html

Re: [PATCH] Fix PR78515

Hi, On Fri, Nov 25, 2016 at 02:55:29PM +0100, Richard Biener wrote: > On Fri, 25 Nov 2016, Martin Jambor wrote: > > ... > > > > There's still that odd 'stmt2' > > > hanging around that gets set to sth else than stmt with > > > > > > op1 = gimple_assign_rhs1 (stmt); > > > > > > if (TREE_CODE

[Bug fortran/79157] gfortran crashed on sparc with openmpi build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #8 from Eric Botcazou --- > what is correct command ? gfortran -S conftestf.f -g -O2 -wrapper gdb

[PR 79108] Put ipa_node_params to GC memory

Hi, when I fixed PR 78365 by streaming types of parameters that might not have been anywhere else, I forgot that I was holding them in non-GC memory and so I caused PR 79108. The following patch fixes it by putting ipa_param_descriptor and ipa_node_params structures into GC memory, together with

[Bug tree-optimization/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604 --- Comment #6 from Michael Meissner --- Unless -ffast-math or -fno-honor-nans is used, you cannot invert < to >=, because you will get a different result if either operand is a NaN. However, the basic code for vector compares hasn't changed

libgo patch committed: Fixes for cgo

This patch to libgo fixes misc/cgo/test in the master repository to work with gccgo. The package testing/internal/testdeps is now installed. It is required by the new go test. The function runtime.lockedOSThread is exported from the runtime package, so that it can be called from misc/cgo/test

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037 --- Comment #10 from Michael Karcher --- OK, I got it. I retract my last comment.

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #9 from Arnd Bergmann --- The warning seems to reliably disappear with -fno-schedule-insns, on every combination I've tried it produces better (smaller stack and faster code) or identical results to -fno-sched-critical-path-heuristic

[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318 --- Comment #9 from Bill Schmidt --- Seen also on powerpc64-unknown-linux-gnu, but not on powerpc64le-unknown-linux-gnu.

[Bug target/79170] New: memcmp builtin expansion sequence can overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79170 Bug ID: 79170 Summary: memcmp builtin expansion sequence can overflow Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79037 --- Comment #9 from Ian Lance Taylor --- The backend.h interface says that if you set the alignment, that is the alignment. I could change it to the GCC version--you can only increase the alignment--but I'd rather keep the backend.h interface

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 20/01/17 19:56, Andreas Tobler wrote: > On 20.01.17 17:12, Richard Earnshaw (lists) wrote: >> On 19/01/17 06:38, Andreas Tobler wrote: >>> On 19.01.17 00:33, Jeff Law wrote: On 01/18/2017 11:43 AM, Andreas Tobler wrote: > Hi all, > > I have the following issue here on

[Bug fortran/79157] gfortran crashed on sparc with openmpi build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 --- Comment #7 from Igor Kozhukhov --- what is correct command ? will be better for copy/past to be sure i do what you need :)

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146 --- Comment #5 from Ian Lance Taylor --- Well, it helped in that it uncovered a different problem. Fixed again.

[Bug go/79146] [7 Regression] Bootstrapping go on s390x fails; redefined symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79146 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Fri Jan 20 20:39:10 2017 New Revision: 244731 URL: https://gcc.gnu.org/viewcvs?rev=244731=gcc=rev Log: PR go/79146 math/big: fix build on s390x Don't build

[Bug fortran/79157] gfortran crashed on sparc with openmpi build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79157 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org ---

Re: libgo patch committed: Fix build on s390x GNU/Linux

On Thu, Jan 19, 2017 at 6:27 PM, Ian Lance Taylor wrote: > This patch to libgo fixes the build on s390x GNU/Linux by ignoring an > s390x-specific file that only works in conjunction with s390x assembly > code that has not (yet) been ported to gccgo. Bootstrapped and ran Go >

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 01/20/2017 12:56 PM, Andreas Tobler wrote: On 20.01.17 17:12, Richard Earnshaw (lists) wrote: On 19/01/17 06:38, Andreas Tobler wrote: On 19.01.17 00:33, Jeff Law wrote: On 01/18/2017 11:43 AM, Andreas Tobler wrote: Hi all, I have the following issue here on aarch64-*-freebsd: (sorry if

[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC|

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC|

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #18

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346 --- Comment #14 from Jeffrey A. Law --- Removing in gcc-8 sounds reasonable to me. Given that my analysis of undesirable sharing of range info for the other bug I was looking at was enough for Richi to find and fix the problem, I guess I'll

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #8 from Andrew Pinski --- The other thing to do is try with -fsched-pressure . PowerPC turns on -fsched-pressure by default (see PR 11488).

[Bug testsuite/79169] New: g++.dg/warn/Wduplicated-branches1.C fails on powerpc since its introduction in r244705

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79169 Bug ID: 79169 Summary: g++.dg/warn/Wduplicated-branches1.C fails on powerpc since its introduction in r244705 Product: gcc Version: 7.0 Status: UNCONFIRMED

Re: [PATCH 9e] Update "startwith" logic for pass-skipping to handle __RTL functions

On 01/19/2017 02:26 AM, Richard Biener wrote: On Wed, Jan 18, 2017 at 5:36 PM, Jeff Law wrote: On 01/17/2017 02:28 AM, Richard Biener wrote: This feels somewhat different, but still a hack. I don't have strong suggestions on how to approach this, but what we've got here

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 Andrew Pinski changed: What|Removed |Added Depends on||11488 --- Comment #7 from Andrew Pinski

Re: [PATCH] Add AVX512 k-mask intrinsics

2017-01-20 20:08 GMT+03:00 Kirill Yukhin : > Hi, > On 20 Jan 14:46, Uros Bizjak wrote: >> On Fri, Jan 20, 2017 at 2:32 PM, Andrew Senkevich >> wrote: >> >> > here is intrinsics for ktest{b,w,d,q} and kortest{b,w,d,q}. Is it Ok? >> > >> > gcc/

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #6 from Maxim Kuvyrkov --- Without looking at the code (it's 11pm) my guess is that 1st scheduling pass is misbehaving in some way, most likely it is doing a lot of interblock moves. One of the big differences between x86 and

Re: Another cprop trap_if fix, PR79125

On 01/20/2017 05:24 AM, Bernd Schmidt wrote: This is essentially the same patch I sent for the previous instance of this problem, but this time applied to local_cprop_pass. Bootstrapped and tested on x86_64-linux, and it seems to fix the testcase with a ppc cross. Ok? Bernd pr79125.diff

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 20.01.17 17:12, Richard Earnshaw (lists) wrote: On 19/01/17 06:38, Andreas Tobler wrote: On 19.01.17 00:33, Jeff Law wrote: On 01/18/2017 11:43 AM, Andreas Tobler wrote: Hi all, I have the following issue here on aarch64-*-freebsd: (sorry if the format is hardly readable) ..

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

On 01/20/2017 01:17 AM, Richard Biener wrote: On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote: On 01/19/2017 05:45 AM, Richard Biener wrote: On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote: In the attached testcase, we have a clearly bounded

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

On Fri, Jan 20, 2017 at 12:35:32PM -0700, Jeff Law wrote: > > This may be a naive question but why is it not possible to create > > such an SSA name? > Time and space complexity. To get the range information in this case we > have to create new SSA_NAMEs and PHI nodes to merge them at BB3. Not

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

On 01/20/2017 09:37 AM, Martin Sebor wrote: On 01/20/2017 01:17 AM, Richard Biener wrote: On Thu, Jan 19, 2017 at 5:53 PM, Martin Sebor wrote: On 01/19/2017 05:45 AM, Richard Biener wrote: On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote: In the

Re: [PR middle-end/79123] cast false positive in -Walloca-larger-than=

On 01/19/2017 05:45 AM, Richard Biener wrote: On Thu, Jan 19, 2017 at 1:17 PM, Aldy Hernandez wrote: In the attached testcase, we have a clearly bounded case of alloca which is being incorrectly reported: void g (int *p, int *q) { size_t n = (size_t)(p - q); if (n <

Re: Improve things for PR71724, in combine/if_then_else_cond

Hi Bernd, On Fri, Jan 20, 2017 at 01:33:59PM +0100, Bernd Schmidt wrote: > So, when looking for situations where we have only one condition, we can > try to undo the conversion of a plain REG into a condition, on the > grounds that this is probably less helpful. > > This seems to cure the

Re: [PATCH] Do not declare artificial variables in tree-profile.c to have a definition (PR lto/69188).

On 01/20/2017 02:46 AM, Martin Liška wrote: On 01/13/2017 06:21 PM, Jeff Law wrote: On 01/13/2017 08:08 AM, Martin Liška wrote: Hello. Nice example provided in the PR causes ICE as we have an artificial symbol created in tree-profile.c once being removed by remove unreachable nodes (-O0) and

Re: [1/5][AArch64] Return address protection on AArch64

On 20/01/17 18:30, Jiong Wang wrote: > > On 20/01/17 18:23, Jiong Wang wrote: >> >> OK, the attached patch disable the building of pointer signing code in >> libgcc >> on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I >> want to book this bit for ILP32 as LP64 in case we

Re: [1/5][AArch64] Return address protection on AArch64

On 20/01/17 18:23, Jiong Wang wrote: OK, the attached patch disable the building of pointer signing code in libgcc on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I want to book this bit for ILP32 as LP64 in case we later enable ILP32 support. All pauth builtins

Re: [1/5][AArch64] Return address protection on AArch64

Here is the patch. For XPACLRI builtin which drops the signature in a pointer, it's prototype is "void *foo (void *)" FOR PAC/AUT builtin which sign or authenticate a pointer, it's prototype is "void *foo (void *, uint64)". This patch adjusted those modes to make sure they strictly follow

Re: [ARM] Fix broken sibcall with longcall, APCS frame and VFP

> This seems to have fallen through a crack. Did you get a chance to try > either of these suggestions? So just: /* { dg-do run } */ /* { dg-options "-mapcs-frame -O -foptimize-sibling-calls -ffunction-sections" } */ in the header of the tescase? -- Eric Botcazou

[Bug c++/79118] [7 Regression] internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2258

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79118 --- Comment #9 from Nathan Sidwell --- Created attachment 40557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40557=edit template-ectomied

[Bug c++/78495] [7 regression][new inheriting ctors] invisible-ref parm has address taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78495 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: -mcx16 vs. not using CAS for atomic loads

On 01/19/2017 10:23 AM, Torvald Riegel wrote: * Option 3a: -mcx16 continues to only mean that cmpxchg16b is available, and we keep __sync builtins unchanged. This doesn't break valid uses of __sync* (eg, if they didn't need atomic loads at all). We change __atomic for 16-byte to not use

[Bug c++/78495] [7 regression][new inheriting ctors] invisible-ref parm has address taken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78495 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Fri Jan 20 17:53:44 2017 New Revision: 244728 URL: https://gcc.gnu.org/viewcvs?rev=244728=gcc=rev Log: PR c++/78495 - wrong code inherited ctor and invisi-ref parm *

Re: transaction_safe exceptions prevent libstdc++ building for some targets

On 19/01/17 12:05 +, Joe Seymour wrote: Here's the patch I'm proposing. I've tested it as follows: - msp430-elf no longer encounters the error when configuring libstdc++-v3. Note that libstdc++-v3 doesn't build due to an ICE though. - Configuring libstdc++-v3 for x86_64-unknown-linux-gnu

Re: RFA: Update XFAIL comments in

On Jan 20 2017, Nick Clifton wrote: > Index: gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c > === > --- gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c (revision 244691) > +++

Re: [ARM] Fix broken sibcall with longcall, APCS frame and VFP

On 01/09/16 10:03, Richard Earnshaw (lists) wrote: > On 01/09/16 10:03, Richard Earnshaw (lists) wrote: >> On 01/09/16 08:47, Eric Botcazou wrote: Since you're going to need a back-port there should be a PR filed for this. >>> >>> PR target/77439 >>> Have you checked that this works with

[Bug c++/78014] -Wformat -vs- size_t

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #5

[Bug c/79153] -Wimplicit-fallthrough missed warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153 --- Comment #5 from Marek Polacek --- I'd even go as far as saying that this is WONTFIX and we will not warn for nested switches.

[Bug c/79153] -Wimplicit-fallthrough missed warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153 --- Comment #4 from Marek Polacek --- This is probably because although we're handling ifs: 1896 /* Ifs are tricky. */ 1897 if (gimple_code (gsi_stmt (*gsi_p)) == GIMPLE_COND) we're not handling switches like that. Won't be that

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

Re: GCC libatomic ABI specification draft

On 01/20/2017 05:41 AM, Michael Matz wrote: Hi, On Wed, 18 Jan 2017, Richard Henderson wrote: Section 3 Rationale, alternative 1: I'm wondering if the example is correct. For a 4-byte-aligned type of size 3, the implementation cannot simply use 4-byte hardware-backed atomics because this

Re: [PATCH] Add AVX512 k-mask intrinsics

Hi, On 20 Jan 14:46, Uros Bizjak wrote: > On Fri, Jan 20, 2017 at 2:32 PM, Andrew Senkevich > wrote: > > > here is intrinsics for ktest{b,w,d,q} and kortest{b,w,d,q}. Is it Ok? > > > > gcc/ > > * config/i386/avx512bwintrin.h: Add k-mask test, kortest intrinsics.

[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 --- Comment #6 from Nick Clifton --- (In reply to ktkachov from comment #5) > Fine with me, Nick. But I suppose gcc-patches is the place to ask, I think > Segher also had something to say for shrink-wrapping Oops - sorry - I knew that. OK, I

[Bug sanitizer/79168] New: libtsan fails to link when cross compiling GCC tip for Aarch64 target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79168 Bug ID: 79168 Summary: libtsan fails to link when cross compiling GCC tip for Aarch64 target Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal

RFA: Update XFAIL comments in

Hi Guys, I would like to close out PR 70681 by applying the patch below. It updates the XFAIL comments in the two affected tests, explaining why the check for shrink-wrapping will fail. There is nothing actually wrong here. The shrink wrapping optimization is working and the targets

[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79167 --- Comment #3 from ronen at barzel dot org --- Ah OK. Thanks for the quick attention.

[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79167 --- Comment #2 from Jonathan Wakely --- N.B. https://gcc.gnu.org/projects/cxx-status.html shows that the "Refining Expression Evaluation Order for Idiomatic C++" feature (which changed these rules) isn't supported until GCC 7.

[Bug c++/79167] assignment operator LHS side-effect sequenced before RHS computation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79167 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/79167] New: LHS of assignment operator side-effect sequenced before RHS computation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79167 Bug ID: 79167 Summary: LHS of assignment operator side-effect sequenced before RHS computation Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal

  1   2   3   >