[PATCH,gcc/MIPS] Make loongson3a use fused madd.d

Hi, Loongson3a has 4 operand fused madd instrcution. This patch set loongson3a use fused madd.d. ChangeLog : *** gcc/ChangeLog *** 2016-11-03 Chenghua Xu config/mips/ * mips.h: Set loongson3a use fused madd.d. Tested on loongson3a. PS: I will soon submit

Re: [C++ Patch/RFC] PR 67980 ("left shift count is negative [-Wshift-count-negative] generated for unreachable code")

.. I'm still looking for some directions about the best way to handle this issue: anyway, in case it wasn't clear, the second patch I posted passes testing. Thanks, Paolo.

Re: [openacc] adjust default num_gangs

On Wed, Nov 02, 2016 at 03:11:52PM -0700, Cesar Philippidis wrote: >if (seen_zero) > { > + /* See if the user provided GOMP_OPENACC_DIM environment > + variable to specify runtime defaults. */ > + static int default_dims[GOMP_DIM_MAX]; > + > + pthread_mutex_lock

Re: [openacc] adjust default num_gangs

On 11/02/2016 12:50 PM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 12:34:47PM -0700, Cesar Philippidis wrote: >> @@ -932,9 +933,84 @@ nvptx_exec (void (*fn), size_t mapnum, void >> **hostaddrs, void **devaddrs, >> >>if (seen_zero) >> { >> + /* See if the user provided

Re: [PATCH 1/2, libgcc]: Implement _divmoddi4

On Wed, Nov 2, 2016 at 12:19 PM, Uros Bizjak wrote: > On Wed, Nov 2, 2016 at 2:27 PM, Ian Lance Taylor wrote: >> On Mon, Oct 31, 2016 at 7:46 AM, Uros Bizjak wrote: >>> This function will be used in a follow-up patch to implement >>>

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

On 11/02/16 18:51, Jason Merrill wrote: > On 11/02/2016 02:11 AM, Bernd Edlinger wrote: >> On 11/01/16 19:15, Bernd Edlinger wrote: >>> On 11/01/16 18:11, Jason Merrill wrote: On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger wrote: > On 11/01/16 16:20,

Re: [openacc] adjust default num_gangs

On Wed, Nov 02, 2016 at 12:34:47PM -0700, Cesar Philippidis wrote: > @@ -932,9 +933,84 @@ nvptx_exec (void (*fn), size_t mapnum, void **hostaddrs, > void **devaddrs, > >if (seen_zero) > { > + /* See if the user provided GOMP_OPENACC_DIM environment > + variable to specify

[openacc] adjust default num_gangs

This patch teaches the libgomp runtime how to probe the CUDA driver to extract the number of Stream Multiprocessors that are available on the graphics hardware and use that as the default value for num_gangs. Without that patch, libgomp used to have num_gangs default to 32, which was chosen

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

On Wed, Nov 02, 2016 at 10:55:23AM -0600, Martin Sebor wrote: > >That's an unfair assertion in light of the numbers above. > > > >>If you want a warning for suspicious calls, sure, but > >>1) it has to be clearly worded significantly differently from how do you > >> word it, so that users really

Re: [RFA] Fix false positive out of bounds array index warning in LRA

On 11/02/2016 01:20 PM, Bernd Schmidt wrote: On 10/29/2016 06:21 PM, Jeff Law wrote: On a small number of ports, we only have 2 defined register classes. NO_REGS and ALL_REGS. Examples would include nvptx and vax. So let's look at check_and_process_move from lra-constraints.c: sclass =

Re: [PATCH, Fortran] Extension: Support legacy PARAMETER statements with -std=legacy (or -fdec?)

On 11/02/2016 04:47 PM, Fritz Reese wrote: All, Another quirk of legacy compilers is their syntax for PARAMETER statements. Such statements are similar to standard PARAMETER statements but lack parentheses following the PARAMETER keyword. There is a good reason the standard doesn't support

Re: [RFA] Fix false positive out of bounds array index warning in LRA

On 10/29/2016 06:21 PM, Jeff Law wrote: On a small number of ports, we only have 2 defined register classes. NO_REGS and ALL_REGS. Examples would include nvptx and vax. So let's look at check_and_process_move from lra-constraints.c: sclass = dclass = NO_REGS; if (REG_P (dreg)) dclass

Re: [PATCH 1/2, libgcc]: Implement _divmoddi4

On Wed, Nov 2, 2016 at 2:27 PM, Ian Lance Taylor wrote: > On Mon, Oct 31, 2016 at 7:46 AM, Uros Bizjak wrote: >> This function will be used in a follow-up patch to implement >> TARGET_EXPAND_DIVMOD_LIBFUNC for x86 targets. Other targets can call >> this

Re: RFD: Buffer handling for ASM_GENERATE_INTERNAL_LABEL

On 10/29/2016 04:17 PM, Trevor Saunders wrote: So actually a thing I've wanted to do for a while is add a long string building class to generate asm into that would use a set of buffers adding new ones when the space is needed. So that would look something like I'd do something a little

Re: [PATCH] xtensa: don't xfail gcc.c-torture/compile/20001226-1.c

On Wed, Nov 2, 2016 at 10:22 AM, augustine.sterl...@gmail.com wrote: > On Tue, Nov 1, 2016 at 12:45 PM, Max Filippov wrote: >> With jump trampolines implemented in binutils since 2.25 and enabled by >> default this test no longer fails on xtensa.

Re: [PATCH] xtensa: fix ICE on pr59037.c test

On Wed, Nov 2, 2016 at 10:23 AM, augustine.sterl...@gmail.com wrote: > On Tue, Nov 1, 2016 at 12:11 PM, Max Filippov wrote: >> xtensa gcc gets ICE on pr59037.c test because its xtensa_output_literal >> function cannot handle integer literals of

Re: [Patch ARM 4/4] Enable _Float16

On Wed, 2 Nov 2016, James Greenhalgh wrote: > Done in this revision, though this makes no difference to what gets tested > as these options are not added when compiling the probe functions > (check_effective_target_float16). These would need a patch like: > > diff --git

Re: [PATCH 0/3] use rtx_insn * more

On Wed, Nov 02, 2016 at 05:35:40PM +0100, Bernd Schmidt wrote: > On 11/02/2016 03:55 PM, David Malcolm wrote: > > > Did you mean this patch: > > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01358.html > > That one is ok after the test, sorry for not being more clear. ah, no worries :) and

Re: [PATCH] Generate reproducible output independently of the build-path

Ximin Luo: > Joseph Myers: >> On Wed, 2 Nov 2016, Ximin Luo wrote: >> >>> This patch series adds a new environment variable SOURCE_PREFIX_MAP. When >>> this >>> is set, GCC will treat this as an implicit "-fdebug-prefix-map=$value" >>> command-line argument. This makes the final binary output

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

On 11/02/2016 02:11 AM, Bernd Edlinger wrote: On 11/01/16 19:15, Bernd Edlinger wrote: On 11/01/16 18:11, Jason Merrill wrote: On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger wrote: On 11/01/16 16:20, Jason Merrill wrote: On 10/17/2016 03:18 PM, Bernd Edlinger

Re: [ping * 4] PR35503 - warn for restrict

On 2 November 2016 at 23:07, Jason Merrill wrote: > On Wed, Nov 2, 2016 at 1:08 PM, Prathamesh Kulkarni > wrote: >> On 2 November 2016 at 18:29, Jason Merrill wrote: >>> Then I'll approve the whole patch. >> Thanks! >> Trying

Re: [Patch ARM 4/4] Enable _Float16

On Mon, Oct 24, 2016 at 10:28:42PM +, Joseph Myers wrote: > On Mon, 24 Oct 2016, James Greenhalgh wrote: > > > Hi, > > > > Finally, having added support for single-step DFmode to HFmode conversions, > > this patch adds support for _Float16 to the ARM back-end. > > Given the need for

Re: [Patch 3/4] Half to double precision conversions

On Mon, Oct 24, 2016 at 10:24:27PM +, Joseph Myers wrote: > On Mon, 24 Oct 2016, James Greenhalgh wrote: > > > Conversions from double precision floats to the ARM __fp16 are required > > to round only once. > > I'd expect that when fixing this you need to update >

Re: RFC: Warnings silenced when macros from system headers are used (PR c/78000, c/71613)

On Wed, Nov 2, 2016 at 12:37 PM, Joseph Myers wrote: > On Wed, 2 Nov 2016, Jason Merrill wrote: > >> It seems to me that the general principle is that we should consider >> the location where the thing we're warning about is happening. In >> >>float_var = LLONG_MIN;

Re: [Patch 6/11] Migrate excess precision logic to use TARGET_EXCESS_PRECISION

On Fri, Oct 28, 2016 at 09:09:55PM +, Joseph Myers wrote: > On Fri, 14 Oct 2016, James Greenhalgh wrote: > > > +/* If the join of the implicit precision in which the target will compute > > + floating-point values and the standard precision in which the target > > will > > + compute

Re: [ping * 4] PR35503 - warn for restrict

On Wed, Nov 2, 2016 at 1:08 PM, Prathamesh Kulkarni wrote: > On 2 November 2016 at 18:29, Jason Merrill wrote: >> Then I'll approve the whole patch. > Thanks! > Trying the patch on kernel build (allmodconfig) reveals the following > couple of

Re: [Patch 1/11] Add a new target hook for describing excess precision intentions

On Fri, Oct 28, 2016 at 09:12:11PM +, Joseph Myers wrote: > On Fri, 14 Oct 2016, James Greenhalgh wrote: > > > + value set for @code{-fexcess-precision=[standard|fast]}.", > > I think the correct markup for the option here is: > > @option{-fexcess-precision=@r{[}standard@r{|}fast@r{]}} > >

Re: [PATCH] DW_TAG_ptr_to_member_type for PMF and DW_AT_{,rvalue_}reference for those

On Wed, Nov 2, 2016 at 12:33 PM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 04:44:05PM +0100, Jakub Jelinek wrote: >> which means if gen_type_die or gen_type_die_with_usage doesn't >> use the langhook, then we'd emit a completely useless { __pfn; __delta } >> struct into

Re: [PATCH] xtensa: fix ICE on pr59037.c test

On Tue, Nov 1, 2016 at 12:11 PM, Max Filippov wrote: > xtensa gcc gets ICE on pr59037.c test because its xtensa_output_literal > function cannot handle integer literals of sizes other than 4 and 8, > whereas the test uses 16-byte int vector. > Split integer literal formatting

Re: [PATCH] xtensa: don't xfail gcc.c-torture/compile/20001226-1.c

On Tue, Nov 1, 2016 at 12:45 PM, Max Filippov wrote: > With jump trampolines implemented in binutils since 2.25 and enabled by > default this test no longer fails on xtensa. > > 2016-11-01 Max Filippov > gcc/testsuite/ > *

PR61409: -Wmaybe-uninitialized false-positive with -O2

Hi Jeff. As discussed in the PR, here is a patch exploring your idea of ignoring unguarded uses if we can prove that the guards for such uses are invalidated by the uninitialized operand paths being executed. This is an updated patch from my suggestion in the PR. It bootstraps with no

Re: [PATCH][AArch64] Improve SHA1 scheduling

On Tue, Oct 25, 2016 at 10:08 AM, Wilco Dijkstra wrote: > SHA1H instructions may be scheduled after a SHA1C instruction > that uses the same input register. However SHA1C updates its input, > so if SHA1H is scheduled after it, it requires an extra move. > Increase the

Re: [ping * 4] PR35503 - warn for restrict

On 2 November 2016 at 18:29, Jason Merrill wrote: > Then I'll approve the whole patch. Thanks! Trying the patch on kernel build (allmodconfig) reveals the following couple of warnings: http://pastebin.com/Sv2HFDUv I think warning for str_error_r() is correct, however I am not

[PATCH, GCC/ARM] Fix PR77933: stack corruption on ARM when using high registers and lr

Hi, When saving registers, function thumb1_expand_prologue () aims at minimizing the number of push instructions. One of the optimization it does is to push lr alongside high register(s) (after having moved them to low register(s)) when there is no low register to save. The way this is

Re: [PATCH] Generate reproducible output independently of the build-path

Joseph Myers: > On Wed, 2 Nov 2016, Ximin Luo wrote: > >> This patch series adds a new environment variable SOURCE_PREFIX_MAP. When >> this >> is set, GCC will treat this as an implicit "-fdebug-prefix-map=$value" >> command-line argument. This makes the final binary output reproducible, and >

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

Sure, they might and in that case the warning would be a false positive. It wouldn't be the first such warning that wasn't 100% free of them. But my testing with Binutils, GCC, and the Linux kernel has exposed only 10 instances of new warnings and I don't think I saw this idiom among them. But

[PATCH] rs6000: Disable shrink-wrap-separate for abi=spe (PR78168)

With the SPE ABI, if we wrap GPRs we need to handle the upper half of the extended 64-bit registers as well, which we cannot easily do. So, this patch disables separate shrink-wrapping for the SPE ABI. Tested on powerpc64-linux {-m32,-m64}; also tested on the testcase (I finally managed to build

Re: [PATCH][AArch64] Improve SHA1 scheduling

ping From: Wilco Dijkstra Sent: 25 October 2016 18:08 To: GCC Patches Cc: nd Subject: [PATCH][AArch64] Improve SHA1 scheduling   SHA1H instructions may be scheduled after a SHA1C instruction that uses the same input register.  However SHA1C updates its input, so if SHA1H is scheduled after

Re: [PATCH][AArch64 - v3] Simplify eh_return implementation

  ping From: Wilco Dijkstra Sent: 02 September 2016 12:31 To: Ramana Radhakrishnan; GCC Patches Cc: nd Subject: Re: [PATCH][AArch64 - v3] Simplify eh_return implementation     Ramana Radhakrishnan wrote: > Can you please file a PR for this and add some testcases ?  This sounds like > a

Re: [PATCH v2][AArch64] Fix symbol offset limit

    ping From: Wilco Dijkstra Sent: 12 September 2016 15:50 To: Richard Earnshaw; GCC Patches Cc: nd Subject: Re: [PATCH v2][AArch64] Fix symbol offset limit     Wilco wrote:    > The original example is from GCC itself, the fixed_regs array is small but > due to > optimization we can end

Re: [PATCH v2] AIX visibility

On Wed, Nov 02, 2016 at 11:28:40AM -0500, Segher Boessenkool wrote: > On Wed, Nov 02, 2016 at 11:41:32AM -0400, David Edelsohn wrote: > > Any comments on ASM_WEAKEN_DECL change? > > It no longer checks RS6000_WEAK, is that always on now? Oh never mind, I can't read (it actually scrolled off my

Re: [PATCH] DW_TAG_ptr_to_member_type for PMF and DW_AT_{,rvalue_}reference for those

On Wed, Nov 02, 2016 at 04:44:05PM +0100, Jakub Jelinek wrote: > which means if gen_type_die or gen_type_die_with_usage doesn't > use the langhook, then we'd emit a completely useless { __pfn; __delta } > struct into debug info first, and then in modified_type_die used > the langhook, get

Re: RFC: Warnings silenced when macros from system headers are used (PR c/78000, c/71613)

On Wed, 2 Nov 2016, Jason Merrill wrote: > It seems to me that the general principle is that we should consider > the location where the thing we're warning about is happening. In > >float_var = LLONG_MIN; > > The relevant location is that of the assignment, not the constant on > the RHS.

Re: [PATCH] Generate reproducible output independently of the build-path

On Wed, 2 Nov 2016, Ximin Luo wrote: > This patch series adds a new environment variable SOURCE_PREFIX_MAP. When this > is set, GCC will treat this as an implicit "-fdebug-prefix-map=$value" > command-line argument. This makes the final binary output reproducible, and Only one argument?

Re: [PATCH 0/3] use rtx_insn * more

On 11/02/2016 03:55 PM, David Malcolm wrote: Did you mean this patch: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01358.html That one is ok after the test, sorry for not being more clear. Bernd

Re: [PATCH v2] AIX visibility

On Wed, Nov 02, 2016 at 11:41:32AM -0400, David Edelsohn wrote: > Any comments on ASM_WEAKEN_DECL change? It no longer checks RS6000_WEAK, is that always on now? Otherwise looks fine to me. Segher

Re: [PATCH 1/4] Use SOURCE_PREFIX_MAP envvar as an implicit debug-prefix-map

On Wed, 2 Nov 2016, Ximin Luo wrote: > +@item SOURCE_PREFIX_MAP If this variable is set, it specifies a mapping The text should start on a separate line from the @item. > +that is used to transform filepaths that are output in debug symbols. > +This helps the embedded paths become reproducible,

Re: RFC: Warnings silenced when macros from system headers are used (PR c/78000, c/71613)

On Wed, Nov 2, 2016 at 11:51 AM, Marek Polacek wrote: > One of the pending issues that we should address before we release GCC 7 is > that sometimes we don't issue a warning if the location points to a macro > defined in a system header, unless -Wsystem-headers. Consider e.g.

Re: [PATCH][GCC][testsuite] Fix failing vminnm/vmaxnm tests for ARM

On 2 November 2016 at 16:38, Tamar Christina wrote: > Hi all, > > This fixes the ARM failures in the testsuite. > Previously these tests were gated on if ARMv8-a > support was available in the compiler, not if the hardware > was an ARMv8-a hardware. > > This thus resulted

RFC: Warnings silenced when macros from system headers are used (PR c/78000, c/71613)

One of the pending issues that we should address before we release GCC 7 is that sometimes we don't issue a warning if the location points to a macro defined in a system header, unless -Wsystem-headers. Consider e.g. enum { e1 = LLONG_MIN }; or float_var = LLONG_MIN; Here, LLONG_MIN

Re: [PATCH] DW_TAG_ptr_to_member_type for PMF and DW_AT_{,rvalue_}reference for those

On Wed, Nov 02, 2016 at 11:31:25AM -0400, Jason Merrill wrote: > On Wed, Nov 2, 2016 at 10:31 AM, Jakub Jelinek wrote: > > It uses Alex' LANG_HOOKS_GET_PTRMEMFN_TYPE langhook. I've tried > > to think about https://gcc.gnu.org/ml/gcc-patches/2011-05/msg00227.html > > and we even

[PATCH, Fortran] Extension: Support legacy PARAMETER statements with -std=legacy (or -fdec?)

All, Another quirk of legacy compilers is their syntax for PARAMETER statements. Such statements are similar to standard PARAMETER statements but lack parentheses following the PARAMETER keyword. There is a good reason the standard doesn't support this - because the statement becomes ambiguous

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

On 11/02/2016 01:37 AM, Jakub Jelinek wrote: On Tue, Nov 01, 2016 at 08:55:03PM -0600, Martin Sebor wrote: struct S { int a, b, c, d; }; #define bos(p, t) __builtin_object_size (p, t) #define memset0(p, i, n) __builtin___memset_chk (p, i, n, bos (p, 0)) #define memset1(p, i, n)

Re: [PATCH][GCC][testsuite] Fix failing vminnm/vmaxnm tests for ARM

On 02/11/16 15:38, Tamar Christina wrote: Hi all, This fixes the ARM failures in the testsuite. Previously these tests were gated on if ARMv8-a support was available in the compiler, not if the hardware was an ARMv8-a hardware. This thus resulted in correct code, but wouldn't run on any other

[PATCH v2] AIX visibility

This revised patch makes two changes: 1) Fix typo in configure.ac 2) Add AIX visibility support for ASM_WEAKEN_DECL, which does touch the same code as Linux. The AIX "weak" support fixes a large number of C++ visibility testcases. Bootstrapped on powerpc-ibm-aix7.2.0.0. * configure.ac

Re: [PATCH] combine: Improve change_zero_ext (fixes PR71847)

On Tue, Oct 25, 2016 at 11:40 AM, Segher Boessenkool wrote: > This improves a few things in change_zero_ext. Firstly, it should use > the passed in pattern in recog_for_combine, not the pattern of the insn > (they are not the same if the whole pattern was replaced).

[PATCH][GCC][testsuite] Fix failing vminnm/vmaxnm tests for ARM

Hi all, This fixes the ARM failures in the testsuite. Previously these tests were gated on if ARMv8-a support was available in the compiler, not if the hardware was an ARMv8-a hardware. This thus resulted in correct code, but wouldn't run on any other hardware. Ran regression tests on

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

OK. On Wed, Nov 2, 2016 at 10:18 AM, Jiong Wang wrote: > On 02/11/16 13:42, Jakub Jelinek wrote: >> >> On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote: >>> >>> -/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION >>> note. */ >>> +/* A

Re: [PATCH] DW_TAG_ptr_to_member_type for PMF and DW_AT_{,rvalue_}reference for those

On Wed, Nov 2, 2016 at 10:31 AM, Jakub Jelinek wrote: > It uses Alex' LANG_HOOKS_GET_PTRMEMFN_TYPE langhook. I've tried > to think about https://gcc.gnu.org/ml/gcc-patches/2011-05/msg00227.html > and we even have such a langhook now, modified_type_die > uses

Re: [PATCH] bb-reorder: Improve compgotos pass (PR71785)

On Wed, Nov 02, 2016 at 02:51:41PM +0100, Richard Biener wrote: > >> I don't believe it needs a cleanup on every iteration. One cleanup at > >> the end should work fine. > > > > But as the comment there says: > > > > /* Merge the duplicated blocks into predecessors, when possible. */ > >

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On 11/02/2016 03:51 PM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 03:38:25PM +0100, Martin Liška wrote: >> it converts: >> foo () >> { >> char a; >> char * p; >> char _1; >> int _2; >> int _8; >> int _9; >> >> : >> ASAN_MARK (2, , 1); >> a = 0; >> p_6 = >> ASAN_MARK (1,

Re: [PATCH] Fix for big-endian gcc.c-torture/execute/pr55750.c

On Wed, 2 Nov 2016, Kyrill Tkachov wrote: > Hi all, > > I noticed that my patch for PR tree-optimization/78170 broke > execute.exp=pr55750.c on big-endian. > The problem with that patch is that we should not forget to clear the padding > bits in the temporary > buffer when merging values even

[PATCH] Fix PR78185

The following fixes PR78185 by properly honoring possibly infinite child loops when computing what blocks are always executed during loop invariant motion. Such loops behave as if the loop would exit at this point. Both GIMPLE and RTL level passes have that very same issue and the following

[PATCH] Fix for big-endian gcc.c-torture/execute/pr55750.c

Hi all, I noticed that my patch for PR tree-optimization/78170 broke execute.exp=pr55750.c on big-endian. The problem with that patch is that we should not forget to clear the padding bits in the temporary buffer when merging values even when they are less than a byte. Tested on

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 02, 2016 at 03:38:25PM +0100, Martin Liška wrote: > it converts: > foo () > { > char a; > char * p; > char _1; > int _2; > int _8; > int _9; > > : > ASAN_MARK (2, , 1); > a = 0; > p_6 = > ASAN_MARK (1, , 1); > _1 = *p_6; You shouldn't convert if a is

Re: [PATCH 0/3] use rtx_insn * more

On Wed, 2016-11-02 at 00:05 -0400, Trevor Saunders wrote: > On Mon, Oct 31, 2016 at 07:37:54AM -0600, Jeff Law wrote: > > On 10/28/2016 01:13 PM, tbsaunde+...@tbsaunde.org wrote: > > > From: Trevor Saunders > > > > > > HI, > > > > > > This series changes various

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On 11/02/2016 02:16 PM, Richard Biener wrote: > On Wed, Nov 2, 2016 at 2:06 PM, Jakub Jelinek wrote: >> On Wed, Nov 02, 2016 at 01:59:00PM +0100, Richard Biener wrote: Yeah, that is what I meant. The issue is how to report uses of such SSA_NAME when there is no

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 02, 2016 at 03:27:42PM +0100, Martin Liška wrote: > > So is there anything I should do wrt -Wswitch-unreachable? > > > > Marek > > > > Probably not. I'm having a patch puts GIMPLE_SWITCH statement to a proper > place > in GIMPLE_BIND. Let's see whether such patch can bootstrap

[PATCH] DW_TAG_ptr_to_member_type for PMF and DW_AT_{,rvalue_}reference for those

Hi! This is a merge of my patch from yesterday, Jason's incremental patch to that and parts of Alex' patch from Oct 19. It uses Alex' LANG_HOOKS_GET_PTRMEMFN_TYPE langhook. I've tried to think about https://gcc.gnu.org/ml/gcc-patches/2011-05/msg00227.html and we even have such a langhook now,

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On 11/02/2016 03:20 PM, Marek Polacek wrote: > On Wed, Nov 02, 2016 at 11:10:53AM +0100, Jakub Jelinek wrote: >> On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote: Which is gimplified as: int * ptr; switch (argc) , case 1: > { int a;

[PATCH] Generate reproducible output independently of the build-path

(Please keep me on CC, I am not subscribed) Background == We are on a long journey to make build processes be able to reproduce the build outputs independently of which filesystem path the build is being executed from - e.g. if the executing user doesn't have root access to be able to

[PATCH 3/4] Use SOURCE_PREFIX_MAP envvar to transform __FILE__

Honour the SOURCE_PREFIX_MAP environment variable when expanding the __FILE__ macro, in the same way that debug-prefix-map works for debugging symbol paths. This patch follows similar lines to the earlier patch for SOURCE_DATE_EPOCH. Specifically, we read the environment variable not in libcpp

[PATCH 1/4] Use SOURCE_PREFIX_MAP envvar as an implicit debug-prefix-map

Define the SOURCE_PREFIX_MAP environment variable, and treat it as an implicit CLI -fdebug-prefix-map option specified before any explicit such options. Acknowledgements Daniel Kahn Gillmor who wrote the patch for r231835, which saved me a lot of time figuring out what to edit.

[PATCH 4/4] Use SOURCE_DATE_EPOCH in place of __TIMESTAMP__ if the latter is newer.

This brings the behaviour in line with the __DATE__ and __TIME__ macros. Note though the minor difference: __TIMESTAMP__ is defined as the file-modification date and not the "current" date or time like the other two macros. Therefore, we do a clamping behaviour (similar to tar --clamp-mtime).

[PATCH 2/4] Split prefix-map values on the last '=' character, not the first

We are planning to ask other tools to support SOURCE_PREFIX_MAP, in the same way that we have already done this for SOURCE_DATE_EPOCH. So, this will last for some time and have quite wide reach. Consequently, we believe it is better to split on the final '=', since it is much less likely to result

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 02, 2016 at 11:10:53AM +0100, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote: > > > Which is gimplified as: > > > > > > int * ptr; > > > > > > switch (argc) , case 1: > > > > { > > > int a; > > > > > > try > > > {

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

On 02/11/16 13:42, Jakub Jelinek wrote: On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote: -/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note. */ +/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note. */ Too long line. Hmm, it

Re: [RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS

On Wed, Nov 2, 2016 at 2:43 PM, Wilco Dijkstra wrote: > Richard Biener wrote: > On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra > wrote: > >> > If bswap is false no byte swap is needed, so we found a native endian load >> > and it will always

Re: [PATCH] bb-reorder: Improve compgotos pass (PR71785)

On Wed, Nov 2, 2016 at 2:40 PM, Segher Boessenkool wrote: > On Wed, Nov 02, 2016 at 11:39:20AM +0100, Steven Bosscher wrote: >> On Wed, Nov 2, 2016 at 10:02 AM, Richard Biener >> wrote: >> > On Mon, Oct 31, 2016 at 4:35 PM, Segher

Re: [RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS

Richard Biener wrote: On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra wrote: > > If bswap is false no byte swap is needed, so we found a native endian load > > and it will always perform the optimization by inserting an unaligned load. > > Yes, the general agreement is

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

On Wed, Nov 02, 2016 at 01:26:48PM +, Jiong Wang wrote: > -/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note. > */ > +/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_EXPRESSION note. > */ Too long line. > +/* RTL sequences inside PARALLEL are raw

Re: [PATCH] bb-reorder: Improve compgotos pass (PR71785)

On Wed, Nov 02, 2016 at 11:39:20AM +0100, Steven Bosscher wrote: > On Wed, Nov 2, 2016 at 10:02 AM, Richard Biener > wrote: > > On Mon, Oct 31, 2016 at 4:35 PM, Segher Boessenkool wrote: > >> On Mon, Oct 31, 2016 at 04:09:48PM +0100, Steven Bosscher wrote: > >>> On

Re: [RFC PATCH] expand_strn_compare should attempt expansion even if neither string is constant

On Wed, 2016-11-02 at 13:41 +0100, Bernd Schmidt wrote: > On 10/27/2016 03:14 AM, Aaron Sawdey wrote: > > > > I'm currently working on a builtin expansion of strncmp for powerpc > > similar to the one for memcmp I checked recently. One thing I > > encountered is that the code in

Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsincs.

On 2 November 2016 at 12:22, Bin.Cheng wrote: > On Tue, Nov 1, 2016 at 12:21 PM, Kyrill Tkachov > wrote: >> Hi Tamar, >> >> >> On 26/10/16 16:01, Tamar Christina wrote: >>> >>> Hi Christophe, >>> >>> Here's the updated patch. >>> >>> Cheers,

Re: [PATCH 1/2, libgcc]: Implement _divmoddi4

On Mon, Oct 31, 2016 at 7:46 AM, Uros Bizjak wrote: > This function will be used in a follow-up patch to implement > TARGET_EXPAND_DIVMOD_LIBFUNC for x86 targets. Other targets can call > this function, so IMO it should be part of a generic library. > > 2016-10-31 Uros Bizjak

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

On 01/11/16 16:48, Jason Merrill wrote: > It seems to me that a CFA_*expression note would never use target > UNSPEC codes, and a DWARF UNSPEC would never appear outside of such a > note, so we don't need to worry about conflicts. Indeed. DWARF UNSPEC is deeper inside DW_CFA_*expression note.

Re: [PATCH] libiberty: Fix -Wimplicit-fallthrough warnings.

On Wed, Nov 02, 2016 at 02:19:33PM +0100, Mark Wielaard wrote: > Adjust some comments, add some explicit fall through comments or explicit > returns where necessary to not get implicit-fallthrough warnings. > > All fall throughs were deliberate. In one case I added an explicit return > false for

[PATCH] libiberty: Fix -Wimplicit-fallthrough warnings.

Adjust some comments, add some explicit fall through comments or explicit returns where necessary to not get implicit-fallthrough warnings. All fall throughs were deliberate. In one case I added an explicit return false for clarity instead of falling through a default case (that also would return

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 2, 2016 at 2:06 PM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 01:59:00PM +0100, Richard Biener wrote: >> > Yeah, that is what I meant. The issue is how to report uses of such >> > SSA_NAME when there is no memory. So, either we'd need a special runtime >> >

[PATCH] Allow non-NULL offset for store-merging bases

The following teaches store-merging to handle non-NULL offset if the base is already addressable (otherwise introducing new pointers to a non-addressable base invalidates points-to information, see a comment in the patch how we could avoid this in theory). Bootstrap and regtest running on

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 02, 2016 at 01:59:00PM +0100, Richard Biener wrote: > > Yeah, that is what I meant. The issue is how to report uses of such > > SSA_NAME when there is no memory. So, either we'd need a special runtime > > library entrypoint that would report uses after scope even when there is no > >

Re: [ping * 4] PR35503 - warn for restrict

Then I'll approve the whole patch. On Wed, Nov 2, 2016 at 8:42 AM, Joseph Myers wrote: > The format-checking parts of the patch are OK. > > -- > Joseph S. Myers > jos...@codesourcery.com

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 2, 2016 at 1:56 PM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 01:36:31PM +0100, Richard Biener wrote: >> > Unless I'm missing something we either need to perform further analysis >> > during the addressable subpass - this variable could be made >> >

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 02, 2016 at 01:36:31PM +0100, Richard Biener wrote: > > Unless I'm missing something we either need to perform further analysis > > during the addressable subpass - this variable could be made > > non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA > > form there

Re: [ping * 4] PR35503 - warn for restrict

The format-checking parts of the patch are OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS

On Tue, Nov 1, 2016 at 10:39 PM, Wilco Dijkstra wrote: > Jeff Law wrote: > >> I think you'll need to look at bz61320 before this could go in. > > I had a look, but there is nothing there that is related - eventually > a latent alignment bug was fixed in

Re: [RFC PATCH] expand_strn_compare should attempt expansion even if neither string is constant

On 10/27/2016 03:14 AM, Aaron Sawdey wrote: I'm currently working on a builtin expansion of strncmp for powerpc similar to the one for memcmp I checked recently. One thing I encountered is that the code in expand_strn_compare will not attempt to expand the cmpstrnsi pattern at all if neither

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

On Wed, Nov 2, 2016 at 10:52 AM, Jakub Jelinek wrote: > On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote: >> > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property >> > set during the asan pass and kept on until end of compilation of that >> >

Re: [PATCH, vec-tails] Support loop epilogue vectorization

On Tue, 1 Nov 2016, Yuri Rumyantsev wrote: > Hi All, > > I re-send all patches sent by Ilya earlier for review which support > vectorization of loop epilogues and loops with low trip count. We > assume that the only patch - vec-tails-07-combine-tail.patch - was not > approved by Jeff. > > I did

Re: [PATCH, RFC, rs6000] Add overloaded built-in function support to altivec.h, and re-implement vec_add

On Nov 2, 2016, at 4:28 AM, Jakub Jelinek wrote: > > On Wed, Nov 02, 2016 at 10:19:26AM +0100, Richard Biener wrote: >> On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote: >>> On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote: The PowerPC

  1   2   >