Re: Detect EAF flags in ipa-modref

On Sun, 15 Nov 2020, Jan Hubicka wrote: > > See PR97840. > Thanks, > this is a false positive where we fail to discover that pointed-to type > is empty on non-x86_64 targets. This is triggered by better alias > analysis caused by non-escape discovery. > > While this is not a full fix (I hope

Re: [PATCH] testsuite: guality/redeclaration1.C test workaround

On Fri, 13 Nov 2020, Jakub Jelinek wrote: > Hi! > > Apparently older GDB versions didn't handle this test right and so while > it has been properly printing 42 on line 14 (e.g. on x86_64), it issued > a weird error on line 17 (and because it didn't print any value, guality > testsuite wasn't

Re: [PATCH, rs6000] Add non-relative jump table support on Power Linux

Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html Thanks. Gui Haochen On 6/11/2020 上午 9:02, HAO CHEN GUI wrote: Hi, Gentle ping this: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html Thanks. Gui Haochen On 15/10/2020 下午 4:46,

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

On 11/14/20 12:29 PM, Liu Hao via Gcc-patches wrote: This is the third revision of my patch: 1. Two typos in the commit message have been fixed. 2. Support for `%a` and `%A` has been added. Documentation can be found on the same page in the commit message. 3. GCC will no longer warn about

[PATCH 2/2] Power10: Add IEEE 128-bit fp conditional move

Power10: Add IEEE 128-bit fp conditional move. This patch adds the support for power10 IEEE 128-bit floating point conditional move and for automatically generating min/max. Unlike the previous patch, I decided to keep two separate patterns for fpmask before splitting (one pattern for normal

[PATCH 1/2] Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.

Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support. This patch adds the support for the IEEE 128-bit floating point C minimum and maximum instructions. The next patch will add the support for using the compare and set mask instruction to implement conditional moves. Originally, I tried to

[PATCH 0/2] Power10 IEEE 128-bit min, max, cmove

These two patches add support for the XSMAXCQP, XSMINCQP, XSCMP{EQ,GT,GE}QP instructions in the Power10. These instructions allow the compiler to generate minimum, maxmimum, and conditional move support for IEEE 128-bit floating point type. I have posted versions of these patches before, going

[PATCH] c++: Extend -Wrange-loop-construct for binding-to-temp [PR94695]

[ This year's end-of-stage1 I'm working virtually from American Samoa. ] This patch finishes the second half of -Wrange-loop-construct I promised to implement: it warns when a loop variable in a range-based for-loop is initialized with a value of a different type resulting in a copy. For

Improve handling of memory operands in ipa-icf 4/4

Hi, this patch implements the logic to drop base alias sets (and thus also access paths) from memory operands when doing so helps merging. This is done by extending func_checker::compare_operand to record mismatched pairs and then processing this in sem_function::equals_private when comparsion

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

This patch implements the long-desired -Wuninitialized warning for member initializer lists, so that the front end can detect bugs like struct A { int a; int b; A() : b(1), a(b) { } }; where the field 'b' is used uninitialized because the order of member initializers in the

Re: BoF DWARF5 patches (25% .debug section size reduction)

On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote: > On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote: > > On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote: > > > --- a/gcc/doc/invoke.texi > > > +++ b/gcc/doc/invoke.texi > > > @@ -9057,13 +9057,14 @@ possible. > > >

[committed] MSP430: Fix inconsistent naming of hwmult libfuncs

The naming scheme used by GCC to reference MSP430 hardware multiply library functions is inconsistent. Sometimes the "GCC" names (e.g. mulsi2) are used, other times the "MSPABI" names (e.g. __mspabi_mpyl) are used. The __mspabi names should always be used. Also, sometimes an identifier for the

[committed] MSP430: Define function to check 16-bit hwmult support

Rather than inferring 16-bit hwmult support from lack of 32-bit/f5series/none hwmult support, define a function which explicitly checks for 16-bit hwmult support. Successfully regtested for msp430-elf. Committed as obvious. >From 814949ddceaef59725c84fe8ef7c6c617fb5d049 Mon Sep 17 00:00:00 2001

[PATCH 3/3] Implement the "persistent" attribute

The "persistent" attribute is used for variables that are initialized by the program loader, but are not initialized by the runtime startup code. "persistent" variables are placed in a non-volatile area of memory, which allows their value to "persist" between processor resets. Successfully

[PATCH 2/3] cp/decl.c: Set DECL_INITIAL before attribute processing

Attribute handlers may want to examine DECL_INITIAL for a decl, to validate the attribute being applied. For C++, DECL_INITIAL is currently not set until cp_finish_decl, by which time attribute validation has already been performed. For msp430-elf this causes the "persistent" attribute to always

[PATCH V2 0/3] Fix "noinit" attr, implement "persistent" attr

This patch series is version 2 of https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557184.html The implementation is now simplified so as to not use a symtab flag for "noinit" variables, instead we just check whether the decl has the attribute set. This patch series fixes behavior related

[PATCH 1/3] Fix "noinit" attribute being ignored for -O0 and -fdata-sections

Variables with the "noinit" attribute are ignored at -O0 because they are treated like a regular bss variable and placed in the .bss section. With -fdata-sections they are ignored because they are not handled in resolve_unique_section. Successfully regtested for arm-none-eabi. Ok for trunk?

Re: [PATCH, v1] PR fortran/48958 - Add runtime diagnostics for SIZE intrinsic function

Hi Harald, Feedback, such as comments for improvement, are welcome. It feels a bit strange to have a check for an allocatable behind -fcheck=pointer, but I'm not sure that introducing a special check option would really be worth it. Regarding pointers: They are usually not nullified (unless

[PATCH 2/2] MSP430: Add 64-bit hardware multiply support

Hardware multipliers that support widening 32-bit multiplication can be used to perform a 64-bit * 64-bit multiplication more efficiently than a software implementation. The following equation is used to perform 64-bit multiplication for devices with "32bit" or "f5series" hardware multiply

[PATCH 1/2] MSP430: Add mulhi, mulsi and {u,}mulsidi3 expanders

GCC generates better code when multiplication operations, which require library functions to perform, are caught in early in RTL, rather than leaving the operation to be mapped to a library function later on. When there is hardware multiply support, it is more efficient to perform widening

[PATCH 0/2] Improve MSP430 hardware multiply support

The attached patch series improves MSP430 hardware multiply support, by improving code generation when setting up the 16-bit and 32-bit hardware multiply functions, and adding a 64-bit hardware multiply library function for devices that have a 32-bit hardware multiplier. Successfully regtested

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

On Tue, 10 Nov 2020, Jeff Law via Gcc-patches wrote: > >>> 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? > >> > > almost 2.4GB. > > see bugzilla comment #4. > >

Re: OpenACC 'kernels' testsuite failures

Thomas, I am seeing a number of new failures on AIX related to the OpenACC kernels patches. c-c++-common/goacc/kernels-decompose-1.c c-c++-common/goacc/kernels-decompose-2.c gfortran.dg/goacc/kernels-decompose-1.f95 gfortran.dg/goacc/kernels-decompose-2.f95

Re: [C PATCH RFC] Drop qualifiers during lvalue conversion

Am Montag, den 09.11.2020, 23:41 + schrieb Joseph Myers: > On Sat, 7 Nov 2020, Uecker, Martin wrote: > >   t = (const T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } }; > >   test (); > > } > > > > Not sure what to do about it, maybe 'convert' is not > > the right function to use. > > I think

