Re: [PATCH][AArch64] Implement ALU_BRANCH fusion

Hi James, >> My reason for asking is that the instruction fusion implemented in LLVM >> ( lib/Target/AArch64/AArch64MacroFusion.cpp::shouldScheduleAdjacent ) Sorry. There seems to be some confusion in the branch instructions. The branch should be conditional for ALU_BRANCH fusion. Please find

[P1][bootstrap/79771] [PATCH] Hack around zlib bug on Cygwin

Our current version of zlib has a bug where zlib has an unsatisfied reference to _wopen on Cygnwin. This is a bug in the upstream zlib and is being discussed there. This patch (from Yaakov Selkowitz) works around the problem and we'll carry it as a local change until upstream decides on

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Wed Mar 15 05:01:23 2017 New Revision: 246152 URL: https://gcc.gnu.org/viewcvs?rev=246152=gcc=rev Log: 2017-03-15 Yaakov Selkowitz PR bootstrap/79771

[Bug tree-optimization/79800] [7 Regression] wrong snprintf result range with precision in a narrow negative-positive range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79800 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|

Re: [PATCH] correct handling of negative-positive precision ranges with floating directives (PR 79800)

On 03/13/2017 06:33 PM, Martin Sebor wrote: The output of a floating point directive whose precision is specified by an asterisk with an argument that's in a range that includes both negative and positive values less than six may include between zero and six fractional digits plus a decimal

[Bug tree-optimization/79800] [7 Regression] wrong snprintf result range with precision in a narrow negative-positive range

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79800 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Wed Mar 15 04:31:27 2017 New Revision: 246151 URL: https://gcc.gnu.org/viewcvs?rev=246151=gcc=rev Log: PR tree-optimization/79800 * gimple-ssa-sprintf.c (format_floating:

Re: [PATCH] Suppress compiler warning in libgcc/unwind-seh.c

On 03/01/2017 04:36 AM, JonY wrote: Patch OK? ChangeLog: * unwind-seh.c: Suppress warnings for RtlUnwindEx() calls. You know this stuff better than anyone else working with GCC. If you think this is the right thing to do for the SEH code, go for it. jeff

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

> > Regression tested for GNU Fortran (GCC) 7.0.1 20170314 (experimental) on > x86_64-pc-linux-gnu with no regressions. This falls into the PITA classification. Also known as simple enough, regression test and commit. (consider it approved)

Re: patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 3

On 03/14/2017 04:01 PM, Thomas Koenig wrote: > Hello world, > > well, here is the third attempt at fixing the second part of the PR. > Glancing over the source, I think there are quite a few places where > we currently issue a runtime error which we could replace by an > assert, but that's

Re: Diagnostics that should not be translated

On 03/12/2017 04:51 PM, Roland Illig wrote: Hi, the gcc.pot file currently contains more than 12000 messages to be translated, which is a very high number. Many of these messages are diagnostics, and they can be categorized as follows: * errors in user programs, reported via error () *

Re: [PATCH doc] use "cannot" consistently

On 03/14/2017 02:53 PM, Richard Kenner wrote: The GCC manual uses "cannot" in most places (280 lines) but there are a few instances of "can't" (33 lines). The attached patch replaces the informal "can't" with the former for consistency. In my opinion, this is the wrong direction.

[Bug target/61837] missed loop invariant expression optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61837 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/62147] missed loop counter based optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62147 --- Comment #3 from Segher Boessenkool --- Still happens.

[Bug target/62233] unnecessary shift instructions to prepare loop counter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62233 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org ---

[Bug sanitizer/65643] FAIL: c-c++-common/asan/swapcontext-test-1.c on powerpc64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65643 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug translation/80001] diagnostics: untranslateable %s placeholders in omp-offload.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80001 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug c++/80016] error is positioned incorrectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80016 --- Comment #2 from David Malcolm --- Candidate patch for bogus *starting* location: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00797.html (this doesn't fix the bogus finish location)

