Re: [PATCH] expr: build string_constant only for a char type

On Mon, Jul 27, 2020 at 10:49 PM Jakub Jelinek via Gcc-patches wrote: > > On Mon, Jul 27, 2020 at 09:53:31AM -0600, Martin Sebor via Gcc-patches wrote: > > Return a pointer P to a NUL-terminated string containing > > the sequence of bytes corresponding to the representation > > of the object

[PATCH] Fortran : Don't warn for LOGICAL kind conversion PR96319

Please find attached patch for PR96319. LOGICAL values fit regardless of kind so warnings are unnecessary. The PR referred to the warning produced for -Wconversion.  This patch also suppresses the warning for -Wconversion-extra. -Wconversion produces "Possible change of value in conversion f

[PATCH 0/2] cpp: fix __has_include in traditional mode

Hi there, this patch intends to fix the regression introduced in gcc 10 with __has_include, see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95889 Best, Tiziano Tiziano Müller (2): libcpp: fix __has_include handling with traditional-cpp [testsuite] add tests for __has_include with trad

[PATCH 2/2] [testsuite] add tests for __has_include with traditional-cpp

--- gcc/testsuite/ChangeLog | 4 ++ .../cpp/has-include-1-traditional.c | 38 +++ 2 files changed, 42 insertions(+) create mode 100644 gcc/testsuite/c-c++-common/cpp/has-include-1-traditional.c diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/

[PATCH 1/2] libcpp: fix __has_include handling with traditional-cpp

fixes #95889 --- libcpp/init.c| 3 +++ libcpp/traditional.c | 4 +++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/libcpp/init.c b/libcpp/init.c index 0aac5acd0a3..b0cf7119258 100644 --- a/libcpp/init.c +++ b/libcpp/init.c @@ -400,6 +400,9 @@ static const struct builtin_ma

[PATCH] tree-optimization/96349 - avoid abnormal coalescing issues in loop split

This avoids splitting a loop when the entry value of a loop PHI is involved with abnormal coalescing. Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. 2020-07-28 Richard Biener PR tree-optimization/96349 * tree-ssa-loop-split.c (stmt_semi_invariant_p_1): When

Re: [PATCH v2] ipa/96291: don't crash on unoptimized lto functions

On Mon, 27 Jul 2020, Sergei Trofimovich wrote: > From: Sergei Trofimovich > > In PR ipa/96291 the test contained an SCC with one > unoptimized function. This tricked ipa-cp into NULL dereference. > > has_undead_caller_from_outside_scc_p() did not take into account > that unoptimized funtions do

Re: [PATCH] Fortran : ICE in gfc_conv_scalarized_array_ref PR53298

ping On 20/07/2020 08:27, Mark Eggleston wrote: Please find attached a fix for PR53298. This appears to be a very simple fix, however, since it involves structures I'm unfamiliar with I think it needs checking. When the gfc_ref structure is created for a (1:) substring it has an expression

Re: Refactor peel_iters_{pro,epi}logue cost model handlings

Hi Richard, on 2020/7/27 下午9:10, Richard Sandiford wrote: > "Kewen.Lin" writes: >> Hi, >> >> As Richard S. suggested in the thread: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html >> >> this patch is separated from the one of that thread, mainly to refactor the >> existing p

[RISC-V] Add support for AddressSanitizer on RISC-V GCC

