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 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 loo

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

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 because

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

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 th

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] 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 Solari

[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

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

On Tue, 17 Nov 2020, Jiufu Guo wrote: > 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: > >>

Re: [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 e

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

On Tue, 17 Nov 2020, Jan Hubicka wrote: > > 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 unin

Re: [PATCH][RFC] Make mingw-w64 printf/scanf attribute alias to ms_printf/ms_scanf only for C89

On 11/16/20 5:40 AM, Jonathan Yong wrote: On 11/14/20 12:29 PM, Liu Hao via Gcc-patches wrote: This is the third revision of my patch: 1. Two typos in the commit message have been fixed. 2. Support for `%a` and `%A` has been added. Documentation can be     found on the same page in the commit m

[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 pat

[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 vec

[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: 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 g

[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 as

[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. --- gcc/testsuite/

[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: Add a vect_element_align_preferred guard

We don't try to increase the alignment of decls if vect_element_align_preferred. 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/aligned-section-anchors-nest-1.c: XFAIL alignment

[committed] testsuite: Add a vect_load_lanes guard

We still fall back to load/store-lanes for slp-46.c, if the target supports it. 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/slp-46.c: XFAIL test for SLP on vect_load_lanes targets.

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

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 for that, it seemed better to disable optimisation for the testing code. Tested on aarch64-

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

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 on aarch64-linux-gnu (with and without SVE), arm-linux-gnueabihf and x86_64-linux-gnu. O

[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 it'

[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 SVE),

[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 p

[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 onl

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 ex

[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. --- gcc/testsuite/gcc.target/aarch64/sve/

[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 * config/aarch64/

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] 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.

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 tha

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 s

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 for

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 o

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 > a

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 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 a

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: Make ltrans type canonicals compatible with WPA ones

On Tue, 17 Nov 2020, Jan Hubicka wrote: > 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

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. T

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 h

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 som

Re: Make ltrans type canonicals compatible with WPA ones

Hi, thanks! > > So do we want to actually compute alias sets and stream them, > "freeing up" TYPE_CANONICAL again? We're sort-of taking it away I am not sure what you mean by freeing up TYPE_CANONICAL again :) but I was playing with idea of streaming the alias sets from WPA to ltrans. It may sim

Re: [1/3][aarch64] Add aarch64 support for vec_widen_add, vec_widen_sub patterns

Joel Hutton writes: > Tests are still running, but I believe I've addressed the comment. > >> There are ways in which we could reduce the amount of cut-&-paste here, >> but I guess everything is a trade-off between clarity and compactness. >> One extreme is to write them all out explicitly, anothe

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

On 16/11/20 15:25 -0500, Patrick Palka via Libstdc++ wrote: 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 iteratio

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, s

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

Richard Biener writes: > 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

Re: [3/3][aarch64] Add support for vec_widen_shift pattern

Richard Biener writes: > On Fri, 13 Nov 2020, Joel Hutton wrote: > >> Tests are still running, but I believe I've addressed all the comments. >> >> > > +#include >> > > + >> > >> > SVE targets will need a: >> > >> > #pragma GCC target "+nosve" >> > >> > here, since we'll generate different co

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

[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...

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) (LAN

Re: Make ltrans type canonicals compatible with WPA ones

On Tue, 17 Nov 2020, Jan Hubicka wrote: > Hi, > thanks! > > > > So do we want to actually compute alias sets and stream them, > > "freeing up" TYPE_CANONICAL again? We're sort-of taking it away > > I am not sure what you mean by freeing up TYPE_CANONICAL again :) but I > was playing with idea o

preprocessor: Fix profiled bootstrap warning [pr97858]

As Jakub points out, we only ever pass a single variadic parm (if at all), so just an optional arg is fine. PR 97858 libcpp/ * mkdeps.c (munge): Drop varadic args, we only ever use one. pushing to trunk -- Nathan Sidwell diff --git i/libcpp/mkdeps.c w/libcpp/mkdeps.c in

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

On Mon, Nov 16, 2020 at 06:36:17PM -0700, Jeff Law via Gcc-patches wrote: > > > 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 funct

Re: OpenACC 'kernels' testsuite failures

Hi, Thomas The standard version of Tcl installed on AIX currently is Tcl 8.4. I'll see if I can have a newer version on the side. The patch resolves the "no such variable" error message. (Great! Thanks!) I now see: during GIMPLE pass: omplower as an Excess error. Any idea where that comes fr

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

On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote: > 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. >> >> The

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

On 17.11.2020 04:49, Hans-Peter Nilsson wrote: > 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 modernizatio

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

On 17/11/2020 15:18, Bernd Edlinger wrote: > On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote: >> 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

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

On Tue, 17 Nov 2020 at 16:41, Richard Earnshaw (lists) via Gcc-patches wrote: > > On 17/11/2020 15:18, Bernd Edlinger wrote: > > On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote: > >> On 03/11/2020 15:08, Bernd Edlinger wrote: > >>> Hi, > >>> > >>> this fixes a problem with a missing symbol __s

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

On 11/17/20 4:53 AM, Philipp Tomsich wrote: > 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 mailto:p...@gnu.org>> > > > > While most shifts wider than the bitwidth of

[committed] libstdc++: Fix unconditional definition of __cpp_lib_span in [PR 97869}

The header is empty unless Concepts are supported, but defines the __cpp_lib_span feature test macro unconditionally. It should be guarded by the same conditions as in . libstdc++-v3/ChangeLog: PR libstdc++/97869 * include/precompiled/stdc++.h: Include . * include/std/ve

preprocessor: module line maps

This patch adds LC_MODULE as a map kind, used to indicate a c++ module. Unlike a regular source file, it only contains a single location, and the source locations in that module are represented by ordinary locations whose 'included_from' location is the module. It also exposes some entry points

preprocessor: new callbacks

These two callbacks are needed for C++ modules. The first is for handling macros from header-units. These are resolved lazily. The second is for include-translation -- whether a #include gets turned into a header-unit import. libcpp/ * include/cpplib.h (struct cpp_callbacks):

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

On 11/17/20 1:22 AM, FX wrote: >> 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. No worries.  Thanks. jeff

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

Jakub, On Tue, 17 Nov 2020 at 16:56, Jeff Law wrote: > > > > On 11/17/20 4:53 AM, Philipp Tomsich wrote: > > 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 mailto

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

Jeff, On Tue, 17 Nov 2020 at 16:56, Jeff Law wrote: > > Note that in his comment to patch 2/2, Jim has noted that user code for > > RISC-V may assume a truncation of the shift-operand... > What I'd suggest doing would be to leave the invalid shift count in the > IL in VRP, then extend the erroneo

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

On Tue, Nov 17, 2020 at 05:29:57PM +0100, Philipp Tomsich wrote: > > > In other words, the change to VRP canonicalizes what a lshift_expr with an > > > shift-amount outside of the type width means... it doesn't assume anything > > > about the original language. > > > Do we assume that a LSHIFT_EXPR

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

On 11/17/20 9:46 AM, Jakub Jelinek wrote: > On Tue, Nov 17, 2020 at 05:29:57PM +0100, Philipp Tomsich wrote: In other words, the change to VRP canonicalizes what a lshift_expr with an shift-amount outside of the type width means... it doesn't assume anything about the original lan

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

On Tue, Nov 17, 2020 at 09:54:46AM -0700, Jeff Law wrote: > > So, e.g. if we had __builtin_warning (dunno where Martin S. is with that), > > we could e.g. queue a __builtin_warning and add __builtin_unreachable (or > > other possibilities), or e.g. during VRP just canonicalize proven always > > out

[pushed] C++ : Remove an overzealous checking assert [PR97871]

Hi, This amends my commit from r11-4927 to remove an assert. tested on x86_64-darwin, pushed to master Iain --- It seems we accept __attribute__(()) without any diagnostic at present, so my added checking assert fires for something like: __attribute__ (()) int a; Fixed by removing the as

Re: [PATCH] Practical Improvement to libgcc Complex Divide

Joseph, thank you for your detailed review and comments. I will get to work on the necessary revisions as well as find for a suitable place for sharing my random number generating tests. - patrick On 11/16/2020 8:34 PM, Joseph Myers wrote: On Tue, 8 Sep 2020, Patrick McGehearty via Gcc-patches

[PATCH] IOR with nonzero, range cannot contain 0.

PR 83072 mentions that we have lost the ability to recognize that when we see   c |= 1; c cannot be zero.   We can at least put it back for multi-ranges. Added a new testcase to make sure EVRP is tracking it. bootstrapped on x86_64-pc-linux-gnu, no regressions.  pushed. Andrew commit a5f9c27

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

On Mon, Nov 16, 2020 at 2:45 PM Philipp Tomsich wrote: > This is an de-optimization only, if applied without patch 1 from the > series: the change to VRP ensures that the backend will never see a shift > wider than the immediate field. > The problem is that if a negative shift-amount makes it to

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

On Tue, Nov 17, 2020 at 8:46 AM Jakub Jelinek via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > On Tue, Nov 17, 2020 at 05:29:57PM +0100, Philipp Tomsich wrote: > > > > In other words, the change to VRP canonicalizes what a lshift_expr > with an > > > > shift-amount outside of the type width mea

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

On 11/17/20 4:41 PM, Richard Earnshaw (lists) wrote: > > libgcc is *still* the wrong place for this. It belongs in the system > library (eg newlib, or glibc, or whatever), which knows about the system > it's running on. (Sorry, I should have said this before, but I've > context-switched this out

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

Jeff & Jakub, I went back to reread the C language standard and it turns out that the delineation between defined and undefined is not as simple as I thought that I remembered (see below). On Tue, 17 Nov 2020 at 17:54, Jeff Law wrote: > > > On 11/17/20 9:46 AM, Jakub Jelinek wrote: > > On Tue,

[PATCH,rs6000] Make MMA builtins use opaque modes

From: Aaron Sawdey This patch changes powerpc MMA builtins to use the new opaque mode class and use modes OO (32 bytes) and XO (64 bytes) instead of POI/PXI. Using the opaque modes prevents optimization from trying to do anything with vector pair/quad, which was the problem we were seeing with th

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

On Tue, Nov 17, 2020 at 09:14:31AM -0800, Jim Wilson wrote: > On Tue, Nov 17, 2020 at 8:46 AM Jakub Jelinek via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > > > On Tue, Nov 17, 2020 at 05:29:57PM +0100, Philipp Tomsich wrote: > > > > > In other words, the change to VRP canonicalizes what a ls

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

On Tue, Nov 17, 2020 at 06:23:51PM +0100, Philipp Tomsich wrote: > The rules for E1 << E2 are: > - if E2 is negative => undefined > - if E1 is unsigned => E1 x 2^E2, reduced module one more than the > maximum representable value > - if E1 is signed and non-negative => E1 x 2^E2, if E1 x 2^E2

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

On 11/16/20 5:54 PM, Jeff Law wrote: 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 op

[PATCH, rs6000] Re-enable vector pair memcpy/memmove expansion

From: Aaron Sawdey After the MMA opaque mode patch goes in, we can re-enable use of vector pair in the inline expansion of memcpy/memmove. After bootstrap/regtest, OK for trunk? Thanks, Aaron gcc/ * config/rs6000/rs6000.c (rs6000_option_override_internal): Enable vector pai

[PATCH] c++: Allow template lambdas without lambda-declarator [PR97839]

Our implementation of template lambdas incorrectly requires the optional lambda-declarator. This was probably required by an early draft of generic lambdas, but now the production is [expr.prim.lambda.general]: lambda-expression: lambda-introducer lambda-declarator [opt] compound-statement

global trees

This reorders the common and c++ global tree arrays. It introduces a module-specific High Water Mark, below which are the immutable slots initialized at startup and beyond which are the lazily filled slots (and a few immutables we need to locate by name lookup anyway). gcc/c-family/

Re: [gcc r9-8794] aarch64: Clear canary value after stack_protect_test [PR96191]

Sebastian Pop writes: > Hi, > > On Fri, Aug 7, 2020 at 6:18 AM Richard Sandiford wrote: >> >> https://gcc.gnu.org/g:5380912a17ea09a8996720fb62b1a70c16c8f9f2 >> >> commit r9-8794-g5380912a17ea09a8996720fb62b1a70c16c8f9f2 >> Author: Richard Sandiford >> Date: Fri Aug 7 12:17:37 2020 +0100 > > co

[AArch64] Add --with-tune configure flag

Hi, the attached patch fixes a configure error on Arm64 when passing --with-tune=... to configure: ``` This target does not support --with-tune. Valid --with options are: abi cpu arch ``` The missing flag sets target tuning to a different value than the generic tuning. gcc/ * co

Re: [PATCH,rs6000] Make MMA builtins use opaque modes

On 11/17/20 11:48 AM, acsaw...@linux.ibm.com wrote: > -;; The MMA patterns use the multi-register PXImode and POImode partial > +;; The MMA patterns use the multi-register XOmode and OOmode partial > ;; integer modes to implement the target specific __vector_quad and XOmode and OOmode are not par

[PATCH] c++: Fix ICE-on-invalid with -Wvexing-parse [PR97881]

This invalid (?) code broke my assumption that if decl_specifiers->type is null, there must be any type-specifiers. Turn the assert into an if to fix this crash. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/97881 * parser.c (warn_about_am

[r11-5094 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) on Linux/x86_64

On Linux/x86_64, afa6adbd6c83eeef6d75655140f7c0c9a02a479e is the first bad commit commit afa6adbd6c83eeef6d75655140f7c0c9a02a479e Author: Jan Hubicka Date: Tue Nov 17 15:41:06 2020 +0100 Improve handling of memory operands in ipa-icf 3/4 caused FAIL: gcc.c-torture/execute/20020412-1.c

[PATCH] Remove lambdas from _Rb_tree

This is a change that has been done to _Hashtable and that I forgot to propose for _Rb_tree. The _GLIBCXX_XREF macro can be easily removed of course.     libstdc++: _Rb_tree code cleanup, remove lambdas.     Use an additional template parameter on the clone method to propagate if the values m

Re: [r11-5094 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) on Linux/x86_64

Hi, I am testing the following fix. I manually applied a rejected hunk and for some reaosn managed to reverse the conditonal :( Honza * ipa-icf.c (sem_function::hash_stmt): Fix conditional on variably_modified_type_p. diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c index 27eeda3a319..

c++: duplicate block-scope extern [PR 97877]

We ICED with a duplicated block-scope extern, as duplicate_decls was dropping the decl_lang_specific of olddecl. Simplys adding appropriate retrofitting and copying turned out to be insufficient because you can get a block-scope using decl also matching the extern. The latter seems a little suspi

Re: [PATCH 2/3] RISC-V: Support zicsr and zifencei extension for -march.

On Thu, Nov 12, 2020 at 11:29 PM Kito Cheng wrote: > - CSR related instructions and fence instructions has to be splitted from >baseline ISA, zicsr and zifencei are corresponding sub-extension. > It is actually only fence.i that is split off. fence is still part of the base ISA. This is w

Re: [AArch64] Add --with-tune configure flag

Hi, here is a follow-up patch to add missing Arm64 configure flags as aliases to the existing flags. gcc/ * config.gcc: add configure flags --with-{cpu,arch,tune}-{32,64} as alias flags for --with-{cpu,arch,tune} on AArch64. * doc/install.texi: Document new flags for aarc

extend cache_integer_cst

This modules-related patch extends cache_integer_cst. Currently, when given a small cst, that cst is added to the type's small and /must not/ already be there. Large values are fine if they are already in the large cache. This adds a parameter to indicate small duplicates are ok, and it returns

[Patch, Fortran, committed]

Committed to master as obvious. Thanks, Harald Fortran texi: Fix description of GFC_RTCHECK_* macros. gcc/fortran/ChangeLog: * gfortran.texi: Fix description of GFC_RTCHECK_* to match actual code. diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 453b30

Re: [PATCH 3/3] RISC-V: Support version controling for ISA standard extensions

On Thu, Nov 12, 2020 at 11:28 PM Kito Cheng wrote: > +#ifndef HAVE_AS_MARCH_ZIFENCE > + /* Skip since older binutils don't recognize zifencei, > + we mad a mistake that is binutils 2.35 support zicsr but not support > + zifencei. */ > + skip_zifencei = true; > +#endif > I'd suggest so

  1   2   >