[Bug c++/80014] [6/7 Regression] Caret missing in error message

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80014 --- Comment #4 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00796.html

[Bug fortran/79852] diagnostics should not end with exclamation mark

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug fortran/79860] i18n: single-word translation in "Character-valued %s %qs"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79860 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[PATCH] Fix location of sizeof/alignof (PR c++/80016)

PR c++/80016 reports an issue with bizarre underlined range for a complicated expression. The root cause for the incorrect *starting* location of that range is that alignof and sizeof expressions currently have start == finish == caret at the opening parenthesis of the expression. This patch

[PATCH] Fix location of typeid() (PR c++/80014)

PR c++/80014 reports an issue where no caret is printed when issuing an error for this bogus code: !typeid(void); Root cause is that we're not setting up the location for the cp_expr for the typeid expression, so that !typeid(void) has start == caret at the '!', but finish ==

[PATCH] omp-offload.c: translation fixes (PR translation/80001)

Successfully bootstrapped on x86_64-pc-linux-gnu. OK for trunk? (either now in stage 4, or for next stage1?) gcc/ChangeLog: PR translation/80001 * omp-offload.c (oacc_loop_fixed_partitions): Make diagnostics more amenable to translation.

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947 --- Comment #5 from Michael Meissner --- Author: meissner Date: Wed Mar 15 00:25:10 2017 New Revision: 246150 URL: https://gcc.gnu.org/viewcvs?rev=246150=gcc=rev Log: [gcc] 2017-03-14 Michael Meissner PR

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035 --- Comment #5 from Tom de Vries --- (In reply to Alexander Monakov from comment #3) > ptxas gets confused around loops lacking > exit edges (and perhaps other "unusual" CFG structures). They can easily > appear even in original source and do

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035 --- Comment #4 from Tom de Vries --- (In reply to Tom de Vries from comment #2) > Replacing trap with exit or ret (or adding it after trap), makes the sigsegv > go away. This problem goes away for ptxas -ori starting cuda 7.0.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

ion tested for GNU Fortran (GCC) 7.0.1 20170314 (experimental) on x86_64-pc-linux-gnu with no regressions.

[Bug driver/80044] New: Specifying both -static and -pie insanity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80044 Bug ID: 80044 Summary: Specifying both -static and -pie insanity Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

2017-03-13 16:33 GMT+03:00 Martin Liška : > On 03/13/2017 02:07 PM, Richard Biener wrote: >> No, that can't happen. I said that for example for >> >> struct S { ... } s; >> foo (s); >> >> pass_by_reference may be true but on gimple you see a struct s as >> actual argument. I'm

[Bug fortran/79447] [F08] gfortran rejects valid & accepts invalid internal subprogram in a submodule

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79447 Damian Rouson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

Re: [PATCH,RS6000] PR79963: Correct which condition code bit represents result of vec_any_eq built-in function

Hi Kelvin, On Tue, Mar 14, 2017 at 03:06:13PM -0600, Kelvin Nilsen wrote: > 2017-03-14 Kelvin Nilsen > > PR target/79963 > * config/rs6000/altivec.h (vec_all_ne): Under __cplusplus++ and It is spelled __cplusplus__. > __POWER9_VECTOR__ #ifdef control,

Re: Reload fix for an old aarch64 issue

On 03/14/2017 05:22 PM, Bernd Schmidt wrote: This triggered a kernel miscompilation with an old (4.8 I think) aarch64 toolchain. Here's the reloads for the insn where things go wrong: Reloads for insn # 210 Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ]) GENERAL_REGS,

Re: Reload fix for an old aarch64 issue

On Tue, Mar 14, 2017 at 4:22 PM, Bernd Schmidt wrote: > This triggered a kernel miscompilation with an old (4.8 I think) aarch64 > toolchain. Yes RHEL's 4.8 has the issue. So did Cavium/MontaVista's GCC 4.7 with AARCH64 support backported to it. We would work around the

Reload fix for an old aarch64 issue