From: shaj gcc/ * config/riscv/riscv.c (asan_shadow_offset): Implement the offset of asan shadow memory for risc-v. (asan_shadow_offset): new macro definition. libsanitizer/ * sanitizer_common/sanitizer_common.h (ModuleArch): New enumerator. (Mo

[PATCH] libcpp: Fix up raw string literal parsing error-recovery [PR96323]

Hi! For (invalid) newline inside of the raw string literal delimiter, doing continue means we skip the needed processing of newlines. Instead of duplicating that, this patch just doesn't continue for those. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2020-07-28 Jakub J

[PATCH] c++: Fix up cp_lexer_safe_previous_token [PR96328]

Hi! The following testcase ICEs, because cp_lexer_safe_previous_token calls cp_lexer_previous_token and that ICEs, because all tokens in the lexer buffer before the current one (CPP_EOF) have been purged. cp_lexer_safe_previous_token is used in the context where it is ok if it punts, so the patch

Re: [PATCH v4] vect/rs6000: Support vector with length cost modeling

Hi Richard, Thanks for the comments! on 2020/7/27 下午9:40, Richard Sandiford wrote: > "Kewen.Lin" writes: [snip] >> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo); >> + bool need_iterate_p >> += (!LOOP_VINFO_EPILOGUE_P (loop_vinfo) >> + && !vect_known_niters_

[PATCH] expander: Fix ICE in maybe_warn_rdwr_sizes [PR96335]

Hi! The following testcase ICEs in maybe_warn_rdwr_sizes. The problem is that the caller uses its fndecl and fntype variables to fill up rdwr_map, and the fntype in that case is a prototype with the access attribute and all the checks needed for that performed. But the maybe_warn_rdwr_sizes func

Re: [PATCH] [og10] Fix goacc/routine-4-extern.c test

Hi Kwok! On 2020-07-26T14:05:32+0100, Kwok Cheung Yeung wrote: > On 24/07/2020 8:27 am, Thomas Schwinge wrote: >> That however completely defeats what we're intending to test here, which >> is to "Test invalid intra-routine parallelism". The same problem has >> been introduced in og10 commit 6a0

Re: [PATCH] expander: Fix ICE in maybe_warn_rdwr_sizes [PR96335]

On Tue, 28 Jul 2020, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs in maybe_warn_rdwr_sizes. The problem is that > the caller uses its fndecl and fntype variables to fill up rdwr_map, and > the fntype in that case is a prototype with the access attribute and all > the checks needed

Re: [PATCH] aarch64: Delete duplicated option docs.

Jim Wilson writes: > Ping. ccing the aarch64 maintainers. If I don't get a response, I > will just commit this as obvious. OK, thanks. Sorry, I hadn't realised the original message was an RFA rather than a post-commit thing. Richard

Re: [PATCH, rs6000] Add non-relative jump table support for 64bit rs6000

Added more CCs. Kewen on 2020/7/28 下午1:25, HAO CHEN GUI via Gcc-patches wrote: > Hi, > > This patch adds non-relative jump table support for 64bit rs6000. It > implements ASM_OUTPUT_ADDR_VEC_ELT and corresponding expansion of jump table > instruction for 64bit rs6000. We want to put non-relati

RE: [PATCH] [PATCH][GCC] arm: Enable no-writeback vldr.16/vstr.16.

Hi Joe, > -Original Message- > From: Gcc-patches On Behalf Of Joe > Ramsay > Sent: 27 July 2020 15:08 > To: Jakub Jelinek via Gcc-patches > Subject: [PATCH] [PATCH][GCC] arm: Enable no-writeback vldr.16/vstr.16. > > Hi, > > There was previously no way to specify that a register operand

Re: [pushed] c++: Allow subobject references in C++20.

On Mon, Jul 20, 2020 at 05:55:53PM -0400, Jason Merrill via Gcc-patches wrote: > +// { dg-final { scan-assembler _Z1g1AIXadixdtL_Z1bE1jLl1EEE } } > +void g(A<&b.j[0]+1>) {} > +TEQ(&b.j[1],&b.j[1]); > +TEQ(&b.j[1],&b.j[0]+1); > +TNEQ(&b.j[1],&b.j[0]); This test FAILs on e.g. x86_64 -m32. because th

Re: [PATCH] [PATCH][GCC] arm: Enable no-writeback vldr.16/vstr.16.

Thanks for the feedback Kyrill. On 28/07/2020, 10:16, "Kyrylo Tkachov" wrote: Hi Joe, > -Original Message- > From: Gcc-patches On Behalf Of Joe > Ramsay > Sent: 27 July 2020 15:08 > To: Jakub Jelinek via Gcc-patches > Subject: [PATCH] [PATCH][GCC] arm: Ena

[PATCH] Use exact=false for vec_safe_grow{,_cleared} functions.

On 7/27/20 1:31 PM, Richard Biener wrote: No, add gro*_exact variants and replace existing ones with this, then switch to exact = false for the non-_exact variants. Or add a exact=false argument to all of them and make all existing calls explicitly passing true. -EBITLAZY Anyway, I prepared a

Re: [PATCH] libgomp: Add helper functions for memory handling.

On Mon, Jul 27, 2020 at 01:59:01PM -0400, y2s1982 via Gcc-patches wrote: > I do know you have said this several times, and I thought I understood it, > but it seems I am wrong each time. I just want to clarify my understanding > and what I had intended on doing on this and would like further explan

Re: [PATCH] expr: build string_constant only for a char type

On 7/28/20 9:00 AM, Richard Biener via Gcc-patches wrote: On Mon, Jul 27, 2020 at 10:49 PM Jakub Jelinek via Gcc-patches wrote: On Mon, Jul 27, 2020 at 09:53:31AM -0600, Martin Sebor via Gcc-patches wrote: Return a pointer P to a NUL-terminated string containing the sequence of bytes co

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu wrote: > > On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote: > > > > On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote: > > > > > > On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote: > > > > > > > > On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu wrote: > > > > > Th

RE: [PATCH] [PATCH][GCC] arm: Enable no-writeback vldr.16/vstr.16.

> -Original Message- > From: Joe Ramsay > Sent: 28 July 2020 11:24 > To: Kyrylo Tkachov ; Jakub Jelinek via Gcc- > patches > Subject: Re: [PATCH] [PATCH][GCC] arm: Enable no-writeback vldr.16/vstr.16. > > Thanks for the feedback Kyrill. > > On 28/07/2020, 10:16, "Kyrylo Tkachov" wro

Re: [Patch] OpenMP: Add 'omp requires' to Fortran (mostly parsing)

Attached is an updated version – whether that will be fully in line with OpenMP 5.1 remains to be seen. But in any case, it now handles properly: "If a directive appears in the declarative part of a module then the behavior is as if that directive appears after any references to that module." Not

Re: [PATCH] c++: Fix up cp_lexer_safe_previous_token [PR96328]

On 7/28/20 4:32 AM, Jakub Jelinek wrote: Hi! The following testcase ICEs, because cp_lexer_safe_previous_token calls cp_lexer_previous_token and that ICEs, because all tokens in the lexer buffer before the current one (CPP_EOF) have been purged. cp_lexer_safe_previous_token is used in the conte

[RISC-V] Add support for AddressSanitizer on RISC-V GCC

From: cooper.joshua gcc/ * config/riscv/riscv.c (asan_shadow_offset): Implement the offset of asan shadow memory for risc-v. (asan_shadow_offset): new macro definition. libsanitizer/ * sanitizer_common/sanitizer_common.h (ModuleArch): New enumerator.

Re: [PATCH] libcpp: Fix up raw string literal parsing error-recovery [PR96323]

On 7/28/20 4:26 AM, Jakub Jelinek wrote: Hi! For (invalid) newline inside of the raw string literal delimiter, doing continue means we skip the needed processing of newlines. Instead of duplicating that, this patch just doesn't continue for those. Bootstrapped/regtested on x86_64-linux and i68

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 6:45 a.m., H.J. Lu wrote: > On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu wrote: >> >> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote: >>> >>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote: On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote: > > On Sat, Jul 25, 2020 a

Re: [PATCH] implement pre-c++20 contracts

Ping. Any feedback would be appreciated :) re: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549868.html older reply: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545339.html On 7/10/20, Jeff Chapman wrote: > Hello again :) > > Attached is a new squashed revision of the patch sans Ch