Add EAF_NOT_RETURNED flag

Hi, one of common cases why we lose track on SSA name in modref propagation is the situation where name is passed to funtion call and we then thus continue by propagating through return value. This patch adds simple logic to track arguments that does not escape to return value. On cc1plus the

Re: [PATCH 2/2] libada: Check for the presence of _SC_NPROCESSORS_ONLN

> gcc/ada/ > * adaint.c (__gnat_number_of_cpus): Check for the presence of > _SC_NPROCESSORS_ONLN before using it. > --- > NB we could probably replace the list of OS #ifdefs with just a check for > _SC_NPROCESSORS_ONLN, making use of it automagically with any new OS that >

Re: Detect EAF flags in ipa-modref

> See PR97840. Thanks, this is a false positive where we fail to discover that pointed-to type is empty on non-x86_64 targets. This is triggered by better alias analysis caused by non-escape discovery. While this is not a full fix (I hope someone with more experience on C++ types and warnings

[patch, fortran] Correct fndecls for some library functions

Hello world, this patch makes sure that we pass the correct fn decls for some of our library functions. cshift and others still remain to be implemented. This is a step in our voyage to stop lying to the middle end :-) Regression-tested. OK for trunk? Best regards Thomas Generate

[committed] VAX: Use `rtx_code' to hold the RTL expression code in `vax_rtx_costs'

