Re: CSE deletes valid REG_EQUAL?

On 17/11/20 02:12, Jeff Law wrote: Removing all REG_EQUAL notes for regs that become dead anywhere That's not what it does. seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay, infinite loops, but other than that.) Yea, but the code which wipes the notes probably has no

Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)

Hi! (As discussed before...), in 2020, email doesn't work anymore the way it did years ago... ;-/ (Let's please *not* discuss this here.) So we're now dealing with emails with "From: [...] via Gcc-patches ", etc. ... which occasionally then ends up in Git commit author: On

Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)

On Tue, 17 Nov 2020 at 09:29, Thomas Schwinge wrote: > > Hi! > > (As discussed before...), in 2020, email doesn't work anymore the way it > did years ago... ;-/ (Let's please *not* discuss this here.) > > So we're now dealing with emails with "From: [...] via Gcc-patches > ", etc. > > ... which

Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)

On 11/17/20 2:26 AM, Thomas Schwinge wrote: > Hi! > > (As discussed before...), in 2020, email doesn't work anymore the way it > did years ago... ;-/ (Let's please *not* discuss this here.) > > So we're now dealing with emails with "From: [...] via Gcc-patches > ", etc. > > ... which

The encoding of GCC's stderr

As far as I can tell, GCC's diagnostic output on stderr is a mixture of bytes from various different places in our internal representation: - filenames - format strings from diagnostic messages (potentially translated via .po files) - identifiers - quoted source code - fix-it hints - labels As

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:13 AM Linus Torvalds wrote: > > > +#define __unqual_typeof(type) typeof( (typeof(type))type ) > > that's certainly a much nicer version than the existing pre-processor > expansion from hell. Oh, and sparse doesn't handle this, and doesn't remove any qualifiers for the

Re: The encoding of GCC's stderr

On Tue, Nov 17, 2020 at 12:01 PM David Malcolm via Gcc wrote: > > As far as I can tell, GCC's diagnostic output on stderr is a mixture of > bytes from various different places in our internal representation: > - filenames > - format strings from diagnostic messages (potentially translated via >

Re: The encoding of GCC's stderr

On Tue, 17 Nov 2020, David Malcolm via Gcc wrote: > What is the intended encoding of GCC's stderr? The locale encoding. > - blithely accept and emit filenames as bytes (I don't think we make > any attempt to enforce that they're any particular encoding) File names that aren't in the locale

Re: Re: typeof and operands in named address spaces

On Mon, Nov 16, 2020 at 3:11 AM Peter Zijlstra wrote: > > XXX: I've only verified the below actually compiles, I've not verified > the generated code is actually 'correct'. Well, it was mainly the arm64 code generation for load-acquire and store-release that wanted this - so it's really the

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:13:52AM -0800, Linus Torvalds wrote: > > +#define __unqual_typeof(type) typeof( (typeof(type))type ) > that's certainly a much nicer version than the existing pre-processor > expansion from hell. It would need to be typeof( (typeof(type)) (type) ) to not be that

Re: Git commit "Author: [...] via Gcc-patches " (was: [gcc r11-5068] Update documentation for spec files)

On Tue, 17 Nov 2020, Thomas Schwinge wrote: > Should we have a Git commit hook to catch that (and similar variants)? I've added a check for gcc-patc...@gcc.gnu.org (or libstd...@gcc.gnu.org or fort...@gcc.gnu.org) as author email address in our commit_checker hook (in ~gccadmin/hooks-bin).

Re: The encoding of GCC's stderr

On Tue, 17 Nov 2020, Lewis Hyatt via Gcc wrote: > I also just wanted to ask... in case we have a general system to > always convert diagnostics output to the current locale, would this > make identifier_to_locale() no longer necessary in most cases? That Format strings come from the message

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > It would need to be typeof( (typeof(type)) (type) ) to not be that > constrained on what kind of expressions it accepts as arguments. Yup. > Anyway, it won't work with array types at least, > int a[10]; > typeof ((typeof (a)) (a)) b;

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote: > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > > > It would need to be typeof( (typeof(type)) (type) ) to not be that > > constrained on what kind of expressions it accepts as arguments. > > Yup. > > > Anyway, it won't

Re: Ping(3): [PATCH v4] : Add nitems()