preprocessor: simplify read_main

We can always use the final map to get the return value, rather than conditionally only when there was an immediate line directive. libcpp/ * init.c (cpp_read_main_file): Always use the last map for the return value. pushed -- Nathan Sidwell diff --git i/libc

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

Hi, On Mon, 2020-07-27 at 12:32 -0700, H.J. Lu via Binutils wrote: > diff --git a/config/pkg.m4 b/config/pkg.m4 > index 13a8890178..45587e97c8 100644 > --- a/config/pkg.m4 > +++ b/config/pkg.m4 > @@ -147,6 +147,12 @@ AC_MSG_CHECKING([for $2]) > _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) > _PKG_C

Re: [PATCH] nvptx: Support 16-bit shifts and extendqihi2.

On 7/11/20 8:44 PM, Roger Sayle wrote: > The following patch adds support for 16-bits shifts and for sign extension > from 8 bits to 16 bits. > > This patch has been tested on nvptx-none with no new regressions. > Ok for mainline? > > 2020-07-11 Roger Sayle > > gcc/ChangeLog > * confi

Re: [PATCH v2 1/2] i386-tdep: Fix naming in zmm and ymm type descriptions.

Hello, On 24 июл 10:59, Felix Willgerodt via Gcc-patches wrote: > gdb/Changelog: > 2020-07-02 Felix Willgerodt > > * i386-tdep.c (i386_zmm_type): Fix field names. > (i386_ymm_type): Fix field names. I guess mailing list is wrong. -- Regards, Kirill Yukhin

