Re: [PATCH] Loop unswitching: support gswitch statements.

2021-11-09 Thread Aldy Hernandez via Gcc-patches
On Tue, Nov 9, 2021 at 5:41 PM Andrew MacLeod wrote: > > On 11/9/21 8:37 AM, Richard Biener wrote: > > On Mon, Nov 8, 2021 at 8:45 PM Andrew MacLeod wrote: > >> On 11/8/21 10:05 AM, Martin Liška wrote: > >>> On 9/28/21 22:39, Andrew MacLeod wrote: > In Theory, modifying the IL should be

[PATCH] [i386] Extend vpcmov to handle V8HF/V16HFmode under TARGET_XOP.

2021-11-09 Thread liuhongt via Gcc-patches
This patch fixes ICE in pr103151. Bootstrap and regtest on x86_64-linux-gnu{-m32,}. Ready to push to trunk. gcc/ChangeLog: PR target/103151 * config/i386/sse.md (V_128_256): Extend to V8HF/V16HF. (avxsizesuffix): Ditto. gcc/testsuite/ChangeLog: *

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Wed, 10 Nov 2021, 05:45 François Dumont, wrote: > I can't see any clue on how my commit can have had an impact on below code. > Agreed. > I don't think libstdc++ hash table has any relation with gcc hash table. > Correct, it's totally unrelated. And "section type conflict" can't be

Re: Make EAF flags more regular (and expressive)

2021-11-09 Thread Richard Biener via Gcc-patches
On Tue, 9 Nov 2021, Jan Hubicka wrote: > Hi, > I hoped that I am done with EAF flags related changes, but while looking into > the Fortran testcases I noticed that I have designed them in unnecesarily > restricted way. I followed the scheme of NOESCAPE and NODIRECTESCAPE which is > however the

Re: [PATCH] [pass_if_conversion] Extend is_cond_scalar_reduction to handle bit_and/bit_xor/bit_ior.

2021-11-09 Thread Hongtao Liu via Gcc-patches
On Tue, Nov 9, 2021 at 6:22 PM Richard Biener via Gcc-patches wrote: > > On Tue, Nov 9, 2021 at 3:09 AM liuhongt wrote: > > > > This will enable transformation like > > > > - # sum1_50 = PHI > > - # sum2_52 = PHI > > + # sum1_50 = PHI <_87(13), 0(4)> > > + # sum2_52 = PHI <_89(13), 0(4)> >

RE: [PATCH]middle-end Add an RPO pass after successful vectorization

2021-11-09 Thread Richard Biener via Gcc-patches
On Tue, 9 Nov 2021, Tamar Christina wrote: > > > + bitmap_set_bit (exit_bbs, single_exit (loop)->dest->index); > > > + bitmap_set_bit (exit_bbs, loop->latch->index); > > > > treating the latch as exit is probably premature optimization (yes, it's > > empty). > > > > > + > > > +

[COMMITTED] Remove unused gimple-ssa-evr-analyze.h header file.

2021-11-09 Thread Aldy Hernandez via Gcc-patches
gcc/ChangeLog: * tree-ssa-threadedge.c: Do not include gimple-ssa-evrp-analyze.h. * value-pointer-equiv.cc: Same. --- gcc/tree-ssa-threadedge.c | 1 - gcc/value-pointer-equiv.cc | 1 - 2 files changed, 2 deletions(-) diff --git a/gcc/tree-ssa-threadedge.c

[COMMITTED] Include PHI threading restrictions in backthreader diagnostics.

2021-11-09 Thread Aldy Hernandez via Gcc-patches
I forgot to include the path dump when failing a path in resolve_phi. To do so I abstracted dump_path into its own function, which made me realize we had another copy with slightly different output. I've merged everything and cleaned it up. Tested on x86-64 Linux. gcc/ChangeLog: *

Re: [PATCH] PR fortran/103217 & 103218 - ICEs during simplification after r12-4967-gbcf3728abe848888

2021-11-09 Thread Thomas Koenig via Gcc-patches
Hi Harald, I'd like to commit the attached patch as obvious within the next 24 hours unless anybody objects, or earlier if there is positive feedback. OK with a ChangeLog entry and the correct PR numbers (I believe they are 103137 and 103138) :-) Best regards Thomas

Re: [PATCH 1/2] [Gimple] Simplify (trunc)fmax/fmin((extend)a, (extend)b) to MAX/MIN(a,b)

2021-11-09 Thread Hongtao Liu via Gcc-patches
On Tue, Nov 9, 2021 at 6:21 PM Richard Biener wrote: > > On Tue, Nov 9, 2021 at 3:37 AM Hongtao Liu wrote: > > > > On Mon, Nov 8, 2021 at 4:59 PM Richard Biener > > wrote: > > > > > > On Mon, Nov 8, 2021 at 2:30 AM Hongtao Liu wrote: > > > > > > > > On Fri, Nov 5, 2021 at 5:52 PM Richard

Re: [PATCH v8] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Jason Merrill via Gcc-patches
On 11/9/21 16:30, Marek Polacek wrote: On Tue, Nov 09, 2021 at 02:17:14PM -0500, Marek Polacek wrote: On Tue, Nov 09, 2021 at 12:27:28PM -0500, Jason Merrill wrote: On 11/9/21 10:55, Marek Polacek wrote: On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: On Tue, 9 Nov

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread François Dumont via Gcc-patches
On 09/11/21 5:25 pm, Jonathan Wakely wrote: On Mon, 8 Nov 2021 at 21:36, François Dumont > wrote: Yet another version this time with only 1 guard implementation. The predicate to invalidate the safe iterators has been externalized. Ok to commit ? I

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread François Dumont via Gcc-patches
I can't see any clue on how my commit can have had an impact on below code. I don't think libstdc++ hash table has any relation with gcc hash table. Still, I'm rebuilding gcc at my revision to confirm. On 10/11/21 1:05 am, H.J. Lu wrote: On Mon, Nov 8, 2021 at 1:37 PM François Dumont via

[PATCH] rs6000/doc: Rename future cpu with power10

2021-11-09 Thread Kewen.Lin via Gcc-patches
Hi, Commmit 5d9d0c94588 renamed future to power10 and ace60939fd2 updated the documentation for "future" renaming. This patch is to rename the remaining "future architecture" references in documentation. Is it ok for trunk? BR, Kewen - gcc/ChangeLog: * doc/invoke.texi: Change

[PATCH] Improve integer bit test on __atomic_fetch_[or|and]_* returns

2021-11-09 Thread liuhongt via Gcc-patches
> > > > +#if GIMPLE > > +(match (nop_atomic_bit_test_and_p @0 @1) > > + (bit_and:c (nop_convert?@4 (ATOMIC_FETCH_OR_XOR_N @2 INTEGER_CST@0 @3)) > > +           INTEGER_CST@1) > > no need for the :c on the bit_and when the 2nd operand is an Changed. > INTEGER_CST (likewise below) > > > + (with {

Re: [PATCH] c++: use auto_vec in cp_parser_template_argument_list

2021-11-09 Thread Jason Merrill via Gcc-patches
On 11/9/21 13:42, Patrick Palka wrote: On Tue, 9 Nov 2021, Jason Merrill wrote: On 11/9/21 11:02, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK, though I wonder about using releasing_vec instead of auto_vec; reusing a previously allocated vec vs.

Re: Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204]

