Re: [PATCH] [tree-optimization] Optimize two patterns with three xors.

On Tue, Nov 17, 2020 at 3:19 AM Eugene Rozenfeld wrote: > > Thank you for the review Richard! > > I re-worked the patch based on your suggestions (attached). > I made the change to reuse the first bit_xor in both patterns and I added :s > to the last xor in the first pattern. > For the second

RE: [PATCH 2/2] middle-end : Add support for complex pattern detection for Add, Mul, FMA and FMS

On Mon, 16 Nov 2020, Tamar Christina wrote: > Hi Richi, thanks for the review! > > Just a quick comment on one of the questions asked: > > > -Original Message- > > From: rguent...@c653.arch.suse.de On > > Behalf Of Richard Biener > > Sent: Monday, November 16, 2020 3:12 PM > > To:

Re: [PATCH] guality: Workaround for guality/pr59776.c testcase

On Mon, 16 Nov 2020, Jakub Jelinek wrote: > Hi! > > The test has been added 3 years before noipa attribute has been introduced, > but already at that point I wanted to avoid IPA opts getting into way, > most of the foo function is optimized away and the debug info just points > to the caller\s

Re: [PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

On 11/16/20 9:41 PM, Martin Sebor wrote: The result of DECL_SIZE_UNIT doesn't always reflect the size of data members of virtual classes.  This can lead to objects of such types appearing smaller than they are to warnings like -Warray-bounds or -Wstringop-overflow, causing false positives. To

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 10:13 PM, Martin Sebor wrote: On 11/16/20 12:02 PM, Jason Merrill wrote: On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the

Re: [PATCH V2] Clean up loop-closed PHIs after loop finalize

On 2020-11-16 17:35, Richard Biener wrote: On Mon, Nov 16, 2020 at 10:26 AM Jiufu Guo wrote: Jiufu Guo writes: > Richard Biener writes: > >> On Wed, 11 Nov 2020, Jiufu Guo wrote: >> >>> >>> Thanks a lot for the suggestion from previous mails. >>> The patch was updated accordingly. >>> >>>

Re: [PATCH] Put absolute address jump table in data.rel.ro.local if targets support relocations

Hi， I just tweaked the patch according to your advice and committed it. Thanks so much for your help and advice. Haochen Gui On 13/11/2020 下午 5:27, Richard Sandiford wrote: Hi, Sorry for the slow reply. Just one minor nit: HAO CHEN GUI writes: diff --git a/gcc/varasm.c b/gcc/varasm.c

[PING] [PATCH] libgcc: Add a weak stub for __sync_synchronize

Ping... I'd like to ping for this patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557886.html Thanks Bernd. On 11/3/20 4:08 PM, Bernd Edlinger wrote: > Hi, > > this fixes a problem with a missing symbol __sync_synchronize > which happens when newlib is used together with

Re: V2 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote: > Done. Here is the updated patch. Hi. I see a test-case for this kind of construct: int foo __attribute__((__used__, __section__ (".bar"))) = 42; and IIUC that it's handled as I'd hope (setting "R" on the named section, not another derived

(VAX) cc0 anyone? (was: [PATCH 0/2] Fixes for old version NetBSD targets)

On Sun, 15 Nov 2020, Maciej W. Rozycki wrote: > Hi, > > In the course of my recent VAX backend modernisation effort Hi. That reminds me that VAX is "still" a cc0 target. Are you aware of anyone planning on that level of modernization? More than a year ago, there was a major heads-up that all

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 12:02 PM, Jason Merrill wrote: On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the front end can detect bugs like    struct A {  

Re: [PATCH][AVX512]Lower AVX512 vector compare to AVX version when dest is vector

On Tue, Nov 17, 2020 at 8:05 AM Jeff Law wrote: > > > On 9/2/20 3:34 AM, Hongtao Liu via Gcc-patches wrote: > > Hi: > > Add define_peephole2 to eliminate potential redundant conversion > > from mask to vector. > > Bootstrap is ok, regression test is ok for i386/x86-64 backend. > > Ok for

[PATCH] c++: Reject identifier label in constexpr [PR97846]

[dcl.constexpr]/3 says that the function-body of a constexpr function shall not contain an identifier label, but we aren't enforcing that. This patch implements that. Of course, we can't reject artificial labels. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog:

[PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

The result of DECL_SIZE_UNIT doesn't always reflect the size of data members of virtual classes. This can lead to objects of such types appearing smaller than they are to warnings like -Warray-bounds or -Wstringop-overflow, causing false positives. To avoid these false positives, the attached

Re: [PATCH] Practical Improvement to libgcc Complex Divide

On Tue, 8 Sep 2020, Patrick McGehearty via Gcc-patches wrote: > This project started with an investigation related to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714. Study of Beebe[1] > provided an overview of past and recent practice for computing complex > divide. The current glibc

Re: [PATCH] [tree-optimization] Optimize two patterns with three xors.

Thank you for the review Richard! I re-worked the patch based on your suggestions (attached). I made the change to reuse the first bit_xor in both patterns and I added :s to the last xor in the first pattern. For the second pattern I didn't add :s because I think the simplification is

Re: [PATCH] x86: Add -mneeded for GNU_PROPERTY_X86_ISA_1_V[234] marker

On Mon, Nov 16, 2020 at 4:58 PM Jeff Law wrote: > > > On 11/9/20 11:57 AM, H.J. Lu via Gcc-patches wrote: > > GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA > > levels: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 > > > > Binutils has been updated to

Re: [PATCH 1/2] NetBSD/libgcc: Check for TARGET_DL_ITERATE_PHDR in the unwinder

On 11/15/20 10:44 AM, Maciej W. Rozycki wrote: > Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions, > fixing compilation errors: > > .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr' >75 | # define ElfW(type) Elf_##type > |

Re: [PATCH][MIPS] PR target/77510 Reduce size of MIPS core automaton

On 11/15/20 2:12 PM, Maciej W. Rozycki wrote: > On Tue, 10 Nov 2020, Jeff Law via Gcc-patches wrote: > > This patch reduce reservation of model do not more than 10 cycles. The > memory of genautomata down to 1GB. How bad is the memory consumption before this change? >>> almost

Re: [PATCH 0/2] Improve MSP430 hardware multiply support

On 11/15/20 2:14 PM, Jozef Lawrynowicz wrote: > The attached patch series improves MSP430 hardware multiply support, by > improving code generation when setting up the 16-bit and 32-bit hardware > multiply functions, and adding a 64-bit hardware multiply library > function for devices that have

Re: [05/32] cpp files

On 11/3/20 2:14 PM, Nathan Sidwell wrote: > As I mentioned in patch 03, include translation is a thing.  This > amends the file handling to determine that, and for resolving explicit > imports of header-units > > The logic for locating a header unit is the same as locating a > header-file. 

Re: [PATCH] Prefer bit-test over the jump table.

On 11/16/20 2:53 AM, Martin Liška wrote: > On 11/9/20 4:56 PM, Jeff Law wrote: >> >> On 11/9/20 7:24 AM, Martin LiÅ¡ka wrote: >>> Hello. >>> >>> As mentioned in the PR, we used to prefer BT over JT in switch >>> expansion. >>> I restore the behavior to that. >>> >>> Patch can bootstrap on

Re: [PATCH] x86: Add -mneeded for GNU_PROPERTY_X86_ISA_1_V[234] marker

On 11/9/20 11:57 AM, H.J. Lu via Gcc-patches wrote: > GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA > levels: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250 > > Binutils has been updated to support GNU_PROPERTY_X86_ISA_1_V[234] marker: > >

Re: [PATCH] add -Wmismatched-new-delete to middle end (PR 90629)

On 11/3/20 4:56 PM, Martin Sebor via Gcc-patches wrote: > Attached is a simple middle end implementation of detection of > mismatched pairs of calls to C++ new and delete, along with > a substantially enhanced implementation of -Wfree-nonheap-object. > The latter option has been in place since

Re: [PATCH] RFC: add "deallocated_by" attribute for use by analyzer

On 11/13/20 2:44 PM, Jeff Law via Gcc-patches wrote: On 10/5/20 5:12 PM, David Malcolm via Gcc-patches wrote: This work-in-progress patch generalizes the malloc/free problem-checking in -fanalyzer so that it can work on arbitrary acquire/release API pairs. It adds a new

Re: [patch] Fix build when source directory includes @ character

On 11/2/20 3:40 AM, FX via Gcc-patches wrote: > Here is an updated patch, that quotes all three makeinfo special characters: > @ { } > Tested on a build with source directory /tmp/foo@bar{gee}qux > > OK to commit? OK.  You have commit privs, right? jeff

Re: float.h: C2x NaN and Inf macros

On 10/26/20 6:44 PM, Joseph Myers wrote: > C2x adds macros for NaNs and infinities to , some of them > previously in (and some still in as well in C2x as > an obsolescent feature). Add these macros to GCC's > implementation. > > This omits the macros for DFP signaling NaNs, leaving those to

Re: [PATCH] Add MODE_OPAQUE

From: Aaron Sawdey Richard, Thanks for the review. I think I have resolved everything, as follows: * I was able to remove the const_tiny_rtx initialization for MODE_OPAQUE. If that becomes a problem it's a pretty simple matter to use an UNSPEC to assign a constant to an opaque mode if

Re: BoF DWARF5 patches (25% .debug section size reduction)

On 9/29/20 7:56 AM, Mark Wielaard wrote: > On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote: >> On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote: >>> --- a/gcc/doc/invoke.texi >>> +++ b/gcc/doc/invoke.texi >>> @@ -9057,13 +9057,14 @@ possible. >>> @opindex gdwarf >>> Produce

Re: [PATCH] doc: gcc.c: Update documentation for spec files

On 9/6/20 9:23 AM, Armin Brauns via Gcc-patches wrote: > gcc/ChangeLog: > * gcc.c: document %T spec file directive > * doc/invoke.texi: > remove %p, %P spec file directives > add %M, %R, %V, %nSTR, %>S, % file directives > add sanitize, version-compare, include, gt

[PATCH] libstdc++ Disable bogus -fsanitize=integer errors from Clang

Clang's "unsigned integer overflow" sanitizer can't tell the difference between expected unsigned wraparound and a bug, and its developers tell users to report bugs against libstdc++. This disables the sanitizer where we are intentionally relying on wraparound working as defined by the standard.

Re: [PATCH] Optimize comparison between result of us_minus and 0.

On 9/3/20 3:39 AM, Hongtao Liu via Gcc-patches wrote: > Hi: > Add define_peephole2 to perform optimization like bellow: > > +/* Optimize for TARGET_AVX512F > + vpsubusw op1, op2, dst1; > + vxorps xmm, xmm, dst2; > vpcmpleuw op1, op2, dst3 > + vpcmpeqw dst1, dst2, dst3 */ > > and > >

Re: [PATCH][AVX512]Lower AVX512 vector compare to AVX version when dest is vector

On 9/2/20 3:34 AM, Hongtao Liu via Gcc-patches wrote: > Hi: > Add define_peephole2 to eliminate potential redundant conversion > from mask to vector. > Bootstrap is ok, regression test is ok for i386/x86-64 backend. > Ok for trunk? > > gcc/ChangeLog: > PR target/96891 > *

Re: [PATCH] x86_64: PR rtl-optimization/92180: class_likely_spilled vs. cant_combine_insn.

On 8/17/20 4:42 AM, Roger Sayle wrote: > This patch catches a missed optimization opportunity where GCC currently > generates worse code than LLVM. The issue, as nicely analyzed in bugzilla, > boils down to the following three insns in combine: > > (insn 6 5 7 2 (parallel [ > (set

Re: [PATCH] introduce --param max-object-size

On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote: > On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches > wrote: >> GCC considers PTRDIFF_MAX - 1 to be the size of the largest object >> so that the difference between a pointer to the byte just past its >> end and the first one

Re: [PATCH v2] c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]

On Mon, Nov 16, 2020 at 05:02:14PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/15/20 10:34 PM, Marek Polacek wrote: > > [ This year's end-of-stage1 I'm working virtually from American Samoa. ] > > > > This patch finishes the second half of -Wrange-loop-construct I promised > > to

Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types

On 11/16/20 11:57 AM, Philipp Tomsich wrote: > From: Philipp Tomsich > > While most shifts wider than the bitwidth of a type will be caught by > other passes, it is possible that these show up for VRP. > Consider the following example: > int func (int a, int b, int c) > { > return (a <<

Re: [PATCH] use is_empty_type to check for empty types (PR 97840)

On 11/16/20 4:22 PM, Martin Sebor via Gcc-patches wrote: > The -Wmaybe-uninitialized enhancement to warn when the address > of an uninitialized object is passed to a function taking a const > pointer (or, in C++, a const reference) tries to avoid triggering > when the address is that of an empty

[committed, wwwdocs] gcc-11/changes: Document analyzer changes

I've gone ahead and pushed this website change, adding a new section to cover analyzer changes, having checked it validates. Dave --- htdocs/gcc-11/changes.html | 32 1 file changed, 32 insertions(+) diff --git a/htdocs/gcc-11/changes.html

[committed, wwwdocs] gcc-11/changes: Document libgccjit changes

I've gone ahead and pushed this website change, having checked it validates. Dave --- htdocs/gcc-11/changes.html | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html index 798257aa..21d59f51 100644 ---

[PATCH] use is_empty_type to check for empty types (PR 97840)

The -Wmaybe-uninitialized enhancement to warn when the address of an uninitialized object is passed to a function taking a const pointer (or, in C++, a const reference) tries to avoid triggering when the address is that of an empty object. It does that by checking EMPTY_TYPE_P() and

Re: [PATCH] Simplify testing symbol sections

On Mon, Nov 16, 2020 at 3:41 PM Jeff Law wrote: > > On 11/14/20 7:08 PM, David Edelsohn wrote: > > On Sat, Nov 14, 2020 at 8:58 PM Jeff Law wrote: > >> > >> On 11/14/20 6:35 PM, David Edelsohn wrote: > Jeffrey Law wrote: > I worry a bit about the less common native targets -- aix,

Re: [PATCH][driver] Don't add suffix for non-files

On Tue, 27 Oct 2020, Tamar Christina via Gcc-patches wrote: > Hi All, > > This patch fixes an issue where on systems that are > HAVE_TARGET_EXECUTABLE_SUFFIX the driver calls convert_filename in order to > add the suffix to the filename. However while it excludes `-` it doesn't > exclude the

Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types

On Mon, 16 Nov 2020 at 23:38, Jim Wilson wrote: > On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich > wrote: > >> This adds simplify_using_ranges::simplify_lshift_using_ranges to >> detect and rewrite such cases. If the intersection of meaningful >> shift amounts for the underlying type and the

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

On Sun, 15 Nov 2020, Uecker, Martin wrote: > > I think it might be safest to avoid doing any conversion in the case where  > > the value is still of array type at this point (C90 non-lvalue arrays). > > I added a test for arrays, but I am not sure what effect it has. > What would be C90

Re: Remove redundant zero extend

On 3/11/20 7:34 AM, Nidal Faour via Gcc-patches wrote: > This patch is a code density oriented and attempt to remove redundant > sign/zero extension from assignment statement. > The approach taken is to use VRP data while expanding the assignment to RTL > to determine whether a sign/zero

Re: [PATCH] c++: Don't form a templated TARGET_EXPR in finish_compound_literal

On Mon, 16 Nov 2020, Jason Merrill wrote: > On 11/13/20 10:43 AM, Patrick Palka wrote: > > On Thu, 12 Nov 2020, Jason Merrill wrote: > > > > > On 11/12/20 1:27 PM, Patrick Palka wrote: > > > > The atom_cache in normalize_atom relies on the assumption that two > > > > equivalent (templated) trees

Re: [PATCH v1 2/2] RISC-V: Adjust predicates for immediate shift operands

Jim, On Mon, 16 Nov 2020 at 23:28, Jim Wilson wrote: > > On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich wrote: >> >> In case a negative shift operand makes it through into the backend, >> it will be treated as unsigned and truncated (using a mask) to fit >> into the range 0..31 (for SImode)

Re: [PATCH] libstdc++: Enable without gthreads

This patch looks good to me. It would be great to find a way to do a similar refactoring of condition_variable. > On Nov 12, 2020, at 9:07 AM, Jonathan Wakely via Libstdc++ > wrote: > > On 11/11/20 17:31 +, Jonathan Wakely wrote: >> On 11/11/20 16:13 +, Jonathan Wakely wrote: >>>

Re: [PATCH v1 1/2] Simplify shifts wider than the bitwidth of types

On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich wrote: > This adds simplify_using_ranges::simplify_lshift_using_ranges to > detect and rewrite such cases. If the intersection of meaningful > shift amounts for the underlying type and the value-range computed > for the shift-amount (whether an

Re: [PATCH v1 2/2] RISC-V: Adjust predicates for immediate shift operands

On Mon, Nov 16, 2020 at 10:57 AM Philipp Tomsich wrote: > In case a negative shift operand makes it through into the backend, > it will be treated as unsigned and truncated (using a mask) to fit > into the range 0..31 (for SImode) and 0..63 (for DImode). > This is a de-optimization. This

Re: [PATCH] c++: Don't form a templated TARGET_EXPR in finish_compound_literal

On 11/13/20 10:43 AM, Patrick Palka wrote: On Thu, 12 Nov 2020, Jason Merrill wrote: On 11/12/20 1:27 PM, Patrick Palka wrote: The atom_cache in normalize_atom relies on the assumption that two equivalent (templated) trees (in the sense of cp_tree_equal) must use the same template parameters

Re: [PATCH] c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]

On 11/15/20 10:34 PM, Marek Polacek wrote: [ This year's end-of-stage1 I'm working virtually from American Samoa. ] This patch finishes the second half of -Wrange-loop-construct I promised to implement: it warns when a loop variable in a range-based for-loop is initialized with a value of a

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 2:24 PM, Marek Polacek wrote: On Mon, Nov 16, 2020 at 02:02:00PM -0500, Jason Merrill via Gcc-patches wrote: On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for

Re: [pushed] Objective-C/C++ (parsers) : Update @property attribute parsing.

Martin Liška wrote: On 11/16/20 10:00 AM, Iain Sandoe wrote: ../../gcc/c-family/stub-objc.c:30: note: an enum with different value name is defined in another translation unit 30 | enum rid { DUMMY }; I’m not disagreeing, of course (and will sort it out).. .. but I don’t see this

[pushed] C-family : Fix a C++ ODR violation [PR97854].

Hi The changes in r11-4799 introduced a dummy enum rid type with a different initial member name to the actual version (an ODR violation). Fixed by including the header declaring the actual type. tested --with-build-config=bootstrap-lto on Linux and --with-build-config=bootstrap-lto-noplugin

[PATCH] guality: Workaround for guality/pr59776.c testcase

Hi! The test has been added 3 years before noipa attribute has been introduced, but already at that point I wanted to avoid IPA opts getting into way, most of the foo function is optimized away and the debug info just points to the caller\s var. With the recent modref/aliasing changes the

Re: [PATCH] c: Reject _Atomic type * as last argument to __builtin_*_overflow [PR90628]

On Mon, Nov 16, 2020 at 10:17:19PM +0100, Jakub Jelinek via Gcc-patches wrote: > Hi! > > During the __builtin_clear_padding implementation, I've noticed we don't > diagnose _ATomic whatever * as last argument to __builtin_*_overflow. > As the storing by that builtin isn't atomic in any way, I

[PATCH] c: Reject _Atomic type * as last argument to __builtin_*_overflow [PR90628]

Hi! During the __builtin_clear_padding implementation, I've noticed we don't diagnose _ATomic whatever * as last argument to __builtin_*_overflow. As the storing by that builtin isn't atomic in any way, I think we should reject it. Bootstrapped/regtested on x86_64-linux, ok for trunk?

[PATCH] c++: __builtin_clear_padding builtin follow-up [PR88101]

On Sun, Nov 15, 2020 at 11:57:55PM -1200, Jakub Jelinek via Gcc-patches wrote: > Tested on x86_64-linux, i686-linux and powerpc64-linux, ok for trunk? Here is an incremental patch that resolves the remaining FIXMEs, in particular implements VLAs (except for variable length structures) and for

Re: [PATCH, v1] PR fortran/48958 - Add runtime diagnostics for SIZE intrinsic function

Hi Thomas, thanks for the comments. > It feels a bit strange to have a check for an allocatable > behind -fcheck=pointer, but I'm not sure that introducing > a special check option would really be worth it. Yes, I thought about that. There's already a discrepancy between the GFC_RTCHECK_* in

Re: [PATCH] Simplify testing symbol sections

On 11/14/20 7:08 PM, David Edelsohn wrote: > On Sat, Nov 14, 2020 at 8:58 PM Jeff Law wrote: >> >> On 11/14/20 6:35 PM, David Edelsohn wrote: Jeffrey Law wrote: I worry a bit about the less common native targets -- aix, hpux and the like. But testing them is too painful to

[PATCH] libstdc++: Fix ranges::search_n for random access iterators [PR97828]

My ranges transcription of the std::search_n implementation for random access iterators missed a crucial part of the algorithm which the tests unfortunately didn't catch. When __remainder is less than __count at the start of an iteration of the outer while loop, it means we're continuing a run of

Re: Detect EAF flags in ipa-modref

> On 11/16/20 1:44 PM, Jan Hubicka wrote: > > Martin, we collected very many warnings when building with > > configure --with-build-config=bootstrap-lto.mk > > This patch fixes some of them, but there are many others, can you take a > > look? > > Hello. > > I guess you mean Martin Jambor, or me?

Re: [PATCH] modref: add missing Param Optimization keywords

On 11/16/20 1:25 PM, Jan Hubicka wrote: Hello. This fixes: FAIL: compiler driver --help=common option(s): "^ +-.*[^:.]$" absent from output: " --param=modref-max-depth= Maximum depth of DFS walk used by modref escape analysis" Ready to be installed after tests? Thanks, Martin

Re: Detect EAF flags in ipa-modref

On 11/16/20 1:44 PM, Jan Hubicka wrote: Martin, we collected very many warnings when building with configure --with-build-config=bootstrap-lto.mk This patch fixes some of them, but there are many others, can you take a look? Hello. I guess you mean Martin Jambor, or me? Please CC :) Martin

[PATCH][pushed] mklog: support unidiff 0.5.4

Hi. The patch adds support of unidiff 0.5.4 for mklog.py. Tested that in a virtual environment. Martin contrib/ChangeLog: * mklog.py: Do not call read on an input stream. Fix some flake8 issues. --- contrib/mklog.py | 9 - 1 file changed, 4 insertions(+), 5

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On Mon, Nov 16, 2020 at 02:02:00PM -0500, Jason Merrill via Gcc-patches wrote: > On 11/16/20 12:42 PM, Martin Sebor wrote: > > On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: > > > This patch implements the long-desired -Wuninitialized warning for > > > member initializer lists, so that

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/16/20 12:42 PM, Martin Sebor wrote: On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the front end can detect bugs like    struct A { int a; int b; A() : b(1),

[PATCH v1 2/2] RISC-V: Adjust predicates for immediate shift operands

From: Philipp Tomsich In case a negative shift operand makes it through into the backend, it will be treated as unsigned and truncated (using a mask) to fit into the range 0..31 (for SImode) and 0..63 (for DImode). Consider the following output illustrating the issue and shows how the shift

[PATCH v1 1/2] Simplify shifts wider than the bitwidth of types

From: Philipp Tomsich While most shifts wider than the bitwidth of a type will be caught by other passes, it is possible that these show up for VRP. Consider the following example: int func (int a, int b, int c) { return (a << ((b && c) - 1)); } This adds

Re: [Patch][wwwdocs] gcc-11/changes.html update for OpenMP + !GCC$ attributes + project/libgomp/ omp 5.1 update

Hi Tobias, should the OpenMP news about Fortran be mentioned (also) in the Fortran section? Best regards Thomas

Re: [Patch][wwwdocs] gcc-11/changes.html update for OpenMP + !GCC$ attributes + project/libgomp/ omp 5.1 update

On Mon, Nov 16, 2020 at 07:15:57PM +0100, Tobias Burnus wrote: > This patch tries to do a minor update for > * htdocs/projects/gomp/index.html > Add link to the just-released OpenMP 5.1 > > * htdocs/gcc-11/changes.html: > - Fortran: Mention the new "!GCC$ attributes DEPRECATED" > - OpenMP:

Re: introduce overridable clear_cache emitter

Hi Alex, Thanks for your proposal on this! > On 11 Nov 2020, at 03:35, Alexandre Oliva wrote: > > This patch introduces maybe_emit_call_builtin___clear_cache for the > builtin expander machinery and the trampoline initializers to use to > clear the instruction cache, removing a source of

[Patch][wwwdocs] gcc-11/changes.html update for OpenMP + !GCC$ attributes + project/libgomp/ omp 5.1 update

This patch tries to do a minor update for * htdocs/projects/gomp/index.html Add link to the just-released OpenMP 5.1 * htdocs/gcc-11/changes.html: - Fortran: Mention the new "!GCC$ attributes DEPRECATED" - OpenMP: Update list. (For OpenMP, there are still some patches pending review and other

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

On 11/15/20 3:44 PM, Marek Polacek via Gcc-patches wrote: This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the front end can detect bugs like struct A { int a; int b; A() : b(1), a(b) { } }; where the field 'b' is used

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

> On Nov 16, 2020, at 4:29 AM, Martin Liška wrote: > > On 11/10/20 9:53 PM, Qing Zhao wrote: >> The deadline for gcc11 stage 1 is approaching. The pinged patch is one that >> has been sent for review 8 months ago in order to >> Make into gcc11. > > Hello. > > You didn't miss the deadline

Re: [PATCH] c++: Predefine __STDCPP_THREADS__ in the compiler if thread model is not single

On 16/11/20 09:23 -0700, Tom Tromey wrote: Jakub> If it is done in the library, it will be defined only if any of the library Jakub> headers are included. Jakub> The https://eel.is/c++draft/cpp.predefined wording doesn't look like it Jakub> would allow defining it only if certain headers are

Re: OpenACC 'kernels' testsuite failures

Hi David! While you were writing your email, I've also been busy: On 2020-11-16T11:32:46-0500, David Edelsohn wrote: > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge > wrote: >> On 2020-11-15T15:47:15-0500, David Edelsohn wrote: >> > I am seeing a number of new failures on AIX related to

Re: OpenACC 'kernels' testsuite failures

On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge wrote: > > Hi David! > > Thanks for reporting. > > On 2020-11-15T15:47:15-0500, David Edelsohn wrote: > > I am seeing a number of new failures on AIX related to the OpenACC > > kernels patches. > > > > c-c++-common/goacc/kernels-decompose-1.c > >

Re: [PATCH] c++: Predefine __STDCPP_THREADS__ in the compiler if thread model is not single

Jakub> If it is done in the library, it will be defined only if any of the library Jakub> headers are included. Jakub> The https://eel.is/c++draft/cpp.predefined wording doesn't look like it Jakub> would allow defining it only if certain headers are included Jakub> (unlike e.g. the __cpp_lib_*

Re: [PATCH] [PR target/97727] aarch64: [testcase] fix bf16_vstN_lane_2.c for big endian targets

Andrea Corallo via Gcc-patches writes: > Hi all, > > this simple patch is to fix PR target/97727. > > Okay for trunk and gcc-10? > > Thanks! > > Andrea > > 2020-11-09 Andrea Corallo > > PR target/97727 > * gcc.target/aarch64/advsimd-intrinsics/bf16_vldN_lane_2.c: Relax >

[PATCH] [PR target/97726] arm: [testsuite] fix some simd tests on armbe

Andrea Corallo via Gcc-patches writes: > Hi all, > > I'd like to submit this patch to fix three testcases reported to be > failing on arm big endian on PR target/97727. > > Okay for trunk? > > Thanks > > Andrea Ops I got the PR number wrong, target/97726 is the correct one. Attached the

Ping^3 Re: float.h: C2x NaN and Inf macros

Ping^3. This patch is still pending review (the DFP sNaN followup has been approved). (The independent C2x patches and

RE: [PATCH 2/2] middle-end : Add support for complex pattern detection for Add, Mul, FMA and FMS

Hi Richi, thanks for the review! Just a quick comment on one of the questions asked: > -Original Message- > From: rguent...@c653.arch.suse.de On > Behalf Of Richard Biener > Sent: Monday, November 16, 2020 3:12 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz; >

[PATCH 6/X] libsanitizer: Add hwasan pass and associated gimple changes

There are four main features to this change: 1) Check pointer tags match address tags. When sanitizing for hwasan we now put HWASAN_CHECK internal functions before memory accesses in the `asan` pass. This checks that a tag in the pointer being used match the tag stored in shadow memory for the

[PATCH 5/X] libsanitizer: mid-end: Introduce stack variable handling for HWASAN

Handling stack variables has three features. 1) Ensure HWASAN required alignment for stack variables When tagging shadow memory, we need to ensure that each tag granule is only used by one variable at a time. This is done by ensuring that each tagged variable is aligned to the tag granule

[PATCH 1/X] libsanitizer: Tie the hwasan library into our build system

This patch tries to tie libhwasan into the GCC build system in the same way that the other sanitizer runtime libraries are handled. libsanitizer/ChangeLog: * Makefile.am: Build libhwasan. * Makefile.in: Build libhwasan. * asan/Makefile.in: Build libhwasan. *

[PATCH 4/X] libsanitizer: options: Add hwasan flags and argument parsing

These flags can't be used at the same time as any of the other sanitizers. We add an equivalent flag to -static-libasan in -static-libhwasan to ensure static linking. The -fsanitize=kernel-hwaddress option is for compiling targeting the kernel. This flag has defaults to match the LLVM

[PATCH 3/X] libsanitizer: Add option to bootstrap using HWASAN

This is an analogous option to --bootstrap-asan to configure. It allows bootstrapping GCC using HWASAN. For the same reasons as for ASAN we have to avoid using the HWASAN sanitizer when compiling libiberty and the lto-plugin. Also add a function to query whether -fsanitize=hwaddress has been

[PATCH 7/X] libsanitizer: Add tests

Adding hwasan tests. Only interesting thing here is that we have to make sure the tagging mechanism is deterministic to avoid flaky tests. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/sanitize-recover-7.c: * c-c++-common/hwasan/aligned-alloc.c: New test. *

[PATCH 2/X] libsanitizer: Only build libhwasan when targeting AArch64

Though the library has limited support for x86, we don't have any support for generating code targeting x86 so there is no point building for that target. Ensure we build for AArch64 but not for AArch64 ilp32. libsanitizer/ChangeLog: * Makefile.am: Condition Build hwasan directory.

Hwasan v5

Hello, Bootstrapped and regression tested on AArch64 (have not finished running tests on the Linux Kernel yet). Sending upstream to catch next set of comments early. This version mainly just consists of requested changes. Some notable exceptions: Have rebased onto a newer version, there was a

GCC 11.0.0 Status Report (2020-11-16), Stage 3 in effect now

Status == GCC trunk which eventually will become GCC 11 is now in Stage 3 which means open for general bugfixing. We have accumulated quite a number of regressions, a lot of the untriaged and eventually stale. Please help in cleaning up. Quality Data Priority #

Innovative automotive performance products

Hi, Would you be interested in contacting the influencers across the *innovative automotive performance products*. to boost your sales efforts? We can help you with contacts from the below communities: *Automotive Engineers* *Automotive Engineering Technicians* *Automotive Specialty

Re: [PATCH 2/2] middle-end : Add support for complex pattern detection for Add, Mul, FMA and FMS

On Sat, 14 Nov 2020, Tamar Christina wrote: > Hi All, > > This patch series adds support for SLP vectorization of complex instructions > [1]. > > These instructions exist only in their vector forms and require you to > recognize > two statements in parallel. Complex operations usually

[PATCH] tree-optimization/97838 - fix SLP leaf detection

This properly handles reduction PHI nodes with unrepresented initial value as leaf in the SLP graph. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-11-16 Richard Biener PR tree-optimization/97838 * tree-vect-slp.c (vect_slp_build_vertices): Properly handle

Re: OpenACC 'kernels' testsuite failures

Hi David! Thanks for reporting. On 2020-11-15T15:47:15-0500, David Edelsohn wrote: > I am seeing a number of new failures on AIX related to the OpenACC > kernels patches. > > c-c++-common/goacc/kernels-decompose-1.c > c-c++-common/goacc/kernels-decompose-2.c >

[Patch] Fortran: cleanup OpenMP's OMP_LIST_* handling

Hi all, as discussed the other day (I think via IRC or in a patch review), omp_list_clauses did grow quite a bit: it has 26 entries and I am about to add two more. This variable is used as: typedef struct gfc_omp_clauses { ... gfc_omp_namelist *lists[OMP_LIST_NUM]; with

Re: [2/3][vect] Add widening add, subtract vect patterns

On Fri, 13 Nov 2020, Joel Hutton wrote: > Tests are still running, but I believe I've addressed all the comments. > > > Like Richard said, the new patterns need to be documented in md.texi > > and the new tree codes need to be documented in generic.texi. > > Done. > > > While we're using tree

  1   2   >