[PATCH] PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 5:54 AM Mark Wielaard wrote: > > Hi, > > On Mon, 2020-07-27 at 12:32 -0700, H.J. Lu via Binutils wrote: > > diff --git a/config/pkg.m4 b/config/pkg.m4 > > index 13a8890178..45587e97c8 100644 > > --- a/config/pkg.m4 > > +++ b/config/pkg.m4 > > @@ -147,6 +147,12 @@ AC_MSG_CHE

[PATCH V2] aarch64: Use Q-reg loads/stores in movmem expansion

Hi This is my attempt at reviving the old patch https://gcc.gnu.org/pipermail/gcc-patches/2019-January/514632.html I have followed on Kyrill's comment upstream on the link above and I am using the recommended option iii that he mentioned. "1) Adjust the copy_limit to 256 bits after checking AA

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 5:46 AM Simon Marchi wrote: > > On 2020-07-28 6:45 a.m., H.J. Lu wrote: > > On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu wrote: > >> > >> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote: > >>> > >>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote: > > On Mon, Jul

[PATCH 1/2] Compute RPO with adjacent SCC members, expose toplevel SCC extents

This produces a more optimal RPO order for iteration processing by making sure that SCC exits are processed before SCC members themselves.. This avoids iterating blocks unrelated to the current iteration for RPO VN and has the chance to improve code-generation for the non-iterative mode of RPO VN.

[PATCH 2/2] Improve var-tracking dataflow iteration order

This builds upon the rev_post_order_and_mark_dfs_back_seme improvements and makes vt_find_locations iterate over the dataflow problems for each toplevel SCC separately, improving memory locality and avoiding to process nodes after the SCC before the SCC itself stabilized. On the asan_interceptors.

RE: [PATCH v2 1/2] i386-tdep: Fix naming in zmm and ymm type descriptions.

Hi Kirill, You are right, PATCH v2 1/2 obviously doesn't need gcc approval. It just landed on gcc-patches as I sent the series out in one go, sorry for that. Please ignore the first patch if you are seeing this on gcc-patches. I am however looking for gcc approval for the code shared between GDB

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Jul 28 2020, H.J. Lu via Binutils wrote: > On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64" > are not cross compiling. You cannot link -m64 and -m32 together. > I didn't set PKG_CONFIG_LIBDIR and I don't want to set it. Then use the correct pkg-config for your tar

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 6:33 AM H.J. Lu wrote: > > On Tue, Jul 28, 2020 at 5:46 AM Simon Marchi wrote: > > > > On 2020-07-28 6:45 a.m., H.J. Lu wrote: > > > On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu wrote: > > >> > > >> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote: > > >>> > > >>> On Mon, Jul

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 9:33 a.m., H.J. Lu wrote: > On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64" > are not cross compiling. And how does that make it not cross-compîling? >> Anyway regardless of vocabulary, I don't think there was a problem to begin >> with (not that I blam

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab wrote: > > On Jul 28 2020, H.J. Lu via Binutils wrote: > > > On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64" > > are not cross compiling. > > You cannot link -m64 and -m32 together. > > > I didn't set PKG_CONFIG_LIBDIR and

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 9:56 a.m., H.J. Lu wrote: > On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab wrote: >> >> On Jul 28 2020, H.J. Lu via Binutils wrote: >> >>> On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64" >>> are not cross compiling. >> >> You cannot link -m64 and -m32 tog

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 7:01 AM Simon Marchi wrote: > > On 2020-07-28 9:56 a.m., H.J. Lu wrote: > > On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab > > wrote: > >> > >> On Jul 28 2020, H.J. Lu via Binutils wrote: > >> > >>> On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc >

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 10:11 a.m., H.J. Lu wrote: > On Tue, Jul 28, 2020 at 7:01 AM Simon Marchi wrote: >> >> On 2020-07-28 9:56 a.m., H.J. Lu wrote: >>> On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab >>> wrote: On Jul 28 2020, H.J. Lu via Binutils wrote: > On x86, the native GCC can s

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Jul 28 2020, H.J. Lu wrote: > My system supports both -m32 and -m64. My system also supports m68k. That doesn't make it "native". $ file hello.m68k hello.m68k: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld., for GNU/Linux 2.6.32,

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 7:34 AM Simon Marchi wrote: > > On 2020-07-28 10:11 a.m., H.J. Lu wrote: > > On Tue, Jul 28, 2020 at 7:01 AM Simon Marchi wrote: > >> > >> On 2020-07-28 9:56 a.m., H.J. Lu wrote: > >>> On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab > >>> wrote: > > On Jul 28 20

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

