Re: [Patch] x86: Enable GCC support for Intel AVX-VNNI extension

On Mon, Nov 9, 2020 at 8:26 PM Uros Bizjak wrote: > > On Mon, Nov 9, 2020 at 11:31 AM Hongtao Liu wrote: > > > > > > > > + /* Support unified builtin. */ > > > + || (mask2 == OPTION_MASK_ISA2_AVXVNNI) > > > > > > I don't think we gain anything with unified builtins. Better, just > > >

Re: Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont

On Tue, Nov 10, 2020 at 3:22 AM Jason Merrill via Gcc-patches wrote: > > This patch was also applied to the GCC 9 and 10 branches and breaks those > builds, because PTA_CLDEMOTE is not defined. > Mine, let me fix it, sorry for that. -- BR, Hongtao

[PATCH] Normalize VARYING for -fstrict-enums.

The problem here is that the representation for VARYING in -fstrict-enums is different between value_range and irange. The helper function irange::normalize_min_max() will normalize to VARYING only if setting the range to the entire domain of the underlying type. That is, [0, 0xff..ff], not the d

Re: [PATCH 1/2] IBM Z: Store long doubles in vector registers when possible

On 09.11.20 20:54, Ilya Leoshkevich wrote: > On z14+, there are instructions for working with 128-bit floats (long > doubles) in vector registers. It's beneficial to use them instead of > instructions that operate on floating point register pairs, because it > allows to store 4 times more data in

Re: [PATCH 2/2] IBM Z: Test long doubles in vector registers

On 09.11.20 20:54, Ilya Leoshkevich wrote: > gcc/testsuite/ChangeLog: > > 2020-11-05 Ilya Leoshkevich > > * gcc.target/s390/vector/long-double-callee-abi-scan.c: New test. > * gcc.target/s390/vector/long-double-caller-abi-run.c: New test. > * gcc.target/s390/vector/long-doubl

Re: Improve handling of memory operands in ipa-icf 1/4

On Sun, 8 Nov 2020, Jan Hubicka wrote: > Hello, > I would like to finally address the problem with ipa-icf being overly > conservating on memory operand equality and having overly weak hash > function. This leads to code size, compile time and compile time memory > use regressions sompared to earl

Re: [PATCH] c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]

On Mon, Nov 09, 2020 at 10:34:00PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Mon, Nov 09, 2020 at 02:35:58PM -0500, Jason Merrill wrote: > > How about calling warn_if_unused_value instead of the new > > warn_if_unused_value_p? > > That seems to work if I just replace the warning_at call wit

[PATCH] sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]

Hi! This patch fixes a thinko in the left-endian push_partial_def path. As the testcase shows, we have 3 bitfields in the struct, bitoff bitsize 0 3 3 28 31 1 the corresponding read is the byte at offset 3 (i.e. 24 bits) and push_partial_def first handles the full store ({}) to a

Re: Detect EAF flags in ipa-modref

> > Alias oracle query stats: > refs_may_alias_p: 65808750 disambiguations, 75664890 queries > ref_maybe_used_by_call_p: 153485 disambiguations, 66711204 queries > call_may_clobber_ref_p: 22816 disambiguations, 28889 queries > nonoverlapping_component_refs_p: 0 disambiguations, 36846 queri

[PATCH] tree-optimization/97760 - reduction paths with unhandled live stmt

This makes sure we reject reduction paths with a live stmt that is not the last one altering the value. This is because we do not handle this in the epilogue unless there's a scalar epilogue loop. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-11-09 Richard Biener

[PATCH] fortran: Fix up gfc_typename CHARACTER length handling [PR97768]

Hi! The first testcase below ICEs when f951 is 32-bit (or 64-bit big-endian). The problem is that ex->ts.u.cl && ex->ts.u.cl->length are both non-NULL, but ex->ts.u.cl->length->expr_type is not EXPR_CONSTANT, but EXPR_FUNCTION. value.function.actual and value.function.name are in that case pointer

Re: [PATCH] sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]