2021-11-09 Thread Martin Sebor via Gcc-patches
On 11/9/21 3:28 AM, Thomas Schwinge wrote: Hi! On 2021-09-01T18:14:46-0600, Martin Sebor wrote: On 9/1/21 1:35 PM, Thomas Schwinge wrote: On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches wrote: --- /dev/null +++ b/gcc/diagnostic-spec.h +typedef location_t key_type_t; +typedef

[PATCH] implement -Winfinite-recursion [PR88232]

2021-11-09 Thread Martin Sebor via Gcc-patches
The attached patch adds support to the middle end for detecting infinitely recursive calls. The warning is controlled by the new -Winfinite-recursion option. The option name is the same as Clang's. I scheduled the warning pass to run after early inlining to detect mutually recursive calls but

Re: [PATCH] aarch64: [PR101529] Fix vector shuffle insertion expansion

2021-11-09 Thread Andrew Pinski via Gcc-patches
On Tue, Nov 9, 2021 at 6:51 AM Richard Sandiford via Gcc-patches wrote: > > apinski--- via Gcc-patches writes: > > From: Andrew Pinski > > > > The function aarch64_evpc_ins would reuse the target even though > > it might be the same register as the two inputs. > > Instead of checking to see if

[PATCH] aarch64: [PR101529] Fix vector shuffle insertion expansion

2021-11-09 Thread apinski--- via Gcc-patches
From: Andrew Pinski The function aarch64_evpc_ins would reuse the target even though it might be the same register as the two inputs. Instead of checking to see if we can reuse the target, just use the original input directly. Committed as approved after bootstrapped and tested on

[PATCH v7 2/2] Don't move cold code out of loop by checking bb count