Use `enum rtx_code' rather than `int' to hold the the RTL expression code in `vax_rtx_costs', matching the type these codes have been defined with and making debugging just a tiny little bit easier. gcc/ * config/vax/vax.c (vax_rtx_costs): Use `rtx_code' rather than

[committed] VAX/testsuite: Fix compilation options for `bswapdi-1.c'

Correct a regression in `vax-netbsdelf' gcc testing: .../gcc/testsuite/gcc.target/vax/bswapdi-1.c: In function '__bswapdi2': .../gcc/testsuite/gcc.target/vax/bswapdi-1.c:5:19: error: use of C99 long long integer constant [-Wlong-long] .../gcc/testsuite/gcc.target/vax/bswapdi-1.c:6:14: error: use

[PATCH 0/2] Fixes for old version NetBSD targets

Hi, In the course of my recent VAX backend modernisation effort I originally tried the initial version of the VAX/NetBSD port that provided ELF file format support, specifically 1.6.2, which at least in theory we aim to support with the `vax-netbsdelf' target. That indeed turned out to be a

[PATCH 2/2] libada: Check for the presence of _SC_NPROCESSORS_ONLN

Check for the presence of _SC_NPROCESSORS_ONLN rather than using it unconditionally with `sysconf', fixing a compilation error: adaint.c: In function '__gnat_number_of_cpus': adaint.c:2398:26: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function) 2398 | cores = (int) sysconf

[PATCH 1/2] NetBSD/libgcc: Check for TARGET_DL_ITERATE_PHDR in the unwinder

Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions, fixing compilation errors: .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr' 75 | # define ElfW(type) Elf_##type | ^~~~ .../libgcc/unwind-dw2-fde-dip.c:132:9: note: in

[committed] VAX: Correct a typo in PIC symbolic addition operand checks

Fix a typo and check both SImode addition operands for being incorrectly symbolic in PIC mode before issuing a diagnostic dump of the offending RTL expression. gcc/ * config/vax/vax.c (vax_output_int_add) : Also check `operands[2]' for being symbolic with PIC rather than

[committed] VAX: Fix a typo in NO_EXTERNAL_INDIRECT_ADDRESS