> > > I think this remapping should happen with `file-prefix-map` but > > > shouldn't with `debug-prefix-map` (though if it happens for both it's > > > also not too bad) and I believe this patch is the minimum change to > > > achieve that. I think it makes sense to make this follow > > > `macro-pre

Re: [Patch] OpenMP: Add 'omp requires' to Fortran (mostly parsing)

I just realized that supporting 'acq_rel' is simple; while 'omp atomic' parsing needs to be updated quite a bit for the OpenMP 5 changes, just adding ACQ_REL support for 'requires' is trivial. Hence, I updated the requires-9.c testcase for 'acq_rel', adjusted trans-openmp.c and did some openmp.c

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 11:05 a.m., H.J. Lu via Gdb-patches wrote: >> Can you clarify how this magic works, is this standard autoconf? Because I >> am trying this >> on Fedora, so pretty much the same setup as you, and I don't see this >> behavior: >> >> $ /home/simark/src/binutils-gdb/configure CC="gcc -

Re: [PATCH] RS6000 Add testlsbb (Test LSB by Byte) operations

On Tue, 2020-05-26 at 11:12 -0500, will schmidt via Gcc-patches wrote: > Hi, > > Add support for new instructions to test LSB by Byte. > > Tested on powerpc64le-unknown-linux-gnu with no > regressions. (power7BE, power8LE, power8BE, power9LE). Ping. I note that I'll need to refresh to up

testsuite: Fix spello

'Patterns' has one 'r'. gcc/testsuite/ * lib/options.exp: Fix spello pushing as obvious. -- Nathan Sidwell diff --git i/gcc/testsuite/lib/options.exp w/gcc/testsuite/lib/options.exp index 44ea51075bc..c7f7316943e 100644 --- i/gcc/testsuite/lib/options.exp +++ w/gcc/tests

c++: tree dump indentation

We were always forcing an indent, even if there was nothing to indent. Fixed thusly. gcc/cp/ * ptree.c (cxx_print_decl): Better indentation. pushing -- Nathan Sidwell diff --git i/gcc/cp/ptree.c w/gcc/cp/ptree.c index 224cf14edb5..dfc244fdceb 100644 --- i/gcc/cp/ptree.c

Re: [PATCH] [RFC] vect: Fix infinite loop while determining peeling amount

On Tue, Jul 28, 2020 at 08:55:57AM +0200, Richard Biener wrote: > On Mon, Jul 27, 2020 at 4:20 PM Stefan Schulze Frielinghaus > wrote: > > > > On Mon, Jul 27, 2020 at 12:29:11PM +0200, Richard Biener wrote: > > > On Mon, Jul 27, 2020 at 11:45 AM Richard Sandiford > > > wrote: > > > > > > > > Rich

Re: [Patch] [OpenMP, Fortran] Add structure/derived-type element mapping

Hi! If I got my tracking right, the og10 commit 4677091db1aa9d2a52e4839812bd73f47cc5e421 "[OpenMP, Fortran] Add structure/derived-type element mapping" regresses: [-PASS:-]{+FAIL:+} gfortran.dg/goacc/pr70828.f90 -O scan-tree-dump-times gimple "omp target oacc_data map\\(tofrom:MEM\\[\\(c

c++: better fixup_type_variants

fixup_type_variants was almost doing all that finish_struct needs. May as well make it do it all. That this is helpful for modules is entirely coincidental :) gcc/cp/ * class.c (fixup_type_variants): Copy TYPE_SIZE and TYPE_SIZE_UINIT. (finish_st

c++: Set more DECL_CONTEXTs

I discovered we were not setting DECL_CONTEXT in a few cases, and grokfndecl's control flow wasn't making it clear that we were doing it in all cases. gcc/cp/ * cp-gimplify.c (cp_genericize_r): Set IMPORTED_DECL's context. * cp-objcp-common.c (cp_pushdecl): S

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 8:13 AM Simon Marchi wrote: > > On 2020-07-28 11:05 a.m., H.J. Lu via Gdb-patches wrote: > >> Can you clarify how this magic works, is this standard autoconf? Because > >> I am trying this > >> on Fedora, so pretty much the same setup as you, and I don't see this > >> be

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote: > What doesn't work with my pkg.m4 change? (1) It deviates from upstream. I don't think we should do this unless absolutely needed. That's not the case here, the change is just there because you don't want to set up pkg-config prop

Re: [PATCH, rs6000] Add non-relative jump table support for 64bit rs6000

On 2020/7/28 下午1:25, HAO CHEN GUI via Gcc-patches wrote: > Hi, > > This patch adds non-relative jump table support for 64bit rs6000. It > implements ASM_OUTPUT_ADDR_VEC_ELT and corresponding expansion of jump table > instruction for 64bit rs6000. We want to put non-relative jump table in > data.

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 9:28 AM Simon Marchi wrote: > > On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote: > > What doesn't work with my pkg.m4 change? > > (1) It deviates from upstream. I don't think we should do this unless > absolutely needed. That's not the case here, the change is

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 1:26 p.m., H.J. Lu wrote: > On Tue, Jul 28, 2020 at 9:28 AM Simon Marchi wrote: >> >> On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote: >>> What doesn't work with my pkg.m4 change? >> >> (1) It deviates from upstream. I don't think we should do this unless >> absolutely n

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 10:43 AM Simon Marchi wrote: > > On 2020-07-28 1:26 p.m., H.J. Lu wrote: > > On Tue, Jul 28, 2020 at 9:28 AM Simon Marchi wrote: > >> > >> On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote: > >>> What doesn't work with my pkg.m4 change? > >> > >> (1) It deviates from

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On 2020-07-28 2:31 p.m., H.J. Lu wrote: >>> Unlike gdb, binutils should have as few external depecies as possible. >>> debuginfod brings in some so many external depecies. >> >> I'm not a binutils maintainer, so that's not my role to decide about that >> tradeoff... but we are talking about having

Re: [PATCH 2/2] Aarch64: Add branch diluter pass

Segher Boessenkool writes: > Hi! Hi Segher, > [ Btw, the mailing list archive will not show your attachments (just lets > me download them); naming the files *.txt probably works, but you can > also use a sane mime type (like, text/plain) ]. [ Sure can do it np, I'm just less sure if text/x-di

Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works

On Tue, Jul 28, 2020 at 11:47 AM Simon Marchi wrote: > > On 2020-07-28 2:31 p.m., H.J. Lu wrote: > >>> Unlike gdb, binutils should have as few external depecies as possible. > >>> debuginfod brings in some so many external depecies. > >> > >> I'm not a binutils maintainer, so that's not my role to

[RFC] libstdc++: Fix pretty-printing old implementations of std::unique_ptr

On binaries compiled against gcc5 the impl_type parameter is None, which results in an exception being raised by is_specialization_of() These versions of std::unique_ptr have the tuple as a root element. --- Hi, I ran into this issue when debugging a binary built using gcc5. I'm not very famili

Re: [PATCH 1/2] Add new RTX instruction class FILLER_INSN

Segher Boessenkool writes: > Hi Andrea, > > On Wed, Jul 22, 2020 at 12:02:33PM +0200, Andrea Corallo wrote: >> This first patch implements the addition of a new RTX instruction class >> FILLER_INSN, which has been white listed to allow placement of NOPs >> outside of a basic block. This is to al

[PATCH] c-family: Macro support in -Wmisleading-indentation [PR80076]

Currently the -Wmisleading-indentation warning doesn't do any analysis when the guarded statement or the statement after it is produced by a macro, as the mentioned PR illustrates. This means that we warn for: if (flag) foo (); bar (); and yet we don't warn for: #define BAR bar if

PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Richard and Uros, Could you please review the change that H.J and I rewrote based on your comments in the previous round of discussion? This patch is a nice security enhancement for GCC that has been requested by security people for quite some time. Thanks a lot for your time. Qing > On

Re: [PATCH] Fortran : Don't warn for LOGICAL kind conversion PR96319

Hi Mark, LOGICAL values fit regardless of kind so warnings are unnecessary. The PR referred to the warning produced for -Wconversion.  This patch also suppresses the warning for -Wconversion-extra. -Wconversion produces "Possible change of value in conversion from LOGICAL(4) to LOGICAL(1) ..

Re: [PATCH] Fortran : ICE in gfc_conv_scalarized_array_ref PR53298

Hi Mark, Please find attached a fix for PR53298. OK. Thanks for the patch! Regards Thomas

Re: [PATCH] c-family: Macro support in -Wmisleading-indentation [PR80076]

On Tue, 2020-07-28 at 15:50 -0400, Patrick Palka wrote: > Currently the -Wmisleading-indentation warning doesn't do any > analysis > when the guarded statement or the statement after it is produced by a > macro, as the mentioned PR illustrates. This means that we warn for: > > if (flag) > f

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

Hi Yichao, Forwarding to fort...@gcc.gnu.org as suggested by Dominique d'Humieres. On Sun, Jul 5, 2020 at 9:29 PM Yichao Yu wrote: I think this remapping should happen with `file-prefix-map` but shouldn't with `debug-prefix-map` (though if it happens for both it's also not too bad) and I be

Re: [committed] libstdc++: Add std::from_chars for floating-point types

On 27/07/20 10:46 +0100, Jonathan Wakely wrote: On 27/07/20 11:41 +0200, Rainer Orth wrote: Hi Jonathan, This adds the missing std::from_chars overloads for floating-point types, as required for C++17 conformance. The implementation is a hack and not intended to be used in the long term. Rath

Re: [PATCH] Map filename from print in gfortran with -ffile-prefix-map (PR96069)

> >>> I think this remapping should happen with `file-prefix-map` but > >>> shouldn't with `debug-prefix-map` (though if it happens for both it's > >>> also not too bad) and I believe this patch is the minimum change to > >>> achieve that. I think it makes sense to make this follow > >>> `macro-pre