This triggered a kernel miscompilation with an old (4.8 I think) aarch64 toolchain. Here's the reloads for the insn where things go wrong: Reloads for insn # 210 Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ]) GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)

[Bug middle-end/79753] [7 Regression][CHKP] ICE in ix86_expand_builtin, at config/i386/i386.c:36869

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

[Bug middle-end/79988] [7 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851

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

[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 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH] PR libstdc++/79789 fix non-reserved names in headers

On 10/03/17 15:20 +, Jonathan Wakely wrote: On 09/03/17 19:46 +, Jonathan Wakely wrote: On 03/03/17 10:47 -0500, David Edelsohn wrote: This patch caused a new regression on AIX. I'm unable to bootstrap on either gcc111 or gcc119 so I can't test the fix. export

[Bug sanitizer/79096] [7 Regression] address sanitizer and jni does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug c++/79393] [7 Regression] cc1plus rejects valid code with noexcept

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

Re: Combiner fix for PR79910

On 03/15/2017 12:03 AM, Jeff Law wrote: On 03/10/2017 04:24 PM, Bernd Schmidt wrote: PR rtl-optimization/79910 * combine.c (record_used_regs): New static function. (try_combine): Handle situations where there is an additional instruction between I2 and I3 which needs to have a

Re: Combiner fix for PR79910

On 03/10/2017 04:24 PM, Bernd Schmidt wrote: In this PR, we have a few insns involved in two instruction combinations: insn 16: set r100 insn 27: some calculation insn 28: some calculation insn 32: using r100 insn 33: using r100 insn 35: some calculation Then we combine insns 27, 28 and 33,

patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 3

Hello world, well, here is the third attempt at fixing the second part of the PR. Glancing over the source, I think there are quite a few places where we currently issue a runtime error which we could replace by an assert, but that's something for 8.0. Regression-tested on x86_64-pc-linux-gnu.

Re: [patch, fortran] PR39239 Warning about EQUIVALENCE and VOLATILE

On 03/14/2017 10:42 PM, Jerry DeLisle wrote: On 03/14/2017 01:17 PM, Nicolas Koenig wrote: Hello everyone, a simple patch to throw a warning if not all and not none of the equivalence objects are volatile. (And the according modification of gfortran.dg/volatile11.f90) Nicolas Regression

[Bug c/80036] Source line not printed for diagnostic if expanded from a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80036 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org

Re: [PATCH doc] use "cannot" consistently

On Tue, 14 Mar 2017, Martin Sebor wrote: > PS I wasted quite a bit of time updating tm.texi. I kept getting > the error below and didn't realize (forgot) that it was asking me > to copy $objdir/gcc/tm.texi to $srcdir/gcc/doc/tm.texi. Can > someone explain why this file requires these special

Re: [PATCH doc] use "cannot" consistently

On 03/14/2017 01:41 PM, Richard Sandiford wrote: Martin Sebor writes: @@ -373,7 +373,7 @@ example, this code would produce an error: @smallexample #if 0 -You can't expect this to work. +You cannot expect this to work. #endif @end smallexample Sure the maintainers

gcc-5-20170314 is now available

Snapshot gcc-5-20170314 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170314/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5

[gomp4] cleanup trans-stmt.h

I noticed that gcc/fortran/trans-stmt.h made a reference to a non-existent trans-openacc.c. Those functions have been placed in trans-openmp.c. This patch has been applied to gomp-4_0-branch to correct that error. Cesar 2017-03-14 Cesar Philippidis gcc/fortran/ *

