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;

[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

[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] 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] 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] maintainer-scripts: Fix jit documentation build with update_web_docs_git

Hi! scripts/update_web_docs_git -r 9.3.0 -d gcc-9.3.0 failed after the sourceware upgrade, there is no python-sphinx10 package and python3-sphinx is new enough that the docs build succeeded. Ok for trunk? 2020-03-12 Jakub Jelinek * update_web_docs_git: Use

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

On Thu, Mar 12, 2020 at 01:58:20AM -0400, Jason Merrill wrote: > > + if (reuse && nelts < CONSTRUCTOR_NELTS (new_init)) > > + { > > + vec *v = NULL; > > + if (nelts) > > vec_alloc does nothing if nelts is 0, so this test seems unnecessary. OK > either way. I wasn't sure, but now

Re: [PATCH] tree-dse: Fix mem* head trimming if call has lhs [PR94130]

On Thu, Mar 12, 2020 at 09:20:08AM +0100, Richard Biener wrote: > On Thu, 12 Mar 2020, Jakub Jelinek wrote: > > > Hi! > > > > As the testcase shows, if DSE decides to head trim > > {mem{set,cpy,move},strncpy} > > and the call has lhs, it is incorrect to leave the lhs as is, because it > > will

[PATCH] doc: Fix up ASM_OUTPUT_ALIGNED_DECL_LOCAL description

Hi! When looking into PR94134, I've noticed bugs in the ASM_OUTPUT_ALIGNED_DECL_LOCAL documentation. varasm.c has: #if defined ASM_OUTPUT_ALIGNED_DECL_LOCAL unsigned int align = symtab_node::get (decl)->definition_alignment (); ASM_OUTPUT_ALIGNED_DECL_LOCAL (asm_out_file, decl, name,

[PATCH] tree-dse: Fix mem* head trimming if call has lhs [PR94130]

Hi! As the testcase shows, if DSE decides to head trim {mem{set,cpy,move},strncpy} and the call has lhs, it is incorrect to leave the lhs as is, because it will then point to the adjusted address (base + head_trim) instead of the original base. The following patch fixes that by dropping the lhs

[committed] maintainer-scripts: Fix up gcc_release without -l, where mkdir was using umask 077 after migration

Hi! After the sourceware migration, seems the gcc_release -u gccadmin ... created directories had 2700 permissions instead of 2755. Fxed thusly, committed to trunk. 2020-03-12 Jakub Jelinek * gcc_release (upload_files): Without -l, pass -m 755 to the mkdir command invoked

[PATCH] aarch64: Fix another bug in aarch64_add_offset_1 [PR94121]

On Thu, Mar 12, 2020 at 12:27:48PM +0100, Andreas Schwab wrote: > I'm getting this ICE with -mabi=ilp32: > > during RTL pass: fwprop1 > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c: In function 'bar': > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/pr94121.c:16:1: internal compiler > error:

[committed] Fix doubled indefinite articles, mostly in comments.

Hi! Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and committed to trunk as obvious. 2020-03-14 Jakub Jelinek * gimple-fold.c (gimple_fold_builtin_strncpy): Change "a an" to "an" in a comment. * hsa-common.h (is_a_helper): Likewise. *

[PATCH] tree-inline: Fix a -fcompare-debug issue in the inliner [PR94167]

Hi! The following testcase fails with -fcompare-debug. The problem is that bar is marked as address_taken only with -g and not without. I've tracked it down to insert_init_stmt calling gimple_regimplify_operands even on DEBUG_STMTs. That function will just insert normal stmts before the

[PATCH] c++: Fix parsing of invalid enum specifiers [PR90995]

Hi! The testcase shows some accepts-invalid (the ones without alignas) and ice-on-invalid-code (the ones with alignas) cases. If the enum doesn't have an underlying type and is not a definition, the caller retries to parse it as elaborated type specifier. E.g. for enum struct S s it will then

[PATCH] reassoc: Avoid code generation to depend on hash_map traversal [PR94166]

Hi! On the following testcase, if there is ASLR, the compiler generates different code each time (out of 1000 invocations 994 unique assembler contents). The problem is that undistribute_bitref_for_vector uses a hash_map from a tree (SSA_NAME) to a vector and such a hash_map is by default doing

[committed] tree-nested: Fix handling of *reduction clauses with C array sections [PR93566]

Hi! tree-nested.c didn't handle C array sections in {,task_,in_}reduction clauses. The following patch implements that, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk so far. 2020-03-14 Jakub Jelinek PR middle-end/93566 * tree-nested.c

[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] 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 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: require tls_runtime for tls execution test

On Wed, Apr 08, 2020 at 12:04:16PM -0300, Alexandre Oliva wrote: > > All TLS execution tests require tls_runtime, not just tls; pr78796.c > is the only exception that is not otherwise limited to platforms known > to support it. I suppose that's an oversight. On a platform whose > linker is

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Wed, Apr 08, 2020 at 05:46:52PM +0200, Jan Hubicka wrote: > I am not quite sure about the offloading done by openMP - I think that > one produces new decls. Yes, it does. It copies some FUNCTION_DECL flags over, but only selected ones (and all attributes but removes a few afterwards).

[committed] openacc: Fix up declare-pr94120.C testcase [PR94533]

Hi! On Wed, Mar 11, 2020 at 02:28:44PM +0100, Tobias Burnus wrote: > gcc/testsuite/ > PR middle-end/94120 > * c-c++-common/goacc/declare-pr94120.c: New. > * g++.dg/declare-pr94120.C: New. This test has been put in a wrong directory, where OpenACC tests aren't tested with

[PATCH] cselib, reload: Fix cselib ICE on m68k/microblaze [PR94526]

Hi! The following testcase ICEs on m68k (and another one Jeff mailed me privately on microblaze). The problem is that reload creates two DEBUG_INSNs with the same value of (plus:P (reg:P sp) (const_int 0)), we compute correctly the same hash value for them, but then don't find them in the cselib

[PATCH] vect: Fix up lowering of TRUNC_MOD_EXPR by negative constant [PR94524]

Hi! The first testcase below is miscompiled, because for the division part of the lowering we canonicalize negative divisors to their absolute value (similarly how expmed.c canonicalizes it), but when multiplying the division result back by the VECTOR_CST, we use the original constant, which can

Re: [PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

On Thu, Apr 09, 2020 at 10:57:46PM +0200, Christophe Lyon via Gcc-patches wrote: > This patch makes GCC fail to build newlib when configured for > aarch64_be-none-elf: > 0x10c488c vt_expand_var_loc_chain > > /tmp/9192639_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/var-tracking.c:8355

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote: > +/* Valid pairs of new and delete operators for DCE. */ > +static hash_set *valid_pairs = NULL; > + > +/* Return that NEW_CALL and DELETE_CALL are a valid pair of new > + and delete operators. */ > + > +static bool >

Re: [Patch] libgomp – fix handling of 'target enter data'

On Fri, Apr 10, 2020 at 04:31:37PM +0200, Thomas Schwinge wrote: > Aha, thanks -- that resolves doubts I had (but Julian and I couldn't > allocate time to track down): see 'GOMP_target_enter_exit_data' mentioned > in > ff., for

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Thu, Apr 09, 2020 at 08:59:59AM +0200, Martin Liška wrote: > What do you mean by 'decl flags'. We can't compare ASM names as one is ctor > and the second one is dtor. It's about argument types that much match, right? You can't disginguish the [] vs. non-[] from arguments, plus there are some

Re: [PATCH] aarch64: Fix bootstrap with old binutils [PR93053]

On Wed, Apr 15, 2020 at 08:27:43AM +, Kyrylo Tkachov wrote: > > I've been testing this in distro scratch builds, so I don't really have > > there the old assembler, but bootstrapped/regtested 5 times, for each of the > > two patches once as is and once with s/cas/caszz/ in the configure{.ac,}

[committed] openmp: Reject requires directives not at file or namespace scope [PR94593]

Hi! This change started with a bugreport about a typo in one requires testcase (diagnosed with -Wunknown-pragmas only), but following discussion lead to noting that we do not diagnose restriction that requires directives in C/C++ may only appear at file or namespace scope; and several our tests

[PATCH] c++: Fix pasto in structured binding diagnostics [PR94571]

Hi! This snippet has been copied from the non-structured binding declaration parsing later in the function, and while for non-structured bindings it can be followed by comma or semicolon, structured bindings may be only followed by semicolon. Fixed thusly, bootstrapped/regtested on x86_64-linux

Re: [PATCH] Fold (add -1; zero_ext; add +1) operations to zero_ext when not zero (PR37451, PR61837)

On Wed, Apr 15, 2020 at 03:47:55AM -0500, luoxhu--- via Gcc-patches wrote: > 2020-04-15 Xiong Hu Luo > > PR rtl-optimization/37451, PR target/61837 > loop-doloop.c (doloop_modify): Simplify (add -1; zero_ext; add +1) "* " missing before loop-doloop.c > to zero_ext. >

[PATCH] aarch64: Fix bootstrap with old binutils [PR93053]

Hi! As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build when using older binutils which lack LSE support, because those instructions are used in libgcc. Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build even with older binutils by using .inst

[PATCH] bootstrap: Fix building with GCC 4.2 [PR89494]

Hi! GCC 4.2 (but I think not the latest tip of GCC 4.2 branch) has broken value initialization, see PR33916. The following patch provides a workaround for that. Tested with GCC 4.2 on a reduced testcase I've distilled from the assign_param_data_one class which has been miscompiled the same, and

[PATCH] intl: Allow building both with old bison and bison >= 3 [PR92008]

Hi! bison 3 apparently made a backwards incompatible change, dropped YYLEX_PARAM/YYPARSE_PARAM support and instead needs %param or %lex-param and %parse-param. Furthermore, there is no easy way to conditionalize on bison version in the *.y files. While e.g. glibc bumped bison requirement and

Re: [PATCH] c++: Hard error with tentative parse of declaration [PR88754]

On Fri, Apr 17, 2020 at 12:45:37PM -0400, Jason Merrill via Gcc-patches wrote: > On 4/16/20 7:33 PM, Patrick Palka wrote: > > In the testcase for this PR, we try to parse the statement > > > >A(value<0>()); > > > > first tentatively as a declaration (with a parenthesized declarator), and >

Re: [Patch][OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)

On Fri, Apr 17, 2020 at 05:57:06PM +0200, Tobias Burnus wrote: > --- a/gcc/gimplify.c > +++ b/gcc/gimplify.c > @@ -8785,11 +8785,15 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq > *pre_p, >'exit data' - and in particular for 'delete:' - having an 'alloc:' >does

Patch ping: Re: [PATCH] combine: Fix split_i2i3 ICE [PR94291]

Hi! I'd like to ping this P1 PR fix: On Tue, Mar 31, 2020 at 09:04:18AM +0200, Jakub Jelinek via Gcc-patches wrote: > 2020-03-31 Jakub Jelinek > > PR rtl-optimization/94291 > * combine.c (try_combine): For split_i2i3, don't assume SET_DEST > must be a REG o

[committed] openmp: Fix parallel master error recovery [PR94512]

Hi! We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master succeeded, because otherwise there is no nested master construct in the parallel. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk, queued for backporting to 9.x. 2020-04-07 Jakub

Re: libgcc patch committed: Avoid hooks in split-stack code

On Tue, Apr 07, 2020 at 12:19:45PM +0200, Richard Biener via Gcc-patches wrote: > On Fri, Apr 3, 2020 at 11:59 PM Ian Lance Taylor via Gcc-patches > wrote: > > > > The split-stack code invokes mmap and munmap with a limited amount of > > stack space. That is fine when the functions just make a

[PATCH] i386: Fix V{64QI,32HI}mode constant permutations [PR94509]

Hi! The following testcases are miscompiled, because expand_vec_perm_pshufb incorrectly thinks it can use vpshufb instruction for the permutations when it can't. The if (vmode == V32QImode) { /* vpshufb only works intra lanes, it is not

Backports to 9.4

Hi! I've backported following 21 commits from trunk to 9.4, bootstrapped/regtested on x86_64-linux and i686-linux and committed to 9 branch. Jakub >From 980a7a0be5a114e285c49ab05ac70881e4f27fc3 Mon Sep 17 00:00:00 2001 From: Jakub Jelinek Date: Tue, 17 Mar 2020 21:21:16 +0100 Subject:

[PATCH] postreload: Fix autoinc handling in reload_cse_move2add [PR94516]

Hi! The following testcase shows two separate issues caused by the cselib changes. One is that through the cselib sp tracking improvements on ... r12 = rsp; rsp -= 8; push cst1; push cst2; push cst3; call rsp += 32; rsp -= 8; push cst4; push cst5; push cst6; call rsp += 32; rsp -= 8; push cst7;

[PATCH] aarch64: Fix {ash[lr],lshr}3 expanders [PR94488]

Hi! The following testcase ICEs on aarch64 apparently since the introduction of the aarch64 port. The reason is that the {ashl,ashr,lshr}3 expanders completely unnecessarily FAIL; if operands[2] is something other than a CONST_INT or REG or MEM and the middle-end code can't cope with the pattern

[committed] cselib: Fix endless cselib loop on (plus:P (reg) (const_int 0))

Hi! getopt.c hangs the compiler on h8300-elf with -O2 -g, because the IL contains addition of constant 0, the first PLUS operand is determined to have the SP_DERIVED_VALUE_P and the new code in cselib recurses indefinitely on seeing SP_DERIVED_VALUE_P with locs of (plus:P SP_DERIVED_VALUE_P

[PATCH] c++: Further fix for -fsanitize=vptr [PR94325]

Hi! For -fsanitize=vptr, we insert a NULL store into the vptr instead of just adding a CLOBBER of this. build_clobber_this makes the CLOBBER conditional on in_charge (implicit) parameter whenever CLASSTYPE_VBASECLASSES, but when adding this conditionalization to the -fsanitize=vptr code in

[PATCH] i386: Fix emit_reduc_half on V{64Q,32H}Imode [PR94500]

Hi! The following testcase is miscompiled in 8.x, because emit_reduc_half is prepared to handle for 512-bit modes only i equal to 512, 256, 128 and 64. V32HImode also needs i equal to 32 and V64QImode i equal to 32 and 16, but emit_reduc_half in that case performs a redundant permutation exactly

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote: > +/* PR c++/94314. */ > +/* { dg-do run } */ > +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */ > +/* { dg-additional-options "-fdelete-null-pointer-checks" } */ Any reason why you want to do it for -std=c++14 only?

Re: Merge dg-options and dg-additional-options (with a target directive)?

On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote: > Hi. > > I've noticed that various files compile both these directives. > Do we want to merge them into dg-options? I'd defer for GCC11, and only do it if the line doesn't get way too long. Jakub

Re: Merge dg-options and dg-additional-options (with a target directive)?

On Tue, Apr 14, 2020 at 01:39:43PM +0200, Martin Liška wrote: > On 4/14/20 1:26 PM, Jakub Jelinek wrote: > > On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote: > > > Hi. > > > > > > I've noticed that various files compile both these directives. > > > Do we want to merge them into

[committed] testsuite: Add testcase for already fixed PR [PR94573]

Hi! The following testcase is optimized since Eric's r10-3575 change. Tested on x86_64-linux -m32/-m64 (and in 9 where it FAILs), committed to trunk as obvious. 2020-04-14 Jakub Jelinek PR tree-optimization/94573 * gcc.dg/store_merging_30.c: New test. ---

Re: [PATCH] i386: Remove mode size check in ix86_get_ssemov

On Sat, Apr 11, 2020 at 02:48:22PM -0700, H.J. Lu via Gcc-patches wrote: > Even though ix86_hard_regno_mode_ok doesn't allow xmm16-xmm31 nor > ymm16-ymm31 in 128/256 bit modes when AVX512VL is disabled, reload > can still generate reg to reg moves with xmm16-xmm31 and ymm16-ymm31 > in 128/256 bit

[PATCH] csa, postreload: Improve csa after recent cselib changes [PR94516]

Hi! This patch addresses a missed optimization caused by the cselib changes. Already in the past postreload could replace sp = sp + const_int with sp = regxy if regxy already has the right value, but with the cselib changes it happens several times more often. It can result in smaller code, so

[PATCH] ubsan: Avoid -Wpadded warnings [PR94641]

Hi! -Wpadded warnings aren't really useful for the artificial types that GCC lays out for ubsan. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2020-04-20 Jakub Jelinek PR c/94641 * ubsan.c (ubsan_get_type_descriptor_type,

[PATCH v2] ubsan: Avoid -Wpadded warnings [PR94641]

Hi! On Tue, Apr 21, 2020 at 08:21:36AM +0200, Richard Biener wrote: > I believe most of those warnings should simply not look at > TYPE_ARTIFICIAL types. So why the above kludge certainly > works a better fix is on the -Wpadded side IMHO. So like this if it passes bootstrap/regtest? 2020-04-21

[PATCH] testsuite: Extend C++ struct-layout-1.exp testing to test C++14 vs. C++17 interoperability of structs with empty bases [PR94383]

Hi! Jonathan reported an ABI incompatibility between C++14 and C++17 in passing some aggregates with empty bases on aarch64 (and apparently on arm too). The following patch adds 3000 (by default) tests for such interoperability, using the struct-layout-1* framework. The current 3000 tests are

Re: [PATCH PR94678] aarch64: unexpected result with -mgeneral-regs-only and sve

On Tue, Apr 21, 2020 at 08:37:09AM +, Yangfei (Felix) wrote: > Yes, that's right. And I have a question here: > Should aarch64_sve::init_builtins ()/aarch64_sve::handle_arm_sve_h () be > guarded by TARGET_SVE? > > I mean in aarch64_init_builtins: > if (TARGET_SVE) >

[committed] testsuite: Add testcase for already fixed PR [PR94686]

Hi! This has been fixed by the PR71311 r7-1170-g4618c453205f18 change. Tested on x86_64-linux (also with gcc 6 where it ICEs), committed to trunk as obvious. 2020-04-21 Jakub Jelinek PR c/94686 * gcc.c-torture/compile/pr94686.c: New test. ---

Re: [AArch64] (PR94383) Avoid C++17 empty base field checking for HVA/HFA

On Tue, Apr 21, 2020 at 02:39:12PM +0100, Matthew Malcomson wrote: > --- a/gcc/config/aarch64/aarch64.c > +++ b/gcc/config/aarch64/aarch64.c > @@ -15909,13 +15909,30 @@ aarch64_conditional_register_usage (void) > } > } > > +enum cpp17empty_state { > +DONT_AVOID = 0, > +AVOID = 1, >

[PATCH] c, objc: Fix up c_parser_objc_selector_arg after CPP_SCOPE changes [PR94637]

Hi! Similarly to inline asm, :: (or any other number of consecutive colons) can appear in ObjC @selector argument and with the introduction of CPP_SCOPE into the C FE, we need to trat CPP_SCOPE as two CPP_COLON tokens. The C++ FE does that already that way. Bootstrapped/regtested on x86_64-linux

Re: [PATCH] Fix use of singleton in optinfo framework

On Mon, Apr 06, 2020 at 09:42:17PM -0400, David Malcolm via Gcc-patches wrote: > > 2020-04-06 Gustavo Romero > > > > * dumpfile.c: > > (selftest::temp_dump_context::temp_dump_context): Fix ctor. > > --- > > gcc/dumpfile.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >

Re: [PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

On Fri, Apr 10, 2020 at 11:54:49AM +0200, Jakub Jelinek via Gcc-patches wrote: > On Thu, Apr 09, 2020 at 10:57:46PM +0200, Christophe Lyon via Gcc-patches > wrote: > > This patch makes GCC fail to build newlib when configured for > > aarch64_be-none-elf: > > 0x10c488c

[committed] testsuite: Fix up pr94482.c testcase [PR94482]

On Wed, Apr 08, 2020 at 08:34:08PM +0200, Martin Jambor wrote: > 2020-04-08 Martin Jambor > Richard Biener > > PR tree-optimization/94482 > * tree-sra.c (create_access_replacement): Dump new replacement with > TDF_UID. > (sra_modify_expr): Fix handling of

Re: [PATCH v2] Fix use of singleton in optinfo framework

On Tue, Apr 07, 2020 at 11:12:48PM -0400, Gustavo Romero via Gcc-patches wrote: > Currently an use of get() method of dump_context singleton in optinfo > framework causes a new class to be instantiated and when its dtor > is called it calls delete on uninitialized data, causing an ICE. To be

[committed] inliner: Don't ICE on NULL TYPE_DOMAIN [PR94621]

Hi! When I've added the VLA tweak for OpenMP to avoid error_mark_nodes in the IL in type, I forgot that TYPE_DOMAIN could be NULL. Furthermore, as an optimization, this patch checks the hopefully cheapest condition that is very likely false most of the time (enabled only during OpenMP handling)

[PATCH] i386: Fix up *testqi_ext_3 define_insn_and_split [PR94567]

Hi! As the testcase shows, there are unfortunately more problematic cases in *testqi_ext_3 if the mode is not CCZmode, because the sign flag might not behave the same between the insn with zero_extract and what we split it into. The previous fix to the insn condition was because *testdi_1 for

Re: [PATCH] middle-end/94614 - avoid multiword moves to nothing

On Thu, Apr 16, 2020 at 10:05:32AM +0200, Richard Biener wrote: > 2020-04-16 Richard Biener > > PR middle-end/94614 > * expr.c (emit_move_multi_word): Do not generate code when > the destination part is undefined_operand_subword_p. > * lower-subreg.c (resolve_clobber):

Re: [stage1] [PATCH] Merge dg-options and dg-additional-options if len <= 120 chars.

On Thu, Apr 16, 2020 at 09:50:02AM +0200, Martin Liška wrote: > On 4/14/20 1:43 PM, Jakub Jelinek wrote: > > Roughly, yes. A few extra in testcases don't hurt necessarily, but say 160 > > chars or more is clearly too much. > > All right, I made a limit of 120 characters for the changes. > >

[PATCH] testsuite: Move misplaced gcc.c-torture/pr92372.c test [PR92372]

Hi! This test got committed into a spot where nothing actually tests it. As there is no main, I assume it was meant to be gcc.c-torture/compile/ test and the test PASSes after moving there (both x86_64-linux and i686-linux). Though, it passed before the PR92372 fixes too. Ok for trunk?

[PATCH] Fix -fcompare-debug issue in delete_insn_and_edges [PR94618]

Hi! delete_insn_and_edges calls purge_dead_edges whenever deleting the last insn in a bb, whatever it is. If it called it only for mandatory last insns in the basic block (that may not be followed by DEBUG_INSNs, dunno if that is control_flow_insn_p or something more complex), that wouldn't be a

Re: [PATCH] Fix a few of the PVS studio reported bugs

On Fri, Apr 17, 2020 at 09:39:20AM +0200, Richard Biener wrote: > On Fri, 17 Apr 2020, Jakub Jelinek wrote: > > > On Fri, Apr 17, 2020 at 09:24:34AM +0200, Richard Biener wrote: > > > --- a/gcc/optabs.c > > > +++ b/gcc/optabs.c > > > @@ -1050,7 +1050,7 @@ expand_binop_directly (enum insn_code

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Tue, Apr 14, 2020 at 12:54:17PM +0200, Martin Liška wrote: > On 4/14/20 10:37 AM, Jakub Jelinek wrote: > > On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote: > > > +/* PR c++/94314. */ > > > +/* { dg-do run } */ > > > +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */

Re: [PATCH] Fix a few of the PVS studio reported bugs

On Fri, Apr 17, 2020 at 09:24:34AM +0200, Richard Biener wrote: > --- a/gcc/optabs.c > +++ b/gcc/optabs.c > @@ -1050,7 +1050,7 @@ expand_binop_directly (enum insn_code icode, > machine_mode mode, optab binoptab, >commutative_p = commutative_optab_p (binoptab); >if (commutative_p >

[PATCH] intl: Unbreak intl build with bison 3 when no regeneration is needed [PR92008]

Hi! As Iain reported, my change broke the case when one has bison >= 3, but make decides there is no reason to regenerate plural.c, unfortunately that seems to be a scenario I haven't tested. The problem is that the pregenerated plural.c has been generated with bison 1.35, but when config.h says

[PATCH v2] i386: Fix up *testqi_ext_3 define_insn_and_split [PR94567]

On Fri, Apr 17, 2020 at 02:12:19PM +0200, Uros Bizjak wrote: > Is it possible to perform widening only for !TARGET_PARTIAL_REG_STALL? > I'm worried that highpart may not be cleared, so the effects of > partial reg stall can be quite noticeable. So, like this then? All I've added was another

[PATCH] cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495]

Hi! On the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94495#c5 testcase GCC emits worse debug info after the PR92264 cselib.c changes. The difference at -O2 -g -dA in the assembly is (when ignoring debug info): # DEBUG g => [argp] # DEBUG k => [argp+0x20] # DEBUG j =>

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote: > On 4/8/20 4:47 AM, Richard Biener wrote: > > On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote: > > > > > > Hi. > > > > > > The patch allows DCE to remove only replaceable operators new and delete. > > > That's

Re: [PATCH] aarch64: Fix another bug in aarch64_add_offset_1 [PR94121]

On Thu, Mar 12, 2020 at 03:24:31PM +0100, Jakub Jelinek via Gcc-patches wrote: > On Thu, Mar 12, 2020 at 12:27:48PM +0100, Andreas Schwab wrote: > > I'm getting this ICE with -mabi=ilp32: > > > > during RTL pass: fwprop1 > > /opt/gcc/gcc-20200312/gcc/testsuite/gcc.dg/

Re: [PATCH] Do not strcat to result of getenv.

On Fri, Mar 13, 2020 at 01:26:02PM +0100, Martin Liška wrote: > diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c > index b8a35c85714..84a0bd24e91 100644 > --- a/gcc/lto-wrapper.c > +++ b/gcc/lto-wrapper.c > @@ -1317,7 +1317,11 @@ run_gcc (unsigned argc, char *argv[]) > >char

[PATCH] c: Handle MEM_REF in c_fully_fold* [PR94179]

Hi! The recent match.pd changes can generate a MEM_REF which can be seen by the C FE folding routines. Unlike the C++ FE, they weren't expected in the C FE yet. MEM_REF should be handled like INDIRECT_REF, except that it has two operands rather than just one and that we should preserve the type

[PATCH v2] c++: Fix parsing of invalid enum specifiers [PR90995]

On Sun, Mar 15, 2020 at 05:21:59PM -0400, Jason Merrill wrote: > Let's use temp_override. So like this? Bootstrapped/regtested on x86_64-linux and i686-linux. 2020-03-15 Jakub Jelinek PR c++/90995 * parser.c (cp_parser_enum_specifier): Use temp_override for

C++ Patch ping

Hi! I'd like to ping the https://gcc.gnu.org/ml/gcc-patches/2020-March/541542.html P2 PR91993 patch If you think it is too dangerous for GCC10 and should be postponed, I can ping it after 10.1 is released, or e.g. if you think for GCC10 we should for all codes handle that way only orig_op0

[committed] mips: Fix up -Wliteral-suffix warning on mti-linux.h

Hi! I've noticed while trying to reproduce PR92989 the following warning: In file included from ./tm.h:42, from ../../gcc/backend.h:28, from ../../gcc/lra-assigns.c:80: ../../gcc/config/mips/mti-linux.h:31:5: warning: invalid suffix on literal; C++11 requires a

[committed] params: Decrease -param=max-find-base-term-values= default [PR92264]

On Thu, Apr 02, 2020 at 12:44:32PM +0200, Richard Biener wrote: > > For the PR in question, my proposal would be to also lower > > -param=max-find-base-term-values= > > default from 2000 to 200 after this, at least in the above 4 > > bootstraps/regtests there is nothing that would ever result in >

[PATCH v2] debug: Improve debug info of c++14 deduced return type [PR94459]

On Sat, Apr 04, 2020 at 12:08:38AM -0400, Jason Merrill wrote: > http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a > decl-specifier. > > http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template > argument can be deduced. > > Looks like you are missing arrays,

[PATCH] c++: Fix up user_provided_p [PR81349]

Hi! The standard says: "A function is user-provided if it is user-declared and not explicitly defaulted or deleted on its first declaration." I don't see anything about function templates having different rules here, but user_provided_p does return true for all TEMPLATE_DECLs. The following

[PATCH] c++: Handle COMPOUND_EXPRs in ocp_convert [PR94339]

Hi! My recent change to get_narrower/warnings_for_convert_and_check broke the following testcase, warnings_for_convert_and_check is upset that expr is a COMPOUND_EXPR with INTEGER_CST at the rightmost operand, while result is a COMPOUND_EXPR with a NOP_EXPR of INTEGER_CST at the rightmost

[PATCH] c++: Avoid calls in non-evaluated contexts affect whether function can or can't throw [PR94326]

Hi! The following testcase FAILs -fcompare-debug, because if we emit a -Wreturn-local-addr warning, we tsubst decltype in order to print the warning and as that function could throw, set_flags_from_callee during that sets cp_function_chain->can_throw and later on we don't set TREE_NOTHROW on foo.

Re: [PATCH] avoid passing expressions to decl_attributes [PR94346]

On Thu, Mar 26, 2020 at 07:55:39PM -0600, Martin Sebor via Gcc-patches wrote: > --- a/gcc/c-family/c-attribs.c > +++ b/gcc/c-family/c-attribs.c > @@ -2526,17 +2526,21 @@ handle_copy_attribute (tree *node, tree name, tree > args, >&& !FUNCTION_POINTER_TYPE_P (TREE_TYPE (ref))) > ref =

Re: [PATCH] tree: Fix -fcompare-debug issues due to protected_set_expr_location [PR94323]

On Fri, Mar 27, 2020 at 09:32:40AM +0100, Richard Biener wrote: > On Fri, 27 Mar 2020, Jakub Jelinek wrote: > > > On Thu, Mar 26, 2020 at 08:41:41PM -0300, Alexandre Oliva wrote: > > > On Mar 26, 2020, Jakub Jelinek wrote: > > > > > > > Or disable -gstatement-frontiers by default and declare it

[PATCH] i386: Fix up *one_cmplv*2* insn with avx512f [PR94343]

Hi! This define_insn has two issues. One is that with -mavx512f -mno-avx512vl it can emit an AVX512VL-only insn - 128-bit or 256-bit EVEX encoded vpternlog{d,q}. Another one is that because there is no vpternlog{b,w}, we emit vpternlogd instead, but then we shouldn't pretend we support masking of

Re: [PATCH] tree: Fix -fcompare-debug issues due to protected_set_expr_location [PR94323]

On Thu, Mar 26, 2020 at 08:41:41PM -0300, Alexandre Oliva wrote: > On Mar 26, 2020, Jakub Jelinek wrote: > > > Or disable -gstatement-frontiers by default and declare it -fcompare-debug > > incompatible. > > I don't get what makes debug stmts introduced by -gstatement-frontiers > special in

[PATCH v2] Fix vextract* masked patterns (PR target/93069)

On Wed, Mar 25, 2020 at 05:59:36PM -0600, Jeff Law via Gcc-patches wrote: > Sorry. I know you asked me to look at this eons ago, but ever time I just get > lost. > > I get the distinct impression that we could do something much simpler (the > patch > you initially proposed for backporting to

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

On Wed, Apr 01, 2020 at 02:43:46AM -0700, H.J. Lu via Gcc-patches wrote: > On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston > wrote: > > > > Please find attached a patch to fix test case failures of pr93365.f90, > > pr93600_1.f90 and pr93600_2.f90. > > > > OK to commit? > > > >

[PATCH] testsuite: Add testcase for already fixed PR [PR94436]

Hi! This PR has been fixed by r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8 already but we didn't have a comparable testcase. Tested on x86_64-linux -m32/-m64, committed to trunk as obvious. 2020-04-01 Jakub Jelinek PR middle-end/94436 * gcc.dg/pr94436.c: New test. ---

[PATCH] i386: Don't use AVX512F integral masks for V*TImode [PR94438]

Hi! The ix86_get_mask_mode hook uses int mask for 512-bit vectors or 128/256-bit vectors with AVX512VL (that is correct), and only for V*[SD][IF]mode if not AVX512BW (also correct), but with AVX512BW it would stop checking the elem_size altogether and pretend the hw has masking support for

Re: [Patch] omp-grid.c – add cast to silence different enumeration types warning

On Fri, Apr 03, 2020 at 11:02:13AM +0200, Tobias Burnus wrote: > Those are all for the same switch statement; > > gomp_for contains 'tree clauses' and this clauses's '->code' is used > to handle store 'enum omp_clauses_code' values in in gimple.{h,c}. > > I think adding this cast (and only this

Re: [PATCH] Improve svn-rev to search for pattern at line beginning.

On Fri, Apr 03, 2020 at 11:13:17AM +0200, Martin Liška wrote: > 2020-04-03 Martin Liska > > * gcc-git-customization.sh: Search for the pattern > at line beginning only. Ok, thanks. > diff --git a/contrib/gcc-git-customization.sh > b/contrib/gcc-git-customization.sh > index

Re: Revert "[nvptx, libgomp] Update pr85381-{2,4}.c test-cases" [PR89713, PR94392] (was: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++)

On Fri, Apr 03, 2020 at 11:36:29AM +0200, Richard Biener wrote: > Note there's now also the opportunity to set the loop flag for > OpenACC/OpenMP annotated loops if any of that guarantees finiteness. > (for GCC11 only please) Dunno about OpenACC, but OpenMP loops guarantee finiteness, as the

  1   2   3   4   5   6   7   8   9   10   >