Hi Joseph, On 11/17/20 11:44 PM, Joseph Myers wrote: > I've asked the WG14 reflector why N2529 (and N2530, though that one's not > relevant to this feature) doesn't seem to have made it onto a meeting > agenda yet, when there have been two WG14 meetings since that proposal was > made and a third

Re: Ping(3): [PATCH v4] : Add nitems()

On Tue, 17 Nov 2020, Alejandro Colomar via Libc-alpha wrote: > Nice! > Please update me on any feedback you receive. Apparently the author is planning new versions of those papers so WG14 discussion is waiting for those. > So glibc will basically hold this patch > at least until the WG answers

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 09:10:53PM +, Will Deacon wrote: > On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote: > > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > > > > > It would need to be typeof( (typeof(type)) (type) ) to not be that > > > constrained on what kind of

Ping(3): [PATCH v4] : Add nitems()

Hi, Do you think the patch is ready, or is there anything else I should do before merging it? Thanks, Alex On 9/28/20 9:12 PM, Alejandro Colomar wrote: > 'nitems()' calculates the length of an array in number of items. > It is safe: if a pointer is passed to the macro (or function, in C++), >

Re: Re: typeof and operands in named address spaces

Am Dienstag, den 17.11.2020, 11:31 -0800 schrieb Linus Torvalds: > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > > > It would need to be typeof( (typeof(type)) (type) ) to not be that > > constrained on what kind of expressions it accepts as arguments. > > Yup. > > > Anyway, it

Re: Ping(3): [PATCH v4] : Add nitems()

I've asked the WG14 reflector why N2529 (and N2530, though that one's not relevant to this feature) doesn't seem to have made it onto a meeting agenda yet, when there have been two WG14 meetings since that proposal was made and a third one coming up. -- Joseph S. Myers jos...@codesourcery.com

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

On Tue, Nov 17, 2020 at 09:44:26AM +0100, Jan Hubicka wrote: > > I think for unused functions we don't even gimplify unused functions, the > > cgraph code just throws them away. Even trying just to run the first few > > passes (gimplification up to uninit1) would have several high costs, > Note

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

> On Tue, Nov 17, 2020 at 09:44:26AM +0100, Jan Hubicka wrote: > > > I think for unused functions we don't even gimplify unused functions, the > > > cgraph code just throws them away. Even trying just to run the first few > > > passes (gimplification up to uninit1) would have several high costs,

[PATCH] gcov: Add __gcov_info_to_gdca()

This is a proposal to get the gcda data for a gcda info in a free-standing environment. It is intended to be used with the -fprofile-info-section option. A crude test program which doesn't use a linker script is: #include #include extern const struct gcov_info *my_info; static void

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-11-17 Ever confirmed|0

[Bug tree-optimization/97873] New: Failure to optimize abs optimally (at least one useless instruction on x86)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873 Bug ID: 97873 Summary: Failure to optimize abs optimally (at least one useless instruction on x86) Product: gcc Version: 11.0 Status: UNCONFIRMED Severity:

[Bug rtl-optimization/31799] Failed to optimize out test instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799 Gabriel Ravier changed: What|Removed |Added CC||gabravier at gmail dot com --- Comment

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

> OK. You have commit privs, right? Yes, and I did commit after Richard’s OK: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=034db20e2ea8301b5dc251bf10a97ce1cf90655f … but I forgot to send an email saying I had, sorry. FX

[Bug c/90628] __builtin_mul_overflow writes to const qualified integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2d8b144a2a61b007f59286731275773f6e167be1 commit r11-5077-g2d8b144a2a61b007f59286731275773f6e167be1 Author: Jakub Jelinek Date:

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 Richard Biener changed: What|Removed |Added Component|target |tree-optimization --- Comment #4 from

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