[Bug rtl-optimization/80025] [5/6/7 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025 Bernd Schmidt changed: What|Removed |Added CC||aoliva at gcc dot gnu.org,

Re: [PATCH] MPX: fix PR middle-end/79753

2017-03-10 16:15 GMT+03:00 Martin Liška : > Hello. > > Currently, __builtin_ia32_bndret is used for all functions that have non-void > return type. I think the right fix is to return bounds just for a bounded > type. > > Patch can bootstrap on x86_64-linux-gnu and survives

[Bug driver/79659] Provide valid values for integer options (e.g. -Wformat) with --help= option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79659 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic

Re: [PATCH], PR target/79947, Fix compiler segmentation fault with -Ofast -mno-powerpc-gfxopt

Hi Mike, On Tue, Mar 14, 2017 at 05:01:53PM -0400, Michael Meissner wrote: > In PR target/79947, the code for using the float reciprocal square root > estimate instruction did not check if the -mpowerpc-gfxopt option was enabled. > The code needs this option to generate a conditional floating

[Bug c/67146] Wchkp is not documented in invoke.texi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67146 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug middle-end/79831] [DOC][CHKP] Missing -Wchkp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79831 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org ---

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80043 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug middle-end/80020] [7 Regression] gcc confused about aligned_alloc argument order

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80020 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|

[Bug middle-end/80020] [7 Regression] gcc confused about aligned_alloc argument order

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80020 --- Comment #2 from Jeffrey A. Law --- Author: law Date: Tue Mar 14 22:16:27 2017 New Revision: 246145 URL: https://gcc.gnu.org/viewcvs?rev=246145=gcc=rev Log: PR middle-end/80020 * builtin-attrs.def

Re: [PATCH] add calls.c to GTFILES in Makefile.in

On 03/07/2017 06:03 PM, Martin Sebor wrote: In bug 79936 - ICE with -Walloc-size-larger-than=32767 the reporter encountered an ICE on x86_64-apple-darwin10.8.0 caused by GCC source file that implements the warning accessing a global tree without having included the file in GTFILES make variable.

Re: [PATCH] correct aligned_alloc argument order (PR 80020)

On 03/13/2017 02:44 AM, Richard Biener wrote: On Mon, Mar 13, 2017 at 2:13 AM, Martin Sebor wrote: r243470 decorates standard allocation functions like alloca and malloc with attribute alloc_size. However, in applying the attribute to aligned_alloc I had overlooked that the

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

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

[Bug c/79936] [7 Regression] ICE with -Walloc-size-larger-than=32767

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79936 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Tue Mar 14 22:09:40 2017 New Revision: 246144 URL: https://gcc.gnu.org/viewcvs?rev=246144=gcc=rev Log: PR c/79936 * Makefile.in (GTFILES): Add calls.c. * calls.c:

Re: [patch, fortran] PR39239 Warning about EQUIVALENCE and VOLATILE

On 03/14/2017 01:17 PM, Nicolas Koenig wrote: > Hello everyone, > > a simple patch to throw a warning if not all and not none of the equivalence > objects are volatile. (And the according modification of > gfortran.dg/volatile11.f90) > > Nicolas > > Regression tested for: > > GNU Fortran (GCC)

Re: [PATCH] Fix PR79908

> On Mar 14, 2017, at 11:07 AM, Bill Schmidt > wrote: >> >> Your suggestion failed bootstrap in libiberty on vprintf-support.c. >> Compilation failed with: >> >> /home/wschmidt/gcc/build/gcc-mainline-test2-debug/gcc/xgcc >>

[PATCH,RS6000] PR79963: Correct which condition code bit represents result of vec_any_eq built-in function

This patch corrects several errors in a patch that was submitted on 2017-03-01. A copy-and-paste error in the previous patch resulted in accidental use of the lt flag instead of the eq flag to represent the outcome of the vec_any_eq built-in function. Also, in reviewing the code of the previous

[PATCH], PR target/79947, Fix compiler segmentation fault with -Ofast -mno-powerpc-gfxopt

In PR target/79947, the code for using the float reciprocal square root estimate instruction did not check if the -mpowerpc-gfxopt option was enabled. The code needs this option to generate a conditional floating point move. I have checked this patch on the trunk, and it fixes the problem and it

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #10 from niXman --- (In reply to Jonathan Wakely from comment #9) > There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html > > I haven't reviewed or tested it yet.

Re: [PATCH doc] use "cannot" consistently

