Re: [PATCH 2/4 GCC11] Add target hook stride_dform_valid_p

2020-05-12 Thread Kewen.Lin via Gcc-patches
Hi, I'd like to ping this patch as well as its sblings. Thanks in advance. 1/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540171.html 2/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541387.html 3/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545643.html

[PATCH 3/4 V3 GCC11] IVOPTs Consider cost_step on different forms during unrolling

2020-05-12 Thread Kewen.Lin via Gcc-patches
Hi, Updated to v3 according to 2/4's param change. BR, Kewen --- gcc/ChangeLog 2020-MM-DD Kewen Lin * tree-ssa-loop-ivopts.c (struct iv_group): New field reg_offset_p. (struct iv_cand): New field reg_offset_p. (struct ivopts_data): New field

[PATCH] c++: SFINAE for invalid delete-expression [PR79706]

2020-05-12 Thread Patrick Palka via Gcc-patches
This fixes SFINAE when substitution yields an invalid delete-expression due to the pertinent deallocation function being marked deleted or otherwise inaccessible. We need to check for an erroneous result from build_op_delete_call and exit early in that case, so that we don't build a COND_EXPR

Re: [PATCH] Refactor tree-vrp.c

2020-05-12 Thread Giuliano Belinassi via Gcc-patches
Hi. On 05/11, Richard Biener wrote: > On Fri, May 8, 2020 at 7:11 PM Jeff Law via Gcc-patches > wrote: > > > > On Fri, 2020-05-08 at 13:06 -0300, Giuliano Belinassi via Gcc-patches wrote: > > > Hi, > > > > > > This patch Refactors tree-vrp.c to eliminate all global variables except > > >

Re: [PR 95013] EOF location is at end of file

2020-05-12 Thread H.J. Lu via Gcc-patches
On Tue, May 12, 2020 at 2:24 PM Nathan Sidwell wrote: > > My recent C++ parser change to pay attention to EOF location uncovered a > separate bug. The preprocesor's EOF logic would set the EOF location to > be the beginning of the last line of text in the file -- not the 'line' > after that,

[PATCH] RISC-V: Make unique SECCAT_SRODATA names start with .srodata

2020-05-12 Thread Jim Wilson
This fixes a bug reported to the RISC-V sw-dev mailing list late last year. https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/JV5Jdh4UjVw Keith Packard wote the obvious patch to fix it. I tested it with cross builds for riscv32-newlib and riscv64-linux. There were no

[PATCH] Add -fsplit-dwarf

2020-05-12 Thread Fangrui Song via Gcc-patches
-fsplit-dwarf is similar to -gsplit-dwarf, but does not enable debugging information by itself. This makes it easier to be plugged into a build system without worrying that unnecessary debugging information may be generated. 2020-05-12 Fangrui Song PR debug/95096 * common.opt:

