RE: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

> -Original Message- > From: Martin Sebor > Sent: Thursday, July 25, 2019 2:08 AM > To: Jeff Law ; JiangNing OS > ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for > conditional store optimization > > On 7/24/19 11:12 AM, Jeff Law wrote: > >

[PATCH, rs6000] Fix PR91050 by adding a DRIVER_SELF_SPECS spec

The -mdejagnu-cpu= option was added as a way for a test case to ensure a particular -mcpu= option is used to compile the test, regardless of whether the user attempts to override it (purposely or accidentally) via RUNTESTFLAGS. This was well and good, but the ASM_CPU_SPEC was not updated to handle

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

On 7/24/19 8:17 PM, Martin Sebor wrote: >> Committed in r273783 after retesting and including a test for >> the warning that I had left out of the patch I posted here. >> >> Martin >> >> PS I suspect some of the tests I added might need tweaking on >> big-endian systems.  I'll deal with them

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

On 7/24/19 8:17 PM, Martin Sebor wrote: >> Committed in r273783 after retesting and including a test for >> the warning that I had left out of the patch I posted here. >> >> Martin >> >> PS I suspect some of the tests I added might need tweaking on >> big-endian systems.  I'll deal with them

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

Committed in r273783 after retesting and including a test for the warning that I had left out of the patch I posted here. Martin PS I suspect some of the tests I added might need tweaking on big-endian systems.  I'll deal with them tomorrow. And maybe also strictly aligned targets. A

Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

I would also mark DECL_IS_OPERATOR_DELETE_P the other operators delete, because of the name of the macro, but it is not important for this patch. DCE has special code to avoid removing the LHS of malloc when it is unused. Is there something different about operator new that makes it not need

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

On 7/24/19 11:06 AM, Jeff Law wrote: On 7/22/19 5:17 PM, Martin Sebor wrote: Umm "store_b4_nul"?  Are you really trying to save 3 characters in the name by writing it this way?  :-) I'm actually saving four characters over "store_before_nul" ;-) :-) It's just a name I picked because I

[committed][MSP430] Enable initfini_array by default

A recent patch to newlib (commit 884b05b54) removes the .init/.fini sections from the CRT library for msp430. initfini_array must now be enabled by default, so that libgcc/crtstuff.c does not try to put functions relating to .ctors/.dtors in .init/.fini. .init_array was already the preferred way

[C++ Patch] Improve delete_sanity locations

Hi, this takes care of the four locations, two warnings and two errors. I'm also adding the missing complain & tf_warning or tf_error guards, I don't have a SFINAE testcase failing but since the function takes a tsubst_flags_t argument I think it's the right thing to do. Tested x86_64-linux.

[committed][MSP430] Only add crtn.o to ENDFILE_SPEC if it exists

A recent patch to Newlib (commit 884b05b54) removes crtn.o for msp430. This patch wraps uses of crtn.o in ENDFILE_SPEC from config/msp430.h in if-exists, so compatibility with new and old newlib is maintained. Committed on trunk as obvious. >From 65a155eb552343a28861b9d5e04e59db28bd2743 Mon Sep

Re: [libgomp, WIP, GSoC'19] Modification to a single queue, single execution path.

On Wed, Jul 24, 2019 at 05:25:56PM +0900, 김규래 wrote: > > Generally, we don't want to have code commented out like this in the final > > patch submission. For this WIP, I think it is acceptable, as I think in the > > end you don't want to use the team's queue, but actually either > >

Re: [PATCH] report as disabled options unsupported by a language (PR 80545)

On 7/22/19 5:26 PM, Jeff Law wrote: On 7/22/19 3:54 PM, Martin Sebor wrote: While resolving PR80545 - option -Wstringop-overflow not recognized by Fortran, I discovered that a command line options that's supported only by a subset of languages is considered as enabled when tested by the 

Re: [PATCH] Fix gcc.dg/gomp/pr89104.c failure on aarch64

Hi Steve, > 2019-07-24 Steve Ellcey > > * gcc.dg/gomp/pr89104.c: Use -w on aarch64*-*-* targets. > > > diff --git a/gcc/testsuite/gcc.dg/gomp/pr89104.c > b/gcc/testsuite/gcc.dg/gomp/pr89104.c > index 505fdda..7f0f688 100644 > --- a/gcc/testsuite/gcc.dg/gomp/pr89104.c > +++

[PATCH] Fix gcc.dg/gomp/pr89104.c failure on aarch64

I noticed that the test gcc.dg/gomp/pr89104.c fails on aarch64 platforms. As mentioned in the bug report for PR 89104, this message is coming from aarch64 target specific code which is why it does not occur on other platforms. There doesn't seem to be complete consensus in the bug report on how

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On 7/24/19 2:18 PM, Jeff Law wrote: On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignore missing reply attributions... ] it. But I'd claim that if callers are required not to change these ranges, then the callers are fundamentally broken. I'm not sure what the "sanitization" is