> The GCC manual uses "cannot" in most places (280 lines) but there > are a few instances of "can't" (33 lines). > > The attached patch replaces the informal "can't" with the former > for consistency. In my opinion, this is the wrong direction. Contractions are becoming more acceptable in even

Re: [PATCH] Windows support for std::filesystem

niXman 2017-02-12 20:28: Hi, Tested on i686/x86_64-MinGW-W64 Please test possible regressions on posix platform. As continuation for: https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html Regression on posix platform was fixed. Tested on i686/x86_64-MinGW-W64 and x86_64-linux-gnu.

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947 --- Comment #4 from Michael Meissner --- Created attachment 40976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40976=edit Proposed patch to fix the problem The tARGET_RSQRTES macro needed a guard to require -mpowerpc-gfxopt.

Re: [PATCH] RISC-V documentation cleanups

On Mon, 13 Mar 2017, Palmer Dabbelt wrote: > A recent mailing list post about install.texi cleanup suggested I > take a look at ours, and there were a few problems: > > * No table of contents entries > * Not alphabetically ordered > * Missing a note about requiring binutils-2.28 This looks

[Bug libstdc++/80041] std::codecvt_utf16 converts to UTF-8 not UTF-16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80041 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #1 from Jonathan

[wwwdocs] remove power.org links from readings.html

Segher confirmed that power.org is gone and that it's okay to remove those links for now. He kindly agreed to help and look for alternatives. Applied. Gerald Index: readings.html === RCS file:

[patch, fortran] PR39239 Warning about EQUIVALENCE and VOLATILE

Hello everyone, a simple patch to throw a warning if not all and not none of the equivalence objects are volatile. (And the according modification of gfortran.dg/volatile11.f90) Nicolas Regression tested for: GNU Fortran (GCC) 7.0.1 20170311 (experimental) Changelog: 2017-03-13 Nicolas

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39239 Nicolas Koenig changed: What|Removed |Added Attachment #40964|0 |1 is obsolete|

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947 --- Comment #3 from Michael Meissner --- The problem is the -mno-powerpc-gfxopt option disables floating point conditional moves, which is needed to use the floating point reciprocal estimate instructions. The macro TARGET_FRSQRTES did not have

[Bug target/79947] [6/7 Regression] ICE in rs6000_emit_swsqrt at gcc/config/rs6000/rs6000.c:37570

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79947 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

On 03/12/2017 05:23 PM, Gerald Pfeifer wrote: Hi Martin, On Mon, 27 Feb 2017, Martin Sebor wrote: Sorry to be jumping in so late. I only noticed this bit now. I would suggest to say that these new built-ins evaluate to integer constant expressions when their arguments do. Not all C

Re: [PATCH doc] use "cannot" consistently

Martin Sebor writes: > @@ -373,7 +373,7 @@ example, this code would produce an error: > > @smallexample > #if 0 > -You can't expect this to work. > +You cannot expect this to work. > #endif > @end smallexample > Sure the maintainers would have caught this, but: the "'"

Re: [PATCH 1/5] testsuite: attr-alloc_size-11.c (PR79356)

On 03/12/2017 07:32 PM, Martin Sebor wrote: On 03/10/2017 10:51 PM, Jeff Law wrote: On 03/10/2017 09:20 AM, Martin Sebor wrote: On 03/10/2017 05:57 AM, Rainer Orth wrote: Hi Segher, On Fri, Feb 10, 2017 at 11:56:39AM +0100, Rainer Orth wrote: Segher Boessenkool

[PATCH doc] use "cannot" consistently

In formal writing it's recommended to prefer the word "cannot" to the somewhat informal "can't." The GCC manual uses "cannot" in most places (280 lines) but there are a few instances of "can't" (33 lines). The attached patch replaces the informal "can't" with the former for consistency. Thanks

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042 --- Comment #1 from Andrew Pinski --- Most likely because gcc assumes sin ( Inf); is a full constant so it can remove the load after it.

[Bug target/79951] ICE in extract_insn, at recog.c:2311 on ppc64le with -mno-cmpb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79951 Pat Haugen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

