Re: [PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

Hi Steve, I have a couple of questions before I have to hurry off to work: First, why is @@ -2253,22 +2253,19 @@ gfc_simplify_dim (gfc_expr *x, gfc_expr *y) gfc_expr* gfc_simplify_dot_product (gfc_expr *vector_a, gfc_expr *vector_b) { + /* If vector_a is a zero-sized array, the result

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

Re: jamais-vu can now ignore renumbering of source lines in dg output (Re: GCC Buildbot Update)

On 24/01/18 20:20, David Malcolm wrote: > > I've added a new feature to jamais-vu (as of > 77849e2809ca9a049d5683571e27ebe190977fa8): it can now ignore test > results that merely changed line number. > > For example, if the old .sum file has a: > > PASS:

[Bug target/84033] New: powerpc64le -moptimize-swaps bad code with vec_vbpermq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033 Bug ID: 84033 Summary: powerpc64le -moptimize-swaps bad code with vec_vbpermq Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3

Re: New istreambuf_iterator debug check

On Wed, 24 Jan 2018 21:34:48 +0100 François Dumont wrote: > On 24/01/2018 18:53, Petr Ovtchenkov wrote: > > On Wed, 24 Jan 2018 17:39:59 +0100 > > François Dumont wrote: > > > >> Hi > >> > >>     I'd like to propose this new debug check. Comparing

libbacktrace patch committed: Fix setting str_size on PE/COFF

This libbacktrace patch fixes the setting of str_size on PE/COFF to not leave some bytes uninitialized on a 64-bit host. Committed to mainline. Ian 2018-01-24 Ian Lance Taylor * pecoff.c (coff_add): Use coff_read4, not memcpy. Index: pecoff.c

[Bug c++/83211] Warning: ignoring incorrect section type for .init_array.00200

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83211 Oleg Endo changed: What|Removed |Added Target||rx*-*-* arm*-*-*

[Bug other/68239] libbacktrace allocation is sometimes very slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68239 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug target/84032] New: ICE in optimize_sc, at modulo-sched.c:1064

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 Bug ID: 84032 Summary: ICE in optimize_sc, at modulo-sched.c:1064 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal

[Bug other/68239] libbacktrace allocation is sometimes very slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68239 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Thu Jan 25 02:24:45 2018 New Revision: 257039 URL: https://gcc.gnu.org/viewcvs?rev=257039=gcc=rev Log: PR other/68239 * mmap.c (backtrace_free_locked): Don't put

libbacktrace patch committed: Only keep 16 entries on free list

PR 68239 points out that libbacktrace can sometimes take a long time scanning the list of free memory blocks looking for one that is large enough. Since the libbacktrace memory allocator does not have to be perfect in practice, only keep the 16 largest entries on the free list. Bootstrapped and

[PATCH] PR fortran/83998 -- fix dot_product on 0-sized arrays

All, The attach patch fixes a regression with dot_product and zero-sized arrays. I bootstrapped and regression tested the patch on x86_64-*-freebsd. OK to commit? 2018-01-23 Steven G. Kargl PR fortran/83998 * simplify.c (gfc_simplify_dot_product): Deal

[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482

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

[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550 --- Comment #9 from Michael Meissner --- Author: meissner Date: Thu Jan 25 01:09:19 2018 New Revision: 257038 URL: https://gcc.gnu.org/viewcvs?rev=257038=gcc=rev Log: [gcc/testsuite] 2018-01-24 Michael Meissner

[Bug c++/84031] New: structured binding unpacks nameless padding bitfields

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84031 Bug ID: 84031 Summary: structured binding unpacks nameless padding bitfields Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/83950] [8 regression] error: no matching function for call to ‘folly::dynamic::at(size_t&) const’

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83950 --- Comment #3 from Sunil Pandey --- I shouldn't say it's bug, sorry about that. Just application build regression from GCC 7 to GCC 8. Looks like creduce reduced this test case too much in this case.

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 05:00:39PM -0500, Michael Meissner wrote: > Replacing 'int' with 'unsigned long' allows the test to succeed once again. I > have checked this on a big endian power8 (both 32-bit and 64-bit) and on a > little endian power8 (64-bit only), and it passes in all three

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #6 from David

[committed] Fix jit.dg/test-alignment* (PR jit/82846)

These testcases jit-compile functions that return char, but were erroneously calling them as if they returned int. This led to errors for certain target configurations (e.g. reading from %eax (32-bit) in the harness when only %al (8-bit) had been written to in the jit-compiled function).

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Thu Jan 25 00:45:51 2018 New Revision: 257037 URL: https://gcc.gnu.org/viewcvs?rev=257037=gcc=rev Log: Fix jit.dg/test-alignment* (PR jit/82846) These testcases jit-compile functions

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #7 from Segher Boessenkool --- It is first V2DI in the RTL, which exists just fine (but there is no such divide insn); then when it is split to two DImode divides, it just generates div:DI etc., which does not exist for -m32. So we

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 03:19:00PM -0500, Michael Meissner wrote: > On Wed, Jan 24, 2018 at 12:35:38PM -0600, Segher Boessenkool wrote: > > Although, hrm, in your patch you also change "int i" to "long i"; that > > alone seems to be enough to fix everything? Could you check that please? > >

Go patch committed: Rationalize external symbol names

This patch to the Go frontend rationalizes the external symbol names that appear in assembler code. It changes from the ad hoc mechanisms used to date to produce a set of names that are at least somewhat more coherent. They are also more readable, after applying a simple demangling algorithms

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #19 from Joseph S. Myers --- Author: jsm28 Date: Wed Jan 24 23:36:29 2018 New Revision: 257032 URL: https://gcc.gnu.org/viewcvs?rev=257032=gcc=rev Log: Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467). PR target/68467

[C++ PATCH] Don't clear TREE_CONSTANT on ADDR_EXPRs (PR c++/83993)

Hi! cxx_eval_outermost_constant_expr clears TREE_CONSTANT on ADDR_EXPRs that aren't considered by C++ constant expressions, but that breaks middle-end which relies on TREE_CONSTANT being set on ADDR_EXPR where the address is constant. The following patch just special cases ADDR_EXPR not to clear

[C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

Hi! In constexpr evaluation of array references for arrays with unknown bounds, we need to diagnose out of bounds accesses, but really don't know the bounds at compile time, right now GCC will see nelts as error_mark_node + 1 and will not consider them a constant expression at all. >From the

[Bug fortran/52153] REAL128 gives extended precision, not quad precision

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW

gcc-6-20180124 is now available

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

Re: Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467)

On 01/24/2018 03:24 PM, Joseph Myers wrote: > PR target/68467 is libgcc failing to build for m68k-linux-gnu > configured for ColdFire. > > Jeff has an analysis in the PR identifying the problem as resulting > from the callers of libcalls with 1-byte or 2-byte arguments wanting > to push just 1 or

Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467)

PR target/68467 is libgcc failing to build for m68k-linux-gnu configured for ColdFire. Jeff has an analysis in the PR identifying the problem as resulting from the callers of libcalls with 1-byte or 2-byte arguments wanting to push just 1 or 2 bytes on the stack, while the libcall implementations

[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #4 from Jakub Jelinek --- (In reply to paul.richard.tho...@gmail.com from comment #3) > OK for trunk? Ok, thanks.

Re: [PATCH, fortran] Support Fortran 2018 teams

On Wed, Jan 24, 2018 at 08:19:58PM +, Paul Richard Thomas wrote: > (Jakub, This is all hidden behind the -fcoarray option. To my mind > this is safe for release.) Ok from RM POV. Jakub

Re: [PATCH][PR target/83994] Fix stack-clash-protection code generation on x86

On 01/24/2018 12:11 AM, Uros Bizjak wrote: > On Wed, Jan 24, 2018 at 12:15 AM, Jeff Law wrote: >> >> pr83994 is a code generation bug in the stack-clash support that affects >> openssl (we've turned on stack-clash-protection by default for the F28 >> builds). >> >> The

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #6 from Bill Schmidt --- But I assume that's your transcription error. In the test case the arguments are vector long long.

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #5 from Bill Schmidt --- That looks completely invalid, the args should be vector long long, not long long.

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 12:35:38PM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 24, 2018 at 12:27:55AM -0500, Michael Meissner wrote: > > > > As Segher and I were discussing over private IRC, the root cause of this > > bug is > > the compiler no long generates the BDNZ instruction for

[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode

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

[Bug target/83994] %ebx is clobbered by stack-clash probing for regparm-3 function in PIC mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994 --- Comment #4 from Jeffrey A. Law --- Author: law Date: Wed Jan 24 21:57:16 2018 New Revision: 257031 URL: https://gcc.gnu.org/viewcvs?rev=257031=gcc=rev Log: PR target/83994 * i386.c (get_probe_interval): Move to earlier

[RFC][PR82479] missing popcount builtin detection

Hi All, Here is a patch for popcount builtin detection similar to LLVM. I would like to queue this for review for next stage 1. 1. This is done part of loop-distribution and effective for -O3 and above. 2. This does not distribute loop to detect popcount (like memcpy/memmove). I dont think that

[Bug target/83743] -mcpu=native causes gcc to exit in error if cpu is not recognized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83743 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL|

[PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

The following patch fixes both PR56010 and PR83743. PR56010 is fixed by adding an extra altname field to the RS6000_CPU table which matches the cases where the Linux kernel's AT_PLATFORM name differs from the name GCC expects. If we match on the altname, then we return the canonical name.

Re: Different dynamical array debug info 7.2 vs. 8.0

On Tue, Jan 23, 2018 at 4:02 PM, Yao Qi wrote: > > Hi, > I observed that gfortran 7.2 and 8.0 generate different debug info for > dynamical array. > Attributes DW_AT_data_location and DW_AT_allocated are different. There > is an extra "DW_OP_plus_uconst: 8" generated by gcc

[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards

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

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

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

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #7 from Bill Long --- Thanks - very helpful information. I'll try to find out what version of gcc was used to build their library.

[Bug middle-end/84024] [8 Regression] internal compiler error: in operator>, at profile-count.h:855

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

[Bug tree-optimization/83055] [8 Regression] ICE in operator>, at profile-count.h:834

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83055 Jeffrey A. Law changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment

Re: [PATCH, fortran] Support Fortran 2018 teams

On January 24, 2018 at 1:29:12 PM, Steve Kargl (s...@troutmask.apl.washington.edu) wrote: Yes, thanks, Paul. Unfortunately, I've run out of time. Damian, GCC is in stage 3, we need to wait for approval from the release manager (aka Jakub) before committing the patch. Will do.  

Re: [PATCH, fortran] Support Fortran 2018 teams

On Wed, Jan 24, 2018 at 01:25:51PM -0800, Damian Rouson wrote: > Thank you, Paul. I think Alessandro has commit rights. > If so, then I’ll ask him to make the requested edits and commit it. > > Damian > Yes, thanks, Paul. Unfortunately, I've run out of time. Damian, GCC is in stage 3, we need

Re: [PATCH, fortran] Support Fortran 2018 teams

Thank you, Paul.   I think Alessandro has commit rights.  If so, then I’ll ask him to make the requested edits and commit it. Damian On January 24, 2018 at 12:19:58 PM, Paul Richard Thomas (paul.richard.tho...@gmail.com) wrote: Hi All, Given the delay relative to the start of stage 3, I

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83926 --- Comment #4 from Will Schmidt --- I'm having a moment of doubt on the validity of the testcases involved here. vector long long a = vec_div(long long b, long long c); Any chance that is invalid for -m32 ? I don't see a whole lot of

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #6 from Dominique d'Humieres --- Note that I got a Internal Error: stash_internal_unit(): Stack Size Exceeded when using mismatched gfortran 7.2.0 and omp_lib.mod.

[Bug c++/84030] New: Name lookup in presence of namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84030 Bug ID: 84030 Summary: Name lookup in presence of namespace Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #5 from Bill Long --- I tried on my Mac laptop (gcc version 6.3.0) and it also works there. Evidently not a representative test. The differences I see between that environment and the original customer's is that they are running

[Bug target/84010] [sparc64] Problematic TLS code generation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010 --- Comment #6 from Richard Henderson --- For better rematerialization, I wonder if it wouldn't be better to represent this as (set (reg:P tmp) (const:P (unspec [(symbol_ref "xxx")] UNSPEC_TLSIE))) prior to reload, and split to

nonsense warning from texinfo while processing intrinsic.texi

I added some documentation to fortran/intrinsic.texi. In processing the gfortran.f90, I discovered this warning. makeinfo --split-size=500 --split-size=500 --split-size=500 \ -I ../../gcc/gcc/doc/include -I ../../gcc/gcc/fortran \ -o doc/gfortran.info

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #4 from Dominique d'Humieres --- > What happens with 16 threads? % gfc -fopenmp pr83948.f90 % setenv OMP_NUM_THREADS 16 % ./a.out Table element number = 995 Same pole re-projecting area source: Beginnng of new record:

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 --- Comment #3 from Bill Long --- What happens with 16 threads?

[Bug target/83926] ICE during RTL pass: ira, in elimination_costs_in_insn, at reload1.c:3633

cc Target: powerpc64-unknown-linux-gnu Configured with: ../../gcc-7-branch/configure --enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7 --disable-multilib --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-7-branch --disable-bootstrap Thread model: posix gcc version 7.2.1 2018

Re: New istreambuf_iterator debug check

On 24/01/2018 18:53, Petr Ovtchenkov wrote: On Wed, 24 Jan 2018 17:39:59 +0100 François Dumont wrote: Hi     I'd like to propose this new debug check. Comparing with non-eos istreambuf_iterator sounds like an obvious coding mistake.     I propose it despite the

Re: Add support for bitwise reductions

Jeff Law writes: > On 11/22/2017 11:12 AM, Richard Sandiford wrote: >> Richard Sandiford writes: >>> This patch adds support for the SVE bitwise reduction instructions >>> (ANDV, ORV and EORV). It's a fairly mechanical extension of existing >>>

[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999 --- Comment #3 from paul.richard.thomas at gmail dot com --- Hi Jakub, I have made the changes to the types of the dtype elements that you suggested. It led to a cast being needed in trans-intrinsic.c(gfc_conv_intrinsic_rank) but, apart from

Re: [PATCH, fortran] Support Fortran 2018 teams

Hi All, Given the delay relative to the start of stage 3, I thought that I had better deal with this asap: + /* TODO: this works on any derived type when + it should only work with team_type. */ + if (team->ts.type != BT_DERIVED) Why don't you give the team_type derived type

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

On Wed, Jan 24, 2018 at 12:35:38PM -0600, Segher Boessenkool wrote: > Hi! > > On Wed, Jan 24, 2018 at 12:27:55AM -0500, Michael Meissner wrote: > > > > As Segher and I were discussing over private IRC, the root cause of this > > bug is > > the compiler no long generates the BDNZ instruction for

Re: [PATCH] Fix gcc.target/aarch64/sve/peel_ind_1.c for -mcmodel=tiny

Szabolcs Nagy writes: > Fix test failures with -mcmodel=tiny when adr is generated instead of adrp. > > FAIL: gcc.target/aarch64/sve/peel_ind_1.c -march=armv8.2-a+sve > scan-assembler \\tadrp\\tx[0-9]+, x\\n > FAIL: gcc.target/aarch64/sve/peel_ind_2.c -march=armv8.2-a+sve >

patch to fix PR84014

The following patch fixes    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 The patch was tested on powerpc64 and bootstrapped on x86-64. Committed as rev. 257029. Index: ChangeLog === --- ChangeLog (revision 257028) +++

[Bug target/84014] [6/7/8 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 --- Comment #3 from Vladimir Makarov --- Author: vmakarov Date: Wed Jan 24 19:45:55 2018 New Revision: 257029 URL: https://gcc.gnu.org/viewcvs?rev=257029=gcc=rev Log: 2018-01-24 Vladimir Makarov PR target/84014

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #13 from Pedro Alves --- Fix is now in GDB's master, 8.1, and 8.0 branches.

jamais-vu can now ignore renumbering of source lines in dg output (Re: GCC Buildbot Update)

On Sat, 2017-12-16 at 12:06 +0100, Paulo Matos wrote: > > On 15/12/17 15:29, David Malcolm wrote: > > On Fri, 2017-12-15 at 10:16 +0100, Paulo Matos wrote: > > > > > > On 14/12/17 12:39, David Malcolm wrote: > > > > [...] > > > > > > It looks like you're capturing the textual output from "jv >

[Bug target/83845] [8 regression] new failures after r256620

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83845 --- Comment #3 from rsandifo at gcc dot gnu.org --- FWIW, I now have patches that fix all the big-endian SVE failures. Hope to post them later this week.

[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/83979] [8 Regression] ICE with pointer comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83979 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug sanitizer/81601] [7/8 Regression] incorrect Warray-bounds warning with -fsanitize

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601 --- Comment #20 from Aldy Hernandez --- Created attachment 43233 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43233=edit WIP that fixes PR, but causes other regressions I am attaching a proof of concept hack that fixes this PR by moving

[Bug middle-end/84029] New: Partially inline strcmp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84029 Bug ID: 84029 Summary: Partially inline strcmp Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 --- Comment #10 from Steve Kargl --- n Wed, Jan 24, 2018 at 03:38:10PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207 > > --- Comment #9 from Steve Kargl --- > On Wed, Jan 24, 2018 at

Re: [PATCH], PR target/81550, Rewrite PowerPC loop_align test so it still tests the original target hook

Hi! On Wed, Jan 24, 2018 at 12:27:55AM -0500, Michael Meissner wrote: > > As Segher and I were discussing over private IRC, the root cause of this bug > is > the compiler no long generates the BDNZ instruction for a count down loop, > instead it decrements the index in a GPR and does a

Re: Unused GCC builtins

* Jakub Jelinek: > On Wed, Jan 24, 2018 at 03:04:55PM +0100, Manuel Rigger wrote: >> In a second step, we also considered internal builtins and found that the >> vararg handling builtins (__builtin_va_start, __builtin_va_end, >> __builtin_va_arg, and __builtin_va_copy) are relied upon by many

[Bug target/84014] [6/7/8 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 --- Comment #2 from Vladimir Makarov --- Thank you for reporting. The problem occurs when only one subreg (obj) of register (allocno) is used in a function. I'll work on a patch.

[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org,

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On January 24, 2018 6:51:54 PM GMT+01:00, Richard Biener wrote: >On January 24, 2018 6:40:25 PM GMT+01:00, Jakub Jelinek > wrote: >>On Wed, Jan 24, 2018 at 06:36:02PM +0100, Martin Jambor wrote: >>> > I think there's already a set of attributes that prevent

[Bug target/84028] [nvptx] nested-function-1.f90 hangs at -O1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84028 Tom de Vries changed: What|Removed |Added Keywords||openacc Target|

Re: New istreambuf_iterator debug check

On Wed, 24 Jan 2018 17:39:59 +0100 François Dumont wrote: > Hi > >     I'd like to propose this new debug check. Comparing with non-eos > istreambuf_iterator sounds like an obvious coding mistake. > >     I propose it despite the stage 1 as it is just a new debug

[Bug target/84028] New: [nvptx] nested-function-1.f90 hangs at -O1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84028 Bug ID: 84028 Summary: [nvptx] nested-function-1.f90 hangs at -O1 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On January 24, 2018 6:40:25 PM GMT+01:00, Jakub Jelinek wrote: >On Wed, Jan 24, 2018 at 06:36:02PM +0100, Martin Jambor wrote: >> > I think there's already a set of attributes that prevent cloning >and >> > or are adjusted by the IPA param machinery. The Martins or Honza >> >

[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug fortran/82007] DTIO write format stored in a string leads to severe errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82007 --- Comment #9 from Dominique d'Humieres --- > Should I backport this to 7? IMO yes.

[build] Configure USE_HIDDEN_LINKONCE on Solaris/x86

Prompted by PR target/83838 (Many gcc.target/i386/indirect-thunk*.c tests FAIL), which is caused by this snippet in i386/sol2.h /* Only recent versions of Solaris 11 ld properly support hidden .gnu.linkonce sections, so don't use them. */ #ifndef USE_GLD #define USE_HIDDEN_LINKONCE 0 #endif

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On Wed, Jan 24, 2018 at 06:36:02PM +0100, Martin Jambor wrote: > > I think there's already a set of attributes that prevent cloning and > > or are adjusted by the IPA param machinery. The Martins or Honza > > should know better. > > I am not sure I understand the problem but if >

[Bug libfortran/83948] Thread safety issue writing to internal file - libgfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

Re: [PATCH] Fix ICEs with "omp declare simd" attribute on versioned fns or omp_fn* (PR middle-end/83977)

On Wed, Jan 24 2018, Richard Biener wrote: > On January 24, 2018 5:16:45 PM GMT+01:00, Jakub Jelinek > wrote: >>On Wed, Jan 24, 2018 at 05:08:10PM +0100, Richard Biener wrote: >>> >The "omp declare simd" attribute refers to argument numbers of the >>> >functions, so trying to

[Bug target/83368] alloca after setjmp breaks PIC base reg

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368 --- Comment #19 from James Clarke --- Thanks for the fix; is this a candidate for backporting to the gcc-7 branch? If not we can just carry it in Debian, but it would be nicer to have it upstream.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906 --- Comment #12 from Pedro Alves --- GDB fix posted here: https://sourceware.org/ml/gdb-patches/2018-01/msg00482.html

[Bug fortran/83939] Constraint C1290 (elemental function cannot be allocatable) not enforced

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83939 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4

[Bug c++/83692] Rejects valid constexpr with unrelated code fixing problem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692 --- Comment #4 from Marek Polacek --- Seems like in C++17 the condition in if (m_x.value() != 1) throw 0; gets evaluated to 1 instead of 0, so we try to evaluate the "throw 0" but that can't be evaluated to a constant value. Maybe some

[Bug fortran/83980] Various issues with character length in array constructors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83980 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Tue, Dec 12, 2017 at 12:54:13AM -0200, Alexandre Oliva wrote: > +/* Check whether BLOCK, a lexical block, is nested within OUTER, or is > + OUTER itself. If BOTHWAYS, check not only that BLOCK can reach > + OUTER through BLOCK_SUPERCONTEXT links, but also that there is a > + path from

[Bug fortran/83823] [8 Regression] Character length issues with PACK()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83823 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote: > --- a/include/dwarf2.h > +++ b/include/dwarf2.h > @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type > DW_LLE_start_end = 0x07, > DW_LLE_start_length = 0x08, > > +/* >

Re: [aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

On Wednesday 24 January 2018 06:29 PM, Siddhesh Poyarekar wrote: >>> +  /* Avoid register indexing for 128-bit stores when the >>> + AARCH64_EXTRA_TUNE_SLOW_REGOFFSET_QUADWORD_STORE option is set.  */ >>> +  if (!optimize_size >>> +  && type == ADDR_QUERY_STR >>> +  &&

  1   2   3   >