Re: PING: Re: lightweight class to wide int ranges in VRP and friends

On Mon, Sep 3, 2018 at 8:58 AM Aldy Hernandez wrote: > > Can you re-base and re-post please? Sorry for being late here. Richard. > > Forwarded Message > Subject: Re: lightweight class to wide int ranges in VRP and friends > Date: Fri, 24 Aug 2018 13:40:29 -0400 > From: Aldy H

Re: RFA: PATCH to fix crash with --enable-gather-detailed-mem-stats

On Fri, Sep 7, 2018 at 12:38 PM Jason Merrill wrote: > > Turning on --enable-gather-detailed-mem-stats was producing for me a > compiler that crashed before main() because initializing the > hash_table sem_item::m_type_hash_cache was trying to add to > hash_table_usage before the latter had been i

Re: Prune TYPE_NEXT_VARIANT lists in free_lang_data

On Sun, 9 Sep 2018, Jan Hubicka wrote: > > On September 8, 2018 10:49:02 AM GMT+01:00, Jan Hubicka > > wrote: > > >Hi > > >while working on path to replace type variant by first compatible one I > > >run > > >into issue that the first vairant was not seen by free_lang_data. I > > >think this > >

Re: VRP: normalize VR_VARYING in PLUS/MINUS_EXPR handling

On Tue, Sep 11, 2018 at 12:34 PM Aldy Hernandez wrote: > > For addition and subtraction, we're currently punting on things like > [0,0] - VR_VARYING. However, if we normalize VR_VARYING to the entire > domain, we can see that the above is actually [-MIN+1, +MAX]. > > We would've normally caught t

[PATCH][libgfortran] Fix uninitialized variable use in fallback_access

Hi all, I've been tracking down a bug in a Fortran program on a newlib target and it boils down to fallback_access doing something bad. The unconditional calls to close cause havoc when open doesn't get called due to the short-circuiting in the if-statement above because the fd is uninitialised

Re: [PATCH][libgfortran] Fix uninitialized variable use in fallback_access

Hi Kyrill, This indeed is an obvious change. OK for trunk and 7- and 8-branches. Thanks for the patch Paul On 14 September 2018 at 09:06, Kyrill Tkachov wrote: > Hi all, > > I've been tracking down a bug in a Fortran program on a newlib target and it > boils down to fallback_access doing some

Re: [GCC][PATCH][Aarch64] Added pattern to match zero extended bfxil

On 08/28/2018 11:54 PM, James Greenhalgh wrote: OK once the other one is approved, with the obvious rebase over the renamed function. James Here is the rebased patch. Still OK for me to commit to trunk now that the other patch has been committed? Sam gcc/ 2018-07-31  Sam Tebbs 

[PATCH] S/390: Improve s390-passes.def formatting

The result looks nicer in the generated pass-instances.def. gcc/ChangeLog: 2018-09-13 Ilya Leoshkevich * config/s390/s390-passes.def (INSERT_PASS_BEFORE): Improve formatting. Obvious fix, committed as r264306. --- gcc/config/s390/s390-passes.def | 2 +- 1 file changed, 1 ins

VRP: make worst case scenario for ABS_EXPR is still the set of positives

First, there's no sense handling !VR_RANGE and symbolics now that we've normalized the inputs. Second, even if we wrap around while calculating ABS, we at the least know the result is positive ;-). BTW, we've already handled ABS(-MIN) and -frapv by the time we get here, so we know we won't ge

VRP: convert pointers of known quantity better

Apparently, my work on VRP will never finish. There's an infinity of things that can be tweaked ;-). First, we shouldn't drop to null/non-null when we know what the actual pointer value is. For example, [1, 3] which we get when we store magic numbers in a pointer (p == (char *)1). BTW, for

VRP: allow unsigned truncating conversions that will fit

I'm still thinking about this one... Is there a subtle reason why we're avoiding unsigned truncating conversions of the form: [X, +INF] If the X fits in the new type, why can't we just build [X, +INF] in the new type? See attached patch. If there isn't, OK for trunk? commit b2e8c9

Re: VRP: allow unsigned truncating conversions that will fit

On 09/14/2018 06:42 AM, Aldy Hernandez wrote: I'm still thinking about this one... Is there a subtle reason why we're avoiding unsigned truncating conversions of the form: [X, +INF] If the X fits in the new type, why can't we just build [X, +INF] in the new type?  See attached patch