Re: [PATCH 1/4] Remove old IPA-SRA, introduce tree-sra.h

On 7/23/19 10:16 AM, Martin Jambor wrote: > This patch removes the old IPA-SRA. Please see the covert letter for > more information about the whole patch-set. > > Martin > > 2019-07-23 Martin Jambor > > * dbgcnt.def: Remove eipa_sra. > * passes.def: Remove old IPA-SRA. >

Re: [PATCH 1/3] add -Wstruct-not-pod, -Wclass-is-pod, -Wmismatched-tags (PR 61339)

On 7/8/19 3:58 PM, Martin Sebor wrote: > The attached patch implements three new warnings: > >  *  -Wstruct-not-pod triggers for struct definitions that are not > POD structs, >  *  -Wclass-is-pod triggers for class definitions that satisfy > the requirements on POD structs, and >  *  

Re: [PATCH 1/2] Come up with function_decl_type and use it in tree_function_decl.

On 7/11/19 12:45 AM, Martin Liška wrote: > On 7/9/19 11:00 PM, Jason Merrill wrote: > Ok, I hopefully addressed the suggested improvements to the patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed? > Thanks, > Martin > >

Re: [RFC/PATCH v2][PR89245] Check REG_CALL_DECL note during the tail-merging

On 7/17/19 2:29 AM, Dragan Mladjenovic wrote: > > > On 09.07.2019. 23:21, Jeff Law wrote: >> On 7/9/19 2:06 PM, Dragan Mladjenovic wrote: >>> This patch prevents merging of CALL instructions that that have different >>> REG_CALL_DECL notes attached to them. >>> >>> On most architectures this is

Re: [PATCH v4] Generalize get_most_common_single_value to return k_th value & count

On 7/17/19 1:55 AM, Martin Liška wrote: > On 7/17/19 7:44 AM, luoxhu wrote: >> Hi Martin, >> Thanks for your review, v4 Changes as below: >> 1. Use decrease bubble sort. >> BTW, I have a question about hist->hvalue.counters[2], when will it become >> -1, please? Thanks. Currently, if it is -1,

Re: [patch] Add simple narrowing optimization to expand_case

On 7/24/19 3:57 AM, Eric Botcazou wrote: > Hi, > > this adds a simple narrowing optimization to expand_case in order to avoid > calling a double-word comparison routine when it is unnecessary to do so. > This is mainly for -O0 because the optimization is otherwise done by forward > propagation

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On July 24, 2019 8:18:57 PM GMT+02:00, Jeff Law wrote: >On 7/24/19 11:00 AM, Richard Biener wrote: >[ Big snip, ignore missing reply attributions... ] > >>> it. But I'd claim that if callers are required not to change these >>> ranges, then the callers are fundamentally broken. I'm not sure >>>

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignore missing reply attributions... ] >> it. But I'd claim that if callers are required not to change these >> ranges, then the callers are fundamentally broken. I'm not sure >> what the "sanitization" is really buying you here. Can you

Re: [PATH] Patch to fix -finstrument-functions-exclude-function-list handling of namespaces and escaped commas

On 7/4/19 2:18 AM, Oliver Browne wrote: > See below for modified patch, indentation and newline for curly braces > style applied, and commented out chunk removed. Apologies, indentation > and newline for scope are not they way I normally write things, habits > got the better of me, and I forgot to

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/24/19 11:12 AM, Jeff Law wrote: On 7/24/19 10:09 AM, Martin Sebor wrote: On 7/24/19 9:25 AM, Jeff Law wrote: On 7/23/19 10:20 AM, Martin Sebor wrote: On 7/22/19 10:26 PM, JiangNing OS wrote: This patch is to fix PR91195. Is it OK for trunk? diff --git a/gcc/ChangeLog b/gcc/ChangeLog

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On 7/24/19 9:25 AM, Richard Biener wrote: On Wed, Jul 24, 2019 at 12:56 AM Andrew MacLeod wrote: On 7/23/19 5:33 AM, Richard Biener wrote: From my point of view, a range object is similar to a tree node. A tree node has the bits to indicate what the value is, but also associates a type

