Re: [PATCH 1/7] C-SKY: Add fpuv3 instructions and CK860 arch

Hi gengqi, I could not find the patchs [3/7], [4/7] and [7/7]. Could you check the emails and send them again ? On 10/29/20 9:22 PM, gengqi via Gcc-patches wrote: gcc/ChangeLog: * config/csky/constraints.md ("W"): New constriant for mem operand with base reg, index

[r11-4516 Regression] FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "Using a splat" 1 on Linux/x86_64

On Linux/x86_64, 1e1e1edf88a7c40ae4ae0de9e6077179e13ccf6d is the first bad commit commit 1e1e1edf88a7c40ae4ae0de9e6077179e13ccf6d Author: Richard Biener Date: Thu Oct 29 08:48:15 2020 +0100 More BB vectorization tweaks caused FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto -ffat-lto-objects

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Thu, Oct 29, 2020 at 02:25:33PM -0400, Jason Merrill via Gcc-patches wrote: > On 10/29/20 2:11 PM, Marek Polacek wrote: > > On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 10/28/20 7:40 PM, Marek Polacek wrote: > > > > On Wed, Oct 28, 2020 at

[PATCH] [tree-optimization] Fix for PR96701

This patch adds a pattern for folding x >> x to   0 as described in PR96701. Without this patch the x86_64-pc-linux-gnu code generated for this function int foo (int i) {   return i >> i; } is mov    ecx,edi sar    edi,cl test   edi,edi setne  al ret With the

[PATCH] c++: Tweaks for value_dependent_expression_p.

We may not call value_dependent_expression_p on expressions that are not potential constant expressions, otherwise value_d could crash, as I saw recently (in C++98). So beef up the checking in i_d_e_p. This revealed a curious issue: when we have __PRETTY_FUNCTION__ in a template function, we set

[PATCH] c++: Disable -Winit-list-lifetime in unevaluated operand [PR97632]

Jon suggested turning this warning off when we're not actually evaluating the operand. This patch does that. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? gcc/cp/ChangeLog: PR c++/97632 * init.c (build_new_1): Disable -Winit-list-lifetime for an unevaluated

[PATCH] [tree-optimization] Fix for PR96701

This patch adds a pattern for folding x >> x to 0 as described in PR96701. Without this patch the x86_64-pc-linux-gnu code generated for this function int foo (int i) { return i >> i; } is movecx,edi saredi,cl test edi,edi setne al

Re: PowerPC: Update __float128 and __ibm128 error messages.

On Thu, Oct 29, 2020 at 02:18:58PM -0500, Segher Boessenkool wrote: > On Thu, Oct 29, 2020 at 01:03:25PM -0400, Michael Meissner wrote: > > On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote: > > > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */ > > > > > > Use

[PATCH 1/5] [PR target/96342] Change field "simdlen" into poly_uint64

Hi, This is the first patch for PR96698. In order to support the generating of SVE functions for "omp declare simd", this patch changes the type of the field "simdlen" of struct cgraph_simd_clone from unsigned int to poly_uint64. Although Richard mentioned in the PR that

[PATCH] AIX xfail for_overwrite.cc libstdc++ testcase

The 20_util/unique_ptr/creation/for_overwrite.cc test relies on operator new, which requires special features on AIX. This patch disables the testcase. Thanks, David --- a/libstdc++-v3/testsuite/20_util/unique_ptr/creation/for_overwrite.cc +++

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

(Very very gentle ping, just to make sure it's still on anyone's radar...!) On Fri, Oct 9, 2020 at 8:39 AM JeanHeyd Meneide wrote: > > Hello, > > > Typo: comple-time > > > > >2020-10-08 JeanHeyd "ThePhD" Meneide > > > > > >* gcc/c-family/c-cppbuiltin.c: Add predefined macro > >

[PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, This is the 6th version of the implementation of patch -fzero-call-used-regs. The X86 part is exactly the same as 5th version. (And it has been approved by Uros already). The major change compared to the previous version (5th version) are: 1. Documentation change per Richard’s

Re: [PATCH] libstdc++: Fix the default constructor of ranges::__detail::__box

On Thu, 29 Oct 2020, Patrick Palka wrote: > The class template semiregular-box of [range.semi.wrap] is specified > to value-initialize the underlying object whenever its type is default- > initializable. Our primary template for __detail::__box respects this > requirement, but the recently added

[PATCH] libstdc++: Fix the default constructor of ranges::__detail::__box

The class template semiregular-box of [range.semi.wrap] is specified to value-initialize the underlying object whenever its type is default- initializable. Our primary template for __detail::__box respects this requirement, but the recently added partial specialization (for types which are

[committed] libstdc++: Avoid narrowing conversion in subrange constructor

libstdc++-v3/ChangeLog: * include/bits/ranges_util.h (subrange::subrange(R&&)): Use direct-initialization instead of list-initialization, so a potential narrowing conversion from ranges::size(r) to the stored size isn't ill-formed. Tested powerpc64le-linux.

[committed] libstdc++: Fix some warnings in headers

These are usually suppressed in system headers, but should be fixed anyway. libstdc++-v3/ChangeLog: * include/bits/parse_numbers.h (_Select_int_base): Avoid narrowing conversion in constant expression. * include/experimental/buffer (buffer_copy): Avoid narrowing

[committed] libstdc++: Prevent deprecation warnings from

libstdc++-v3/ChangeLog: * include/tr1/shared_ptr.h (__shared_count, __shared_ptr) (shared_ptr): Add diagnostic pragmas around uses of auto_ptr. * testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc: Adust dg-error line numbers. Tested powerpc64le-linux.

[committed] libstdc++: Avoid warnings in tests

This fixes some warnings emitted when testing with warning flags added. Some of these are only necessary when testing with -Wsystem-headers, but either way it cleans up the tests to be less noisy under non-default flags. Tested powerpc64le-linux. Committed to trunk. commit

Re: [PATCH] libstdc++: Implement C++20 features for

On 29/10/20 21:41 +, Jonathan Wakely wrote: On 29/10/20 21:06 +0100, Rainer Orth wrote: Tightening the patterns as in the attached patch at least allows libstdc++.so.6 to link on i386-pc-solaris2.11; full bootstrap still running. However, I can't tell if this is really correct. I think

Re: Fix thunk_info with PCH

On 10/29/20 3:32 PM, Jan Hubicka wrote: > Hi, > symbol summaries are not PCH safe and thus thunk_info summary can not be > created before parsing is finished. This patch stores thunk infos into > a vector before they are attachd to actual symbol nodes at symtab > construction time. > > I am not

Re: PowerPC: Add __float128 conversions to/from Decimal

On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > Doing these conversions accurately is nontrivial. Converting via strings > > is the simple approach (i.e. the one that moves the complexity somewhere > > else). There are more complicated but more efficient approaches that can > > achieve

[PATCH] SPARC: add leon3v7 libgcc to leon3-elf

This patch adds the leon3v7 version of libgcc to the leon3-elf target. If approved, I'll need a maintainer to kindly commit on my behalf. Thanks, Pat Bernardi Senior Software Engineer, AdaCore 2020-10-29 Pat Bernardi mailto:berna...@adacore.com>> gcc/ChangeLog *

Re: [PATCH] libstdc++: Implement C++20 features for

On 29/10/20 21:06 +0100, Rainer Orth wrote: Tightening the patterns as in the attached patch at least allows libstdc++.so.6 to link on i386-pc-solaris2.11; full bootstrap still running. However, I can't tell if this is really correct. I think we want this attached patch instead. It tightens

Fix thunk_info with PCH

Hi, symbol summaries are not PCH safe and thus thunk_info summary can not be created before parsing is finished. This patch stores thunk infos into a vector before they are attachd to actual symbol nodes at symtab construction time. I am not sure how to add the testcase - I did not find similar

Re: [Patch] Fortran: Update omp atomic for OpenMP 5

Forgot to add fortran@. On 29.10.20 18:05, Tobias Burnus wrote: The parser partially anticipates the upcoming OpenMP 5.1 changes, which adds some more clauses - but otherwise does not update it for OpenMP 5.1, yet. In particular, the "omp end atomic" for capture is still required and the

[PATCH] libstdc++: Add c++2a

From: Thomas Rodgers Addresses latest patch feedback. Changes to also work on single threaded configurations. libstdc++/ChangeLog: libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header. libstdc++-v3/include/Makefile.am (std_headers): Add new header.

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

On Wed, 22 Jul 2020, Asher Gordon via Gcc-patches wrote: > Hello Joseph, Martin, > > Asher Gordon writes: > > > Joseph Myers writes: > > > >> I don't see you in the FSF copyright assignment list; could you > >> complete > >>

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

On Thu, Oct 29, 2020 at 03:08:07PM -0500, Segher Boessenkool wrote: > It isn't set anywhere else. > > Mike, the patch is okay for trunk with that line restored. Thanks! > (And thanks for spotting the problem Will!) It is set since the variable is a static. The whole point is to only raise the

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

On Thu, Oct 29, 2020 at 01:32:53PM -0500, Segher Boessenkool wrote: > On Thu, Oct 29, 2020 at 12:50:10PM -0400, Michael Meissner wrote: > > On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote: > > > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote: > > > > This patch

Ping: [PATCH] i386: Cleanup i386/i386elf.h and align it's return convention with the SVR4 ABI

Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552186.html Thanks. > On 18 Aug 2020, at 6:02 pm, Pat Bernardi wrote: > > As observed a number of years ago in the following thread, i386/i386elf.h has > not been

Re: Avoid char[] array in tree_def

On 10/29/20 1:40 PM, Richard Biener wrote: On Thu, 29 Oct 2020, Jakub Jelinek wrote: On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote: That's ugly and will for sure defeat warning / access code when we access this as char[], no? I mean, we could as well use 'int str[1];' here?

[patch] gcc.dg/analyzer tests: relax dependency on alloca.h

Hello, Some of the tests in gcc.dg/analyzer exercize alloca and #include . Some systems, e.g. VxWorks, don't feature alloca.h and the aforementioned tests fail. Other tests in the suite have been in this situation and the usual way around consists in resorting to __builtin_alloca directly.

Re: [RS6000] Don't be too clever with dg-do run and dg-do compile

On Thu, Oct 29, 2020 at 09:09:13AM +1030, Alan Modra wrote: > On Wed, Oct 28, 2020 at 12:16:00PM -0500, Segher Boessenkool wrote: > > On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote: > > > Otherwise some versions of dejagnu go ahead and run the vsx tests > > > below when they should

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Segher, > On Oct 29, 2020, at 2:31 PM, Segher Boessenkool > wrote: > > On Thu, Oct 29, 2020 at 06:02:58PM +, Richard Sandiford wrote: >> Qing Zhao via Gcc-patches writes: > +Return-Oriented Programming (ROP) or preventing information leak leakage (FWIW, I'm

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 29, 2020, at 1:06 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Now, the documentation (gcc.info) is like following, let me know any issue >> there: > > Yeah, looks good apart from merging > >> In order to satisfy users with different security needs and control >>

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 29, 2020, at 1:02 PM, Richard Sandiford > wrote: > > Qing Zhao via Gcc-patches writes: +Return-Oriented Programming (ROP) or preventing information leak >>> >>> leakage >>> >>> (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't >>> have any better

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

On Thu, Oct 29, 2020 at 02:11:47PM -0500, will schmidt wrote: > On Thu, 2020-10-29 at 13:05 -0400, Michael Meissner wrote: > > On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote: > > > On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches > > > wrote: > > > > PowerPC:

Re: [PATCH] libstdc++: Implement C++20 features for

Hi Jonathan, > On > The patch that was committed broke the linker script. The attached > patch restores the piece that got lost, and removes the duplicate > patterns added for the new symbols. Pushed to trunk. even this fixed version broke Solaris bootstrap: ld: fatal:

Re: [PATCH v2] c++: Deducing type from initializer_list [PR93107]

On 10/29/20 3:55 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 03:18:18PM -0400, Jason Merrill via Gcc-patches wrote: On 10/16/20 11:31 AM, Marek Polacek wrote: In this testcase we weren't able to deduce b's type: template void Task() { } auto b = { }; because

Re: [PATCH v2] c++: Deducing type from initializer_list [PR93107]

On Wed, Oct 28, 2020 at 03:18:18PM -0400, Jason Merrill via Gcc-patches wrote: > On 10/16/20 11:31 AM, Marek Polacek wrote: > > In this testcase we weren't able to deduce b's type: > > > >template void Task() { } > >auto b = { }; > > > > because resolve_nondeduced_context doesn't

RE: [EXTERNAL] Re: [PATCH] [tree-optimization] Fix for PR97223

Thank you for the review Richard! I re-worked the patch based on your suggestions. I combined the two patterns. Neither one requires a signedness check as long as the type of the 'add' has overflow wrap semantics. I had to modify the regular expression in no-strict-overflow-4.c test. In that

Re: PowerPC: Add __float128 conversions to/from Decimal

On Thu, Oct 29, 2020 at 06:31:54PM +, Joseph Myers wrote: > On Thu, 29 Oct 2020, Segher Boessenkool wrote: > > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > > > +#if HAVE_KF_MODE > > > > > +

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

On Thu, Oct 29, 2020 at 06:02:58PM +, Richard Sandiford wrote: > Qing Zhao via Gcc-patches writes: > >>> +Return-Oriented Programming (ROP) or preventing information leak > >> > >> leakage > >> > >> (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't > >> have any

Re: PowerPC: Update __float128 and __ibm128 error messages.

On Thu, Oct 29, 2020 at 01:03:25PM -0400, Michael Meissner wrote: > On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote: > > > +/* { dg-do compile { target { powerpc*-*-linux* } } } */ > > > > Use *-*-linux* instead? (In all relevant tests.) > > Ok. > > > Is there any reason

Re: [PATCH] arm: Fix multiple inheritance thunks for thumb-1 with -mpure-code

On 28/10/2020 18:10, Christophe Lyon via Gcc-patches wrote: > On Wed, 28 Oct 2020 at 18:44, Richard Earnshaw > wrote: >> >> On 27/10/2020 15:42, Richard Earnshaw via Gcc-patches wrote: >>> On 26/10/2020 10:52, Christophe Lyon via Gcc-patches wrote: On Thu, 22 Oct 2020 at 17:22, Richard

[PATCH 0/3] Enable PGO/LTO build for binutils+gdb

Add the --enable-pgo-build[=lto] configure option. When binutils+gdb is not built together with GCC, --enable-pgo-build enables the PGO build: 0. Pass --plugin to AR and RANLIB. 1. First build with -fprofile-generate. 2. Use "make maybe-check-*" to generate profiling data. 3. Use "make clean" to

[PATCH 1/3] GCC: Pass --plugin to AR and RANLIB

Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. * Makefile.tpl (AR): Add @AR_PLUGIN_OPTION@ (RANLIB): Add @RANLIB_PLUGIN_OPTION@. * configure.ac: Include config/gcc-plugin.m4. AC_SUBST AR_PLUGIN_OPTION and RANLIB_PLUGIN_OPTION.

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

On Thu, 2020-10-29 at 13:05 -0400, Michael Meissner wrote: > On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote: > > On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches > > wrote: > > > PowerPC: Allow C/C++ to change long double type on GLIBC 2.32. > > > > > > This is a

[PATCH 3/3] Support the PGO build for binutils+gdb

Add the --enable-pgo-build[=lto] configure option. When binutils+gdb is not built together with GCC, --enable-pgo-build enables the PGO build: 1. First build with -fprofile-generate. 2. Use "make maybe-check-*" to generate profiling data. 3. Use "make clean" to remove the previous build. 4.

[PATCH 2/3] Binutils: Pass --plugin to AR and RANLIB

Detect GCC LTO plugin. Pass --plugin to AR and RANLIB to support LTO build. bfd/ * configure: Regenerated. binutils/ * configure: Regenerated. gas/ * configure: Regenerated. gprof/ * configure: Regenerated. ld/ * configure: Regenerated. libctf/

Re: PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

On Thu, Oct 29, 2020 at 12:56:03PM -0400, Michael Meissner wrote: > On Wed, Oct 28, 2020 at 04:58:46PM -0500, Segher Boessenkool wrote: > > > #if defined (__LONG_DOUBLE_128__) && defined (__LONG_DOUBLE_IBM128__) > > > \ > > > && !(defined (_SOFT_FLOAT) || defined (__NO_FPRS__)) > > >

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

On Thu, Oct 29, 2020 at 12:50:10PM -0400, Michael Meissner wrote: > On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote: > > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote: > > > This patch adds long double variants of the power10 __float128 built-in > > >

Re: PowerPC: Add __float128 conversions to/from Decimal

On Thu, 29 Oct 2020, Segher Boessenkool wrote: > Hi! > > On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > > +#if HAVE_KF_MODE > > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > >

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

On Thu, Oct 29, 2020 at 12:47:20PM -0400, Michael Meissner wrote: > On Tue, Oct 27, 2020 at 09:38:20AM -0500, will schmidt wrote: > > > @@ -2420,6 +2423,8 @@ BU_P9V_64BIT_VSX_2 (VSIEDPF, > > > "scalar_insert_exp_dp", CONST, xsiexpdpf) > > > > > > BU_FLOAT128_HW_VSX_2 (VSIEQP,

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On 10/29/20 2:11 PM, Marek Polacek wrote: On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches wrote: On 10/28/20 7:40 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote: On 10/28/20 1:58 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at

[PATCH] LTO: get_section: add new argument

One more backport I've just tested: gcc/ChangeLog: PR lto/97508 * langhooks.c (lhd_begin_section): Call get_section with not_existing = true. * output.h (get_section): Add new argument. * varasm.c (get_section): Fail when NOT_EXISTING is true and

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches wrote: > On 10/28/20 7:40 PM, Marek Polacek wrote: > > On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote: > > > On 10/28/20 1:58 PM, Marek Polacek wrote: > > > > On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason

Re: PowerPC: Add __float128 conversions to/from Decimal

Hi! On Thu, Oct 29, 2020 at 12:45:15PM -0400, Michael Meissner wrote: > On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > > > +#if HAVE_KF_MODE > > > + strfromf128 (buf, BUFMAX, BFP_FMT, (BFP_VIA_TYPE) x); > > > +#else > > >sprintf (buf, BFP_FMT, (BFP_VIA_TYPE) x); > > >

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Qing Zhao writes: > Now, the documentation (gcc.info) is like following, let me know any issue > there: Yeah, looks good apart from merging > In order to satisfy users with different security needs and control > the run-time overhead at the same time, CHOICE parameter provides a >

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Qing Zhao via Gcc-patches writes: >>> +Return-Oriented Programming (ROP) or preventing information leak >> >> leakage >> >> (FWIW, I'm not sure “mitigating ROP” is really correct usage, but I don't >> have any better suggestions.) > > Do you mean whether “mitigating ROP’ is one of the major

Re: [PATCH][AArch64] ACLE intrinsics: convert from BFloat16 to Float32

Dennis Zhang writes: > diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def > b/gcc/config/aarch64/aarch64-simd-builtins.def > index 5bc596dbffc..b68c3ca7f4b 100644 > --- a/gcc/config/aarch64/aarch64-simd-builtins.def > +++ b/gcc/config/aarch64/aarch64-simd-builtins.def > @@ -732,3 +732,8

Re: Avoid char[] array in tree_def

On Thu, 29 Oct 2020, Jakub Jelinek wrote: > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote: > > > > > > That's ugly and will for sure defeat warning / access code > > > when we access this as char[], no? I mean, we could > > > as well use 'int str[1];' here? > > > > Well, we

Re: [PATCH] libstdc++: remove an ignored qualifier on function return type

On Fri, 28 Aug 2020 at 07:56, Krystian Kuźniarek via Libstdc++ wrote: > > > So then you need to produce a changelog entry by hand. > I had this problem on some old Ubuntu 18.04. Anyway, here's new ChangeLog: > > libstdc++-v3/ChangeLog: > > * include/std/variant: Fix

[PATCH] aarch64: Add backend support for expanding __builtin_memset

Hi This patch implements aarch64 backend expansion for __builtin_memset. Most of the implementation is based on the expansion of __builtin_memcpy. We change the values of SET_RATIO and MOVE_RATIO for cases where we do not have to strictly align and where we can benefit from NEON instructions

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

Jakub Jelinek writes: > On Tue, Oct 27, 2020 at 11:13:21AM +, Richard Sandiford via Gcc-patches > wrote: >> Sorry to stick my oar in, but I think we should reconsider the >> bcst_mem_operand approach. It seems like these patches (and the >> previous one) are fighting against the principle

[Patch] Fortran: Update omp atomic for OpenMP 5

The parser partially anticipates the upcoming OpenMP 5.1 changes, which adds some more clauses - but otherwise does not update it for OpenMP 5.1, yet. In particular, the "omp end atomic" for capture is still required and the memory-order-clause restrictions still apply. I am a bit unsure about

Re: PowerPC: Allow C/C++ to change long double type on GLIBC 2.32.

On Mon, Oct 26, 2020 at 05:48:48PM -0500, will schmidt wrote: > On Thu, 2020-10-22 at 18:15 -0400, Michael Meissner via Gcc-patches wrote: > > PowerPC: Allow C/C++ to change long double type on GLIBC 2.32. > > > > This is a new patch. It turns off the warning about switching the long > > double

Improve vec::copy mem stat annotations

Hi, this patch annotates vec::copy so it shows better in stats. I still do not see how auto vecs gets miscounted. Bootstrapped/regtested x86_64-linux, comitted. Honza * vec.h (vec::copy): Pass mem stat info. diff --git a/gcc/vec.h b/gcc/vec.h index 3ad26972a62..14d77e87342 100644 ---

Re: PowerPC: Update __float128 and __ibm128 error messages.

On Tue, Oct 27, 2020 at 06:27:22PM -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Oct 22, 2020 at 06:11:35PM -0400, Michael Meissner wrote: > > This patch attempts to make the error messages for intermixing IEEE 128-bit > > floating point with IBM 128-bit extended double types to be clearer

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

Hongtao Liu via Gcc-patches writes: > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford > wrote: >> >> Hongtao Liu via Gcc-patches writes: >> > Hi: >> > For inline asm, there could be an operand like (not (mem:)), it's >> > not a valid operand for normal memory constraint. >> > Bootstrap is

Re: Avoid char[] array in tree_def

> On Thu, 29 Oct 2020, Jan Hubicka wrote: > > > > > > > That's ugly and will for sure defeat warning / access code > > > when we access this as char[], no? I mean, we could > > > as well use 'int str[1];' here? > > > > Well, we always get char pointer via macro that is IMO OK, but I am also >

Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

Hongtao Liu via Gcc-patches writes: > On Thu, Oct 29, 2020 at 2:46 AM Richard Sandiford > wrote: >> >> Hongtao Liu writes: >> > On Tue, Oct 27, 2020 at 7:13 PM Richard Sandiford >> > wrote: >> >> >> >> Hongtao Liu via Gcc-patches writes: >> >> > Hi: >> >> > For inline asm, there could be an

Re: Avoid char[] array in tree_def

> On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote: > > > > > > That's ugly and will for sure defeat warning / access code > > > when we access this as char[], no? I mean, we could > > > as well use 'int str[1];' here? > > > > Well, we always get char pointer via macro that is IMO

Re: PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

On Tue, Oct 27, 2020 at 09:30:03AM -0500, will schmidt wrote: > On Thu, 2020-10-22 at 18:10 -0400, Michael Meissner via Gcc-patches wrote: > > PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit. > > > > I have split all of these patches into separate patches to hopefully get > >

Re: PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit.

On Wed, Oct 28, 2020 at 04:58:46PM -0500, Segher Boessenkool wrote: > Hi Mike, > > On Thu, Oct 22, 2020 at 06:10:37PM -0400, Michael Meissner wrote: > > PowerPC: Use __builtin_pack_ieee128 if long double is IEEE 128-bit. > > This title makes no sense, and thankfully is not what the patch does

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

On Wed, Oct 28, 2020 at 06:27:42PM -0500, Segher Boessenkool wrote: > On Thu, Oct 22, 2020 at 06:09:38PM -0400, Michael Meissner wrote: > > This patch adds long double variants of the power10 __float128 built-in > > functions. This is needed when long double uses IEEE 128-bit because > >

Re: PowerPC: Update IEEE 128-bit built-ins for long double is IEEE 128-bit.

On Tue, Oct 27, 2020 at 09:38:20AM -0500, will schmidt wrote: > > @@ -2420,6 +2423,8 @@ BU_P9V_64BIT_VSX_2 (VSIEDPF, "scalar_insert_exp_dp", > > CONST, xsiexpdpf) > > > > BU_FLOAT128_HW_VSX_2 (VSIEQP, "scalar_insert_exp_q", CONST, > > xsiexpqp_kf) > > BU_FLOAT128_HW_VSX_2 (VSIEQPF,

Re: PowerPC: Add __float128 conversions to/from Decimal

On Wed, Oct 28, 2020 at 07:04:31PM -0500, Segher Boessenkool wrote: > On Thu, Oct 22, 2020 at 06:06:03PM -0400, Michael Meissner wrote: > > This patch adds the various decimal to/from IEEE 128-bit conversions. I > > had to make some changes to the infrastructure, since that infrastructure > >

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Richard, Now, the documentation (gcc.info) is like following, let me know any issue there: thanks. Qing == 'zero_call_used_regs ("CHOICE")' The 'zero_call_used_regs' attribute causes the compiler to zero a subset of all call-used registers(1) at function return.

Re: [PATCH] libstdc++: Add c++2a

On 21/10/20 09:53 -0700, Thomas Rodgers wrote: From: Thomas Rodgers libstdc++/Changelog: libstdc++-v3/doc/doxygen/user.cfg.in (INPUT): Add new header. libstdc++-v3/include/Makefile.am (std_headers): Add new header. libstdc++-v3/include/Makefile.in: Regenerate.

Re: [PATCH 2/2] c++: Clean up constraint normalization routines

On 10/19/20 6:08 PM, Patrick Palka wrote: Many of the high-level constraint normalization routines allow the caller to supply the initial template arguments for normalization, but in practice all of the callers ultimately supply either NULL_TREE or a set of generic template arguments (*). Since

Re: [PATCH 1/2] c++: Tolerate empty initial targs during normalization [PR97412]

On 10/29/20 11:21 AM, Patrick Palka wrote: On Mon, 19 Oct 2020, Patrick Palka wrote: When normalizing the constraint-expression of a nested-requirement, we pass NULL_TREE as the initial template arguments for normalization, but tsubst_argument_pack is not prepared to handle a NULL_TREE targ

Re: [PATCH] c++: Fix up constexpr evaluation of arguments passed by invisible reference [PR97388]

On 10/29/20 11:40 AM, Jakub Jelinek wrote: On Thu, Oct 29, 2020 at 11:09:05AM -0400, Jason Merrill wrote: I think this isn't enough; if bar calls foo twice, the second call will find the value in the hash table and not change the temporary, so the destructor will throw. I think we also need to

Re: Avoid char[] array in tree_def

On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote: > > > > That's ugly and will for sure defeat warning / access code > > when we access this as char[], no? I mean, we could > > as well use 'int str[1];' here? > > Well, we always get char pointer via macro that is IMO OK, but I am

Re: Avoid char[] array in tree_def

On Thu, 29 Oct 2020, Jan Hubicka wrote: > > > > That's ugly and will for sure defeat warning / access code > > when we access this as char[], no? I mean, we could > > as well use 'int str[1];' here? > > Well, we always get char pointer via macro that is IMO OK, but I am also > not very much in

[PATCH] Fix some memleaks

This fixes some memleaks, one older, one recently introduced. Bootstrap / regtest in progress on x86_64-unknown-linux-gnu. 2020-10-29 Richard Biener * tree-ssa-pre.c (compute_avail): Free operands consistently. * tree-vect-loop.c (vectorizable_phi): Make sure all operand

Re: Avoid char[] array in tree_def

> > That's ugly and will for sure defeat warning / access code > when we access this as char[], no? I mean, we could > as well use 'int str[1];' here? Well, we always get char pointer via macro that is IMO OK, but I am also not very much in love with this. > > Maybe we can invent some C++

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

Re: Avoid char[] array in tree_def

> On Thu, Oct 29, 2020 at 04:50:54PM +0100, Jan Hubicka wrote: > > * tree.c (build_string): Update. > > * tree-core.h (tree_fixed_cst): Avoid typeless storage. > > Is it valid then to > #define TREE_STRING_POINTER(NODE) \ > ((const char *)(STRING_CST_CHECK (NODE)->string.str)) > and

Re: Avoid char[] array in tree_def

On Thu, 29 Oct 2020, Jan Hubicka wrote: > Hi, > this patch removes second char array from tree_def union and makes it > !TYPELESS_STORAGE. Now all accesses to anything in tree no longer have alias > set 0, but they all have alias set 1 :) > This is because the way we handle unions. However it

Re: [committed] libstdc++: Make std::function work better with -fno-rtti

On 29/10/20 14:49 +, Jonathan Wakely wrote: This change allows std::function::target() to work even without RTTI, using the same approach as std::any. Because we know what the manager function would be for a given type, we can check if the stored pointer has the expected address. If it does,

Re: Avoid char[] array in tree_def

On Thu, Oct 29, 2020 at 04:50:54PM +0100, Jan Hubicka wrote: > * tree.c (build_string): Update. > * tree-core.h (tree_fixed_cst): Avoid typeless storage. Is it valid then to #define TREE_STRING_POINTER(NODE) \ ((const char *)(STRING_CST_CHECK (NODE)->string.str)) and strcpy etc. it

Avoid char[] array in tree_def

Hi, this patch removes second char array from tree_def union and makes it !TYPELESS_STORAGE. Now all accesses to anything in tree no longer have alias set 0, but they all have alias set 1 :) This is because the way we handle unions. However it still increases TBAA effectivity by about 12%. From:

Re: [PATCH] c++: Fix up constexpr evaluation of arguments passed by invisible reference [PR97388]

On Thu, Oct 29, 2020 at 11:09:05AM -0400, Jason Merrill wrote: > I think this isn't enough; if bar calls foo twice, the second call will find > the value in the hash table and not change the temporary, so the destructor > will throw. I think we also need to set non_constant_args if the argument >

Re: [PATCH v2] c++: Implement CWG 625: Use of auto as template-arg [PR97479]

On 10/28/20 10:56 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 02:34:15PM -0400, Jason Merrill via Gcc-patches wrote: On 10/28/20 2:02 PM, Marek Polacek wrote: This patch implements CWG 625 which prohibits using auto in a template argument. A few tests used this construction. We could

Re: [PATCH 1/2] c++: Tolerate empty initial targs during normalization [PR97412]

On Mon, 19 Oct 2020, Patrick Palka wrote: > When normalizing the constraint-expression of a nested-requirement, we > pass NULL_TREE as the initial template arguments for normalization, but > tsubst_argument_pack is not prepared to handle a NULL_TREE targ vector. > This causes us to ICE when

Re: [PATCH] c++: Deprecate arithmetic convs on different enums [PR97573]

On 10/28/20 10:46 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 02:43:30PM -0400, Jason Merrill wrote: On 10/28/20 2:01 PM, Marek Polacek wrote: I noticed that C++20 P1120R0 deprecated certain arithmetic conversions as outlined in [depr.arith.conv.enum], but we don't warn about them. In

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On 10/28/20 7:40 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 03:09:08PM -0400, Jason Merrill wrote: On 10/28/20 1:58 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 01:26:53AM -0400, Jason Merrill via Gcc-patches wrote: On 10/24/20 7:40 PM, Marek Polacek wrote: On Fri, Oct 23, 2020 at

Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742]

On 10/28/20 10:45 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 05:48:08PM -0400, Jason Merrill wrote: On 10/28/20 5:29 PM, Marek Polacek wrote: On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote: On 10/28/20 2:00 PM, Marek Polacek wrote: On Tue, Oct 27, 2020 at 01:36:30PM

Re: [PATCH] c++: Diagnose constexpr delete [] new int; and delete new int[N]; [PR95808]

On 10/16/20 5:42 AM, Jakub Jelinek wrote: Hi! This patch diagnoses delete [] new int; and delete new int[1]; in constexpr contexts by remembering IDENTIFIER_OVL_OP_FLAGS (DECL_NAME (fun)) & OVL_OP_FLAG_VEC from the operator new and checking it at operator delete time. Bootstrapped/regtested on

  1   2   >