Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On 3/11/20 6:28 PM, Jakub Jelinek wrote: On Wed, Mar 11, 2020 at 04:02:51PM -0400, Jason Merrill via Gcc-patches wrote: We should certainly avoid copying if they're the same. The code above for only copying the bits that aren't going to be thrown away seems pretty straightforward, might as

[PATCH] libstdc++: Fix the return type of __cxa_finalize according to the Itanium C++ ABI

Alternatively, we can delete it, because no user code should call it. It may be weird that libc is expected to define this function. This function is a language runtime interface that has nothing to do with a libc. --- libstdc++-v3/libsupc++/cxxabi.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [testsuite] Fix PR93935 to guard case under vect_hw_misalign

On Wed, 2020-03-11 at 14:22 +0800, Kewen.Lin via Gcc-patches wrote: > Hi, > > Gentle ping this patch, also request to backport to gcc9 after some burn-in > time. > > BR, > Kewen > > on 2020/2/26 下午2:17, Kewen.Lin wrote: > > Hi, > > > > This patch is to apply the same fix as r267528 to another

Re: [PATCH 6/6] i386: Use ix86_output_ssemov for MMX TYPE_SSEMOV

On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote: > There is no need to set mode attribute to XImode since ix86_output_ssemov > can properly encode xmm16-xmm31 registers with and without AVX512VL. > > Remove ext_sse_reg_operand since it is no longer needed. > > PR target/89229 > *

Re: [PATCH 5/6] i386: Use ix86_output_ssemov for SFmode TYPE_SSEMOV

On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote: > There is no need to set mode attribute to V16SFmode since ix86_output_ssemov > can properly encode xmm16-xmm31 registers with and without AVX512VL. > > gcc/ > > PR target/89229 > * config/i386/i386.c (ix86_output_ssemov): Handle

Re: [PATCH 4/6] i386: Use ix86_output_ssemov for DFmode TYPE_SSEMOV

On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote: > There is no need to set mode attribute to XImode nor V8DFmode since > ix86_output_ssemov can properly encode xmm16-xmm31 registers with and > without AVX512VL. > > gcc/ > > PR target/89229 > * config/i386/i386.c

Re: [PATCH 3/6] i386: Use ix86_output_ssemov for SImode TYPE_SSEMOV

On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote: > There is no need to set mode attribute to XImode since ix86_output_ssemov > can properly encode xmm16-xmm31 registers with and without AVX512VL. > > gcc/ > > PR target/89229 > * config/i386/i386.c (ix86_output_ssemov): Handle

Re: [PATCH 2/6] i386: Use ix86_output_ssemov for DImode TYPE_SSEMOV

On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote: > There is no need to set mode attribute to XImode since ix86_output_ssemov > can properly encode xmm16-xmm31 registers with and without AVX512VL. > > gcc/ > > PR target/89229 > * config/i386/i386.c (ix86_output_ssemov): Handle

Re: [PATCH] Add myself to MAINTAINERS

Hi, On 2020/3/12 上午10:19, Bin Bin Lv wrote: Hi, This adds myself to MAINTAINERS in the Write After Approval section. gcc/ChangeLog 2020-03-11 Bin Bin Lv * MAINTAINERS (Write After Approval): Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git

Re: Fix modulo-scheduler -fcompare-debug issues