Re: [PATCH 1/3] add -Wstruct-not-pod, -Wclass-is-pod, -Wmismatched-tags (PR 61339)

On 7/22/19 6:53 PM, Martin Sebor wrote: > On 7/22/19 4:19 PM, Jeff Law wrote: >> On 7/8/19 3:58 PM, Martin Sebor wrote: >>> The attached patch implements three new warnings: >>> >>>   *  -Wstruct-not-pod triggers for struct definitions that are not >>> POD structs, >>>   *  -Wclass-is-pod

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/24/19 10:09 AM, Martin Sebor wrote: > On 7/24/19 9:25 AM, Jeff Law wrote: >> On 7/23/19 10:20 AM, Martin Sebor wrote: >>> On 7/22/19 10:26 PM, JiangNing OS wrote: This patch is to fix PR91195. Is it OK for trunk? diff --git a/gcc/ChangeLog b/gcc/ChangeLog index

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)

On 7/22/19 5:17 PM, Martin Sebor wrote: >> Umm "store_b4_nul"?  Are you really trying to save 3 characters in the >> name by writing it this way?  :-) > > I'm actually saving four characters over "store_before_nul" ;-) :-) > > It's just a name I picked because I like it.  Would you prefer to >

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On July 24, 2019 6:00:04 PM GMT+02:00, Jeff Law wrote: >On 7/23/19 3:42 AM, Richard Biener wrote: >> On Tue, Jul 23, 2019 at 1:59 AM Jeff Law wrote: >>> >>> On 7/16/19 12:37 PM, Andrew MacLeod wrote: On 7/9/19 5:56 AM, Richard Biener wrote: > On Tue, Jul 9, 2019 at 9:28 AM Aldy

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/24/19 9:25 AM, Jeff Law wrote: On 7/23/19 10:20 AM, Martin Sebor wrote: On 7/22/19 10:26 PM, JiangNing OS wrote: This patch is to fix PR91195. Is it OK for trunk? diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 711a31ea597..4db36644160 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On 7/23/19 3:42 AM, Richard Biener wrote: > On Tue, Jul 23, 2019 at 1:59 AM Jeff Law wrote: >> >> On 7/16/19 12:37 PM, Andrew MacLeod wrote: >>> On 7/9/19 5:56 AM, Richard Biener wrote: On Tue, Jul 9, 2019 at 9:28 AM Aldy Hernandez wrote: > > > On 7/4/19 6:33 AM, Richard Biener

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/22/19 10:26 PM, JiangNing OS wrote: > This patch is to fix PR91195. Is it OK for trunk? > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index 711a31ea597..4db36644160 100644 > --- a/gcc/ChangeLog > +++ b/gcc/ChangeLog > @@ -1,3 +1,9 @@ > +2019-07-22 Jiangning Liu > + > + PR

Re: [PATCH] Deduce automatically number of cores for -flto option.

On 7/23/19 4:15 AM, Martin Liška wrote: > On 7/23/19 11:20 AM, Jan Hubicka wrote: >> Hi, >> great you found time to make this. It should become the default for >> -flto IMO. > > Works for me. Then I'm suggesting to not come up with -flto=auto and > only document that -flto passed during linking

Re: [PATCH] Come up with -flto=auto option.

On 7/23/19 2:30 AM, Martin Liška wrote: > Hi. > > As we as openSUSE started using -flto, I see it very handy to have > an option value that will automatically detect number of cores > that can be used for parallel LTRANS phase. > > Thoughts? > > gcc/ChangeLog: > > 2019-07-23 Martin Liska >

Re: [PATCH][ARM] Fix low reg issue in Thumb-2 movsi patterns

On 24/07/2019 16:16, Wilco Dijkstra wrote: The Thumb-2 movsi patterns try to prefer low registers for loads and stores. However this is done incorrectly by using 2 separate variants with 'l' and 'h' register classes. The register allocator will only use low registers, and as a result we end

Re: [PATCH] MIPS: Fix GCC `noreorder' for undefined R5900 short loops

On 7/24/19 9:31 AM, Maciej W. Rozycki wrote: > Fredrik, > >>> Why? What is wrong with using `-Werror'? >>> >>> Or you could use `-Wa,-fatal-warnings' to limit making warnings fatal to >>> the assembly stage only if you are concerned about bad high-level language >>> code quality interfering