On Tue, 10 Nov 2020, Jakub Jelinek wrote: > Hi! > > This patch fixes a thinko in the left-endian push_partial_def path. > As the testcase shows, we have 3 bitfields in the struct, > bitoffbitsize > 0 3 > 3 28 > 311 > the corresponding read is the byte at offset 3 (i.e. 24 bits

Re: [Patch] x86: Enable GCC support for Intel AVX-VNNI extension

On Tue, Nov 10, 2020 at 9:08 AM Hongtao Liu wrote: > > On Mon, Nov 9, 2020 at 8:26 PM Uros Bizjak wrote: > > > > On Mon, Nov 9, 2020 at 11:31 AM Hongtao Liu wrote: > > > > > > > > > > > + /* Support unified builtin. */ > > > > + || (mask2 == OPTION_MASK_ISA2_AVXVNNI) > > > > > > > > I

Re: Detect EAF flags in ipa-modref

> Bootstrapped/regtested x86_64-linux, OK? > (I will analyze more the t2.c failure) I have found independent reproducer that is now in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775 Honza

[PATCH] Use extremes of underlying type when building VR_ANTI_RANGEs.

[Andrew, this doesn't fix a PR per se. It's just something I stumbled upon in my other -fstrict-enums fixes. It passes tests. What do you think? Should we push it?] Imagine an enum in an -fstrict-enums world: enum foo { zero, one, two, three }; Building the inverse of [0,3] currently

[committed] doc: Fix grammar in description of earlyclobber

Committing this as obvious. diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index 2b462869437..813875b973b 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -1634,7 +1634,7 @@ constraints with multiple alternatives, sometimes one alternative requires @samp{&} while others do not. See, for ex

Re: Detect EAF flags in ipa-modref

> > Bootstrapped/regtested x86_64-linux, OK? > > (I will analyze more the t2.c failure) > > I have found independent reproducer that is now in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775 ... and with Jakub's fix the testcase works now. Honza > > Honza

Re: Detect EAF flags in ipa-modref

On Tue, 10 Nov 2020, Jan Hubicka wrote: > Hi, > this is updated patch for autodetection of EAF flags. Still the goal is > to avoid fancy stuff and get besic logic in place (so no dataflow, no IPA > propagation, no attempts to handle trickier cases). There is one new failure > > ./gcc/testsuite/

Re: [PATCH][AArch64] Skip arm targets in vq*shr*n_high_n intrinsic tests

David Candler writes: > Hi, > > These tests should be skipped for arm targets as the instrinsics > are only supported on aarch64. > > Tested on aarch64 and aarch32 > > gcc/testsuite/ChangeLog > > 2020-11-09 David Candler > > * gcc.target/aarch64/advsimd-intrinsics/vqrshrn_high_n.c: Added skip

[PATCH] More PRE TLC

This makes get_expr_value_id cheap and completes the constant value-id simplification by turning the constant_value_expressions into a direct map instead of a set of pre_exprs for the value. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. 2020-11-10 Richard Biener * tree-

Re: [PATCH] C-family : Add attribute 'unavailable'.

Hi Richard, Richard Biener wrote: On Mon, 9 Nov 2020, Iain Sandoe wrote: Hi, I?ve been carrying this patch around on my Darwin branches for a very long time? tested across the Darwin patch and on x86_64-linux-gnu, OK for master? thanks Iain = commit message If an interface is marked

Re: testsuite: Adjust pr96789.c to exclude vect_load_lanes

"Kewen.Lin" writes: > Hi, > > As Lyon pointed out, the newly introduced test case > gcc.dg/tree-ssa/pr96789.c fails on arm-none-linux-gnueabihf. > Loop vectorizer is able to vectorize the two loops which > operate on array tmp with load_lanes feature support. It > makes dse3 get unexpected inputs

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

Hi: This patch reduce reservation of model do not more than 10 cycles. The memory of genautomata down to 1GB. ChangeLog gcc/     PR target/77510     * config/mips/gs464.md: Reduce reservation     duration to 10 cycles.     * config/mips/i6400.md: Likewise.     * config/mips/m5100.md: Likewis

Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

xiezhiheng writes: >> -Original Message- >> From: Richard Sandiford [mailto:richard.sandif...@arm.com] >> Sent: Tuesday, November 3, 2020 9:57 PM >> To: xiezhiheng >> Cc: gcc-patches@gcc.gnu.org >> Subject: Re: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions >> emitted at -O3 >>

Re: [PATCH] C-family : Add attribute 'unavailable'.

On Tue, 10 Nov 2020, Iain Sandoe wrote: > Hi Richard, > > Richard Biener wrote: > > >On Mon, 9 Nov 2020, Iain Sandoe wrote: > > > >>Hi, > >> > >>I?ve been carrying this patch around on my Darwin branches for a very long > >>time? > >> > >>tested across the Darwin patch and on x86_64-linux-gnu,

Re: Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont

On Tue, Nov 10, 2020 at 4:17 PM Hongtao Liu wrote: > > On Tue, Nov 10, 2020 at 3:22 AM Jason Merrill via Gcc-patches > wrote: > > > > This patch was also applied to the GCC 9 and 10 branches and breaks those > > builds, because PTA_CLDEMOTE is not defined. > > > Mine, let me fix it, sorry for tha

[PATCH] tree-optimization/97780 - fix ICE in fini_pre

This deals with blocks elimination added. Pushed as obvious. 2020-11-10 Richard Biener PR tree-optimization/97780 * tree-ssa-pre.c (fini_pre): Deal with added basic blocks when freeing PHI_TRANS_TABLE. --- gcc/tree-ssa-pre.c | 2 +- 1 file changed, 1 insertion(+), 1 d

Re: [PATCH] Cleanup irange::set.

Hi, On Mon, 9 Nov 2020 at 15:43, Aldy Hernandez via Gcc-patches wrote: > > [This is actually part of a larger patch that actually changes > behavior, but I thought I'd commit the non-invasive cleanups first > which will simplify the upcoming work.] > > irange::set was doing more work than it shou

Re: [Patch] Fortran: OpenMP 5.0 (in_,task_)reduction clause extensions

On Tue, Nov 10, 2020 at 12:40:08AM +0100, Tobias Burnus wrote: > --- a/gcc/fortran/openmp.c > +++ b/gcc/fortran/openmp.c > @@ -762,6 +762,10 @@ enum omp_mask1 >OMP_CLAUSE_SHARED, >OMP_CLAUSE_COPYIN, >OMP_CLAUSE_REDUCTION, > + OMP_CLAUSE_REDUCTION_DEFAULT, > + OMP_CLAUSE_REDUCTION_MODI

Re: [PATCH] Cleanup irange::set.

This breaks aarch64. spawn -ignore SIGHUP /opt/gcc/test/Build/gcc/xgcc -B/opt/gcc/test/Build/gcc/ -mabi=lp64 -fdiagnostics-plain-output -march=armv8.2-a+sve -O3 --save-temps -ffat-lto-objects -fno-ident -c -o abs_1.o /opt/gcc/test/gcc/testsuite/gcc.target/aarch64/sve/abs_1.c during GIMPLE pass:

Re: Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont

On Tue, Nov 10, 2020 at 08:03:29PM +0800, Hongtao Liu via Gcc-patches wrote: > --- a/gcc/config/i386/i386.h > +++ b/gcc/config/i386/i386.h > @@ -2437,6 +2437,7 @@ const wide_int_bitmask PTA_AVX512BF16 (0, > HOST_WIDE_INT_1U << 11); > const wide_int_bitmask PTA_WAITPKG (0, HOST_WIDE_INT_1U << 12);

[PATCH] tree-optimization/97769 - fix assert in peeling for alignment

The following removes an assert that can not easily be adjusted to cover the additional cases we now handle after the removal of the same-align DRs vector. Tested on x86_64-unknown-linux and aarch64, pushed. 2020-11-10 Richard Biener PR tree-optimization/97769 * tree-vect-data

Re: Detect EAF flags in ipa-modref

> > + tree callee = gimple_call_fndecl (stmt); > > + if (callee) > > +{ > > + cgraph_node *node = cgraph_node::get (callee); > > + modref_summary *summary = node ? get_modref_function_summary (node) > > + : NULL; > > + > > + if (summary && summary->arg

[Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Everyone, I am afraid that this is a rather long sad story, mainly due to my efforts with gfortran being interrupted by daytime work. I posted the first version of the patch nearly a year ago but this was derailed by Tobias's question at: https://gcc.gnu.org/legacy-ml/fortran/2019-11/msg00098.h

[PATCH] aarch64: Make use of RTL predicates

Hi all, I'd like to propose this patch to make use of RTL predicates into the AArch64 back-end where possible. Bootstrapped and regtested on aarch64-unknown-linux-gnu. Okay for trunk? Thanks Andrea >From 9a027963f228b5c11aba30537cf888bba09bd6c2 Mon Sep 17 00:00:00 2001 From: Andrea Corallo

Re: [PATCH] Cleanup irange::set.

(actually I can see 3245 ICEs on aarch64) Can you fix it? Sure can. Richard, I seem to have incorrectly removed the early exit for varying, and that affected the changes you made for poly ints. Is there any reason we can't just exit and set varying without checking for kind != VR_VARYING?

Re: RFC: Monitoring old PRs, new dg directives [v2]

Hi! On 2020-08-10T17:30:21-0400, Marek Polacek via Gcc-patches wrote: > This patch adds a new DejaGNU directive, dg-ice, as outlined in the > proposal here: > https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550913.html > > It means that it's expected that the compiler crashes with an interna

Re: [PATCH] Use extremes of underlying type when building VR_ANTI_RANGEs.

On 11/10/20 5:41 AM, Aldy Hernandez wrote: [Andrew, this doesn't fix a PR per se. It's just something I stumbled upon in my other -fstrict-enums fixes. It passes tests. What do you think? Should we push it?] Imagine an enum in an -fstrict-enums world: enum foo { zero, one, two, thre

Re: Detect EAF flags in ipa-modref

Hi, here is updaed patch. Honza Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)? 2020-11-10 Jan Hubicka * gimple.c: Include ipa-modref-tree.h and ipa-modref.h. (gimple_call_arg_flags): Use modref to determine flags. * ipa-modref.c: Include gimple-ssa.

Re: [PATCH] c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]

On 11/10/20 3:48 AM, Jakub Jelinek wrote: On Mon, Nov 09, 2020 at 10:34:00PM +0100, Jakub Jelinek via Gcc-patches wrote: On Mon, Nov 09, 2020 at 02:35:58PM -0500, Jason Merrill wrote: How about calling warn_if_unused_value instead of the new warn_if_unused_value_p? That seems to work if I jus

Re: [PATCH] Cleanup irange::set.

Aldy Hernandez writes: >> (actually I can see 3245 ICEs on aarch64) >> >> Can you fix it? > > Sure can. > > Richard, I seem to have incorrectly removed the early exit for varying, > and that affected the changes you made for poly ints. Is there any > reason we can't just exit and set varying w

Re: [PATCH] "used" attribute saves decl from linker garbage collection

On Mon, Nov 09, 2020 at 12:31:09PM -0800, H.J. Lu via Gcc-patches wrote: > On Mon, Nov 9, 2020 at 11:56 AM Jozef Lawrynowicz > wrote: > > > > On Mon, Nov 09, 2020 at 10:36:07AM -0800, H.J. Lu via Gcc-patches wrote: > > > On Mon, Nov 9, 2020 at 9:41 AM Jozef Lawrynowicz > > > wrote: > > > > > > >

Re: [PATCH] generalized range_query class for multiple contexts

On 11/6/20 2:54 PM, Andrew MacLeod wrote: On 11/6/20 11:13 AM, Martin Sebor wrote: On 11/5/20 8:08 PM, Andrew MacLeod wrote: On 11/5/20 7:50 PM, Martin Sebor wrote: On 11/5/20 5:02 PM, Andrew MacLeod wrote: On 11/5/20 4:02 PM, Martin Sebor wrote: On 11/5/20 12:29 PM, Martin Sebor wrote: On

Re: [PATCH] Use extremes of underlying type when building VR_ANTI_RANGEs.

On 11/10/20 3:26 PM, Andrew MacLeod wrote: On 11/10/20 5:41 AM, Aldy Hernandez wrote: [Andrew, this doesn't fix a PR per se.  It's just something I stumbled upon in my other -fstrict-enums fixes.  It passes tests.  What do you think?  Should we push it?] Imagine an enum in an -fstrict-enums

libgo patch committed: Update to Go 1.15.4 release

This patch updates libgo to the 1.15.4 release. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline. Ian 8815a8e97f8d0ee4066e737152c8198a80e9fe32 diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE index 149f20077e3..e62578fc781 100644 --- a/gcc/go/gofronte

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

On 10/5/20 10:49 AM, Stefan Kanthak wrote: > The implementation of the functions __absv?i2(), __addv?i3() etc. for > trapping integer overflow provided in libgcc2.c is rather bad. > Same for __cmp?i2() and __ucmp?i2() > > At least for AMD64 and i386 processors GCC creates awful to horrible > code

Re: [PATCH] C-family : Add attribute 'unavailable'.

This patch seems to be missing documentation for the new attribute in extend.texi. -- Joseph S. Myers jos...@codesourcery.com

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

> On Nov 10, 2020, at 6:42 AM, Xu Chenghua wrote: > > > Hi: > > This patch reduce reservation of model do not more than 10 cycles. The memory > of genautomata down to 1GB. Does this make any significant difference in performance of the generated code? The original cycle counts are from t

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

On Tue, Nov 10, 2020 at 08:29:58AM -0700, Jeff Law via Gcc-patches wrote: > On 10/5/20 10:49 AM, Stefan Kanthak wrote: > > The implementation of the functions __absv?i2(), __addv?i3() etc. for > > trapping integer overflow provided in libgcc2.c is rather bad. > > Same for __cmp?i2() and __ucmp?i2()

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

On 11/10/20 8:57 AM, Jakub Jelinek wrote: > On Tue, Nov 10, 2020 at 08:29:58AM -0700, Jeff Law via Gcc-patches wrote: >> On 10/5/20 10:49 AM, Stefan Kanthak wrote: >>> The implementation of the functions __absv?i2(), __addv?i3() etc. for >>> trapping integer overflow provided in libgcc2.c is rath

[PATCH/RFC v2] Add -fdiagnostics-path-format=html [v2]

Here's an updated version of the HTML output idea from: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556848.html I reworked the HTML path output to show stack frames as well as just runs of events, using drop-shadows to give a 3D look. The idea is to try to highlight the stack of fram

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

Hi all, I'd like to submit this patch to fix three testcases reported to be failing on arm big endian on PR target/97727. Okay for trunk? Thanks Andrea >From c2d5faf49647381edbcdce6a709b5ed046ce13a4 Mon Sep 17 00:00:00 2001 From: Andrea Corallo Date: Tue, 10 Nov 2020 15:15:27 +0100 Subjec

Re: [PATCH 1/3] Refactor copying decl section names

On 11/12/19 11:28 PM, Strager Neds wrote: > Sometimes, we need to copy a section name from one decl or symtab node > to another. Currently, this is done by getting the source's section > name and setting the destination's section name. For example: > > set_decl_section_name (dest, DECL_SECTIO

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/9/20 7:21 PM, Marek Polacek wrote: Currently, when a static_assert fails, we only say "static assertion failed". It would be more useful if we could also print the expression that evaluated to false; this is especially useful when the condition uses template parameters. Consider the motiva

Re: [PATCH] c-family: Avoid unnecessary work when -Wpragmas is being ignored

On Mon, 2020-11-09 at 10:38 -0500, Patrick Palka wrote: > This speeds up handle_pragma_diagnostic by avoiding computing a > spelling > suggestion for an unrecognized option inside a #pragma directive when > -Wpragmas warnings are being suppressed. > > In the range-v3 library, which contains many i

Re: [Patch] Fortran: OpenMP 5.0 (in_,task_)reduction clause extensions

Hi Jakub, thanks for the comments. I have now removed OMP_CLAUSE_REDUCTION{_DEFAULT,_MODIFIER} and use 'openacc' as flag for OpenACC. The only 'default:' check is now moved to resolution stage. If I gathered it correctly, the splitting is complex but the way it is implemented, it happens to be f

Re: [PATCH] analyzer: remove dead code

On Fri, 2020-10-23 at 17:26 +0200, Martin Liška wrote: > Hey. > > I've noticed that when building GCC with Clang. > David what do you think about it? Thanks for the patch. Looks good to me, assuming it goes through normal bootstrap and regression-testing. That said, technically I'm not a mainta

Re: [PATCH] analyzer: remove dead code

On 11/10/20 9:57 AM, David Malcolm via Gcc-patches wrote: > On Fri, 2020-10-23 at 17:26 +0200, Martin Liška wrote: >> Hey. >> >> I've noticed that when building GCC with Clang. >> David what do you think about it? > Thanks for the patch. > > Looks good to me, assuming it goes through normal boots

Re: [PATCH] fortran: Fix up gfc_typename CHARACTER length handling [PR97768]

On 10.11.20 10:58, Jakub Jelinek via Gcc-patches wrote: The earlier version of the patch has been successfully bootstrapped and regtested (only with a few regressions) on x86_64-linux and i686-linux, this version passed all the new and earlier problematic tests, ok for trunk if it passes another

Re: [PATCH] c-family: Avoid unnecessary work when -Wpragmas is being ignored

On Tue, 10 Nov 2020, David Malcolm wrote: > On Mon, 2020-11-09 at 10:38 -0500, Patrick Palka wrote: > > This speeds up handle_pragma_diagnostic by avoiding computing a > > spelling > > suggestion for an unrecognized option inside a #pragma directive when > > -Wpragmas warnings are being suppressed

Re: [PATCH] Overflow-trapping integer arithmetic routines7code

Jeff Law wrote: > On 10/5/20 10:49 AM, Stefan Kanthak wrote: >> The implementation of the functions __absv?i2(), __addv?i3() etc. for >> trapping integer overflow provided in libgcc2.c is rather bad. >> Same for __cmp?i2() and __ucmp?i2() >> >> At least for AMD64 and i386 processors GCC creates a

Re: [Patch] Fortran: OpenMP 5.0 (in_,task_)reduction clause extensions

On Tue, Nov 10, 2020 at 05:46:17PM +0100, Tobias Burnus wrote: > Fortran: OpenMP 5.0 (in_,task_)reduction clause extensions > > gcc/fortran/ChangeLog: > > PR fortran/95847 > * dump-parse-tree.c (show_omp_clauses): Handle new reduction enums. > * gfortran.h (OMP_LIST_REDUCTION_IN

[PATCH] IBM Z: Fix bootstrap breakage due to HAVE_TF macro

Bootstrap and regtest running on s390x-redhat-linux with --enable-shared --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-checking=yes,rtl --enable-gnu-indirect-function --disable-werror --enable-languages=c,c++,fortran,objc,obj-c++ --with-arch=arch13. Ok for master? Com

Re: [PATCH] IBM Z: Fix bootstrap breakage due to HAVE_TF macro

On 10.11.20 18:43, Ilya Leoshkevich wrote: > Bootstrap and regtest running on s390x-redhat-linux with --enable-shared > --with-system-zlib --enable-threads=posix --enable-__cxa_atexit > --enable-checking=yes,rtl --enable-gnu-indirect-function > --disable-werror --enable-languages=c,c++,fortran,objc

Re: [PATCH] openmp: Retire nest-var ICV

On Mon, Nov 09, 2020 at 05:43:20PM +, Kwok Cheung Yeung wrote: > commit b4feb16f3c84b8f82163a4cbba6a31d55fbb8e5b > Author: Kwok Cheung Yeung > Date: Mon Nov 9 09:34:39 2020 -0800 > > openmp: Retire nest-var ICV for OpenMP 5.0 > > This removes the nest-var ICV, expressing nestin

[PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions is rather bad, it yields bad machine code at least on i386 and AMD64. Since GCC knows how to shift integers twice the register size these functions can be written as one-liners. The implementation of the __bswapsi2() func

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions > is rather bad, it yields bad machine code at least on i386 and AMD64. Since > GCC knows how to shift integers twice the register size these functions can > be written as one-liners. These functions are precisely meant

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches wrote: > The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions > is rather bad, it yields bad machine code at least on i386 and AMD64. > Since GCC knows how to shift integers twice the register size thes

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches wrote: > The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions > is rather bad, it yields bad machine code at least on i386 and AMD64. > Since GCC knows how to shift integers twice the register size thes

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On 11/10/20 11:09 AM, Jakub Jelinek via Gcc-patches wrote: > On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches > wrote: >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions >> is rather bad, it yields bad machine code at least on i386 and AMD64.

Merge from trunk to gccgo branch

I merged trunk revision cf392dbdf17e38026f8e3c0e9af7f5b87f63be56 to the gccgo branch. Ian

Re: [PATCH 1/3] Refactor copying decl section names

On 11/12/19 11:28 PM, Strager Neds wrote: > * gcc/cgraph.h (symtab_node::get_section): Constify. > (symtab_node::set_section): Declare new overload. > * gcc/symtab.c (symtab_node::set_section): Define new overload. > (symtab_node::copy_visibility_from): Use new overload of > symtab_node::set_sect

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: > On 11/9/20 7:21 PM, Marek Polacek wrote: > > Currently, when a static_assert fails, we only say "static assertion > > failed". > > It would be more useful if we could also print the expression that > > evaluated to false; this is esp

Re: RFC: Monitoring old PRs, new dg directives [v2]

On Tue, Nov 10, 2020 at 03:15:00PM +0100, Thomas Schwinge wrote: > Hi! > > On 2020-08-10T17:30:21-0400, Marek Polacek via Gcc-patches > wrote: > > This patch adds a new DejaGNU directive, dg-ice, as outlined in the > > proposal here: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550913

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/10/20 1:59 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: On 11/9/20 7:21 PM, Marek Polacek wrote: Currently, when a static_assert fails, we only say "static assertion failed". It would be more useful if we could also print the expression that eval

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On Tue, Nov 10, 2020 at 02:15:56PM -0500, Jason Merrill wrote: > On 11/10/20 1:59 PM, Marek Polacek wrote: > > On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: > > > On 11/9/20 7:21 PM, Marek Polacek wrote: > > > > Currently, when a static_assert fails, we only say "static assertion

Re: [PATCH] c++: Improve static_assert diagnostic [PR97518]

On 11/10/20 2:28 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 02:15:56PM -0500, Jason Merrill wrote: On 11/10/20 1:59 PM, Marek Polacek wrote: On Tue, Nov 10, 2020 at 11:32:04AM -0500, Jason Merrill wrote: On 11/9/20 7:21 PM, Marek Polacek wrote: Currently, when a static_assert fails, we

[PATCH v2] C-family : Add attribute 'unavailable'.

Hi Jospeh, Joseph Myers wrote: > This patch seems to be missing documentation for the new attribute in > extend.texi. Apologies, for that omission, revised patch includes the documentation and also addresses Richi’s comments. documentation patch tested with “make pdf” and visual inspection of

[committed] libstdc++: Reorder constructors in

This groups all the constructors together, consistent with the synopses in the C++20 standard. libstdc++-v3/ChangeLog: * include/std/sstream (basic_stringbug, basic_istringstream) (basic_ostringstream, basic_stringstream): Reorder C++20 constructors to be declared next to

[committed] libstdc++: Fix more unspecified comparisons to null pointer [PR 97415]

This adds some more null checks to avoid a relational comparison with a null pointer, similar to 78198b6021a9695054dab039340202170b88423c. libstdc++-v3/ChangeLog: PR libstdc++/97415 * include/std/sstream (basic_stringbuf::_M_update_egptr) (basic_stringbuf::__xfer_bufptrs::

[committed] libstdc++: Add remaining C++20 additions to [P0408R7]

This adds the new overloads of basic_stringbuf::str, and the corresponding overloads to basic_istringstream, basic_ostringstream and basic_stringstream. libstdc++-v3/ChangeLog: * config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Tighten patterns. (GLIBCXX_3.4.29): Export new symbols.

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

Eric Botcazou wrote: >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions >> is rather bad, it yields bad machine code at least on i386 and AMD64. Since >> GCC knows how to shift integers twice the register size these functions can >> be written as one-liners. > > Thes

[pushed] c++: Add 5 unfixed tests.

A couple of dg-ice tests. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog: PR c++/52830 PR c++/88982 PR c++/90799 PR c++/87765 PR c++/89565 * g++.dg/cpp0x/constexpr-52830.C: New test. * g++.dg/cpp0x/vt-88982.C: New te

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote: > Eric Botcazou wrote: > > >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() > >> functions > >> is rather bad, it yields bad machine code at least on i386 and AMD64. Since > >> GCC knows how to shift integers tw

Re: [PATCH] Practical Improvement to libgcc Complex Divide

2nd ping - submitted Sept 8, 2020, last comment Sept 9, 2020 This patch is a correctness bug fix and not a change to any user visible interface. It makes a major improvement to complex divide accuracy, including algorithm improvements known for 8 years. It is highly desirable to get these changes

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

Jakub and Jeff, PING^7 on the following patch proposed 8 months ago for gcc11: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542198.html The deadline for gcc11 stage 1 is approaching. The pinged patch is one that has be

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote: > On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote: >> Eric Botcazou wrote: >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions is rather bad, it yields bad machine code at least o

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On Tue, Nov 10, 2020 at 02:09:20PM -0700, Jeff Law wrote: > > On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote: > > On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote: > >> Eric Botcazou wrote: > >> > The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() > >

PING: Re: [PATCH] Add analyzer plugin support and CPython GIL example

I'd like to ping this patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556214.html Are the non-analyzer parts OK for master? Thanks Dave On Wed, 2020-10-14 at 21:21 -0400, David Malcolm wrote: > This patch adds a new GCC plugin event: PLUGIN_ANALYZER_INIT, called > when -fanalyzer

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On 11/10/20 12:44 PM, Stefan Kanthak wrote: > Eric Botcazou wrote: > >>> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions >>> is rather bad, it yields bad machine code at least on i386 and AMD64. Since >>> GCC knows how to shift integers twice the register size these

[r11-4883 Regression] FAIL: gfortran.dg/gomp/workshare-reduction-57.f90 -O scan-tree-dump-times optimized "__builtin_GOMP_loop_dynamic_next " 1 on Linux/x86_64

On Linux/x86_64, e929ef532ad52cde873dfc0849907b020ffc5afd is the first bad commit commit e929ef532ad52cde873dfc0849907b020ffc5afd Author: Tobias Burnus Date: Tue Nov 10 18:28:18 2020 +0100 Fortran: OpenMP 5.0 (in_,task_)reduction clause extensions caused FAIL: gfortran.dg/gomp/workshare-

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote: > On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote: >> Eric Botcazou wrote: >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions is rather bad, it yields bad machine code at least o

Re: [Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

Hi Paul, This all bootstraps and regtests on FC31/x86_64 - OK for master? This is a sizable patch, and from what I can see, it all looks plausible. So, I's say OK for master (with one nit, below), but maybe you could wait a day or so to give others the chance to look it over, too. The nit:

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

On 11/10/20 4:42 AM, Xu Chenghua wrote: > > Hi: > > This patch reduce reservation of model do not more than 10 cycles. The > memory of genautomata down to 1GB. How bad is the memory consumption before this change? > > ChangeLog > > gcc/ >     PR target/77510 >     * config/mips/gs464.md: Reduc

Re: [PATCH] Objective-C : Implement NSObject attribute.

On 11/6/20 1:18 PM, Iain Sandoe wrote: > Hi > > Originally, I had this as a Darwin-only patch, however GNUStep > also makes use of NSObject and similar constructs, so this really > needs to be available to linux-gnu as well. > > tested across several Darwin versions and on x86_64-linux-gnu. > > O

Re: [07/32] cpp main

On 11/3/20 2:14 PM, Nathan Sidwell wrote: > Here's the changes to starting the main file. I have added the ability > to search the user or system include paths for the main file.  That's > real helpful to users attempting to build header-units.  I'll discuss > the CLI with the options patch. > >

Re: [08/32] cpp mkdeps

On 11/3/20 2:14 PM, Nathan Sidwell wrote: > The final bit of preprocessor change is that to mkdeps.  We have a new > kind of thing to be dependent upon -- a compiled module interface. > That's also an additional target. > > This adds the logic to mkdeps to keep those dependencies separate from >

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On 11/10/20 2:17 PM, Jakub Jelinek wrote: > On Tue, Nov 10, 2020 at 02:09:20PM -0700, Jeff Law wrote: >> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote: >>> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote: Eric Botcazou wrote: >> The implementation of the _

Re: [PATCH] Objective-C : Implement NSObject attribute.

Hi Jeff, Jeff Law wrote: This attribute allows pointers to be marked as pointers to an NSObject-compatible object. This allows for additional OK with a suitable update to documentation. I have no idea the attribute is supposed to do. Joseph ack’d this and I applied it to master .. ..

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

On 11/10/20 10:59 AM, Stefan Kanthak via Gcc-patches wrote: > The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions > is rather bad, it yields bad machine code at least on i386 and AMD64. > Since GCC knows how to shift integers twice the register size these functions > can

  1   2   >