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 >

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

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

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

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:

Re: Unused GCC builtins

Thank you for all answers, which are very useful for us! As you pointed out, we only considered GitHub projects. If I understood correctly, builtins would still not be deprecated even if we considered all other open-source hosting sites because closed-source projects could still rely on them,

Re: Unused GCC builtins

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 projects, > even though

[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

[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

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

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

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

[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

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

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

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 >

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

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

[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

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.

[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

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.  

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

[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

[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

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

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

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

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

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

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

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

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

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

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

[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

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

[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

[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 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #6 from David

[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

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

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

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

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

[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

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

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

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On 01/24/2018 12:03 PM, Jakub Jelinek wrote: On Wed, Jan 24, 2018 at 11:41:45AM +0100, Tom de Vries wrote: +/* Insert a dummy ptx insn when encountering a branch to a label with no ptx + insn inbetween the branch and the label. This works around a JIT bug + observed at driver version

[Bug target/84025] New: [nvptx] Don't generate branch-around-nothing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84025 Bug ID: 84025 Summary: [nvptx] Don't generate branch-around-nothing Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component:

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #21 from boger at us dot ibm.com --- (In reply to Alexandre Oliva from comment #19) > I was copied, presumably because the problem occurred in var-tracking. > > I've tried to duplicate the problem on gcc112. I bootstrapped the trunk

[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug tree-optimization/84011] Optimize switch table with run-time relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 --- Comment #8 from rguenther at suse dot de --- On Wed, 24 Jan 2018, hjl.tools at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 > > H.J. Lu changed: > >What|Removed |Added >

[Bug target/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83589 --- Comment #9 from Tom de Vries --- Author: vries Date: Wed Jan 24 13:52:12 2018 New Revision: 257016 URL: https://gcc.gnu.org/viewcvs?rev=257016=gcc=rev Log: [nvptx, PR83589] Workaround for branch-around-nothing JIT bug 2018-01-24 Tom de

RE: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} issues (PR target/83488)

Hi, Fixed it. Ok for trunk? gcc/ * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask, _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask, _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask, _mm_mask_bitshuffle_epi64_mask): Fix

[Bug testsuite/84023] gcc.dg/ipa/inline-8.c fail with -fpic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84023 --- Comment #2 from H.J. Lu --- (In reply to Richard Biener from comment #1) > I think that's probably spurious: > > void > set () > { > a=nan(""); > } > ... > float a = move (1); > if (!__builtin_constant_p (a)) > __builtin_abort ();

Re: [PATCH, 2/2][nvptx, PR83589] Workaround for branch-around-nothing JIT bug

On Wed, Jan 24, 2018 at 02:56:28PM +0100, Tom de Vries wrote: > +#if WORKAROUND_PTXJIT_BUG_2 > +/* Variant of pc_set that only requires JUMP_P (INSN) if STRICT. This > variant > + is needed in the nvptx target because the branches generated for > + parititioning are NONJUMP_INSN_P, not

Re: Remove explicit dg-do runs from gcc.dg/vect (PR 83889)

On Tue, Jan 23, 2018 at 12:32 PM, Richard Sandiford wrote: > The failures in this PR were from forcing { dg-do run } even when > vect.exp chooses options that are incompatible with the runtime. > The default vect.exp behaviour is to execute when possible, so there's

[PATCH][testsuite] Fix arm options in gcc.dg/lto/20110201-1_0.c

Hi all, This test fails on arm hardfloat targets because it sets an explicit -mfloat-abi=softfp. The usual approach to setting the NEON options is to use dg-add-options arm_neon. But in the lto tests we don't have that framework, we can only set them explicitly with dg-lto-options. The

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2

[Bug fortran/2018] Sqrt causes ice in emit_move_insn, at expr.c:2718

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2018 --- Comment #3 from Tom de Vries --- Author: vries Date: Wed Jan 24 13:52:12 2018 New Revision: 257016 URL: https://gcc.gnu.org/viewcvs?rev=257016=gcc=rev Log: [nvptx, PR83589] Workaround for branch-around-nothing JIT bug 2018-01-24 Tom de

[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4

[Bug target/84011] Optimize switch table with -fPIE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 --- Comment #5 from H.J. Lu --- (In reply to rguent...@suse.de from comment #4) > > The question is why run-time relocations aren't allowed. > > Probably added to save binary space? An optimization would be to I don't think so: text

[Bug target/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83589 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/84011] Optimize switch table with -fPIE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 H.J. Lu changed: What|Removed |Added CC||jakub at redhat dot com Depends on|

[Bug tree-optimization/84011] Optimize switch table with run-time relocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7

Re: Fix use of boolean_true/false_node (PR 83979)

On Tue, Jan 23, 2018 at 12:25 PM, Richard Sandiford wrote: > r255913 changed some constant_boolean_node calls to boolean_true_node > and boolean_false_node, which meant that the returned tree didn't > always have the right type. > > Tested on aarch64-linux-gnu.

  1   2   3   >