Re: [PATCH][MSP430] Allow lower-case "r" to be used in register names by defining ADDITIONAL_REGISTER_NAMES (PR target/70320)

On 7/23/19 6:50 AM, Jozef Lawrynowicz wrote: > The attached patch enables a lower-case "r" to be used in register names > specified in asm statements clobber list or command line options, in addition > to > the upper case "R" that is currently supported. > > Successfully regtested on trunk for

Re: [PATCH] MIPS: Fix GCC `noreorder' for undefined R5900 short loops

Fredrik, > > Why? What is wrong with using `-Werror'? > > > > Or you could use `-Wa,-fatal-warnings' to limit making warnings fatal to > > the assembly stage only if you are concerned about bad high-level language > > code quality interfering with your goal. > > It appears unfeasible to

Re: [PATCH][MSP430] Reject -m{code,data}-region options unless large memory model is selected

On 7/23/19 7:22 AM, Jozef Lawrynowicz wrote: > The attached patch adds error messages to be emitted when -mcode/data-region > are > used without the accompanying -mlarge option that enables the large memory > model. > Use of the upper/either regions without -mlarge can cause relocation overflows

Re: [PATCH][ARM] Fix low reg issue in Thumb-2 movsi patterns

Hi Wilco, On 7/24/19 4:16 PM, Wilco Dijkstra wrote: The Thumb-2 movsi patterns try to prefer low registers for loads and stores. However this is done incorrectly by using 2 separate variants with 'l' and 'h' register classes.  The register allocator will only use low registers, and as a

Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

On 7/23/19 10:20 AM, Martin Sebor wrote: > On 7/22/19 10:26 PM, JiangNing OS wrote: >> This patch is to fix PR91195. Is it OK for trunk? >> >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog >> index 711a31ea597..4db36644160 100644 >> --- a/gcc/ChangeLog >> +++ b/gcc/ChangeLog >> @@ -1,3 +1,9 @@ >>

[PATCH][ARM] Fix low reg issue in Thumb-2 movsi patterns

The Thumb-2 movsi patterns try to prefer low registers for loads and stores. However this is done incorrectly by using 2 separate variants with 'l' and 'h' register classes. The register allocator will only use low registers, and as a result we end up with significantly more spills and moves to

Re: [PATCH] Come up with -flto=auto option.

On 7/24/19 12:47 AM, Martin Liška wrote: > On 7/24/19 12:32 AM, Jeff Law wrote: >> On 7/23/19 8:23 AM, Martin Liška wrote: >>> On 7/23/19 3:57 PM, Jeff Law wrote: On 7/23/19 7:50 AM, Michael Matz wrote: > Hi, > > On Tue, 23 Jul 2019, Jeff Law wrote: > >>> great you found

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

On 7/23/19 8:00 AM, Richard Biener wrote: > > The following fixes the runtime regression of 456.hmmer caused > by matching ICC in code generation and using cmov more aggressively > (through GIMPLE level MAX_EXPR usage). Appearantly (discovered > by manual assembler editing) using the SSE unit

Re: [PATCH] MIPS: Fix GCC `noreorder' for undefined R5900 short loops

Hi Maciej, > > > > How can one reasonably prevent the bug when compiling a whole Linux > > > > distribution with thousands of packages if GAS merely warns and proceeds > > > > in many cases? > > > > > > I think the tools must not set a policy. By using `.set noreorder' the > > > user told the

Re: [patch] More precise message with -Winline

> Looks good besides > > + if (e->count.ipa () == profile_count::zero ()) > + e->inline_failed = CIF_NEVER_CALL; > > does it actually matter what kind of profile quality e->count.ipa has > compared to profile_count::zero ()? I don't really know, the other examples in the

[PATCH] Fix PR91236

The following fixes a stack corruption and a missed optimization. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. Richard. 2019-07-24 Richard Biener PR tree-optimization/91236 * tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): Fix size of

Re: Representative returns and location info (Re: [RFC, PATCH] Display inlining context for uninitialized warnings)