Re: [PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

2020-05-12 Thread Jim Wilson
On Sun, Apr 12, 2020 at 7:54 PM Kito Cheng wrote: > On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson wrote: > > Do we really need this now? It is a new feature not a bug fix, so it > > might be better to wait until we reach stage1. We have limited time > > to test this before the gcc-10 release. > >

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

2020-05-12 Thread Jim Wilson
On Mon, Apr 27, 2020 at 10:08 AM Craig Blackmore wrote: > Thanks for the review. I have updated the following patch with those changes. This looks good, and the tree is open for development work again, so I committed both parts 1 and 2 and pushed it. One weird thing is that while the patch

[PR 95013] EOF location is at end of file

2020-05-12 Thread Nathan Sidwell
My recent C++ parser change to pay attention to EOF location uncovered a separate bug. The preprocesor's EOF logic would set the EOF location to be the beginning of the last line of text in the file -- not the 'line' after that, which contains no characters. Mostly. This fixes things so

[Ada] Suppress warning for Interfaces.C with -fdump-ada-spec

2020-05-12 Thread Eric Botcazou
The C/C++ bindings generated by means of -fdump-ada-spec always contain with and use clauses for Interfaces.C, but they can be unused in some cases so make sure to avoid warning about that. Tested on x86-64/Linux, applied on the mainline. 2020-05-12 Eric Botcazou c-family/ *

[Ada] Be prepared for more aggregates in gigi

2020-05-12 Thread Eric Botcazou
This makes sure that gigi is prepared to handle more aggregates in the special memset code path. Tested on x86-64/Linux, applied on the mainline. 2020-05-12 Eric Botcazou * sem_aggr.ads (Is_Single_Aggregate): New function. * sem_aggr.adb (Is_Others_Aggregate): Use local

Re: [PATCH] c++: Function found via ADL when it should not [PR95074]

2020-05-12 Thread Nathan Sidwell
On 5/12/20 4:18 PM, Marek Polacek wrote: I noticed that we don't implement [basic.lookup.argdep]/3: quite correctly; it says "If X (the lookup set produced by unqualified lookup) contains -- a block-scope function declaration that is not a using-declaration [...] then Y (the lookup set produced

[PATCH] c++: Function found via ADL when it should not [PR95074]

2020-05-12 Thread Marek Polacek via Gcc-patches
I noticed that we don't implement [basic.lookup.argdep]/3: quite correctly; it says "If X (the lookup set produced by unqualified lookup) contains -- a block-scope function declaration that is not a using-declaration [...] then Y (the lookup set produced by ADL) is empty." but we were still

[PATCH] x86: Properly count cost of XMM register push

2020-05-12 Thread H.J. Lu via Gcc-patches
Update STV pass to properly count cost of XMM register push. In 32-bit mode, to convert XMM register push in DImode, we do an XMM store in DImode, followed by 2 memory pushes in SImode, instead of 2 integer register pushes in SImode. To convert XM register push in SImode, we do an XMM register

testsuite: Fix up gcc.dg/asan/pr95051.c testcase [PR95051]

2020-05-12 Thread Jakub Jelinek via Gcc-patches
Hi! On Tue, May 12, 2020 at 12:06:25PM -0700, H.J. Lu wrote: > Excess errors: > cc1: error: '-fsanitize=address' is incompatible with > '-fsanitize=kernel-address' asan.exp adds -fsanitize=address which is incompatible with -fsanitize=kernel-address, so we need to disable it first. Tested on

[committed] wwwdocs: Update link to IBM Journal of Research and Development.

2020-05-12 Thread Gerald Pfeifer
I really don't get it why so many corporate webmasters do not put redirects in place at least for a while. Luckily we've got Google. Pushed. Gerald --- htdocs/readings.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index

Re: [PATCH] ASAN: do not rewrite param for DECL_NOT_GIMPLE_REG_P.

2020-05-12 Thread H.J. Lu via Gcc-patches
On Tue, May 12, 2020 at 11:57 AM H.J. Lu wrote: > > On Tue, May 12, 2020 at 1:12 AM Richard Biener via Gcc-patches > wrote: > > > > On Tue, May 12, 2020 at 9:04 AM Martin Liška wrote: > > > > > > On 5/11/20 2:44 PM, Richard Biener wrote: > > > > Hmm, I think the fix is to clear

Re: [PATCH] ASAN: do not rewrite param for DECL_NOT_GIMPLE_REG_P.

2020-05-12 Thread H.J. Lu via Gcc-patches
On Tue, May 12, 2020 at 1:12 AM Richard Biener via Gcc-patches wrote: > > On Tue, May 12, 2020 at 9:04 AM Martin Liška wrote: > > > > On 5/11/20 2:44 PM, Richard Biener wrote: > > > Hmm, I think the fix is to clear DECL_NOT_GIMPLE_REG_P instead > > > where the code clears TREE_ADDRESSABLE of

Re: [PATCH] rs6000: Add vec_extracth and vec_extractl

2020-05-12 Thread Bill Schmidt via Gcc-patches
On 5/12/20 1:21 PM, Segher Boessenkool wrote: Hi! On Mon, May 11, 2020 at 09:56:14PM -0500, Bill Schmidt wrote: On 5/11/20 9:48 AM, David Edelsohn wrote: On Sun, May 10, 2020 at 9:14 AM Bill Schmidt wrote: * config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant.

Re: [PATCH v2] Fold (add -1; zero_ext; add +1) operations to zero_ext when not overflow (PR37451, part of PR61837)

2020-05-12 Thread Richard Sandiford
luoxhu writes: > + /* Fold (add -1; zero_ext; add +1) operations to zero_ext. i.e: > + > + 73: r145:SI=r123:DI#0-0x1 > + 74: r144:DI=zero_extend (r145:SI) > + 75: r143:DI=r144:DI+0x1 > + ... > + 31: r135:CC=cmp (r123:DI,0) > + 72:

Re: [PATCH] rs6000: Add vec_extracth and vec_extractl

2020-05-12 Thread Segher Boessenkool
Hi! On Mon, May 11, 2020 at 09:56:14PM -0500, Bill Schmidt wrote: > On 5/11/20 9:48 AM, David Edelsohn wrote: > >On Sun, May 10, 2020 at 9:14 AM Bill Schmidt > >wrote: > >> * config/rs6000/altivec.md (UNSPEC_EXTRACTL): New constant. > >> (UNSPEC_EXTRACTR): Likewise. > >>

Re: [PATCH 1/1] Make anti_adjust_stack_and_probe_stack_clash extern and use it for Z

2020-05-12 Thread Jeff Law via Gcc-patches
On Fri, 2020-05-08 at 19:51 +0200, Andreas Krebbel via Gcc-patches wrote: > When compiling with -mbackchain -fstack-clash-protection currently no > probes are emitted. This patch adjusts the "allocate_stack" expander > to call anti_adjust_stack_and_probe_stack_clash when needed. In order > to do

[committed] i386: Add V2SFmode copysign, xorsign and signbit expanders [PR95046]

2020-05-12 Thread Uros Bizjak via Gcc-patches
gcc/ChangeLog: 2020-05-12 Uroš Bizjak PR target/95046 * config/i386/mmx.md (copysignv2sf3): New expander. (xorsignv2sf3): Ditto. (signbitv2sf3): Ditto. testsuite/ChangeLog: 2020-05-12 Uroš Bizjak PR target/95046 * gcc.target/i386/pr95046-4.c: New test.

Re: [PATCH] Enable CET in cross compiler if possible

2020-05-12 Thread Jeff Law via Gcc-patches
On Fri, 2020-05-08 at 06:11 -0700, H.J. Lu via Gcc-patches wrote: > Don't perform CET run-time check for host when cross compiling. Instead, > enable CET in cross compiler if possible so that it will run on both CET > and non-CET hosts. > > config/ > > PR bootstrap/94998 > * cet.m4

[committed] i386: Add V2SFmode FMA insn patterns [PR95046]

2020-05-12 Thread Uros Bizjak via Gcc-patches
gcc/ChangeLog: 2020-05-12 Uroš Bizjak PR target/95046 * config/i386/mmx.md (fmav2sf4): New insn pattern. (fmsv2sf4): Ditto. (fnmav2sf4): Ditto. (fnmsv2sf4): Ditto. testsuite/ChangeLog: 2020-05-12 Uroš Bizjak PR target/95046 * gcc.target/i386/pr95046-3.c: New

[committed] c++: Add abbreviated fn template test for [PR78752]

2020-05-12 Thread Patrick Palka via Gcc-patches
This adds an abbreviated function template version of the testcase in PR78752, which seems to already be fixed. gcc/testsuite/ChangeLog: PR c++/78752 * g++.dg/cpp2a/concepts-pr78752-2.C: New test. --- .../g++.dg/cpp2a/concepts-pr78752-2.C | 21 +++ 2

Re: [PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

2020-05-12 Thread Jeff Law via Gcc-patches
On Thu, 2020-04-23 at 16:05 -0600, Martin Sebor wrote: > On 4/23/20 9:42 AM, Jeff Law wrote: > > On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote: > > > When computing the size of an object with a flexible array member > > > the object size pass doesn't consider that the

Re: [PATCH 1/3] zlib: Add --enable-cet to configure

2020-05-12 Thread Jeff Law via Gcc-patches
On Fri, 2020-05-08 at 13:10 -0700, H.J. Lu wrote: > When --enable-cet is used to configure GCC, enable Intel CET in target > zlib. > > * Makefile.am (AM_CFLAGS): New. > * configure.ac (CET_FLAGS): Add GCC_CET_FLAGS and AC_SUBST. > * Makefile.in: Regenerated. > *

Re: [libitm] eh specifications are lax

2020-05-12 Thread Jeff Law via Gcc-patches
On Tue, 2020-05-05 at 16:08 -0400, Nathan Sidwell wrote: > I discovered that libitm: > (a) declares __cxa_allocate_exception and friends directly, > (b) doesn't mark them as 'throw()' > (c) doesn't mark the replacment fns _ITM_$foo as nothrow either > > We happen to get away with it because of

Re: [PATCH 3/5] libcpp: Enable Intel CET on Intel CET enabled host for jit

2020-05-12 Thread Jeff Law via Gcc-patches
On Sat, 2020-05-09 at 08:43 -0700, H.J. Lu wrote: > Since on Intel CET enabled host, dlopen in Intel CET enabled applications > fails on shared libraries which aren't Intel CET enabled, compile with > -fcf-protection on Intel CET enabled host when jit is enabled to enable > Intel CET on libgccjit.

Re: [PATCH 5/5] libbacktrace: Enable Intel CET on Intel CET enabled host for jit

2020-05-12 Thread Jeff Law via Gcc-patches
On Sat, 2020-05-09 at 08:43 -0700, H.J. Lu wrote: > Since on Intel CET enabled host, dlopen in Intel CET enabled applications > fails on shared libraries which aren't Intel CET enabled, compile with > -fcf-protection on Intel CET enabled host when jit is enabled to enable > Intel CET on libgccjit.

Re: [PATCH 4/5] libdecnumber: Enable Intel CET on Intel CET enabled host for jit

2020-05-12 Thread Jeff Law via Gcc-patches
On Sat, 2020-05-09 at 08:43 -0700, H.J. Lu wrote: > Since on Intel CET enabled host, dlopen in Intel CET enabled applications > fails on shared libraries which aren't Intel CET enabled, compile with > -fcf-protection on Intel CET enabled host when jit is enabled to enable > Intel CET on libgccjit.

Re: [PATCH 2/5] gcc: Enable Intel CET on Intel CET enabled host for jit

2020-05-12 Thread Jeff Law via Gcc-patches
On Sat, 2020-05-09 at 08:43 -0700, H.J. Lu wrote: > Since on Intel CET enabled host, dlopen in Intel CET enabled applications > fails on shared libraries which aren't Intel CET enabled, compile with > -fcf-protection on Intel CET enabled host when jit is enabled to enable > Intel CET on libgccjit.

Re: [PATCH 1/5] libcc1: Enable Intel CET on Intel CET enabled host

2020-05-12 Thread Jeff Law via Gcc-patches
On Sat, 2020-05-09 at 08:43 -0700, H.J. Lu wrote: > Since on Intel CET enabled host, dlopen in Intel CET enabled applications > fails on shared libraries which aren't Intel CET enabled, enable Intel > CET in libcc1 on Intel CET enabled host. > > * Makefile.am (AM_CXXFLAGS): Add

[committed] i386: Add V2SFmode NEG, ABS and logic insn patterns [PR95046]

2020-05-12 Thread Uros Bizjak via Gcc-patches
gcc/ChangeLog: 2020-05-12 Uroš Bizjak PR target/95046 * config/i386/mmx.md (v2sf2): New insn pattern. (*mmx_v2sf2): New insn_and_split pattern. (*mmx_nabsv2sf2): Ditto. (*mmx_andnotv2sf3): New insn pattern. (*mmx_v2sf3): Ditto. * config/i386/i386.md (absneg_op):

[PATCH, FORTRAN] ICE in gfc_conv_array_constructor_expr PR93497

2020-05-12 Thread Mark Eggleston
Please find attached for PR93497. This patch was posted as a comment to the PR, I've checked it added a test case. It has the side affect of changing the errors for three other test cases which have modified accordingly. The commit message is as follows: fortran : ICE in

Re: [PATCH v2] Fold (add -1; zero_ext; add +1) operations to zero_ext when not overflow (PR37451, part of PR61837)

2020-05-12 Thread Segher Boessenkool
Hi! On Tue, May 12, 2020 at 02:48:40PM +0800, luoxhu wrote: > diff --git a/gcc/testsuite/gcc.target/powerpc/doloop-2.c > b/gcc/testsuite/gcc.target/powerpc/doloop-2.c > new file mode 100644 > index 000..dc8516bb0ab > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/doloop-2.c > @@

Re: [pushed] c++: Make references to __cxa_pure_virtual weak.

2020-05-12 Thread Christophe Lyon via Gcc-patches
On Tue, 12 May 2020 at 10:28, Andreas Schwab wrote: > > On Mai 11 2020, Jason Merrill via Gcc-patches wrote: > > > If a program has no other dependencies on libstdc++, we shouldn't require it > > just for __cxa_pure_virtual, which is only there to give a prettier > > diagnostic before crashing

Re: [PATCH] rs6000: Vector string isolate instructions

2020-05-12 Thread Bill Schmidt via Gcc-patches
On 5/12/20 4:54 AM, Segher Boessenkool wrote: Hi! Looks fine to me... Just the same generic things as before, things we can improve later, not even limited to this series: On Sat, May 09, 2020 at 08:16:26AM -0500, Bill Schmidt wrote: * config/rs6000/altivec.md (UNSPEC_VSTRIR): New

Re: [PATCH] remove dead debug-bind resets

2020-05-12 Thread Richard Biener
On Tue, 12 May 2020, Richard Biener wrote: > > This removes debug-bind resets aka > > # DEBUG b = NULL > > when the reset variable is otherwise unused. I've gathered statistics > for a single TU, fold-const.ii which at -O2 -g shows > > 28 ssa "dead debug bind reset" 1 > 34 einline "dead

PING: [PATCH] Enable CET in cross compiler if possible

2020-05-12 Thread H.J. Lu via Gcc-patches
On Fri, May 8, 2020 at 6:11 AM H.J. Lu wrote: > > Don't perform CET run-time check for host when cross compiling. Instead, > enable CET in cross compiler if possible so that it will run on both CET > and non-CET hosts. > > config/ > > PR bootstrap/94998 > * cet.m4

Re: [PATCH] rs6000: Add cntlzdm and cnttzdm

2020-05-12 Thread Segher Boessenkool
On Mon, May 11, 2020 at 11:45:09AM -0500, Bill Schmidt wrote: > On 5/8/20 6:51 PM, Segher Boessenkool wrote: > >On Fri, May 08, 2020 at 08:17:18AM -0500, Bill Schmidt wrote: > >>From: Kelvin Nilsen > >> > >>Add support for new scalar instructions for counting leading or > >>trailing zeros under

Re: [PATCH] rs6000: Add vec_extracth and vec_extractl

2020-05-12 Thread David Edelsohn via Gcc-patches
On Mon, May 11, 2020 at 10:56 PM Bill Schmidt wrote: > > On 5/11/20 9:48 AM, David Edelsohn wrote: > > On Sun, May 10, 2020 at 9:14 AM Bill Schmidt wrote: > >> From: Kelvin Nilsen > >> > >> Add new insns vextdu[bhw]vlx, vextddvlx, vextdu[bhw]vhx, and > >> vextddvhx, along with built-in access

[PATCH] middle-end/94988 fix testcase for big-endian

2020-05-12 Thread Richard Biener
The testcase only works for little-endian, mark it so. 2020-05-12 Richard Biener * gcc.dg/torture/pr94988.c: Disable runtime test for * non-little-endian. --- gcc/testsuite/gcc.dg/torture/pr94988.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[committed] MSP430: Define ASM_OUTPUT_ALIGNED_DECL_LOCAL

2020-05-12 Thread Jozef Lawrynowicz
The attached patch implements ASM_OUTPUT_ALIGNED_DECL_LOCAL for msp430. The default handler needs to be overridden so local common symbols which need their own section (e.g. variables with the "noinit" attribute) will be placed in that section rather than the common block. This fixes

[committed] MSP430: Allow .bss section to be created in region-attribute-misuse test

2020-05-12 Thread Jozef Lawrynowicz
Uninitialized global variables are put in the .bss section since the -fno-common change, the attached patch prevents region-attribute-misuse.c failing if a .bss section is in the assembler output. Committed as obvious. >From 89aa37dc3c71666d0ff05e96ea84e195d049a226 Mon Sep 17 00:00:00 2001 From:

[Ada] Fix PR ada/95035

2020-05-12 Thread Eric Botcazou
This fixes an oversight in the new canonicalization code for packable types: it does not take into account the scalar storage order. Tested on x86-64/Linux and SPARC/Solaris, applied on the mainline. 2020-05-12 Eric Botcazou PR ada/95035 * gcc-interface/utils.c

Re: [Patch][Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

2020-05-12 Thread Jakub Jelinek via Gcc-patches
On Thu, Apr 23, 2020 at 08:52:39AM +0200, Tobias Burnus wrote: > [Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690) > > PR fortran/94690 > * openmp.c (OMP_DISTRIBUTE_CLAUSES): Add OMP_CLAUSE_LASTPRIVATE. > * trans-openmp.c (gfc_trans_omp_do): Don't add

[PATCH] remove dead debug-bind resets

2020-05-12 Thread Richard Biener
This removes debug-bind resets aka # DEBUG b = NULL when the reset variable is otherwise unused. I've gathered statistics for a single TU, fold-const.ii which at -O2 -g shows 28 ssa "dead debug bind reset" 1 34 einline "dead debug bind reset" 340 54 release_ssa "dead debug bind reset" 176

Re: [Patch][OpenMP] Fix mapping of artificial variables (PR94874)

2020-05-12 Thread Jakub Jelinek via Gcc-patches
On Fri, May 08, 2020 at 05:09:07PM +0200, Tobias Burnus wrote: > I was thinking of simply marking them as > "nflags |= GOVD_FIRSTPRIVATE" but I am not sure whether > that would always make sense, either. In any case, a > simple usage would bypass the > "implicit mapping of assumed size array" >

Re: Follow-up Patch – Re: [Patch][OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

2020-05-12 Thread Jakub Jelinek via Gcc-patches
On Thu, Apr 23, 2020 at 03:43:47PM +0200, Tobias Burnus wrote: > On 4/20/20 11:33 PM, Thomas Schwinge wrote: > > Really 'GOMP_MAP_DELETE', or should that rather be 'GOMP_MAP_RELEASE'? > > Depends on the previous item, i.e. 'delete:' vs. 'release:/from:/…' > > Rather obvious – OK? > > Tobias >

Re: [PATCH] [PR94118]] Update documentation for x86 operand modifier.

2020-05-12 Thread Uros Bizjak via Gcc-patches
On Tue, May 12, 2020 at 7:27 AM Hongtao Liu wrote: > > Documents operand modifiers which are available in asm stmt but > missing in document. > > | Modifier | Description | Available in asm stmt | Existed in documentation | > | --- | --- | --- | - | > | L,W,B,Q,S,T | print the opcode

Re: [PATCH] rs6000: Vector string isolate instructions

2020-05-12 Thread Segher Boessenkool
Hi! Looks fine to me... Just the same generic things as before, things we can improve later, not even limited to this series: On Sat, May 09, 2020 at 08:16:26AM -0500, Bill Schmidt wrote: > * config/rs6000/altivec.md (UNSPEC_VSTRIR): New constant. > (UNSPEC_VSTRIL): Likewise. Names

Re: Automatically generated ChangeLog files - PHASE 1

2020-05-12 Thread Martin Liška
I'm also CCing gcc-patches and fortran ML. Martin On 5/12/20 11:05 AM, Martin Liška wrote: Hi. Thanks to Jakub, we finally set up an experimental environment: gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git The repository now contains a new pre-commit hook that validates the git commit

Re: [pushed] c++: Make references to __cxa_pure_virtual weak.

2020-05-12 Thread Andreas Schwab
On Mai 11 2020, Jason Merrill via Gcc-patches wrote: > If a program has no other dependencies on libstdc++, we shouldn't require it > just for __cxa_pure_virtual, which is only there to give a prettier > diagnostic before crashing the program; resolving the reference to NULL will > also crash,

Re: [PATCH] make minmax detection work with FMIN/FMAX IFNs

2020-05-12 Thread Richard Biener
On Mon, 11 May 2020, Joseph Myers wrote: > On Fri, 8 May 2020, Richard Biener wrote: > > > The IFNs are supposed to match fmin and fmax from the C standard which > > IIRC have IEEE semantics. > > fmin and fmax have IEEE (2008) semantics (where an sNaN operand results in > a qNaN result with

Re: [C++] EOF has a location

2020-05-12 Thread Rainer Orth
Hi Jakub, > On Fri, May 08, 2020 at 11:48:34AM -0400, Nathan Sidwell wrote: >> 2020-05-08 Nathan Sidwell >> >> gcc/cp/ >> * parser.c (cp_lexer_set_source_position_from_token): EOF has a >> location too. > > This change: > >> --- c/gcc/cp/parser.c >> +++ w/gcc/cp/parser.c >> @@

[PATCH] Optimize store_expr from STRING_CST [PR95052]

2020-05-12 Thread Jakub Jelinek via Gcc-patches
Hi! In the following testcase, store_expr of e.g. 97 bytes long string literal into 1MB long array is implemented by copying the 97 bytes from .rodata section, followed by clearing the remaining bytes. But, as the STRING_CST has type char[1024*1024], we actually allocate whole 1MB in .rodata

[committed] openmp: Fix up handling of DECL_OMP_PRIVATIZED_MEMBER for bit-fields [PR95063]

2020-05-12 Thread Jakub Jelinek via Gcc-patches
Hi! The r11-15 change broke this testcase, as it now asserts type is equal to the type of the DECL_VALUE_EXPR, but for DECL_OMP_PRIVATIZED_MEMBER artificial vars mapping to bitfields it wasn't. Fixed by changing the DECL_OMP_PRIVATIZED_MEMBER var type in that case. Bootstrapped/regtested on

[committed] openmp: Implement discovery of implicit declare target to clauses

2020-05-12 Thread Jakub Jelinek via Gcc-patches
Hi! This attempts to implement what the OpenMP 5.0 spec in declare target section says as ammended by the 5.1 changes so far (related to device_type(host)), except that it doesn't have the device(ancestor: ...) handling yet because we do not support it yet, and I've left so far out the except

Re: [PATCH] ASAN: do not rewrite param for DECL_NOT_GIMPLE_REG_P.

2020-05-12 Thread Richard Biener via Gcc-patches
On Tue, May 12, 2020 at 9:04 AM Martin Liška wrote: > > On 5/11/20 2:44 PM, Richard Biener wrote: > > Hmm, I think the fix is to clear DECL_NOT_GIMPLE_REG_P instead > > where the code clears TREE_ADDRESSABLE of 'arg' > > Ah, you are right. There's a patch that I've just tested. > > Patch can

Re: [C++] EOF has a location

2020-05-12 Thread Jakub Jelinek via Gcc-patches
On Fri, May 08, 2020 at 11:48:34AM -0400, Nathan Sidwell wrote: > 2020-05-08 Nathan Sidwell > > gcc/cp/ > * parser.c (cp_lexer_set_source_position_from_token): EOF has a > location too. This change: > --- c/gcc/cp/parser.c > +++ w/gcc/cp/parser.c > @@ -895,10 +895,7 @@

Re: [PATCH] ASAN: do not rewrite param for DECL_NOT_GIMPLE_REG_P.

2020-05-12 Thread Martin Liška
On 5/11/20 2:44 PM, Richard Biener wrote: Hmm, I think the fix is to clear DECL_NOT_GIMPLE_REG_P instead where the code clears TREE_ADDRESSABLE of 'arg' Ah, you are right. There's a patch that I've just tested. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to

[PATCH v2] Fold (add -1; zero_ext; add +1) operations to zero_ext when not overflow (PR37451, part of PR61837)

2020-05-12 Thread luoxhu via Gcc-patches
Minor refine of checking iterations nonoverflow and a testcase for stage 1. This "subtract/extend/add" existed for a long time and still annoying us (PR37451, part of PR61837) when converting from 32bits to 64bits, as the ctr register is used as 64bits on powerpc64, Andraw Pinski had a patch but

[PATCH] preserve EDGE_DFS_BACK across split_edge

2020-05-12 Thread Richard Biener
This moves EDGE_DFS_BACK to the appropriate edge when the split edge had it set. Bootstrap & regtest running on x86_64-unknown-linux-gnu. 2020-05-12 Richard Biener * cfghooks.c (split_edge): Preserve EDGE_DFS_BACK if set. --- gcc/cfghooks.c | 6 ++ 1 file changed, 6

[PATCH] tree-optimization/95045 - fix SM with exit exiting multiple loops

2020-05-12 Thread Richard Biener
Since we apply SM to an edge which exits multiple loops we have to make sure to commit insertions on it immediately since otherwise store order is not preserved. The testcase was committed with yesterdays fix, the bug was still latent (with careful -fdbgcnt=lim you could still trigger it).

Re: [RFC PATCH] i386: Add V2SFmode FMA insn patterns [PR95046]

2020-05-12 Thread Uros Bizjak via Gcc-patches
On Tue, May 12, 2020 at 7:57 AM Richard Biener wrote: > > On Mon, 11 May 2020, Uros Bizjak wrote: > > > Attached patch implements V2SFmode FMA insn patterns. Patched compiler > > vectorizes FMA, FMS and FNMA instructions, but for some reason fails > > to vectorize FNMS. > > > > I have double