Re: [committed] libstdc++: Add std::from_chars for floating-point types

On 28/07/20 22:01 +0100, Jonathan Wakely wrote: On 27/07/20 10:46 +0100, Jonathan Wakely wrote: On 27/07/20 11:41 +0200, Rainer Orth wrote: Hi Jonathan, This adds the missing std::from_chars overloads for floating-point types, as required for C++17 conformance. The implementation is a hack a

[PATCH] New test for PR rtl-optimization/96298.

I was considering committing this new test case as obvious, however I've decided to err on the side of caution and ask folks whether they have any suggestions or improvements to my proposed dejagnu directives. This test now passes with the recently committed fix for this regression, but fails with

Re: [PATCH] RS6000 Add testlsbb (Test LSB by Byte) operations

Hi! On Tue, Jul 28, 2020 at 10:31:02AM -0500, will schmidt wrote: > > * config/rs6000/rs6000-builtin.def (BU_FUTURE_VSX_1): New built- > > in > > handling macro. (XVTLSBB_ZEROS, XVTLSBB_ONES) New builtin > > defines. New (...) should start a new line. Missing colon here, btw. > > (

RFC: Monitoring old PRs, new dg directives

In Bugzilla, for the c++ component, we currently have over 3200 open bugs. In my experience, a good amount of them have already been fixed; my periodical sweeps always turn up a bunch of PRs that had already been fixed previously. Sometimes my sweeps are more or less random, but more often than no

Re: [PATCH 2/2] Aarch64: Add branch diluter pass

Hi! On Tue, Jul 28, 2020 at 07:55:58PM +0100, Andrea Corallo wrote: > > [ Btw, the mailing list archive will not show your attachments (just lets > > me download them); naming the files *.txt probably works, but you can > > also use a sane mime type (like, text/plain) ]. > > [ Sure can do it np,

[Committed] middle-end: Parity and popcount folding optimizations.

Here is the final version of this patch, implementing Richard's latest suggestion, as committed to mainline. This revision has been tested on x86_64-pc-linux-gnu with a "make bootstrap" and "make -k check" with no new regressions. Many thanks for the helpful feedback about match.pd's BUILT_IN_

Re: [PATCH v4] dse: Remove partial load after full store for high part access[PR71309]

Gentle ping in case this mail is missed, Thanks :) https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550602.html Xionghu On 2020/7/24 18:47, luoxhu via Gcc-patches wrote: Hi Richard, This is the updated version that could pass all regression test on Power9-LE. Just need another "maybe_lt

Re: [PATCH] c-family: Macro support in -Wmisleading-indentation [PR80076]

On Tue, 28 Jul 2020, David Malcolm wrote: > On Tue, 2020-07-28 at 15:50 -0400, Patrick Palka wrote: > > Currently the -Wmisleading-indentation warning doesn't do any > > analysis > > when the guarded statement or the statement after it is produced by a > > macro, as the mentioned PR illustrates.

mmix.h (ASM_OUTPUT_EXTERNAL): Define to default_elf_asm_output_external.

Committed. Whoops. When un-disabling visibility support for mmix, I missed that some of the newly enabled tests were FAILs, for not emitting .hidden for references to external declarations. This takes care of gcc.dg/visibility-14.c .. -19.c, and gcc.dg/visibility-23.c. gcc: * config/mmi

config/mmix/mmix.h (NO_FUNCTION_CSE): Define to 1.

Committed. The tests gcc.dg/tree-ssa/loop-1.c and gcc.dg/weak/typeof-2.c assume this setting and are as a consequence riddled with exceptions for targets that actually do yield better code when calling through a register rather than repeatedly the same symbol. Nonetheless, defining it makes sense

[PATCH 0/5] add checking of function array parameters (PR 50584)

The C99 T[static N] form of declaring function arguments means the argument must point to an object large enough to fit at least N elements of T. Diagnosing calls where the argument is smaller helps detect buffer overflow. Similarly, so does diagnosing accesses by such functions to parameters be

[PATCH 1/5] infrastructure to detect out-of-bounds accesses to array parameters

Patch 1 adds the basic infrastructure to support array/VLA bounds in attribute access. It extends the access string specification to describe function parameters of array types (including VLAs), extends the attr_access class to parse the string and store the data in a form that's easy to work wit

Re: [PATCH 0/5] add checking of function array parameters (PR 50584)

Patch 3 adjusts tree-ssa-uninit.c to the changes to attribute access but has only a cosmetic effect on informational notes in -Wuninitialized. [3/5] - Make use of new attribute access infrastructure in tree-ssa-uninit.c. gcc/ChangeLog: * tree-ssa-uninit.c (maybe_warn_pass_by_reference): Handle

[PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

Patch 2 adds support for the internal attribute access specification for array/VLA parameters to the C front end and two new options to control warnings. The attribute is added in two steps: first, push_parm_decl adds a new attribute "arg spec" to each array parameter with a string describing its

[PATCH 4/5] - extend -Wstringop-overflow to detect out-of-bounds accesses to array parameters

Patch 4 adds support to the machinery behind -Wstringop-overflow to issue warnings for (likely) out of bounds accesses in calls to functions with the internal attribute access specification. This implements the feature pr50584 asks for (plus more). [4/5] - Extend -Wstringop-overflow to detect out

[PATCH 5/5] extend -Warray-bounds to detect out-of-bounds accesses to array parameters

Patch 5 adds support for -Warray-bounds to detect out of bounds accesses in functions that take array/VLA arguments. The changes also enable the warning for dynamically allocated memory and with it the detection of accesses that are only partially out of bounds (e.g., accessing a four byte int in

Re: RFC: Monitoring old PRs, new dg directives

I'll punt to the the C++ front-end folks to chime in. Usually we only check in bugs that are fixed, as they are fixed, this is what makes it a regression suite. Doing this does have advantages, like, the testsuite is small and doesn't have duplicates and doesn't test anything that is known to

[PATCH] libstdc++ testsuite: atomic_float/value_init.cc requires libatomic

atomic_float/value_init.cc requires libatomic on some targets, i.e., when it tries to perform an atomic operation with a 64 bit floating point double type on a 32 bit target. This patch adds AIX to the list of targets that require the libatomic option and adds the option to the atomic_float/value_

Re: RFC: Monitoring old PRs, new dg directives

On Tue, 2020-07-28 at 17:44 -0400, Marek Polacek via Gcc-patches wrote: > In Bugzilla, for the c++ component, we currently have over 3200 open bugs. In > my experience, a good amount of them have already been fixed; my periodical > sweeps always turn up a bunch of PRs that had already been fixed p

Re: [PATCH] Don't make -gsplit-dwarf imply -g

On Thu, May 14, 2020 at 12:16 AM Richard Biener wrote: > > On Wed, May 13, 2020 at 5:50 PM Fangrui Song wrote: > > > > On 2020-05-13, Eric Botcazou wrote: > > >> Did I mention I dislike -fsplit-dwarf? ;) > > > > > >Seconded, this will be confusing for almost all users. Since the option > > >onl

  1   2   >