Re: VRP: allow unsigned truncating conversions that will fit

Hi, On Fri, 14 Sep 2018, Aldy Hernandez wrote: > Is there a subtle reason why we're avoiding unsigned truncating conversions of > the form: > > [X, +INF] > > If the X fits in the new type, why can't we just build [X, +INF] in the new > type? But (uin8_t)((unsigned)[255,+INF]) aka ([255,+

Re: [PATCH] fixincludes: vxworks: regs.h: Guard include of vxTypesOld.h by !_ASMLANGUAGE

> On 13 Sep 2018, at 00:25, Rasmus Villemoes wrote: >> What happens on your end if you just remove the hack ? > Unfortunately, the libstdc++ build breaks: > > In file included from > /usr/powerpc-wrs-vxworks/wind_base/target/h/regs.h:66:0, > from > /bld/vestas/auto/work.20180

Re: [PATCH] Avoid another non zero terminated string constant (revert)

On 07/30/18 08:52, Richard Biener wrote: > On Sun, 29 Jul 2018, Bernd Edlinger wrote: > >> Hi! >> >> This fixes another not NUL terminated string literal that is created >> in tree-ssa-forwprop.c at simplify_builtin_call. >> >> src_buf is set up to contain a NUL at src_buf[src_len], thus use src_l

Re: [PATCH][tree-ssa-mathopts] PR tree-optimization/87259: Try execute_cse_reciprocals_1 when optimize_recip_sqrt fails

On Wed, Sep 12, 2018 at 6:25 PM Kyrill Tkachov wrote: > > > On 12/09/18 15:51, Richard Biener wrote: > > On Wed, Sep 12, 2018 at 2:56 PM Kyrill Tkachov > > wrote: > >> Hi all, > >> > >> This PR is an SSA validation error where the definition ends up not > >> dominating a use. > >> This appeared

Re: [PR debug/87295] ICE in dwarf2out

On Thu, Sep 13, 2018 at 5:22 PM Nathan Sidwell wrote: > > Richard, Jan, as early debug experts perhaps you can clue me in? > > 87295 is an ICE in lookup_external_ref, we strcmp a NULL > die->die_id.die_symbol. > > The die is being cloned in clone_as_declaration during a > copy_ancestor_tree walk

[PATCH] rs6000: Add another Z to go with Y (PR87224)

This is another case where we ICE because Y does not allow reg+reg, we need Z for that. Committing. Segher 2018-09-14 Segher Boessenkool PR target/87224 * config/rs6000/rs6000.md (*mov_hardfloat64): Add Z to the Y alternatives. --- gcc/config/rs6000/rs6000.md | 4

Re: Fold more boolean expressions

Thanks for the review! I've cleaned up the :s and :c flags. You can see the changes here: https://www.diffchecker.com/sjNOq5TQ Anyone else have time for another review? Would be really appreciated. 2018-09-14 MCC CS gcc/ PR tree-optimization/87261 * match.pd: Add boolean

Re: [PATCH 01/25] Handle vectors that don't fit in an integer.

writes: > GCN vector sizes range between 64 and 512 bytes, none of which have > correspondingly sized integer modes. This breaks a number of assumptions > throughout the compiler, but I don't really want to create modes just for this > purpose. > > Instead, this patch fixes up the cases that I've

[PATCH][AArch64][committed] Fix gcc.target/aarch64/combine_bfi_1.c

Hi all, This test started failing because some of the functions in the combine dump that it scans uses a different pattern to match the same instruction: insv_regsi rather than aarch64_bfi. The code generation is still the same. The patch changes the scan to look for the actual instruction we w

Re: [PATCH] rs6000: Add another Z to go with Y (PR87224)

On Fri, Sep 14, 2018 at 03:20:28PM +, Segher Boessenkool wrote: > This is another case where we ICE because Y does not allow reg+reg, we > need Z for that. Backported to 8, too. Segher > 2018-09-14 Segher Boessenkool > > PR target/87224 > * config/rs6000/rs6000.md (*mov_har

Re: [PATCH 24/25] Ignore LLVM's blank lines.

On 9/5/18 5:52 AM, a...@codesourcery.com wrote: > > The GCN toolchain must use the LLVM assembler and linker because there's no > binutils port. The LLVM tools do not have the same diagnostic style as > binutils, so the "blank line(s) in output" tests are inappropriate (and very > noisy). > > Th

Re: [PATCH 23/25] Testsuite: GCN is always PIE.

On 9/5/18 5:52 AM, a...@codesourcery.com wrote: > > The GCN/HSA loader ignores the load address and uses a random location, so we > build all GCN binaries as PIE, by default. > > This patch makes the necessary testsuite adjustments to make this work > correctly. > > 2018-09-05 Andrew Stubbs >

Re: Fold more boolean expressions

On Fri, 14 Sep 2018, MCC CS wrote: +/* (~x & y) | ~(x | y) -> ~x */ +(simplify + (bit_ior:c (bit_and:c (bit_not @0) @1) (bit_not (bit_ior:c @0 @1))) + (bit_not @0)) As I said last time, you should not generate a new (bit_not @0) in the output when there is already one in the input. Maybe (s

Go patch committed: Don't use address of temporary for deferred delete

This patch changes the Go frontend to nott use the address of a temporary for a deferred delete. This corrects the handling of a deferred delete in a loop, to not use a temporary whose value will, at deferred execution time, wind up being the last value in the loop. The test for this is TestDeferD

Re: Fix a minor copyright year typo

On 9/4/18 3:39 AM, wei xiao wrote: > Hi, > > According to commit log, this file is created in the year 2018, hence > the copyright year should be corrected to 2018. > Is below patch ok to fix this problem? > > Thanks > Wei Xiao > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index 62e32c6..416d

Re: [PATCH, Darwin, config] Arrange for configure to detect "otool".

On 8/30/18 9:45 AM, Iain Sandoe wrote: > Currently, we fail to detect some Darwin assembler capabilities because the > configure tests rely on a BINUTILS objdump, which isn’t generally available > on Darwin. > > Darwin uses a tool called "otool" to provide information about objects, and we > shoul

Re: [PATCH, testsuite] Don't assume that HOSTCXX can respond to TEST_ALWAYS_FLAGS.

On 8/29/18 4:30 AM, Iain Sandoe wrote: > Hi, > > I have noticed, for some configuration cases, that the ms-sysv tests fail > with “can’t build generator”. > > The setting of HOSTCXX in gcc/testsuite/gcc/site.exp is dependent on the top > level configuration; > for example, configuring with —tar

Re: [PATCH] Fix overeager spelling corrections (PR c/82967)

On 8/24/18 9:24 AM, David Malcolm wrote: > This patch tunes class best_match's cutoff for rejecting meaningless > spelling suggestions. > > Previously, we allowed an edit distance of up to half of the length of the > longer of the goal string and closest candidate strings, rounded down. > > With

Re: PR85787: Extend malloc_candidate_p to handle multiple phis.

On 8/28/18 5:26 AM, Prathamesh Kulkarni wrote: > H > The attached patch extends malloc_candidate_p to handle multiple phis. > There's a lot of noise in the patch because I moved most of > malloc_candidate_p into > new function malloc_candidate_p_1. The only real change is following hunk: > > +

C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions

This patch implements another bit of C++20, virtual calls in constant expression: The basic idea is that since in a constant expression we know the dynamic type (to detect invalid code etc.), the restriction that prohibits virtu

Re: [PATCH] genmatch: isolate reporting into a function

On 9/3/18 1:56 AM, Martin Liška wrote: > Hi. > > This is small improvement for {gimple,generic}-match.c files. > The code path that reports application of a pattern is now guarded > with __builtin_expect. And reporting function lives in gimple.c. > > For gimple-match.o, difference is: > > bloaty

[PATCH 1/5] substring-locations: add class format_string_diagnostic_t

With the addition of ranges in r263564, format_warning_at_substring_n has 10 arguments. Reduce the number of args by bundling the shared ones into a class format_string_diagnostic_t. gcc/c-family/ChangeLog: * c-format.c (format_warning_at_char): Update for introduction of format_s

[PATCH 0/5] RFC: gimple-ssa-sprintf.c: a new approach (PR middle-end/77696)

Martin: on the way back from Cauldron I had a go at implementing new output formats for the warnings from gimple-ssa-sprintf.c, to try to better indicate to the end user what the problem is. My plan was to implement some of the ASCII art ideas we've been discussing. However, to try to understand

[PATCH 5/5] gimple-ssa-sprintf.c: rewrite overflow/truncation diagnostic (PR middle-end/77696)

gcc/ChangeLog: PR middle-end/77696 * gimple-ssa-sprintf.c: Include "gcc-rich-location.h". (struct directive_state): New struct. (directive_state::get_text): New function. (format_result::add_directive): New member function. (format_result::should_warn

[PATCH 3/5] gimple-ssa-sprintf.c: move struct call_info out of the dom_walker subclass

gcc/ChangeLog: * gimple-ssa-sprintf.c (struct call_info): New forward decl. (class sprintf_dom_walker): Remove forward decl. (struct sprintf_dom_walker::call_info): Rename to... (struct call_info): ...this. (should_warn_p): Update for move of call_info out of

[PATCH 4/5] Add pp_humanized_limit and pp_humanized_range

gcc/ChangeLog: * pretty-print.c (get_power_of_two): New function. (struct relative_to_power_of_2): New struct. (pp_humanized_limit): New function. (pp_humanized_range): New function. (selftest::assert_pp_humanized_limit): New function. (ASSERT_PP_HUMA

[PATCH 2/5] Add range_idx param to range_label::get_text

This patch updates the pure virtual function range_label::get_text (and its implementations) so that the index of the range is passed in, allowing for one label instance to be shared by multiple ranges. gcc/c-family/ChangeLog: * c-format.c (range_label_for_format_type_mismatch::get_text):

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions

On Fri, Sep 14, 2018 at 01:19:50PM -0400, Marek Polacek wrote: > + /* We expect something in the form of &x.D.2103.D.2094; get x. */ > + if (TREE_CODE (obj) != ADDR_EXPR) > + return t; Shouldn't it then be a gcc_assert instead, or code like: if (TREE_CODE (obj) != ADDR_EXPR)

Re: [PATCH][4/4][v2] RPO-style value-numbering for FRE/PRE

On Thu, 13 Sep 2018, Richard Biener wrote: > If it reproduces with clang as a host compiler maybe you can > use ASAN with it? That's an ancient version of clang (3.4), so not too useful, but... On Thu, 13 Sep 2018, Richard Biener wrote: > PR bootstrap/87134 > * tree-ssa-sccvn.c (vn_na

Re: detect unterminated const arrays in strcpy calls (PR 86552)

This is primarily Martin's work. My changes: First, this picks up the last bit of stuff from patch #1 of the 6 series kit to handle unterminated strings -- I was mistaken last night when I said the prior patch wrapped up the bits from patch #1 that we needed. I made NONSTR simply passed through

Re: [PATCH 5/6] detect unterminated const arrays in stpcpy calls (PR 86552)

On 8/13/18 3:28 PM, Martin Sebor wrote: > The attached changes implement the detection of past-the-end reads > by stpcpy due to unterminated arguments. > > > gcc-86552-5.diff > > PR tree-optimization/86552 - missing warning for reading past the end of > non-string arrays > > gcc/ChangeLog: >

[PATCHv2] Handle not explicitly zero terminated strings in merge sections

Hi, this is an upate of the string-merge section, it is based on the V2-STRING_CST semantic patch series, which was finally installed yesterday. It merges single-byte string constants with or without terminating NUL. The patch has the same Ada and C test cases that were already in the V1 patch. T

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections

On Fri, Sep 14, 2018 at 06:39:38PM +, Bernd Edlinger wrote: > Hi, > > this is an upate of the string-merge section, it is based on the V2-STRING_CST > semantic patch series, which was finally installed yesterday. > It merges single-byte string constants with or without terminating NUL. > The p

Re: [PATCHv2] Handle not explicitly zero terminated strings in merge sections

On 09/14/18 21:01, Jakub Jelinek wrote: > On Fri, Sep 14, 2018 at 06:39:38PM +, Bernd Edlinger wrote: >> Hi, >> >> this is an upate of the string-merge section, it is based on the >> V2-STRING_CST >> semantic patch series, which was finally installed yesterday. >> It merges single-byte string

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions (v2)

On Fri, Sep 14, 2018 at 07:36:47PM +0200, Jakub Jelinek wrote: > On Fri, Sep 14, 2018 at 01:19:50PM -0400, Marek Polacek wrote: > > + /* We expect something in the form of &x.D.2103.D.2094; get x. */ > > + if (TREE_CODE (obj) != ADDR_EXPR) > > + return t; > > Shouldn't it then be a gcc_ass

libgo patch committed: Correct gccgo buildid file on ARM

This libgo patch changes the go tool to use %progbits rather than @progbits on ARM. This is necessary because gas on ARM uses @ as a comment character. This is a copy of https://golang.org/cl/135297 in the master sources. This fixes GCC PR 87260. Bootstrapped and ran Go testsuite on x86_64-pc-l

[PATCH] Resolve the TODO in fold_builtin_strlen

Hi, this resolves the TODO I left in fold_builtin_strlen by adding some test cases that fail without the c_strlen call with the TODO comment and pass when the additional c_strlen call is done. Bootstrapped and reg-tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. 2018-09-14 Ber

Re: [PATCH] Resolve the TODO in fold_builtin_strlen

On 9/14/18 1:51 PM, Bernd Edlinger wrote: > Hi, > > this resolves the TODO I left in fold_builtin_strlen by adding some test cases > that fail without the c_strlen call with the TODO comment and pass when the > additional c_strlen call is done. > > > Bootstrapped and reg-tested on x86_64-pc-linu

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions

On Fri, Sep 14, 2018 at 1:19 PM, Marek Polacek wrote: > This patch implements another bit of C++20, virtual calls in constant > expression: > > The basic idea is that since in a constant expression we know the dynamic > type (t

Re: VRP: make worst case scenario for ABS_EXPR is still the set of positives

On 9/14/18 4:25 AM, Aldy Hernandez wrote: > First, there's no sense handling !VR_RANGE and symbolics now that we've > normalized the inputs. > > Second, even if we wrap around while calculating ABS, we at the least > know the result is positive ;-).  BTW, we've already handled ABS(-MIN) > and -fra

[PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

Hi, this is the 2nd version of the patch to add a new first-class option -finline-only-static to guide inlining only on static functions. -finline-only-static By default, GCC inlines functions without considering whether they are static or not. This flag guides inliner to only inline stati

Re: [PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

On Fri, Sep 14, 2018 at 1:34 PM Qing Zhao wrote: > > Hi, > > this is the 2nd version of the patch to add a new first-class option > > -finline-only-static > > to guide inlining only on static functions. > > -finline-only-static > By default, GCC inlines functions without considering whether they

Re: C++ PATCH to implement P1064R0, Virtual Function Calls in Constant Expressions

On Fri, Sep 14, 2018 at 04:30:46PM -0400, Jason Merrill wrote: > On Fri, Sep 14, 2018 at 1:19 PM, Marek Polacek wrote: > > This patch implements another bit of C++20, virtual calls in constant > > expression: > > > > The basic

Re: [PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

On Fri, Sep 14, 2018 at 1:42 PM Andrew Pinski wrote: > > On Fri, Sep 14, 2018 at 1:34 PM Qing Zhao wrote: > > > > Hi, > > > > this is the 2nd version of the patch to add a new first-class option > > > > -finline-only-static > > > > to guide inlining only on static functions. > > > > -finline-only

Re: [PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

> On Sep 14, 2018, at 3:42 PM, Andrew Pinski wrote: > > On Fri, Sep 14, 2018 at 1:34 PM Qing Zhao > wrote: >> >> Hi, >> >> this is the 2nd version of the patch to add a new first-class option >> >> -finline-only-static >> >> to guide inlining only on static fun

Re: VRP: convert pointers of known quantity better

On 9/14/18 4:31 AM, Aldy Hernandez wrote: > Apparently, my work on VRP will never finish. There's an infinity of > things that can be tweaked ;-). > > First, we shouldn't drop to null/non-null when we know what the actual > pointer value is.  For example, [1, 3] which we get when we store magic >

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

On 9/12/18 11:46 AM, Martin Sebor wrote: > On 08/31/2018 04:07 AM, Richard Biener wrote: >> On Thu, Aug 30, 2018 at 7:39 PM Martin Sebor wrote: >>> >>> On 08/30/2018 11:22 AM, Richard Biener wrote: On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor wrote: > On 08/30/2018 02:35 AM

Re: [PATCH v3] combine: perform jump threading at the end

Hi! On Mon, Sep 10, 2018 at 12:59:19PM +0200, Ilya Leoshkevich wrote: > Consider the following RTL: > > (code_label 11 10 26 4 2 (nil) [1 uses]) > (note 26 11 12 4 [bb 4] NOTE_INSN_BASIC_BLOCK) > (insn 12 26 15 4 (set (reg:SI 65) > (if_then_else:SI (eq (reg:CCZ 33 %cc) > (

Re: [PATCH] i386: move alignment defaults to processor_costs.

On 9/12/18 6:44 AM, Martin Liška wrote: > Hi. > > Honza asked me to do the follow-up. It moves definition of alignments > related to a CPU into *_cost scructures. Advantage of it is that there's > no redundant definition for CPUs that have equal cost. > > I verified that it produces same output f

Re: [PATCH v2] combine: perform jump threading at the end

On Mon, Sep 10, 2018 at 12:58:19PM +0200, Ilya Leoshkevich wrote: > > Am 06.09.2018 um 20:11 schrieb Jeff Law : > > This is (of course) much easier to do when the target block has no insns > > other than the conditional branch. So perhaps only do this when the > > target block has just the conditi

Re: [PATCH] Add -Wabsolute-value

On 9/4/18 3:08 AM, Martin Jambor wrote: > Hi, > > On Fri, Aug 31 2018, Joseph Myers wrote: >> On Fri, 31 Aug 2018, Martin Jambor wrote: >> >>> diff --git a/gcc/common.opt b/gcc/common.opt >>> index ebc3ef43ce2..2950760fb2a 100644 >>> --- a/gcc/common.opt >>> +++ b/gcc/common.opt >>> @@ -815,6 +815

Re: [committed] Fix minor bug in recently added sanity test in tree-ssa-dse.c

On 8/28/18 3:37 AM, Richard Biener wrote: > On Mon, Aug 27, 2018 at 10:31 PM Jeff Law wrote: >> >> >> We recently changes tree-ssa-dse.c to not trim stores outside the bounds >> of the referenced object. This is generally a good thing. >> >> However, there are cases where the object doesn't have

Re: [PATCH v2] combine: perform jump threading at the end

On Wed, Sep 05, 2018 at 02:00:59PM +0200, Ilya Leoshkevich wrote: > +/* { dg-final { scan-assembler > "\n\tlt\t.*\n\tjne\t(\\.L\\d+)\n(.*\n)*\tcs\t.*\n\tber\t%r14\n\\1:\n\tjg\tbar\n" > } } */ About this RE. "." matches anything, also newlines, so (.*\n)* is the same as just .* (ignoring capture

Re: [PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

On 09/14/2018 03:35 PM, Jeff Law wrote: On 9/12/18 11:46 AM, Martin Sebor wrote: On 08/31/2018 04:07 AM, Richard Biener wrote: On Thu, Aug 30, 2018 at 7:39 PM Martin Sebor wrote: On 08/30/2018 11:22 AM, Richard Biener wrote: On August 30, 2018 6:54:21 PM GMT+02:00, Martin Sebor wrote: On

[committed] hppa: Fix canonicalize of method and void pointers in comparison operations

The attached change fixes the canonicalization of method and void pointers in comparisons against another method or function pointer on 32-bit hppa targets.  As far as I know, 32-bit hppa is the only architecture that requires function pointer canonicalization due to lazy binding. Tested on hp

Re: [PATCH 03/25] Improve TARGET_MANGLE_DECL_ASSEMBLER_NAME.

On Wed, 12 Sep 2018 13:34:06 -0400 Julian Brown wrote: > On Wed, 12 Sep 2018 17:31:58 +0100 > Andrew Stubbs wrote: > > > On 12/09/18 16:16, Richard Biener wrote: > > > I think the symptom GCN sees needs to be better understood - like > > > wheter it is generally OK to mangle things arbitraril

Re: Fold more boolean expressions

Sorry for doing the same mistake twice. Is this OK, and do I need to test it again after the first version of this patch? 2018-09-15 MCC CS gcc/ PR tree-optimization/87261 * match.pd: Add boolean optimizations, fix whitespace. 2018-09-15 MCC CS gcc/test