2021-11-09 Thread Xionghu Luo via Gcc-patches
On 2021/11/4 21:00, Richard Biener wrote: > On Wed, Nov 3, 2021 at 2:29 PM Xionghu Luo wrote: >> >> >>> + while (outmost_loop != loop) >>> +{ >>> + if (bb_colder_than_loop_preheader (loop_preheader_edge >>> (outmost_loop)->src, >>> +

[committed] Nios2: Add TARGET_CAN_INLINE_P hook

2021-11-09 Thread Sandra Loosemore
I've checked in the attached patch, which fixes 30+ FAILs across the gcc and g++ testsuites on nios2-elf target. The only target options we have to worry about in this backend are the nios2 custom instructions, and the hashing in the default hook function seemed to be confused by all the

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread H.J. Lu via Gcc-patches
On Mon, Nov 8, 2021 at 1:37 PM François Dumont via Gcc-patches wrote: > > Yet another version this time with only 1 guard implementation. The > predicate to invalidate the safe iterators has been externalized. > > Ok to commit ? > This may have broken GCC bootstrap on Linux/x86-64:

Re: [PATCH] fixincludes: don't assume getcwd() can handle NULL argument

2021-11-09 Thread Joseph Myers
On Tue, 9 Nov 2021, Xi Ruoyao via Gcc-patches wrote: > POSIX says: > > On some implementations, if buf is a null pointer, getcwd() may obtain > size bytes of memory using malloc(). In this case, the pointer returned > by getcwd() may be used as the argument in a subsequent call to

[committed] c: more precise locations for some -Wpragmas diagnostics

2021-11-09 Thread David Malcolm via Gcc-patches
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as 8722a17067f1590e82f49b3fd385647b762a45dc. gcc/c-family/ChangeLog: * c-pragma.c (GCC_BAD_AT): New macro. (GCC_BAD2_AT): New macro. (handle_pragma_pack): Use the location of the pertinent token

Re: [PATCH v4 1/1] [ARM] Add support for TLS register based stack protector canary access

2021-11-09 Thread Ard Biesheuvel via Gcc-patches
On Tue, 9 Nov 2021 at 21:45, Qing Zhao wrote: > > Hi, Ard, > > Sorry for the late reply (since I don’t have the right to approve a patch, I > has been waiting for any arm port maintainer to review this patch). > The following is the arm port maintainer information I got from MAINTAINERS > file

[PATCH] rs6000: Fix a handful of 32-bit built-in function problems in the new support

2021-11-09 Thread Bill Schmidt via Gcc-patches
Hi! Some time ago I realized I hadn't tested the new builtin support against 32-bit big-endian in quite a while. When I did, I found a handful of errors that needed correcting. - One builtin needs to be disabled for 32-bit. - One builtin needs to be restricted to 32-bit only. - One builtin

Re: [PATCH] rs6000: Match recent builtins changes in new builtins support

2021-11-09 Thread David Edelsohn via Gcc-patches
On Tue, Nov 9, 2021 at 4:40 PM Bill Schmidt wrote: > > Hi! Over the last month or so, Haochen made a couple of changes to the > builtins > support that need to be reflected into the new builtin support: > > 14e355df Disable gimple folding for vector min/max without fast-math > 91419baf

[PATCH] rs6000: Match recent builtins changes in new builtins support

2021-11-09 Thread Bill Schmidt via Gcc-patches
Hi! Over the last month or so, Haochen made a couple of changes to the builtins support that need to be reflected into the new builtin support: 14e355df Disable gimple folding for vector min/max without fast-math 91419baf Optimize vec_xl_sext In both cases these require almost identical

[PATCH v8] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Marek Polacek via Gcc-patches
On Tue, Nov 09, 2021 at 02:17:14PM -0500, Marek Polacek wrote: > On Tue, Nov 09, 2021 at 12:27:28PM -0500, Jason Merrill wrote: > > On 11/9/21 10:55, Marek Polacek wrote: > > > On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: > > > > On Tue, 9 Nov 2021 00:12:10 -0500 > > >

Make EAF flags more regular (and expressive)

2021-11-09 Thread Jan Hubicka via Gcc-patches
Hi, I hoped that I am done with EAF flags related changes, but while looking into the Fortran testcases I noticed that I have designed them in unnecesarily restricted way. I followed the scheme of NOESCAPE and NODIRECTESCAPE which is however the only property tht is naturally transitive. This

Re: [PATCH v4 1/1] [ARM] Add support for TLS register based stack protector canary access

2021-11-09 Thread Qing Zhao via Gcc-patches
Hi, Ard, Sorry for the late reply (since I don’t have the right to approve a patch, I has been waiting for any arm port maintainer to review this patch). The following is the arm port maintainer information I got from MAINTAINERS file (you might want to explicitly cc’ing one of them for a

Re: [PATCH v7] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Marek Polacek via Gcc-patches
On Tue, Nov 09, 2021 at 08:57:48PM +0100, Bernhard Reutner-Fischer wrote: > On Tue, 9 Nov 2021 20:47:02 +0100 > Bernhard Reutner-Fischer wrote: > > > On Tue, 9 Nov 2021 14:17:14 -0500 > > Marek Polacek wrote: > > > > > + if (!valid_p (vendor_start, vendor_len) > > > + || !valid_p

[PATCH] PR fortran/103217 & 103218 - ICEs during simplification after r12-4967-gbcf3728abe848888

2021-11-09 Thread Harald Anlauf via Gcc-patches
Dear all, I'd like to commit the attached patch as obvious within the next 24 hours unless anybody objects, or earlier if there is positive feedback. The patch only fixes three obvious NULL pointer dereferences that were latent before the referenced commit and exhibited in the testcases, see

Re: [PATCH v7] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Bernhard Reutner-Fischer via Gcc-patches
On Tue, 9 Nov 2021 20:47:02 +0100 Bernhard Reutner-Fischer wrote: > On Tue, 9 Nov 2021 14:17:14 -0500 > Marek Polacek wrote: > > > + if (!valid_p (vendor_start, vendor_len) > > + || !valid_p (attr_start, attr_len)) > > + { > > + error ("wrong argument to ignored attributes"); >

Re: [PATCH v7] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Bernhard Reutner-Fischer via Gcc-patches
On Tue, 9 Nov 2021 14:17:14 -0500 Marek Polacek wrote: > + if (!valid_p (vendor_start, vendor_len) > + || !valid_p (attr_start, attr_len)) > + { > + error ("wrong argument to ignored attributes"); > + continue; > + } > + canonicalize_attr_name (vendor_start,

Re: libstdc++: Make atomic::wait() const [PR102994]

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Tue, 9 Nov 2021 at 18:09, Thomas Rodgers wrote: > Revised patch attached. > OK for trunk and gcc-11, thanks. > On Fri, Nov 5, 2021 at 4:46 PM Jonathan Wakely > wrote: > >> On Fri, 5 Nov 2021 at 21:51, Jonathan Wakely via Libstdc++ >> wrote: >> > >> > OK, thanks. >> >> Actually, we should

[PATCH v7] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Marek Polacek via Gcc-patches
On Tue, Nov 09, 2021 at 12:27:28PM -0500, Jason Merrill wrote: > On 11/9/21 10:55, Marek Polacek wrote: > > On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: > > > On Tue, 9 Nov 2021 00:12:10 -0500 > > > Jason Merrill wrote: > > > > > > > On 11/8/21 20:41, Marek Polacek

Re: [PATCH] powerpc: Remove LINK_OS_EXTRA_SPEC{32, 64} from --with-advance-toolchain

2021-11-09 Thread Lucas A. M. Magalhaes via Gcc-patches
Quoting Segher Boessenkool (2021-11-09 11:19:58) > Hi! > > On Tue, Nov 09, 2021 at 10:39:46AM -0300, Lucas A. M. Magalhaes wrote: > > Ping. > > I did not get the original, and neither did the archives? > Strange, it's on the archives.

[PATCH] [Committed] Fix tree-optimization/103152: Still one more -signed1bit issue

2021-11-09 Thread apinski--- via Gcc-patches
From: Andrew Pinski When I fixed PR 102622, I accidently left behind a TYPE_PRECISION check which I had there for checking before hand. This check is not needed as the code will handle it correctly anyways. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. PR

[PATCH 08/10] tree-object-size: Handle GIMPLE_CALL

2021-11-09 Thread Siddhesh Poyarekar
Handle non-constant expressions in GIMPLE_CALL arguments. Also handle alloca. gcc/ChangeLog: * tree-object-size.c (alloc_object_size): Make and return non-constant size expression. (call_object_size): Return expression or unknown based on whether dynamic object

[PATCH 09/10] tree-object-size: Dynamic sizes for ADDR_EXPR

2021-11-09 Thread Siddhesh Poyarekar
Allow dynamic expressions from ADDR_EXPR for __builtin_dynamic_object_size. Offsets in objects still need to be constant for now because offset computation need more validation to support, e.g. negative offsets with dynamic sizes. gcc/ChangeLog: * tree-object-size.c (size_known_p): New

[PATCH 10/10] tree-object-size: Handle dynamic offsets

2021-11-09 Thread Siddhesh Poyarekar
Compute whole sizes for objects to allow offsets to be negative for dynamic object sizes. This way, the returned object size would be precise even for negative offsets as long as the offset is within bounds of the object. gcc/ChangeLog: * tree-object-size.c (addr_object_size,

[PATCH 06/10] tree-object-size: Support dynamic sizes in conditions

2021-11-09 Thread Siddhesh Poyarekar
Handle GIMPLE_PHI and conditionals specially for dynamic objects, returning PHI/conditional expressions instead of just a MIN/MAX estimate. This makes the returned object size variable for loops and conditionals, so tests need to be adjusted to look for precise size in some cases.

[PATCH 05/10] __builtin_dynamic_object_size: Recognize builtin

2021-11-09 Thread Siddhesh Poyarekar
Recognize the __builtin_dynamic_object_size builtin and add paths in the object size path to deal with it, but treat it like __builtin_object_size for now. Also add tests to provide the same testing coverage for the new builtin name. gcc/ChangeLog: * builtins.def

[PATCH 07/10] tree-object-size: Handle function parameters

2021-11-09 Thread Siddhesh Poyarekar
Handle hints provided by __attribute__ ((access (...))) to compute dynamic sizes for objects. gcc/ChangeLog: * tree-object-size.c: Include tree-dfa.h. (parm_object_size): New function. (collect_object_sizes_for): Call it. gcc/testsuite/ChangeLog: *

[PATCH 04/10] tree-object-size: Single pass dependency loop resolution

2021-11-09 Thread Siddhesh Poyarekar
Use SSA names as placeholders self-referencing variables to generate expressions for object sizes and then reduce those size expressions to constants instead of repeatedly walking through statements. This change also makes sure that object sizes for an SSA name are updated at most twice, once if

[PATCH 03/10] tree-object-size: Use tree instead of HOST_WIDE_INT

2021-11-09 Thread Siddhesh Poyarekar
Transform tree-object-size to operate on tree objects instead of host wide integers. This makes it easier to extend to dynamic expressions for object sizes. The compute_builtin_object_size interface also now returns a tree expression instead of HOST_WIDE_INT, so callers have been adjusted to

[PATCH 02/10] tree-object-size: Abstract object_sizes array

2021-11-09 Thread Siddhesh Poyarekar
Put all accesses to object_sizes behind functions so that we can add dynamic capability more easily. gcc/ChangeLog: * tree-object-size.c (object_sizes_grow, object_sizes_release, object_sizes_unknown_p, object_sizes_get, object_size_set_force, object_sizes_set): New

[PATCH 01/10] tree-object-size: Replace magic numbers with enums

2021-11-09 Thread Siddhesh Poyarekar
A simple cleanup to allow inserting dynamic size code more easily. gcc/ChangeLog: * tree-object-size.c: New enum. (object_sizes, computed, addr_object_size, compute_builtin_object_size, init_object_sizes, fini_object_sizes, object_sizes_execute): Replace magic

[PATCH 00/10] __builtin_dynamic_object_size

2021-11-09 Thread Siddhesh Poyarekar
This patchset implements the __builtin_dynamic_object_size builtin for gcc. The primary motivation to have this builtin in gcc is to enable _FORTIFY_SOURCE=3 support with gcc, thus allowing greater fortification in use cases where the potential performance tradeoff is acceptable. Semantics:

Re: [PATCH] c++: use auto_vec in cp_parser_template_argument_list

2021-11-09 Thread Patrick Palka via Gcc-patches
On Tue, 9 Nov 2021, Jason Merrill wrote: > On 11/9/21 11:02, Patrick Palka wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > OK, though I wonder about using releasing_vec instead of auto_vec; reusing a > previously allocated vec vs. building one on the stack.

Re: [PATCH v1 1/7] LoongArch Port: gcc

2021-11-09 Thread Xi Ruoyao via Gcc-patches
s129806 # of unexpected failures31 # of unexpected successes 4 # of expected failures 831 # of unresolved testcases 2 # of unsupported tests 2234 /home/xry111/gcc-test/gcc-12-larch-v1/build/gcc/xgcc version 12.0.0 20211109 (experimental) (GCC)

[COMMITTED] Keep x_range_query NULL for global ranges.

2021-11-09 Thread Andrew MacLeod via Gcc-patches
On 11/9/21 10:28 AM, Jakub Jelinek wrote: On Tue, Nov 09, 2021 at 10:23:19AM -0500, Andrew MacLeod wrote: yeah, that doesnt work because range_query is a pure virtual. However, there also does not seem to be any reason why we need to jump thru hoops since get_range_query() doesn't need to be in

Re: [PATCH v4 0/1] implement TLS register based stack canary for ARM

2021-11-09 Thread Ard Biesheuvel via Gcc-patches
On Thu, 28 Oct 2021 at 13:27, Ard Biesheuvel wrote: > > Bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102352 > > In the Linux kernel, user processes calling into the kernel are > essentially threads running in the same address space, of a program that > never terminates. This means that

Re: libstdc++: Make atomic::wait() const [PR102994]

2021-11-09 Thread Thomas Rodgers via Gcc-patches
Revised patch attached. On Fri, Nov 5, 2021 at 4:46 PM Jonathan Wakely wrote: > On Fri, 5 Nov 2021 at 21:51, Jonathan Wakely via Libstdc++ > wrote: > > > > OK, thanks. > > Actually, we should really have a test to verify it can be called on a > const object. Please add something when you

[PATCH] Replace gnu::unique_ptr with std::unique_ptr

2021-11-09 Thread Jonathan Wakely via Gcc-patches
Now that GCC is compiled as C++11 there is no need to keep the C++03 implementation of gnu::unique_ptr. This removes the unique-ptr.h header and replaces it with in system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY. Uses of gnu::unique_ptr and gnu::move can be replaced with

Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

2021-11-09 Thread Qing Zhao via Gcc-patches
So, based on the discussion so far, is the following patch good to go? Let me know if you have more comments on the following patch: (At the same time, I am testing this patch on both x86 and aarch64) thanks. Qing diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c index

Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Jason Merrill via Gcc-patches
On 11/9/21 10:55, Marek Polacek wrote: On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: On Tue, 9 Nov 2021 00:12:10 -0500 Jason Merrill wrote: On 11/8/21 20:41, Marek Polacek wrote: On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote: + for (auto opt :

Re: [PATCH] Return NULL for maybe_register_path when unprofitable.

2021-11-09 Thread Jeff Law via Gcc-patches
On 11/9/2021 4:15 AM, Aldy Hernandez wrote: This is a minor cleanup for maybe_register_path to return NULL when the path is unprofitable. It is needed for a follow-up patch to generate better dumps from the threader. There is no change in behavior, since the only call to this function bails

Re: [PATCH] c++: use auto_vec in cp_parser_template_argument_list

2021-11-09 Thread Jason Merrill via Gcc-patches
On 11/9/21 11:02, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? OK, though I wonder about using releasing_vec instead of auto_vec; reusing a previously allocated vec vs. building one on the stack. gcc/cp/ChangeLog: * parser.c

Re: [PATCH] Loop unswitching: support gswitch statements.

2021-11-09 Thread Martin Liška
On 11/9/21 14:37, Richard Biener wrote: On Mon, Nov 8, 2021 at 8:45 PM Andrew MacLeod wrote: On 11/8/21 10:05 AM, Martin Liška wrote: On 9/28/21 22:39, Andrew MacLeod wrote: In Theory, modifying the IL should be fine, it happens already in places, but its not extensively tested under those

Re: [PATCH] Loop unswitching: support gswitch statements.

2021-11-09 Thread Andrew MacLeod via Gcc-patches
On 11/9/21 8:37 AM, Richard Biener wrote: On Mon, Nov 8, 2021 at 8:45 PM Andrew MacLeod wrote: On 11/8/21 10:05 AM, Martin Liška wrote: On 9/28/21 22:39, Andrew MacLeod wrote: In Theory, modifying the IL should be fine, it happens already in places, but its not extensively tested under those

Re: Merge IPA and late local modref flags

2021-11-09 Thread Marek Polacek via Gcc-patches
On Tue, Nov 09, 2021 at 05:32:42PM +0100, Jan Hubicka via Gcc-patches wrote: > > > + } > > > + if (!(flags & EAF_UNUSED)) > > > + lags |= past; > >    ^ > > > > > > Broke bootstrap. > Martin just fixed it. Sorry for that. > Diff complained about 8 spaces instead of tab

Re: Merge IPA and late local modref flags

2021-11-09 Thread Jan Hubicka via Gcc-patches
> > + } > > + if (!(flags & EAF_UNUSED)) > > + lags |= past; >    ^ > > > Broke bootstrap. Martin just fixed it. Sorry for that. Diff complained about 8 spaces instead of tab and I did not rebuild after replacing it bit too overzelaously. Honza > > jeff >

Re: [PATCH] Dump details of an attempt to register a jump threading path.

2021-11-09 Thread Jeff Law via Gcc-patches
On 11/9/2021 4:15 AM, Aldy Hernandez wrote: The goal with these sets of patches is to improve the detailed dumps for the threader, as I hope we eventually reach the point when I'm not the only one looking at these dumps ;-). This patch adds candidate paths to the detailed threading dumps to

Re: Merge IPA and late local modref flags

2021-11-09 Thread Jeff Law via Gcc-patches
On 11/9/2021 9:13 AM, Jan Hubicka via Gcc-patches wrote: Hi, since at the time we compute local solution during late modref the summaries from IPA are readily available (and I added logic to compare them), it is easy to intersect both solutions to get around cases where late optimization

[committed] [PR/target 102957] Allow Z*-ext extension with only 2 char.

2021-11-09 Thread Kito Cheng
We was assume the Z* extension should be more than 2 char, so we put an assertion there, but it should just an error or warning rather than an assertion, however RISC-V has add `Zk` extension, which just 2 char, so actually, we should just allow that. gcc/ChangeLog PR target/102957

Re: [EXTERNAL] Re: [PATCH] PR tree-optimization/102232 Adding a missing pattern to match.pd

2021-11-09 Thread Navid Rahimi via Gcc-patches
Hi Richard, Thank you so much for your detailed feedback. I am attaching another version of the patch which does include all the changes you mentioned. Bellow you can see my response to your feedbacks: > the canonical order of the plus is (plus:s (trunc_div ...) integer_onep) as > constants

Re: [PATH][_GLIBCXX_DEBUG] Fix unordered container merge

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Mon, 8 Nov 2021 at 21:36, François Dumont wrote: > Yet another version this time with only 1 guard implementation. The > predicate to invalidate the safe iterators has been externalized. > > Ok to commit ? > I like this version a lot - thanks for persisting with it. OK to commit, thanks.

Merge IPA and late local modref flags

2021-11-09 Thread Jan Hubicka via Gcc-patches
Hi, since at the time we compute local solution during late modref the summaries from IPA are readily available (and I added logic to compare them), it is easy to intersect both solutions to get around cases where late optimization obstructate code enough so flags are no longer analyzed correctly.

Re: [committed] openmp: Fix up strtoul and strtoull uses in libgomp

2021-11-09 Thread Thomas Schwinge
Hi! On 2021-10-15T16:46:33+0200, Jakub Jelinek via Gcc-patches wrote: > also discovered that the hang was a result of making wrong assumptions > about strtoul/strtoull. (Also 'strtol'.) ;-) > All the uses were for portability setting > errno = 0 before the calls and treating non-zero errno

[PATCH] c++: use auto_vec in cp_parser_template_argument_list

2021-11-09 Thread Patrick Palka via Gcc-patches
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? gcc/cp/ChangeLog: * parser.c (cp_parser_template_argument_list): Use auto_vec instead of manual memory management. --- gcc/cp/parser.c | 35 --- 1 file changed, 8 insertions(+), 27

Re: [PATCH] dwarf: Multi-register CFI address support.

2021-11-09 Thread Jakub Jelinek via Gcc-patches
On Sun, Jun 13, 2021 at 02:27:38PM +0100, Hafiz Abid Qadeer wrote: > *** with this patch (edited for brevity)*** > > 0024 CIE > > DW_CFA_def_cfa_expression: DW_OP_bregx SGPR49+0, DW_OP_const1u 0x20, > DW_OP_shl, DW_OP_bregx SGPR48+0, DW_OP_plus > DW_CFA_expression:

Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Marek Polacek via Gcc-patches
On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote: > On Tue, 9 Nov 2021 00:12:10 -0500 > Jason Merrill wrote: > > > On 11/8/21 20:41, Marek Polacek wrote: > > > On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote: > > > > + for (auto opt : v) > > > +{ > >

Re: [PATCH] Remove dead Fortran function.

2021-11-09 Thread Jeff Law via Gcc-patches
On 11/9/2021 6:59 AM, Martin Liška wrote: Hello. The function was introduced in 2009 in g:cf2b3c22a2cbd7f50db530ca9d2b14c70ba0359d and has never been used since that. Ready to be installed? Thanks, Martin gcc/fortran/ChangeLog: * symbol.c (gfc_get_ultimate_derived_super_type):

Re: [PATCH v1 1/7] LoongArch Port: gcc

2021-11-09 Thread Xi Ruoyao via Gcc-patches
On Tue, 2021-11-09 at 21:53 +0800, Xi Ruoyao via Gcc-patches wrote: > On Mon, 2021-11-08 at 23:14 +, Joseph Myers wrote: > > /* snip */ > > > Please make sure the back end builds cleanly with current GCC mainline.  > > This can be tested either with a native bootstrap, or by building a

Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]

2021-11-09 Thread Marek Polacek via Gcc-patches
On Tue, Nov 09, 2021 at 12:12:10AM -0500, Jason Merrill wrote: > On 11/8/21 20:41, Marek Polacek wrote: > > On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote: > > > On 11/6/21 14:28, Marek Polacek wrote: > > > > On Sat, Nov 06, 2021 at 02:32:26AM +0100, Bernhard Reutner-Fischer > > >

Re: [COMMITTED] Remove TDF_THREADING flag in favor of param.

2021-11-09 Thread Aldy Hernandez via Gcc-patches
On Tue, Nov 9, 2021 at 4:29 PM Andrew MacLeod wrote: > > On 11/9/21 9:39 AM, Martin Liška wrote: > > On 11/9/21 15:36, Aldy Hernandez wrote: > >> I don't see any ordering in these items, so I've placed it next to > >> another of the backward threader knobs. > >> > >> How does this look? > > > >

Re: [COMMITTED] Remove TDF_THREADING flag in favor of param.

2021-11-09 Thread Andrew MacLeod via Gcc-patches
On 11/9/21 9:39 AM, Martin Liška wrote: On 11/9/21 15:36, Aldy Hernandez wrote: I don't see any ordering in these items, so I've placed it next to another of the backward threader knobs. How does this look? That's fine, thanks. Note that similar --param 'ranger-debug' is also documented ;P

Re: [PATCH] pch: Add support for PCH for relocatable executables

2021-11-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Nov 09, 2021 at 10:23:19AM -0500, Andrew MacLeod wrote: > yeah, that doesnt work because range_query is a pure virtual. However, there > also does not seem to be any reason why we need to jump thru hoops since > get_range_query() doesn't need to be in function.h..   If I relocate it to >

Re: [PATCH] pch: Add support for PCH for relocatable executables

2021-11-09 Thread Andrew MacLeod via Gcc-patches
On 11/9/21 9:58 AM, Jakub Jelinek wrote: On Tue, Nov 09, 2021 at 09:41:08AM -0500, Andrew MacLeod wrote: Yeah, Im not particular about how we do this...  I think thats perfectly reasonable.   Would something like the following solve this issue? Yes, but see below. commit

Re: [PATCH, v2, OpenMP 5.0] Implement relaxation of implicit map vs. existing device mappings (for mainline trunk)

2021-11-09 Thread Jakub Jelinek via Gcc-patches
On Sat, Nov 06, 2021 at 12:51:59AM +0800, Chung-Lin Tang wrote: > static int > get_kind (bool short_mapkind, void *kinds, int idx) > { > - return short_mapkind ? ((unsigned short *) kinds)[idx] > -: ((unsigned char *) kinds)[idx]; > + int val = (short_mapkind > +

Re: [committed] libstdc++: Support getentropy and arc4random in std::random_device

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Fri, 5 Nov 2021 at 18:22, Jonathan Wakely wrote: > Oops sorry - this is NOT committed yet. I won't push it until I've tested > it on at least one BSD, preferably OpenBSD so I can test parts of the new > code. > It got tested on darwin, and has been pushed to trunk now. > > > On Fri, 5 Nov

[committed] libstdc++: Make test print which random_device tokens work

2021-11-09 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux, pushed to trunk. libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/random_device/cons/token.cc: Print results of random_device_available checks. --- .../26_numerics/random/random_device/cons/token.cc | 7 +++ 1 file changed, 7 insertions(+)

[committed] libstdc++: Do not use 64-bit DARN on 32-bit powerpc [PR103146]

2021-11-09 Thread Jonathan Wakely via Gcc-patches
Tested powerpc64le-linux, pushed to trunk. We need to use the 64-bit DARN to detect failure without bias, but it's not available in 32-bit mode. libstdc++-v3/ChangeLog: PR libstdc++/103146 * src/c++11/random.cc: Check __powerpc64__ not __powerpc__. ---

Re: [PATCH 14/18] rs6000: Debug support

2021-11-09 Thread Bill Schmidt via Gcc-patches
On 11/5/21 4:34 PM, Segher Boessenkool wrote: > On Wed, Sep 01, 2021 at 11:13:50AM -0500, Bill Schmidt wrote: >> * config/rs6000/rs6000-call.c (rs6000_debug_type): New function. >> (def_builtin): Change debug formatting for easier parsing and >> include more information. >>

RE: [PATCH]middle-end Add an RPO pass after successful vectorization

2021-11-09 Thread Tamar Christina via Gcc-patches
> > + bitmap_set_bit (exit_bbs, single_exit (loop)->dest->index); > > + bitmap_set_bit (exit_bbs, loop->latch->index); > > treating the latch as exit is probably premature optimization (yes, it's > empty). > > > + > > + do_rpo_vn (cfun, loop_preheader_edge (loop), exit_bbs); > >

Re: require et random_device for cons token test

2021-11-09 Thread Jonathan Wakely via Gcc-patches
On Thu, 25 Mar 2021 at 11:38, Jonathan Wakely wrote: > On 25/03/21 08:00 -0300, Alexandre Oliva wrote: > >On Mar 24, 2021, Jonathan Wakely wrote: > > > >> Does vxworks provide any platform-specific source of randomness, like > >> Linux getrandom(2) or BSD arc4random(3) or Windows rand_s? If yes,

Re: [AArch64] Fix TBAA information when lowering NEON loads and stores to gimple

2021-11-09 Thread Richard Sandiford via Gcc-patches
"Andre Vieira (lists)" writes: > And second (also added a test): > > [AArch64] Fix TBAA information when lowering NEON loads and stores to gimple > > This patch fixes the wrong TBAA information when lowering NEON loads and > stores > to gimple that showed up when bootstrapping with UBSAN. > >

Re: [PATCH] pch: Add support for PCH for relocatable executables

2021-11-09 Thread Jakub Jelinek via Gcc-patches
On Tue, Nov 09, 2021 at 09:41:08AM -0500, Andrew MacLeod wrote: > Yeah, Im not particular about how we do this...  I think thats perfectly > reasonable.   Would something like the following solve this issue? Yes, but see below. > commit 17a5b03c95549b5488bc8dd2af4f6e2cc9ddf098 > Author: Andrew

Re: [aarch64] PR102376 - Emit better diagnostic for arch extensions in target attr

2021-11-09 Thread Richard Sandiford via Gcc-patches
Prathamesh Kulkarni writes: > On Thu, 4 Nov 2021 at 14:19, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> > On Wed, 20 Oct 2021 at 15:05, Richard Sandiford >> > wrote: >> >> >> >> Prathamesh Kulkarni writes: >> >> > On Tue, 19 Oct 2021 at 19:58, Richard Sandiford >> >> >

Re: [PATCH] aarch64: [PR101529] Fix vector shuffle insertion expansion

2021-11-09 Thread Richard Sandiford via Gcc-patches
apinski--- via Gcc-patches writes: > From: Andrew Pinski > > The function aarch64_evpc_ins would reuse the target even though > it might be the same register as the two inputs. > Instead of checking to see if we can reuse the target, creating > a new register always is better. > > OK?

[committed] libstdc++: Support getentropy and arc4random in std::random_device

2021-11-09 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux, and Iain Sandoe tested the arc4random code on darwin too. Pushed to trunk. This adds additional "getentropy" and "arc4random" tokens to std::random_device. The former is supported on Glibc and OpenBSD (and apparently wasm), and the latter is supported on various BSDs.

Re: [PATCH] pch: Add support for PCH for relocatable executables

2021-11-09 Thread Andrew MacLeod via Gcc-patches
On 11/9/21 7:29 AM, Jakub Jelinek wrote: On Tue, Nov 09, 2021 at 01:03:38PM +0100, Richard Biener wrote: Apparently the range_of_expr can handle some tree cases through range_query::get_tree_range, like INTEGER_CSTs, ADDR_EXPRs, and some binary and unary ops. But that shouldn't need a range

[committed] libstdc++: Make spurious std::random_device FAIL less likely

2021-11-09 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux, committed to trunk. It's possible that independent reads from /dev/random and /dev/urandom could produce the same value by chance. Retry if that happens. The chances of it happening twice are miniscule. libstdc++-v3/ChangeLog: *

Re: [COMMITTED] Remove TDF_THREADING flag in favor of param.

2021-11-09 Thread Martin Liška
On 11/9/21 15:36, Aldy Hernandez wrote: I don't see any ordering in these items, so I've placed it next to another of the backward threader knobs. How does this look? That's fine, thanks. Note that similar --param 'ranger-debug' is also documented ;P Cheers, Martin

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

2021-11-09 Thread Richard Sandiford via Gcc-patches
apinski--- via Gcc-patches writes: > From: Andrew Pinski > > This fixes fully where SVE types were being used without sve being enabled. > Instead of trying to fix it such that we error out during RTL time, it is > better to error out in front-ends. This expands verify_type_context to > have a

Re: Use 'location_hash' for 'seen_locations' in 'gcc/profile.c:branch_prob' (was: [PATCH] Fix GCOV CFG related issues)

2021-11-09 Thread Martin Liška
On 11/9/21 15:29, Thomas Schwinge wrote: Hi! On 2018-07-25T15:40:24+0200, Martin Liška wrote: --- a/gcc/profile.c +++ b/gcc/profile.c @@ -1256,6 +1256,8 @@ branch_prob (void) /* Initialize the output. */ output_location (NULL, 0, NULL, NULL); + hash_set >

Re: [COMMITTED] Remove TDF_THREADING flag in favor of param.

2021-11-09 Thread Aldy Hernandez via Gcc-patches
On Tue, Nov 9, 2021 at 3:28 PM Martin Liška wrote: > > On 11/9/21 15:22, Aldy Hernandez wrote: > > On Tue, Nov 9, 2021 at 3:10 PM Martin Liška wrote: > >> > >>> +-param=threader-debug= > >> > >> Please document the param in gcc/doc/invoke.texi. > > > > I purposely didn't document it. This is an

  1   2   >