On Tue, 2020-03-10 at 19:39 +0300, Roman Zhuykov wrote: > Hi! > > Current modulo-sched implementation is a bit faulty from -fcompile-debug > perspective. > > I found that few years ago, the most simple example is pr42631.c which fails > (with just -fmodulo-sched or together with

Re: [testsuite] Add @ lines to check-function-bodies fluff

On Tue, 2020-03-10 at 17:22 +, Matthew Malcomson wrote: > When using `check-function-bodies`, the subroutine `parse_function_bodies` > uses > the `fluff` regexp to remove uninteresting assembly lines. > > Arm targets generate assembly with some lines prefixed by `@`, these lines are > left

Re: Remove redundant zero extend

On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote: > This patch is a code density oriented and attempt to remove redundant > sign/zero > extension from assignment statement. > The approach taken is to use VRP data while expanding the assignment to RTL to > determine whether a

Re: [PATCH] [rs6000] Fix a wrong GC issue

Hi, On 2020/3/10 上午10:30, binbin wrote: Hi, On 2020/3/9 下午10:32, Segher Boessenkool wrote: Hi! On Mon, Mar 09, 2020 at 01:58:01PM +0800, binbin wrote: 2020-03-09  Bin Bin Lv  * config/rs6000/rs6000-internal.h (altivec_builtin_mask_for_load,

[RS6000] make PLT loads volatile

With lazy PLT resolution the first load of a PLT entry may be a value pointing at a resolver stub. gcc's loop processing can result in the PLT load in inline PLT calls being hoisted out of a loop in the mistaken idea that this is an optimisation. It isn't. If the value hoisted was that for a

[PATCH] Add myself to MAINTAINERS

Hi, This adds myself to MAINTAINERS in the Write After Approval section. gcc/ChangeLog 2020-03-11 Bin Bin Lv * MAINTAINERS (Write After Approval): Add myself. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index be80166..56574fb1

[PATCH v3 2/2] generate EH info for all asm statements (PR93981)

This patch extends the generation of exception handling information to cover all asm statements, when -fnon-call-exceptions is given. The previous patch only enabled this for volatile asms. The previously added test cases are adjusted to cover this change. gcc/ 2020-03-11 Jan W. Jagersma

[PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

The following patch extends the generation of exception handling information, so that it is possible to catch exceptions thrown from volatile asm statements, when -fnon-call-exceptions is enabled. Parts of the gcc code already suggested this should be possible, but it was never fully implemented.

[PATCH v3 0/2] generate EH info for asm statements (PR93981)

As there were no more comments in the previous thread, I am submitting a new revision of this patch. The patch is split up in two parts now. The first covers only volatile asms and is mostly identical to the last revision. There are no code changes, only the test cases and documentation are

[committed] testsuite: Fix concepts-using2.C failure on 32-bit targets [PR93907]

Hi! The test FAILs on 32-bit targets that don't have __int128 type. Fixed thusly, regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2020-03-12 Jakub Jelinek PR c++/93907 * g++.dg/cpp2a/concepts-using2.C (cc): Use long long instead of __int128

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On Wed, Mar 11, 2020 at 11:28:01PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Wed, Mar 11, 2020 at 04:02:51PM -0400, Jason Merrill via Gcc-patches wrote: > > We should certainly avoid copying if they're the same. The code above for > > only copying the bits that aren't going to be thrown

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On Wed, Mar 11, 2020 at 04:02:51PM -0400, Jason Merrill via Gcc-patches wrote: > We should certainly avoid copying if they're the same. The code above for > only copying the bits that aren't going to be thrown away seems pretty > straightforward, might as well use it even if the savings aren't

Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures

On Wed, 11 Mar 2020, Jason Merrill wrote: > On 3/9/20 6:23 PM, Patrick Palka wrote: > > This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend > > which controls how deeply we replay errors when diagnosing a constraint > > satisfaction failure. The default is

Re: [PATCH,rs6000] Add command line and builtin compatibility

On Wed, Mar 11, 2020 at 02:12:59PM -0500, Bill Schmidt wrote: > >+ error ("%s is incompatible with mno-fprnd option", > > I believe you need %qs here.  Also replace mno-fprnd with %qs and put > "-mno-fprnd" as the associated parameter. > > Example from nearby code:   error ("%qs requires

Re: [PATCH,rs6000] Add command line and builtin compatibility

Hi! On Wed, Mar 11, 2020 at 12:00:12PM -0700, Carl Love wrote: > The following patch add a check to make sure the user did not specify > -mno_fprnd with the builtins __builtin_vsx_xsrdpim and > __builtin_vsx_xsrdpip. These builtins are incompatible with the > -mno_fprnd command line. The

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/11/20 2:10 PM, Jason Merrill wrote: On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: On 3/9/20 1:40 PM, Jason Merrill wrote: On 3/9/20 12:31 PM, Martin Sebor wrote: On 2/28/20 1:24 PM, Jason Merrill wrote: On

[pushed] c++: Fix ICE with concepts and aliases [PR93907].

The problem here was that we were checking satisfaction once with 'e', a typedef of 'void', and another time with 'void' directly, and treated them as different for hashing based on the assumption that canonicalize_type_argument would have already removed a typedef that wasn't a complex dependent

Re: [PATCH 1/2] c++: Replay errors during diagnosis of constraint satisfaction failures

On 3/9/20 6:23 PM, Patrick Palka wrote: This patch adds a new flag -fconcepts-diagnostics-depth to the C++ frontend which controls how deeply we replay errors when diagnosing a constraint satisfaction failure. The default is -fconcepts-diagnostics-depth=1 which diagnoses only the topmost

Re: [PATCH v2] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

On Wed, Mar 11, 2020 at 04:17:02PM -0400, Jason Merrill via Gcc-patches wrote: > On 3/11/20 1:59 PM, Marek Polacek wrote: > > On Tue, Mar 10, 2020 at 03:46:03PM -0400, Jason Merrill wrote: > > > On 3/9/20 4:34 PM, Marek Polacek wrote: > > > > On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek

Re: [PATCH v2] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

On 3/11/20 1:59 PM, Marek Polacek wrote: On Tue, Mar 10, 2020 at 03:46:03PM -0400, Jason Merrill wrote: On 3/9/20 4:34 PM, Marek Polacek wrote: On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote: On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote: On 3/9/20 9:40 AM,

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/11/20 12:57 PM, Martin Sebor wrote: On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: On 3/9/20 1:40 PM, Jason Merrill wrote: On 3/9/20 12:31 PM, Martin Sebor wrote: On 2/28/20 1:24 PM, Jason Merrill wrote: On 2/28/20 12:45 PM, Martin Sebor wrote: On

Re: [PATCH,rs6000] Add command line and builtin compatibility

Bill: On Wed, 2020-03-11 at 14:12 -0500, Bill Schmidt wrote: > I believe you need %qs here. Also replace mno-fprnd with %qs and > put > "-mno-fprnd" as the associated parameter. > > Example from nearby code: error ("%qs requires %qs", "-mdirect- > move", > "-mvsx"); Yes. I had originally

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On 3/11/20 11:44 AM, Marek Polacek wrote: On Wed, Mar 11, 2020 at 07:52:15AM +0100, Jakub Jelinek via Gcc-patches wrote: On Tue, Mar 10, 2020 at 07:38:17PM -0400, Marek Polacek via Gcc-patches wrote: --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -6062,6 +6062,13 @@ reshape_init_array_1 (tree

Re: [PATCH,rs6000] Add command line and builtin compatibility

On 3/11/20 2:00 PM, Carl Love wrote: GCC maintianers: The following patch add a check to make sure the user did not specify -mno_fprnd with the builtins __builtin_vsx_xsrdpim and __builtin_vsx_xsrdpip. These builtins are incompatible with the -mno_fprnd command line. The check prevents GCC

[PATCH,rs6000] Add command line and builtin compatibility

GCC maintianers: The following patch add a check to make sure the user did not specify -mno_fprnd with the builtins __builtin_vsx_xsrdpim and __builtin_vsx_xsrdpip. These builtins are incompatible with the -mno_fprnd command line. The check prevents GCC crashing under these conditions.

Re: [GCC][Patch]Bug fix: cannot convert 'const short int*' to 'const __bf16*'

On 3/11/20 5:59 PM, Kyrill Tkachov wrote: Hi Delia, On 3/11/20 5:49 PM, Delia Burduv wrote: This patch fixes a bug introduced by my earlier patch ( https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541680.html ). It introduces a new scalar builtin type that was missing in the original

Re: [GCC][Patch]Bug fix: cannot convert 'const short int*' to 'const __bf16*'

Hi Delia, On 3/11/20 5:49 PM, Delia Burduv wrote: This patch fixes a bug introduced by my earlier patch ( https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541680.html ). It introduces a new scalar builtin type that was missing in the original patch. Bootstrapped cleanly on

Re: [PATCH v2] c++: Fix wrong modifying const object error for COMPONENT_REF [PR94074]

On Tue, Mar 10, 2020 at 03:46:03PM -0400, Jason Merrill wrote: > On 3/9/20 4:34 PM, Marek Polacek wrote: > > On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote: > > > On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote: > > > > On 3/9/20 9:40 AM, Marek Polacek wrote: > > > > >

[GCC][Patch]Bug fix: cannot convert 'const short int*' to 'const __bf16*'

This patch fixes a bug introduced by my earlier patch ( https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541680.html ). It introduces a new scalar builtin type that was missing in the original patch. Bootstrapped cleanly on arm-none-linux-gnueabihf. Tested for regression on

Re: [PATCH] pdp11: Fix handling of common (local and global) vars [PR94134]

Ok, thanks. paul > On Mar 11, 2020, at 1:12 PM, Jakub Jelinek wrote: > > Hi! > > As mentioned in the PR, the generic code decides to put the a variable into > lcomm_section, which is a NOSWITCH section and thus the generic code doesn't > switch into a particular section before using

[PATCH] pdp11: Fix handling of common (local and global) vars [PR94134]

Hi! As mentioned in the PR, the generic code decides to put the a variable into lcomm_section, which is a NOSWITCH section and thus the generic code doesn't switch into a particular section before using ASM_OUTPUT{_ALIGNED{,_DECL}_}_LOCAL, on many targets that results just in .lcomm (or for

[committed] RISC-V: Fix testsuite regression due to recent IRA changes.

100644 --- a/gcc/testsuite/ChangeLog +++ b/gcc/testsuite/ChangeLog @@ -1,3 +1,7 @@ +2020-03-11 Kito Cheng + + * gcc.target/riscv/interrupt-2.c: Update testcase and expected output. + 2020-03-11 Richard Biener * gcc.dg/torture/20200311-1.c: New testcase. diff --git a/gcc

Re: [PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

On 3/9/20 6:08 PM, Jason Merrill wrote: On 3/9/20 5:39 PM, Martin Sebor wrote: On 3/9/20 1:40 PM, Jason Merrill wrote: On 3/9/20 12:31 PM, Martin Sebor wrote: On 2/28/20 1:24 PM, Jason Merrill wrote: On 2/28/20 12:45 PM, Martin Sebor wrote: On 2/28/20 9:58 AM, Jason Merrill wrote: On

Re: [GCC][PATCH][AArch64] ACLE intrinsics for BFCVTN, BFCVTN2 (AArch64 AdvSIMD) and BFCVT (AArch64 FP)

Vasee Vinayagamoorthy writes: > Hi, > > I think this commit causes a failure on aarch64-none-elf due to a DejaGnu > typo in gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c. > > { dg-final { check-function-bodies "**" "" "-O[^0]" } } > > I think the square brackets need to be escaped or use

Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins

On 11/03/2020 13:53, Richard Earnshaw (lists) wrote: > On 11/03/2020 13:50, Szabolcs Nagy wrote: >> On 10/03/2020 09:55, Andrea Corallo wrote: >>> Hi all, >>> >>> second and last patch of the two reworking FPCR and FPSR builtins. >>> >>> This rework __builtin_aarch64_set_fpcr (unsigned) and >>>

Re: [PATCH] libstdc++: Add a test that takes the split_view of a non-forward range

On 11/03/20 11:46 -0400, Patrick Palka wrote: This adds a tests that verifies taking the split_view of a non-forward range works correctly. Doing so revealed a typo in one of _OuterIter's constructors. Oops! It also revealed that the default constructor of __gnu_test::test_range::iterator

Re: [PATCH] Prevent IPA-SRA from creating calls to local comdats (PR 92676)

Hello, ping. Thanks, Martin On Mon, Dec 16 2019, Martin Jambor wrote: > Hi, > > since r278669 (fix for PR ipa/91956), IPA-SRA makes sure that the clone > it creates is put into the same same_comdat as the original cgraph_node, > so that it can call private comdats (such as the ipa-split bits

[PATCH] libstdc++: Add a test that takes the split_view of a non-forward range

This adds a tests that verifies taking the split_view of a non-forward range works correctly. Doing so revealed a typo in one of _OuterIter's constructors. It also revealed that the default constructor of __gnu_test::test_range::iterator misbehaves, because by delegating to Iter(nullptr,

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On Wed, Mar 11, 2020 at 07:52:15AM +0100, Jakub Jelinek via Gcc-patches wrote: > On Tue, Mar 10, 2020 at 07:38:17PM -0400, Marek Polacek via Gcc-patches wrote: > > --- a/gcc/cp/decl.c > > +++ b/gcc/cp/decl.c > > @@ -6062,6 +6062,13 @@ reshape_init_array_1 (tree elt_type, tree max_index, > >

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

‐‐‐ Original Message ‐‐‐ On Sunday, February 16, 2020 7:06 PM, Segher Boessenkool wrote: > On Sat, Feb 15, 2020 at 05:22:09PM +, GT wrote: > > I have not been able to configure protonmail for either git imap-send or > > send-email. > > Do you use git format-patch? You should, as

Re: ODR violation in ranges

On 3/11/20 11:23 AM, Jason Merrill wrote: On Wed, Mar 11, 2020 at 11:05 AM Nathan Sidwell > wrote: On 3/11/20 6:56 AM, Tam S. B. wrote: > IIUC using lambda in inline variable initializer is not ODR violation. This is covered in CWG 2300 (

Re: ODR violation in ranges

On Wed, Mar 11, 2020 at 11:05 AM Nathan Sidwell wrote: > On 3/11/20 6:56 AM, Tam S. B. wrote: > > IIUC using lambda in inline variable initializer is not ODR violation. > This is covered in CWG 2300 ( > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1510r0.html#2300 > ). > > ah, thanks

Re: ODR violation in ranges

On 3/11/20 6:56 AM, Tam S. B. wrote: IIUC using lambda in inline variable initializer is not ODR violation. This is covered in CWG 2300 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1510r0.html#2300 ). ah, thanks for the pointer. For lambdas in function scope we do achieve

[PATCH] fold-undefined-pointer-offsetting

New pattern. * gcc.dg/torture/20200311-1.c: New testcase. --- gcc/match.pd | 9 + gcc/testsuite/gcc.dg/torture/20200311-1.c | 26 ++ 2 files changed, 35 insertions(+) create mode 100644 gcc/testsuite/gcc.dg/torture/202003

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, 11 Mar 2020, Martin Liška wrote: > > Is there a comprehensive list of plugins out in the wild using the LD > > plugin API? > > I know only about: > $ ls /usr/lib/bfd-plugins > liblto_plugin.so.0.0.0 LLVMgold.so > > and I know about Alexander Monakov (some dead code elimination

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On 3/11/20 1:51 PM, Richard Biener wrote: Splitting an existing field isn't hackish IMHO. I guess even explicitely changing it to one short and two char fields would be OK. Good, I'm doing that in the updated version of that patch. H.J. is right now working on the corresponding binutils

Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins

On 11/03/2020 13:50, Szabolcs Nagy wrote: On 10/03/2020 09:55, Andrea Corallo wrote: Hi all, second and last patch of the two reworking FPCR and FPSR builtins. This rework __builtin_aarch64_set_fpcr (unsigned) and __builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences as:

Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins

On 10/03/2020 09:55, Andrea Corallo wrote: > Hi all, > > second and last patch of the two reworking FPCR and FPSR builtins. > > This rework __builtin_aarch64_set_fpcr (unsigned) and > __builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences > as: > > mrs x1, fpsr >

RE: Remove redundant zero extend

Attaching the correct patch. diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index 9864e4344d2..c3739b2f331 100644 --- a/gcc/cfgexpand.c +++ b/gcc/cfgexpand.c @@ -17,6 +17,7 @@ You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see

[C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

Fortran patch: https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html Like for Fortran, it also fixes some other issues – here for C++ related to namespaces. (For class, see PR c++/94140.) Test case of the PR yields an ICE in the middle end and the namespace tests an ICE in cc1plus.

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On 3/11/20 2:24 PM, H.J. Lu wrote: ld-new don't have to use the new interface since it isn't needed. Yeah. We talk about nm that should utilize the new API, right? Martin

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 6:09 AM Martin Liška wrote: > > On 3/11/20 1:51 PM, Richard Biener wrote: > > I'm not sure I understand the versioning, we should aim at something where > > an updated plugin can talk to old and new ld and where a new ld can also > > talk > > to an old plugin. That

Re: ODR violation in ranges

On Wed, 11 Mar 2020, Tam S. B. via Gcc-patches wrote: > IIUC using lambda in inline variable initializer is not ODR violation. This > is covered in CWG 2300 ( > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1510r0.html#2300 ). > > > From:

Re: Ping: [PATCH] wwwdocs: Document support for extended identifiers added to GCC 10

Great, thank you very much for taking a look at it. Sorry if this email is unnecessary noise, but it wasn't quite clear to me whether this should also still be approved from a content perspective? I didn't want to assume. Thanks! -Lewis On Sat, Mar 7, 2020 at 6:23 PM Gerald Pfeifer wrote: > >

Re: Remove redundant zero extend

On Wed, 2020-03-11 at 13:04 +, Nidal Faour via Gcc-patches wrote: [...] > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog > index f91af78a302..c5a701e08af 100644 > --- a/gcc/testsuite/ChangeLog > +++ b/gcc/testsuite/ChangeLog > @@ -1,3 +1,7 @@ > +2020-02-19 Nidal Faour > +

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On 3/11/20 1:51 PM, Richard Biener wrote: I'm not sure I understand the versioning, we should aim at something where an updated plugin can talk to old and new ld and where a new ld can also talk to an old plugin. That requires an arbitration which I don't see implemented? So ld-new will set

Remove redundant zero extend

This patch is a code density oriented and attempt to remove redundant sign/zero extension from assignment statement. The approach taken is to use VRP data while expanding the assignment to RTL to determine whether a sign/zero extension is necessary. Thought the motivation of the patch is code

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote: Hello. Thank you for the patch. You haven't received a review because we are right now in stage4 of the development cycle: https://gcc.gnu.org/develop.html#stage4 Anyway, I'm going to provide a review (even though I'm not maintainer of

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 1:22 PM Martin Liška wrote: > > On 3/11/20 11:22 AM, Richard Biener wrote: > > On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: > >> > >> On 3/10/20 1:07 PM, Martin Liška wrote: > >>> On 3/10/20 12:24 PM, Richard Biener wrote: > Not sure how symtab is encoded

Re: ODR violation in ranges

On 11/03/20 10:56 +, Tam S. B. via Libstdc++ wrote: IIUC using lambda in inline variable initializer is not ODR violation. This is covered in CWG 2300 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1510r0.html#2300 ). Ah yes, I think somebody (probably Patrick) has pointed

RE: [PATCHv2] Ada: gcc-interface: fixed assertion for aliased entities

> -Original Message- > From: Eric Botcazou > Sent: March 11, 2020 6:16 AM > To: Richard Wai > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCHv2] Ada: gcc-interface: fixed assertion for aliased entities > > > Thanks for the analysis and the fix. This has indeed apparently never

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On 3/11/20 11:22 AM, Richard Biener wrote: On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: On 3/10/20 1:07 PM, Martin Liška wrote: On 3/10/20 12:24 PM, Richard Biener wrote: Not sure how symtab is encoded right now but we also could have Ok, right now I don't see symtab entry much

Re: [testsuite] Add @ lines to check-function-bodies fluff

Matthew Malcomson writes: > When using `check-function-bodies`, the subroutine `parse_function_bodies` > uses > the `fluff` regexp to remove uninteresting assembly lines. > > Arm targets generate assembly with some lines prefixed by `@`, these lines are > left by this process. > > As an example

[PATCH v4][ARM][GCC][2/x]: MVE ACLE intrinsics framework patch.

Hello Kyrill, This patch addresses all the comments in patch version v2. (version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540416.html Please ignore version v3. (version v3) https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541783.html ### Hello, This patch is part of MVE

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 11:22 AM Richard Biener wrote: > > On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: > > > > On 3/10/20 1:07 PM, Martin Liška wrote: > > > On 3/10/20 12:24 PM, Richard Biener wrote: > > >> Not sure how symtab is encoded right now but we also could have > > > > > > Ok,

Re: [patch] Fix middle-end/93961

> OK. Note I wondered for some time whether we can pre-compute (and LTO > stream) whether a type is variably modified during type layout? During type layout seems a little early, the end of gimplification would seem more natural since we have a workaround in RETURN_TRUE_IF_VAR: /* Test if T is

Re: ODR violation in ranges

On 11/03/20 06:08 -0400, Nathan Sidwell wrote: Jonathan, the ranges header contains code like: inline constexpr __adaptor::_RangeAdaptorClosure all = [] (_Range&& __r) { if constexpr (view>) return std::forward<_Range>(__r); else if constexpr (requires {

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On Wed, Mar 11, 2020 at 10:19 AM Martin Liška wrote: > > On 3/10/20 1:07 PM, Martin Liška wrote: > > On 3/10/20 12:24 PM, Richard Biener wrote: > >> Not sure how symtab is encoded right now but we also could have > > > > Ok, right now I don't see symtab entry much extensible. > > > > But what am

Re: [PATCHv2] Ada: gcc-interface: fixed assertion for aliased entities

> This is the second go at this patch, and now with a testcase! > > In summary: > > If the type is derived in the current compilation unit, and Allocate is not > overridden on derivation (as is typically the case with > Root_Storage_Pool_With_Subpools), the entity for Allocate for the derived >

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

Hi Sebastian, On 3/9/20 9:47 PM, Pop, Sebastian wrote: Hi, Please see attached the patches to add -moutline-atomics to the gcc-9 branch. Tested on graviton2 aarch64-linux with bootstrap and `make check` passes with no new fails. Tested `make check` on glibc built with gcc-9 with and without

ODR violation in ranges

Jonathan, the ranges header contains code like: inline constexpr __adaptor::_RangeAdaptorClosure all = [] (_Range&& __r) { if constexpr (view>) return std::forward<_Range>(__r); else if constexpr (requires { ref_view{std::forward<_Range>(__r)}; }) return

Re: [PATCH] aarch64: Fix ICE in aarch64_add_offset_1 [PR94121]

Hi Jakub, On 3/11/20 7:22 AM, Jakub Jelinek wrote: Hi! abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the (invalid) testcase shows, the function can be called with such an offset. The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows even that value and

Re: [PATCH][RFC] API extension for binutils (type of symbols).

On 3/10/20 1:07 PM, Martin Liška wrote: On 3/10/20 12:24 PM, Richard Biener wrote: Not sure how symtab is encoded right now but we also could have Ok, right now I don't see symtab entry much extensible. But what am I suggesting is to parse LTO bytecode version and then process conditional

Re: [PING PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

Bin.Cheng wrote: > On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote: >> With current trunk + Bin’s two approved patches. >> >> I see no change in the testcase (lambda-09-capture-object.C) before / after >> the patch >> (it fails for me at -O0 only - in both cases). > > I tried exactly

Re: [patch] Fix middle-end/93961

On Wed, Mar 11, 2020 at 8:56 AM Eric Botcazou wrote: > > Hi, > > this is a GIMPLE verification failure in LTO mode on Ada code: > > /vol/gcc/src/hg/master/local/gcc/testsuite/gnat.dg/lto24_pkg1.ads:9:8: error: > type mismatch in 'component_ref' > lto24_pkg1__rec___b___XVN > >

Re: [PATCH] value-prof: Fix abs uses in value-prof.c [PR93962]

On Wed, 11 Mar 2020, Jakub Jelinek wrote: > Hi! > > Jeff has recently fixed dump_histogram_value to use std::abs instead of abs, > because on FreeBSD apparently the ::abs isn't overloaded and only has > int abs (int); > Seems on Solaris /usr/include/iso/stdlib_iso.h abs has: > int abs (int); >

Re: [PATCH] dfp: Fix decimal_to_binary [PR94111]

On Wed, 11 Mar 2020, Jakub Jelinek wrote: > Hi! > > As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation > contains a decimal128 embedded in ->sig only if it is rvc_normal, for > other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is > contained in the

Re: [PATCH] ldist: Further fixes for -ftrapv [PR94114]

On Wed, 11 Mar 2020, Jakub Jelinek wrote: > Hi! > > As the testcase shows, arithmetics that for -ftrapv would need multiple > basic blocks can show up not just in nb_bytes expressions where we > are calling rewrite_to_non_trapping_overflow for a while already, > but also in the pointer

Re: Fix modulo-scheduler -fcompare-debug issues

On Tue, 10 Mar 2020, Roman Zhuykov wrote: > Hi! > > Current modulo-sched implementation is a bit faulty from -fcompile-debug > perspective. > > I found that few years ago, the most simple example is pr42631.c which fails > (with just -fmodulo-sched or together with

[PATCH] value-prof: Fix abs uses in value-prof.c [PR93962]

Hi! Jeff has recently fixed dump_histogram_value to use std::abs instead of abs, because on FreeBSD apparently the ::abs isn't overloaded and only has int abs (int); Seems on Solaris /usr/include/iso/stdlib_iso.h abs has: int abs (int); long abs (long); overloads but already not long long abs

[PATCH] dfp: Fix decimal_to_binary [PR94111]

Hi! As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation contains a decimal128 embedded in ->sig only if it is rvc_normal, for other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is contained in the REAL_VALUE_TYPE flags (cl, sign, signalling and decimal).

[patch] Fix middle-end/93961

Hi, this is a GIMPLE verification failure in LTO mode on Ada code: /vol/gcc/src/hg/master/local/gcc/testsuite/gnat.dg/lto24_pkg1.ads:9:8: error: type mismatch in 'component_ref' lto24_pkg1__rec___b___XVN lto24_pkg1__rec___b___XVN The __XVN fields are the fields with QUAL_UNION_TYPE in Ada,

[PATCH] ldist: Further fixes for -ftrapv [PR94114]

Hi! As the testcase shows, arithmetics that for -ftrapv would need multiple basic blocks can show up not just in nb_bytes expressions where we are calling rewrite_to_non_trapping_overflow for a while already, but also in the pointer expression to the start of the region. While the testcase covers

[PATCH] aarch64: Fix ICE in aarch64_add_offset_1 [PR94121]

Hi! abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the (invalid) testcase shows, the function can be called with such an offset. The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows even that value and will return (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN in

Re: [PATCH] c++: Fix wrong conversion error with non-viable overload [PR94124]

On Tue, Mar 10, 2020 at 07:38:17PM -0400, Marek Polacek via Gcc-patches wrote: > --- a/gcc/cp/decl.c > +++ b/gcc/cp/decl.c > @@ -6062,6 +6062,13 @@ reshape_init_array_1 (tree elt_type, tree max_index, > reshape_iter *d, >else if (last_nonzero < nelts - 1) > nelts = last_nonzero + 1;

Re: [testsuite] Fix PR93935 to guard case under vect_hw_misalign

Hi, Gentle ping this patch, also request to backport to gcc9 after some burn-in time. BR, Kewen on 2020/2/26 下午2:17, Kewen.Lin wrote: > Hi, > > This patch is to apply the same fix as r267528 to another similar case > bb-slp-over-widen-2.c which requires misaligned vector access. > > Verified