Fix a typo in a NO_EXTERNAL_INDIRECT_ADDRESS macro check around an assertion verifying DImode addition operands to be valid for PIC. gcc/ * config/vax/vax.c (vax_output_int_add) : Fix a typo in NO_EXTERNAL_INDIRECT_ADDRESS. --- Hi, No regressions in `vax-netbsdelf'

[PATCH] PowerPC: Restrict long double test to use IBM long double.

PowerPC: Restrict long double test to use IBM long double. I posted this patch previously as a set of 3 testsuite patches. I have separated them into separate patches. This patch marks the convert-bfp-11.c patch as needing IBM extended double. If you look at the code, it is specifically

[PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.

>From 698d9fd8a5701fa4ed9690ddf71d57765921778c Mon Sep 17 00:00:00 2001 From: Michael Meissner Date: Sun, 15 Nov 2020 00:48:23 -0500 Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test. This patch was previously posted as a combined patch with 2 other testsuite patches. I moved it

[PATCH] Include math.h in nextafter-2.c test.

Include math.h in nextafter-2.c test. I previously posted this with two other patches. I've separated this into its own patch. What happens is because the nextafter-2.c test uses -fno-builtin, and it does not include math.h, the wrong nextafterl and nextforwardl gets called when long double is

[Committed] patch fixing LRA crash on s390x

My last patch implementing output reloads in asm goto resulted in LRA crash in compiling kernel on s390x.  Jeff Law reported it recently.  The culprit was in incorrect emitting reload insns in last empty BB.  The emitted insns got null BB which is wrong. Actually in this case we do not need to

[pushed] c++: Check abstract type only on object creation. [PR86252]

Abstract checking has been problematic for a while; when I implemented an earlier issue resolution to do more checking it led to undesirable instantiations, and so backed some of it out. During the C++20 process we decided with P0929R2 that we should go the other way, and only check abstractness

Re: [PATCH] Remove vr_values::extract_range_builtin.

Since Jeff says that the latest Fedora build went fine, we can safely remove the duplicated code in vr_values. Here is the original proposal rebased for latest trunk. Tested on x86-64 Linux. Pushed. commit 82b6d25d289195d41e53fc91f63325864e3e28d0 Author: Aldy Hernandez Date: Wed Oct 28

Re: Detect EAF flags in ipa-modref

See PR97840. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."

Re: Detect EAF flags in ipa-modref

Hi Jan, >> > When I configure with ../configure --enable-languages=go my build >> > eventually finishes fine on curren trunk: >> [...] >> > On Debian SLES machines. Having preprocessed go-diagnostics.cc and >> > .uninit1 dump would probably help. >> >> apart from go/diagnostics.cc, I see the

Re: [PATCH] SLP vectorize across PHI nodes

On Fri, Oct 30, 2020 at 2:46 AM Richard Biener wrote: > > On Fri, 30 Oct 2020, Richard Sandiford wrote: > > > Richard Biener writes: > > > On Wed, 28 Oct 2020, Christophe Lyon wrote: > > > > > >> On Wed, 28 Oct 2020 at 11:27, Christophe Lyon > > >> wrote: > > >> > > > >> > On Tue, 27 Oct 2020

Re: Detect EAF flags in ipa-modref

> On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote: > > > > On Tue, 10 Nov 2020, Jan Hubicka wrote: > > > > > Hi, > > > here is updaed patch. > > > > > > Honza > > > > > > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)? > > > > OK. > > > > Thanks, > > Richard. > > > > This

Re: Detect EAF flags in ipa-modref

On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote: > > On Tue, 10 Nov 2020, Jan Hubicka wrote: > > > Hi, > > here is updaed patch. > > > > Honza > > > > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)? > > OK. > > Thanks, > Richard. > This caused:

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

On 2020-11-13 09:41, Richard Biener wrote: > On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches > wrote: >> diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c >> index 2a409dcaffe..58b16aa763a 100644 >> --- a/gcc/tree-eh.c >> +++ b/gcc/tree-eh.c >> @@ -2077,6 +2077,8 @@ lower_eh_constructs_2

Re: Detect EAF flags in ipa-modref

> Hi Jan, > > >> I'm seeing the same on both i386-pc-solaris2.11 and > >> sparc-sun-solaris2.11, so I don't think there are special configure > >> flags involved. > > > > When I configure with ../configure --enable-languages=go my build > > eventually finishes fine on curren trunk: > [...] > > On

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

On 2020-11-12 16:51, Jeff Law wrote: > > On 3/11/20 6:38 PM, J.W. Jagersma via Gcc-patches wrote: >> 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

Re: Detect EAF flags in ipa-modref

Hi Jan, >> I'm seeing the same on both i386-pc-solaris2.11 and >> sparc-sun-solaris2.11, so I don't think there are special configure >> flags involved. > > When I configure with ../configure --enable-languages=go my build > eventually finishes fine on curren trunk: [...] > On Debian SLES

Re: Detect EAF flags in ipa-modref

> Hi Jan, > > >> This breaks bootstrap with go. > >> > >> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string > >> expand_message(const char*, va_list)': > >> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may > >> be used uninitialized

Re: Detect EAF flags in ipa-modref

Hi Jan, >> This breaks bootstrap with go. >> >> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string >> expand_message(const char*, va_list)': >> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may >> be used uninitialized [-Werror=maybe-uninitialized] >> 110 |

Re: Detect EAF flags in ipa-modref

> This breaks bootstrap with go. > > ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string > expand_message(const char*, va_list)': > ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be > used uninitialized [-Werror=maybe-uninitialized] > 110 |

Re: Detect EAF flags in ipa-modref

This breaks bootstrap with go. ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string expand_message(const char*, va_list)': ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be used uninitialized [-Werror=maybe-uninitialized] 110 | "memory

IPA propagation of EAF flags in ipa-modref

Hi, this patch implements the IPA propagation part of EAF flags handling in ipa-modref. It extends the local analysis to collect lattice consisting of flags and escape points (SSA name escapes if it is passed directly or indirectly to a function call) If useful flags are found for parameter its

Re: Decompose OpenACC 'kernels' constructs into parts, a sequence of compute constructs (was: [og8] OpenACC 'kernels' construct changes: splitting of the construct into several regions)

Hi Thomas, regarding the new option: +fopenacc-kernels= +C ObjC C++ ObjC++ RejectNegative Joined Enum(openacc_kernels) Var(flag_openacc_kernels) Init(OPENACC_KERNELS_PARLOOPS) +-fopenacc-kernels=[decompose|parloops] Specify mode of OpenACC 'kernels' constructs handling. + and On 13.11.20