Re: [PATCH] Various fixes for facets

On 13/03/17 19:35 +, Jonathan Wakely wrote: This is a series of patches to fix various bugs in the Unicode character conversion facets. Ther first patch fixes a silly < versus <= bug that meant that 0x got written as a surrogate pair instead of as simply 0xff, and an endianness bug for

Re: C++ PATCH to fix ICE in replace_placeholders_r (PR c++/79937)

On Tue, Mar 14, 2017 at 2:33 PM, Jason Merrill wrote: > On Tue, Mar 7, 2017 at 12:10 PM, Marek Polacek wrote: >> In this testcase we have >> C c = bar (X{1}); >> which store_init_value sees as >> c = TARGET_EXPR >

Re: C++ PATCH to fix ICE in replace_placeholders_r (PR c++/79937)

On Tue, Mar 7, 2017 at 12:10 PM, Marek Polacek wrote: > In this testcase we have > C c = bar (X{1}); > which store_init_value sees as > c = TARGET_EXPR .n=(&)->i}>)> > i.e. we're initializing "c" with a TARGET_EXPR. We call

[Bug c++/80043] New: [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80043 Bug ID: 80043 Summary: [6/7 Regression] ICE with pointer-to-member-function and -fpermissive Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords:

[Bug middle-end/80042] New: gcc thinks sin/cos don't set errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042 Bug ID: 80042 Summary: gcc thinks sin/cos don't set errno Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

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

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728 --- Comment #7 from Jeffrey A. Law --- Author: law Date: Tue Mar 14 17:50:46 2017 New Revision: 246138 URL: https://gcc.gnu.org/viewcvs?rev=246138=gcc=rev Log: PR rtl-optimization/79728 * regs.h (struct target_regs): New field

Re: Fix IRA issue, PR79728

On 03/03/2017 06:51 AM, Bernd Schmidt wrote: This is an ICE where setup_pressure_classes fails if xmm0 is a global reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only SSE_FIRST_REG as the third register class. The problem is that the costs for moving between SSE_FIRST_REG and SSE_REGS

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

Thanks for answer, i got it now. I will also delete all readlink code. Looks like is no reason to use it instead just one call of realpath(char*,char*). Binutils using realpath in the same cases. On 03/14/2017 07:26 PM, Ian Lance Taylor wrote: On Tue, Mar 14, 2017 at 7:30 AM, Denis Khalikov

Re: Fix IRA issue, PR79728

On 03/03/2017 06:51 AM, Bernd Schmidt wrote: This is an ICE where setup_pressure_classes fails if xmm0 is a global reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only SSE_FIRST_REG as the third register class. The problem is that the costs for moving between SSE_FIRST_REG and SSE_REGS

Re: [PATCH] Use fixed_nonglobal_reg_set to deduce ok_regs (PR rtl-optimization/79728)

On 03/06/2017 01:27 AM, Xi Ruoyao wrote: Hi, After Bernd fixed PR44281 (r235809), the registers fixed only because they are global can be selected by IRA. However, since they are not in ok_regs, the move cost estimation about them are wrong. Then an assertion in ira.c failed and then ICE. To

[Bug rtl-optimization/79949] ICE in Max. number of generated reload insns per insn is achieved (90)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79949 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

Re: [PATCH] Install gcov-dump.

On 14.03.2017 15:15, Richard Biener wrote: > On Tue, Mar 14, 2017 at 1:30 PM, Martin Liška wrote: >> Tested on my local machine that's properly installed. >> >> Ready for trunk? > > Ok. > > Richard. shouldn't that go to the active branches as well? Matthias

[Bug c++/80038] Random segfault using local vectors in Cilk function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #8 from Jeffrey A. Law --- It's unfortunate and directly related to the maintenance effort involved. The deprecation plan for Cilk+ would have code in gcc-7, but the code would be removed prior to the gcc-8 release. Unless someone

[Bug libstdc++/80041] std::codecvt_utf16 converts to UTF-8 not UTF-16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80041 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

  1   2   3   >