> (Let's focus on location info and representative returns in this > subthread.) > > AFAIU, a return statement may be chosen as a representative return for a > function. The representative return's location is set to > UNKNOWN_LOCATION, because otherwise the results of coverage analysis are >

Re: [patch] More precise message with -Winline

On Wed, Jul 24, 2019 at 11:29 AM Eric Botcazou wrote: > > Hi, > > for EH cleanups, the branch probability heuristics can consider that edges are > never taken, i.e. their profile count is set to zero. In this case, no matter > how you tweak the inlining parameters, you cannot get function calls

Re: [patch] Set TREE_THIS_NOTRAP throughout tree-nested.c

On Wed, Jul 24, 2019 at 11:14 AM Eric Botcazou wrote: > > Hi, > > stack memory is considered non-trapping by the compiler once the frame has > been established so TREE_THIS_NOTRAP can be set on the dereferences built > during the unnesting pass. > > Tested on x86_64-suse-linux, OK for the

Re: [PATCH 1/2] [ARC] Fix and refurbish the interrupts.

Pushed. Thank you for your review, Claudiu On Tue, Jul 23, 2019 at 12:51 AM Jeff Law wrote: > > On 7/9/19 10:23 AM, claz...@gmail.com wrote: > > Hi Jeff, > > > > Please find attached the updated patch. > > > > What is new: > > - mailing list feedback is taken into account. > > - some comments

Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

On Wed, Jul 24, 2019 at 12:56 AM Andrew MacLeod wrote: > > On 7/23/19 5:33 AM, Richard Biener wrote: > > > >> What irange contains internally is a bit arbitrary. It's really an API > >> for managing a set of subranges. We could have used trees internally > >> just as easily, then we wouldnt

Ping: [PATCH 1/2] gdbhooks.py: use strip_typedefs to simplify matching type names

Vladislav Ivanishin writes: > David Malcolm writes: > >> On Tue, 2019-07-02 at 14:29 +0300, Vladislav Ivanishin wrote: >>> David Malcolm writes: >>> >>> > On Mon, 2019-07-01 at 12:50 +0300, Vladislav Ivanishin wrote: >>> > > Hi! >>> > > >>> > > GDB's Python API provides strip_typedefs method

Re: [PATCH 2/4] New parameter manipulation infrastructure

Hello, On Tue, Jul 23 2019, Martin Jambor wrote: > This patch adds the capability to split parameters directly to the > call graph cloning infrastructure, while still allowing omp-simd to > clone functions on its own. Please see the cover letter for the whole > IPA-SRA patch-set for more

Representative returns and location info (Re: [RFC, PATCH] Display inlining context for uninitialized warnings)

Jeff Law writes: > On 6/19/19 8:57 AM, Martin Sebor wrote: >> On 6/19/19 5:11 AM, Vladislav Ivanishin wrote: >>> Hi, >>> >>> This patch (partially) adds displaying inlining context for >>> -W{maybe,}uninitialized warnings.  This is not as trivial to enable as >>> simply supplying the "%G" format

Ping: [RFC, PATCH] Display inlining context for uninitialized warnings

Hi, I'm pinging . I think, there are two subtopics to it that can be discussed separately. I would like to focus on the patch itself here. I am going to also start a subthread dedicated to dealing with representative returns. I still

[Committed] S/390: Add add/sub/mul overflow check patterns

This patch implements the addv, subv, and mulv patterns for signed integers. Bootstrapped and regression tested on s390x (IBM z14). Committed to mainline. gcc/ChangeLog: 2019-07-24 Andreas Krebbel * config/s390/predicates.md (addv_const_operand): New predicate. *

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

On Wed, 24 Jul 2019, Richard Biener wrote: > On Tue, 23 Jul 2019, Richard Biener wrote: > > > > > The following fixes the runtime regression of 456.hmmer caused > > by matching ICC in code generation and using cmov more aggressively > > (through GIMPLE level MAX_EXPR usage). Appearantly

Re: [PATCH] MIPS: Fix GCC `noreorder' for undefined R5900 short loops

Fredrik, > > > How can one reasonably prevent the bug when compiling a whole Linux > > > distribution with thousands of packages if GAS merely warns and proceeds > > > in many cases? > > > > I think the tools must not set a policy. By using `.set noreorder' the > > user told the toolchain he

Re: [PATCH] Come up with -flto=auto option.

On 7/24/19 3:12 AM, Martin Liška wrote: On 7/24/19 9:03 AM, Allan Sandfeld Jensen wrote: There are patches to enable it in ninja, and I know some Linux distros apply the patches by default. Though that is more listening, so it probably requires launching ninja using make, if you want to be

Re: [PATCH, og9] Port OpenACC profiling interface to OG9

Hi Kwok! On 2019-06-24T20:37:12+0100, Kwok Cheung Yeung wrote: > On 17/06/2019 6:24 pm, Thomas Schwinge wrote: >>> Okay to push to openacc-gcc-9-branch? >> I think what would be best, is the following approach: [...] > I have now ported over the mainline patch over to OG9, plus an >

[PATCH] i386: Roundeven expansion for SSE4.1+

Hi. This is a patch that Uros suggested for roundeven expansion, here. Thanks for the heads up. I have rerun the testsuite on the patch, it survives the regression tests and bootstraps on x86_64-linux-gnu. Note, patch to be applied on top

[patch] Add simple narrowing optimization to expand_case

Hi, this adds a simple narrowing optimization to expand_case in order to avoid calling a double-word comparison routine when it is unnecessary to do so. This is mainly for -O0 because the optimization is otherwise done by forward propagation and avoids having to drag libgcc or not depending on

[patch] More precise message with -Winline

Hi, for EH cleanups, the branch probability heuristics can consider that edges are never taken, i.e. their profile count is set to zero. In this case, no matter how you tweak the inlining parameters, you cannot get function calls inlined, but -Winline nevertheless prints the standard message

[patch] Set TREE_THIS_NOTRAP throughout tree-nested.c

Hi, stack memory is considered non-trapping by the compiler once the frame has been established so TREE_THIS_NOTRAP can be set on the dereferences built during the unnesting pass. Tested on x86_64-suse-linux, OK for the mainline? 2019-07-24 Eric Botcazou * tree-nested.c

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

On Tue, 23 Jul 2019, Richard Biener wrote: > > The following fixes the runtime regression of 456.hmmer caused > by matching ICC in code generation and using cmov more aggressively > (through GIMPLE level MAX_EXPR usage). Appearantly (discovered > by manual assembler editing) using the SSE unit

Re: [libgomp, WIP, GSoC'19] Modification to a single queue, single execution path.

Hi Jakub, thanks for your detailed comments. > Can you please try to tweak your mailer settings? In the text version of > the patch the mailer ate tab characters, so the patch can't apply, and in > the html version which we generally don't want to see on the mailing list, > one has to open it

Re: [libgomp, WIP, GSoC'19] Modification to a single queue, single execution path.

Hi! Thanks for the patch. On Mon, Jul 22, 2019 at 04:40:21AM +0900, 김규래 wrote: Can you please try to tweak your mailer settings? In the text version of the patch the mailer ate tab characters, so the patch can't apply, and in the html version which we generally don't want to see on the mailing

Re: [PATCH] Come up with -flto=auto option.

On 7/24/19 9:03 AM, Allan Sandfeld Jensen wrote: > On Mittwoch, 24. Juli 2019 08:45:21 CEST Martin Liška wrote: >> On 7/24/19 12:11 AM, Allan Sandfeld Jensen wrote: >>> On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: Hi. As we as openSUSE started using -flto, I see it

Re: [PATCH] Come up with -flto=auto option.

On Mittwoch, 24. Juli 2019 08:45:21 CEST Martin Liška wrote: > On 7/24/19 12:11 AM, Allan Sandfeld Jensen wrote: > > On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: > >> Hi. > >> > >> As we as openSUSE started using -flto, I see it very handy to have > >> an option value that will

[PATCH] Fix off-by-one in simple-object-elf.c (PR lto/91228).

Hi. The patch is about off-by-one error that I used for a wrong argument. I consider that pre-approved by Richi. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Thanks, Martin libiberty/ChangeLog: 2019-07-23 Martin Liska PR lto/91228 *

Re: [PATCH] Come up with -flto=auto option.

On 7/24/19 12:32 AM, Jeff Law wrote: > On 7/23/19 8:23 AM, Martin Liška wrote: >> On 7/23/19 3:57 PM, Jeff Law wrote: >>> On 7/23/19 7:50 AM, Michael Matz wrote: Hi, On Tue, 23 Jul 2019, Jeff Law wrote: >> great you found time to make this. It should become the default for

Re: [PATCH] Come up with -flto=auto option.

On 7/24/19 12:11 AM, Allan Sandfeld Jensen wrote: > On Dienstag, 23. Juli 2019 10:30:07 CEST Martin Liška wrote: >> Hi. >> >> As we as openSUSE started using -flto, I see it very handy to have >> an option value that will automatically detect number of cores >> that can be used for parallel LTRANS