Jiufu Guo writes: > 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: >>> >> .. >>> + >>> + /* Check dominator info before get

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

On Mon, Nov 16, 2020 at 5:10 PM Joseph Myers wrote: > > Ping^3. This patch > is > still pending review (the DFP sNaN followup has been approved). (The > independent C2x patches >

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

> On Tue, Nov 17, 2020 at 01:33:48AM -0500, Jason Merrill via Gcc-patches wrote: > > > > Why doesn't the middle-end warning work for inline functions? > > > > > > It does but only when they're called (and, as usual, also unless > > > the uninitialized use is eliminated). > > > > Yes, but why? I

[Bug target/97682] Miscompiled tail call with -fPIC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:c52868904b784f5a90db6cf347edba81d14cf921 commit r9-9051-gc52868904b784f5a90db6cf347edba81d14cf921 Author: Monk Chiang Date:

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

On Tue, Nov 17, 2020 at 01:33:48AM -0500, Jason Merrill via Gcc-patches wrote: > > > Why doesn't the middle-end warning work for inline functions? > > > > It does but only when they're called (and, as usual, also unless > > the uninitialized use is eliminated). > > Yes, but why? I assume

[Bug target/97682] Miscompiled tail call with -fPIC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97682 Kito Cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 --- Comment #5 from Eric Botcazou --- > We need: > > #include We cannot do that unconditionally because it's also compiled as a C file.

[Bug d/97842] ice compiling dxml

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97842 --- Comment #5 from Iain Buclaw --- (In reply to Alex from comment #4) > Created attachment 49573 [details] > dustmite reduced problem. Your reduction seems to have instead found another segfault. :-)

[PATCH] ada: c++: Get rid of libposix4, librt on Solaris

I recently noticed that neither libposix4 nor librt are needed on Solaris 11 any longer: * libposix4 was renamed to librt in Solaris 7 back in 1998. * librt was folded into libc in the OpenSolaris timeframe, leaving librt only as a filter on libc. Thus, it's no longer needed on either

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805 Eric Botcazou changed: What|Removed |Added Attachment #49555|0 |1 is obsolete|

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #4 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #3) > I didn't have x86 Big Sur until the weekend - still working through things. > > 1/ > > The change you have keeps the default as $wl-undefined

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:9d65095e72502c12903e202cfe2e1fc58140522a commit r9-9052-g9d65095e72502c12903e202cfe2e1fc58140522a Author: Tamar Christina

[PATCH] tree-optimization/97832 - avoid breaking linearization in reassoc

The first reassoc pass is supposed to strictly linearize expressions but re-propagation of negates can break this in case it is faced with (-a + -b) + c which it turns into c - (a + b). The root-cause is swap_ops_for_binary_stmt which prematurely associates two negates together. The following

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #15 from Tamar Christina --- Hmm indeed. I only saw it was doing unsigned arithmetic. I'll patch that one too.

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 Tamar Christina changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

[PATCH 5/5] testsuite: Adjust bb-slp-pr68892.c for AArch64

AArch64 passes the "not profitable" test because it treats vec_construct as having a high-enough cost. This means that we can try other vector modes, which in turn causes "BB vectorization with gaps at the end of a load is not supported" to be printed more than once. The number of times that we

[PATCH 4/5] testsuite: Adjust gcc.dg/vect/slp-21.c for Arm targets

On arm* and aarch64* targets, we can vectorise the second of the main loops using SLP, not just the third. As the comments say, whether this is supported depends on a very specific permutation, so it seemed better to use direct target selectors. Tested on aarch64-linux-gnu (with and without

[Bug tree-optimization/97693] [11 Regression] SVE: ICE in prepare_load_store_mask, at tree-vect-stmts.c since r11-1143-gb05d5563

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97693 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[PATCH]AArch64[GCC-8] Fix overflow in memcopy expansion on aarch64.

Hi All, This a partial backport for 0f801e0b6cc9f67c9a8983127e23161f6025c5b6 which fixes a truncation error for the inline memcopy on AArch64 on GCC-8. Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. Ok for GCC-8? gcc/ChangeLog: PR target/97535 *

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

On 03/11/2020 15:08, Bernd Edlinger wrote: > Hi, > > this fixes a problem with a missing symbol __sync_synchronize > which happens when newlib is used together with libstdc++ for > the non-threaded simulator target arm-none-eabi. > > There are several questions on stackoverflow about this issue.

Re: [PATCH]AArch64[GCC-8] Fix overflow in memcopy expansion on aarch64.

Tamar Christina writes: > Hi All, > > This a partial backport for 0f801e0b6cc9f67c9a8983127e23161f6025c5b6 which > fixes > a truncation error for the inline memcopy on AArch64 on GCC-8. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for GCC-8? OK, thanks. Richard >

Re: [PATCH 1/5] testsuite: Fix vect/vect-sdiv-pow2-1.c

Richard Biener via Gcc-patches writes: > On Tue, Nov 17, 2020 at 12:24 PM Richard Sandiford via Gcc-patches > wrote: >> >> We're now able to vectorise the set-up loop: >> >> int p = power2 (fns[i].po2); >> for (int j = 0; j < N; j++) >> a[j] = ((p << 4) * j) / (N - 1) - (p <<

Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris

Hi Jonathan, There are two more uses of librt left: * On glibc targets before 2.17 it's needed for clock_gettime. I've no idea how long gcc is supposed to support such targets (glibc 2.17 was released in December 2012). >>> >>> RHEL 7 uses glibc 2.17, so it will still be

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #9 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #8) > (In reply to Jürgen Reuter from comment #4) > > It's OK to need it (there are legitimate design reasons to do so) - however > where that need exists, the

langhooks: preprocessor hooks for c++ modules

This is a slightly modified version of 01-langhooks.def. I realized I didn't need the deferred macro langhook -- that can be directly installed into the preprocessor callbacks via preprocess_options lang hook. gcc/ * langhooks-def.h (LANG_HOOKS_PREPROCESS_MAIN_FILE)

[Bug driver/97574] Allow for nul output with Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574 --- Comment #5 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:200c9e865f49255ea32d4891b746d394d156a16f commit r11-5078-g200c9e865f49255ea32d4891b746d394d156a16f Author: Tamar Christina Date:

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #7 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #6) > (In reply to Iain Sandoe from comment #5) > > I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and > > have been looking into other issues. >

[committed] testsuite: Remove XFAIL for variable-length vectors

The XFAIL for variable-length vectors is no longer needed since we can't build the required constant vector and so fall back to fixed-length alternatives. Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf and x86_64-linux-gnu. Pushed as obvious. Richard gcc/testsuite/

[committed] testsuite: Extend vector() regexp

For variable-length vectors, the N inside “vector(N) T” can contain the characters ‘[’, ‘]’ and ‘,’. Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf and x86_64-linux-gnu. Pushed as obvious. Richard gcc/testsuite/ * gcc.dg/vect/pr91750.c: Allow "[]," inside a

[PATCH 3/5] testsuite: Add vect_perm3_int guards

SLP vectorisation of gcc.dg/vect/fast-math-vect-call-1.c involves a group of 3 floats, which requires the same permutation as vect_perm3_int. The load/store_lanes XFAILs in gcc.dg/vect/slp-perm-6.c implicitly assumed vect_perm3_int, which is true for Advanced SIMD but not for VLA SVE. Whether

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #8 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #4) > (In reply to Iain Sandoe from comment #3) > > I didn't have x86 Big Sur until the weekend - still working through things. > > 1/ > > > > The change you have

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

On Mon, Nov 16, 2020 at 7:59 PM Hans-Peter Nilsson wrote: > > 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

[Bug rtl-optimization/31799] Failed to optimize out test instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799 --- Comment #9 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:7f87b4ef2323769bd71f7ccea2aa6017a7376f76 commit r11-5090-g7f87b4ef2323769bd71f7ccea2aa6017a7376f76 Author: H.J. Lu Date: Tue Nov 17

[Bug rtl-optimization/31799] Failed to optimize out test instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[PATCH] x86: Add a testcase for PR target/31799

Add a testcase for PR target/31799 which was fixed by commit 4f0473fe89e68bf7c09542ee5c3684da25a5b435 Author: Uros Bizjak Date: Fri May 12 21:04:05 2017 +0200 compare-elim.c (try_eliminate_compare): Canonicalize operation with embedded compare to [(set (reg:CCM) (compare:CCM...

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #13 from rguenther at suse dot de --- On Tue, 17 Nov 2020, tnfchris at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 > > Tamar Christina changed: > >What|Removed

[committed] testsuite: Adjust vect/bb-slp-subgroups-3.c for VL vectors

Because we disable the cost model, targets with variable-length vectors can end up vectorising the store to a[0..7] on its own. With the cost model we do something sensible. Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf and x86_64-linux-gnu. Pushed as obvious. Richard

[committed] testsuite: Adjust vect/pr65947-8.c for SVE

We can vectorise vect/pr65947-8.c for SVE, as we can for GCN. Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf and x86_64-linux-gnu. Pushed as obvious. Richard gcc/testsuite/ * gcc.dg/vect/pr65947-8.c: Expect the loop to be vectorized for SVE. ---

[committed] testsuite: XFAIL SLP induction tests for VL vectors

We don't yet support SLP inductions for variable-length vectors, so this patch XFAILs some associated tests. (Inductions aren't inherently difficult to support. It just hasn't been done yet.) Tested on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf and x86_64-linux-gnu. Pushed

[committed] testsuite: XFAIL some SLP reduction tests for VLA SVE

For variable-length SVE, we can only use SLP for N scalars of type T if the number of Ts in a vector is a multiple of N. For ints this means that N must be 4 or 2, so this patch XFAILs two tests for N==8. The exact limit seems inherently target-specific -- variable-length vectors with a 256-bit

[Bug tree-optimization/97693] [11 Regression] SVE: ICE in prepare_load_store_mask, at tree-vect-stmts.c since r11-1143-gb05d5563

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97693 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:fcd513df9aa83f30dbd1c34d13c8a0972702ffa1 commit r11-5088-gfcd513df9aa83f30dbd1c34d13c8a0972702ffa1 Author: Richard Sandiford

[committed] aarch64: Remove XFAILs for two SVE tests

These tests started passing a while ago, so remove the XFAILs. Tested on aarch64-linux-gnu, pushed to trunk. Richard gcc/testsuite/ * gcc.target/aarch64/sve/cond_cnot_1.c: Remove XFAIL. * gcc.target/aarch64/sve/cond_unary_1.c: Likewise. ---

Make ltrans type canonicals compatible with WPA ones

Hi, this patch fixes profiledbootstrap failure with LTO enabled. What happens is that alias_ptr_types_compatible_p relies on the fact that alias sets are not refined from WPA to ltrans time: /* This function originally abstracts from simply comparing get_deref_alias_set so that we are

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #16 from CVS Commits --- The releases/gcc-8 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:ff3bb57646fb49090ce84b05bda5003b8f33fc07 commit r8-10626-gff3bb57646fb49090ce84b05bda5003b8f33fc07 Author: Tamar

Re: [PATCH 5/5] testsuite: Adjust bb-slp-pr68892.c for AArch64

On Tue, Nov 17, 2020 at 12:29 PM Richard Sandiford via Gcc-patches wrote: > > AArch64 passes the "not profitable" test because it treats vec_construct > as having a high-enough cost. This means that we can try other vector > modes, which in turn causes "BB vectorization with gaps at the end of >

Re: [PATCH] Add MODE_OPAQUE

acsaw...@linux.ibm.com writes: > 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

Re: [PATCH 4/5] testsuite: Adjust gcc.dg/vect/slp-21.c for Arm targets

On Tue, Nov 17, 2020 at 12:29 PM Richard Sandiford via Gcc-patches wrote: > > On arm* and aarch64* targets, we can vectorise the second of the main > loops using SLP, not just the third. As the comments say, whether this > is supported depends on a very specific permutation, so it seemed better

Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris

On 17/11/20 10:47 +0100, Rainer Orth wrote: I recently noticed that neither libposix4 nor librt are needed on Solaris 11 any longer: * libposix4 was renamed to librt in Solaris 7 back in 1998. * librt was folded into libc in the OpenSolaris timeframe, leaving librt only as a filter on libc.

[Bug fortran/97589] Segementation fault when allocating coarrays.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 --- Comment #17 from Thomas Koenig --- A bit more reduced (no derived types necessary): program random_weather implicit none real, allocatable :: ps(:,:) [:,:] integer :: nxslab, nyslab integer :: npx integer :: i, j real,

Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris

On 17/11/20 14:25 +0100, Rainer Orth wrote: Hi Jonathan, There are two more uses of librt left: * On glibc targets before 2.17 it's needed for clock_gettime. I've no idea how long gcc is supposed to support such targets (glibc 2.17 was released in December 2012). RHEL 7 uses glibc 2.17,

[Bug libstdc++/97869] defines __cpp_lib_span even when doesn't provide an implementation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97869 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 --- Comment #5 from Richard Biener --- OK, so I have a patch to keep the association linear which IMHO is good. It fixes the smaller and my testcase but not the original one which now is linear but still not homogenous. The store groups are as

[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #38 from Levy --- Created attachment 49575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49575=edit riscv-shorten-memrefs_V1.patch Did little bit change in get_si_mem_base_reg() and transform() Now for the same c input

[Bug tree-optimization/97717] compilation with -O(1/2/3) flag failed while -O0 succeeds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97717 --- Comment #3 from Rahul Kranti Kiran --- The stack size was 8 KB and 'ulimit -s unlimited' worked for root but gets reset as soon as I got back to the userspace. Running the compilation with unlimited stack still threw a SEGFAULT. The

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #5 from Iain Sandoe --- I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and have been looking into other issues. Note that the libgfortran directory throws up a lot of warnings when 'autoreconf'ed' so maybe

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

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

Jeff, On Tue, 17 Nov 2020 at 00:38, Jeff Law wrote: > > 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

[committed] PR97693: Specify required vectype in vectorizable_call

The vectorizable_call part of r11-1143 dropped the required vectype when moving from vect_get_vec_def_for_operand to vect_get_vec_defs_for_operand. This caused an ICE on the testcase for SVE, because we ended up with a non-predicate value being passed to a predicate input. AFAICT this was the

c-family: token streamer

This is broken out of modules patch 01-langhooks.diff, I realized that this part is independent, and removes some duplicated code -- migrated to the token_streamer class. gcc/c-family/ * c-ppoutput.c (scan_translation_unit): Use token_streamer, remove code duplicating

Re: [PATCH] ada: c++: Get rid of libposix4, librt on Solaris

Hi Jonathan, >>There are two more uses of librt left: >> >>* On glibc targets before 2.17 it's needed for clock_gettime. I've no >> idea how long gcc is supposed to support such targets (glibc 2.17 was >> released in December 2012). > > RHEL 7 uses glibc 2.17, so it will still be in use for

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115 --- Comment #8 from Jonathan Wakely --- Thanks for starting the discussion there.

[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857 --- Comment #13 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:18dd295638724b455e072cd790451ace15a3d463 commit r11-5093-g18dd295638724b455e072cd790451ace15a3d463 Author: Jan Hubicka Date: Tue

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #6 from Andrew Pinski --- (In reply to luoxhu from comment #4) > float foo(float f, float x, float y) { > return (fabs(f)*x+y); > } > > the input of fabs is float type, so use fabsf is enough here, drafted a > patch to avoid double

[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:886964a78aa89ef3c15e69a7b4b96c55d51ea812 commit r10-9034-g886964a78aa89ef3c15e69a7b4b96c55d51ea812 Author: Tamar

[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #6 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #5) > I bootstrapped several times (without using MACOSX_DEPLOYMENT_TARGET) and > have been looking into other issues. > > Note that the libgfortran directory throws up

Re: [PATCH 3/5] testsuite: Add vect_perm3_int guards

On Tue, Nov 17, 2020 at 12:25 PM Richard Sandiford via Gcc-patches wrote: > > SLP vectorisation of gcc.dg/vect/fast-math-vect-call-1.c involves > a group of 3 floats, which requires the same permutation as > vect_perm3_int. > > The load/store_lanes XFAILs in gcc.dg/vect/slp-perm-6.c implicitly >

Re: [PATCH 1/5] testsuite: Fix vect/vect-sdiv-pow2-1.c

On Tue, Nov 17, 2020 at 12:24 PM Richard Sandiford via Gcc-patches wrote: > > We're now able to vectorise the set-up loop: > > int p = power2 (fns[i].po2); > for (int j = 0; j < N; j++) > a[j] = ((p << 4) * j) / (N - 1) - (p << 5); > > Rather than adjust the expected output

Re: [PATCH 2/5] testsuite: Add a vect_partial_vectors_usage_2 guard

On Tue, Nov 17, 2020 at 12:24 PM Richard Sandiford via Gcc-patches wrote: > > We don't need an epilogue loop if the main loop can operate on > partial vectors, so this patch disables an associated test. > The alternative would be to force partial-vectors-usage=1 > on the command line. > > Tested

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 Dan Horák changed: What|Removed |Added CC||dan at danny dot cz --- Comment #12 from

[Bug rtl-optimization/31799] Failed to optimize out test instruction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31799 --- Comment #8 from H.J. Lu --- It is fixed by r8-647.

  1   2   3   4   >