Re: [DOC,PATCH] Mention clog10, clog10f an clog10l in Builtins section.

On 12/04/2015 10:45 AM, Martin Liška wrote: > Hello. > > I noticed that Builtins section of documentation does not mention > clog10{,f,l} functions. > I've tried to write a patch, however I'm not sure how should be these > functions described. > > Thanks, > Martin > PING

Re: [DOC,PATCH] Mention clog10, clog10f an clog10l in Builtins section.

On 02/26/2016 12:11 PM, Richard Biener wrote: > Ok with also addign them to the @findex list above. > > Richard. Thanks for review, updated version installed as r233738. Martin

Re: [PATCH] Do not gather mem stats in run_exit_handles (PR middle-end/69919)

On 02/25/2016 07:02 PM, David Malcolm wrote: > Was this tested with "jit" in --enable-languages? I ask because > toplev::main can be run repeatedly by libgccjit, and it looks like > nothing can reset after_memory_report. (Though I don't typically build > with --enable-gather-detailed-mem-stats,

Re: [hsa merge 07/10] IPA-HSA pass

On 01/16/2016 11:00 AM, Jan Hubicka wrote: > Can't it be represented via explicit REF_ADDR or something like that? > > Honza Hi. Sure, I've just done a patch that can do that. However, as we're currently in stage4, that change would probably require explicit permission of a release manager?

Re: [PATCH] Fix PR sanitizer/PR69276

On 01/27/2016 01:58 PM, Jakub Jelinek wrote: > On Wed, Jan 27, 2016 at 01:47:10PM +0100, Martin Liška wrote: >> Following patch was kind of pre-approved by Jakub in: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69276#c4 >> >> Patch can bootstrap in x86_64-linux-gnu an

Re: [hsa merge 07/10] IPA-HSA pass

On 01/26/2016 12:41 AM, Jan Hubicka wrote: >> On Mon, Jan 25, 2016 at 04:21:50PM +0100, Martin Liška wrote: >>> On 01/16/2016 11:00 AM, Jan Hubicka wrote: >>>> Can't it be represented via explicit REF_ADDR or something like that? >>>> >>>> Hon

[PATCH] Fix PR sanitizer/PR69276

Following patch was kind of pre-approved by Jakub in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69276#c4 Patch can bootstrap in x86_64-linux-gnu and survives regression tests. I also verified that newly added test-case works with the patch. Ready for trunk? Thanks, Martin >From

[PATCH] Fix PR pch/68758

Hello. As mentioned in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758#c5, I consider more logic to encapsulate valgrind annotation magic within a ENABLE_VALGRIND_ANNOTATIONS macro rather than ENABLE_VALGRIND_CHECKING. With patch applied, ggc invalid reads/writes, reported by valgrind

Re: [wwwdocs] Describe behavior of -flifetime-dse in class constructors

On 02/16/2016 05:55 PM, Martin Sebor wrote: > I think the new text deserves a new heading of its own rather than > being added under the existing "Stricter flexible array member rules." > (The "Finally..." part changed by the patch still applies to the > flexible array members.) > > Martin Hi

Re: [wwwdocs] Describe behavior of -flifetime-dse in class constructors

On 02/17/2016 03:23 PM, Jakub Jelinek wrote: > "has been" looks weird. I'd say that the C++ compiler is now more > aggressive... > > Jakub Sending v3. M. Index: htdocs/gcc-6/porting_to.html === RCS file:

[PATCH] Do not emit red stack zones for a fn with no_sanitize_address (PR sanitizer/69863)

Hi. Following patch was suggested by Jakub (and suggested to be installed in this stage4). I've been thinking about a test-case (which would require an assembler scan of red zone emission). Should I come up with a ?86 test-case that will scan that? Bootstrap and regression tests have been

Re: [PATCH] Do not emit red stack zones for a fn with no_sanitize_address (PR sanitizer/69863)

On 02/18/2016 01:59 PM, Jakub Jelinek wrote: > Ok for trunk with those changes. > > Jakub Thank you for review, installed as r233524. Martin

[wwwdocs] Describe behavior of -flifetime-dse in class constructors

Hello. As I finally hunted issue in Firefox that was responsible for start-up segfault, I would like to describe a new behavior of the compiler that emits clobbers to class constructors (w/ -flifetime-dse). As also Richi spotted quite similar issue in openjade package, I think it worth for

[PATCH] Retry to emit global variables in HSA (PR hsa/70234)

Hi. As emission of a HSAIL function can fail for various reason (-Whsa), we must guarantee that a global variable is declared and at maximum once. Following patch does that, patch can survive make check-target-libgomp and HSAILAsm is happy with BRIG output of declare_target-5.c source file.

[PATCH] Revert r234572 (aka PR testsuite/70577)

Hello. As release managers agreed on IRC, following patch reverts r234572 which introduced new PR testsuite/70577. I've been running bootstrap & regression tests on x86_64-linux-gnu. Ready to be installed after it finishes? Thanks, Martin >From 978ddfeada20e5597767df120e5d65eef1115c1b Mon Sep

Re: [HSA, PATCH] Allocate memory for shadow arg (PR hsa/70337)

On 03/21/2016 07:23 PM, Martin Jambor wrote: This is strange. The pointer to the shadow data structure is, from the HSA perspective, a normal kernel argument and therefore should already be included in the kernel->kernarg_segment_size. Have you checked that the values are indeed off? Hi

Re: [PATCH] Skip static ctors/dtors in IPA ICF (PR ipa/70306)

On 03/21/2016 07:20 PM, Jan Hubicka wrote: > OK, (it woudl make more sense to turn them into wrappers that can be easily > done, too, but we can do that next stage1) > thanks! > > Honza Sure, will do that in next stage1. I've just bootstrapped and regtested the same patch on GCC-5 branch w/o

[PATCH, HSA]: Fix PR hsa/70399

Hello. Current HSA back-end wrongly handles memory stores. Although, we properly identify that an immediate operand needs to respect type of a memory store instruction it belongs to, the binary representation of the operand is not updated. Following patch delays emission of the binary

Re: [PATCH] Retry to emit global variables in HSA (PR hsa/70234)

On 03/17/2016 07:21 PM, Martin Jambor wrote: > Hopefully the linear search in m_global_symbols never becomes > prohibitively expensive. But it is only necessary when > is_in_global_vars is true, so at least we could do something like: > > if (is_in_global_vars && !sym->m_emitted_to_brig) >

[HSA, PATCH] Enhance dump output

Hello. Following patch enhances dump output for SBR instructions and provides a BRIG offset of HSA symbols. The change does not touch any code generation snippet and I hope it can be installed during the stage4? Patch can bootstrap on x86_64-linux-gnu and survives make check-target-libgomp.

[HSA, PATCH] Allocate memory for shadow arg (PR hsa/70337)

Hello. Following patch fixes an invalid write in HSA plug-in. I've been running bootstrap and regression tests on x86-linux-gnu. Ready after it finishes? Thanks, Martin >From 2674ceb5fddeaeb26ff87d26a43bddaf40060ea2 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 21 Mar 2016

[PATCH] Skip static ctors/dtors in IPA ICF (PR ipa/70306)

Hello. Following patch skips static {c,d}tors in IPA ICF. Patch can bootstrap and survives regtests on x86_64-linux-gnu. Ready for trunk? Thanks, Martin >From 7a5748b38e173702c88b97420d6b4d8969ae7e85 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 21 Mar 2016 13:51:32 +0100

[PATCH] Properly assign to packet header (PR hsa/70394)

Hello. Following patch initializes whole packet->header field, which is eventually stored to a packet in atomic manner. The function mechanism was adopted from the HSA runtime manual. I've been running bootstrap and regression tests. Ready to be installed after it finishes? Thanks, Martin

[PATCH] Skip properly debug stmt in optimize_mask_stores (PR tree-optimization/70043)

Hi. Following patch fixes the PR, regtested on x86_64-linux-gnu. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2016-03-02 Martin Liska * tree-vect-loop.c (optimize_mask_stores): Move iterator to previous statement if we see a debug statement.

Re: [PATCH 2/2] HSA: handle alignment of string builtins (PR hsa/70391)

On 03/31/2016 04:58 PM, Martin Jambor wrote: > Hi, > > On Wed, Mar 23, 2016 at 02:43:17PM +0100, Martin Liska wrote: >> gcc/ChangeLog: >> >> 2016-03-23 Martin Liska >> >> PR hsa/70391 >> * hsa-gen.c (hsa_function_representation::update_cfg): New >> function. >>

Re: [PATCH 1/2] HSA: support alignment for hsa_symbols (PR hsa/70391)

On 03/31/2016 04:40 PM, Martin Jambor wrote: > Let's say "efficient memory copy instructions." It is of curse > possible to use slower ones. > > Thanks, > > Martin Thanks for review, I'm attaching the version of the patch I'm going to install. Martin >From

Re: [PATCH, HSA]: Fix PR hsa/70399

On 03/24/2016 03:59 PM, Martin Liška wrote: > Hello. > > Current HSA back-end wrongly handles memory stores. Although, we properly > identify > that an immediate operand needs to respect type of a memory store instruction > it belongs to, > the binary represen

[HSA branch, PATCH] introduce append_phi method

Hello. Following patch introduces just a single helper method, install to HSA branch as r234648. Thanks, Martin >From 6d7c765425de3363a8edef2c25572b8208123fb8 Mon Sep 17 00:00:00 2001 From: marxin Date: Thu, 31 Mar 2016 11:39:56 +0200 Subject: [PATCH] HSA: introduce append_phi

[PATCH] Fix PR hsa/70402

Hello. As reported here: https://github.com/HSAFoundation/gccbrig/issues/3#issuecomment-199887172, our current HSA back-end emits a SBR instruction that is followed by a jump instruction for cases where index is outside of array of labels. However, as mentioned here:

[PATCH 1/2] Do not verify CFG if a function is discarded (PR

Hello. The problem with the original patch is that I'm forced to produce an empty BB to produce true/false edge needed for the 'index' check: /home/marxin/Programming/testhsa/run_tests/012-switch/switch-5.c:28:9: error: true/false edge after a non-GIMPLE_COND in bb 4

[PATCH 2/2] Fix PR hsa/70402

Second part of the patch set which omits one split_block (compared to the original patch). Acceptable just in case the first part will be accepted. Thanks Martin >From 2a9a8f11ea1ecd04c3b9915ff77fc791c55632da Mon Sep 17 00:00:00 2001 From: marxin Date: Tue, 29 Mar 2016 12:06:20

Re: [PATCH 1/2] Do not verify CFG if a function is discarded (PR

On 03/29/2016 02:10 PM, Richard Biener wrote: > On Tue, Mar 29, 2016 at 1:42 PM, Martin Liška <mli...@suse.cz> wrote: >> Hello. >> >> The problem with the original patch is that I'm forced to produce >> an empty BB to produce true/false edge needed for the

Re: [HSA, PATCH] Enhance dump output

On 03/21/2016 06:44 PM, Martin Jambor wrote: ...please remove the added newlines here... >+ if (symbol->m_directive_offset) >+fprintf (f, " /* BRIG offset: %u", symbol->m_directive_offset); ...and I think you are missing an ending "*/" in the string you dump. Sure, fixed.

Re: [PATCH 2/2] Fix PR hsa/70402

On 03/29/2016 01:44 PM, Martin Liška wrote: > Second part of the patch set which omits one split_block (compared to the > original patch). > Acceptable just in case the first part will be accepted. > > Thanks > Martin > Hi. I'm sending v3 of the patch which does n

[PATCH] Prevent LTO wrappers to process a recursive execution

Hello. To make LTO wrappers (gcc-nm, gcc-ar, gcc-ranlib) more smart, I would like to prevent execution of the same binary by these wrapper. For LTO testing I symlink ar (nm, ranlib) to these wrappers instead of hacking a build system to respect NM (AR, RANLIB) environment variables. The only

Re: [PATCH GCC]Refactor IVOPT.

Hello. Please consider application of the following patch, it fixes a coding style issue and a memory leak. Thanks, Martin >From 6afc975de0b6de76aa51b8c2ef741cd72c76dc75 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 25 Apr 2016 13:50:41 +0200 Subject: [PATCH 1/4] Fix coding

[PATCH] Replace old AWK script (utilizing bc) with Python implementation

Hello. As I've been playing with branch predictions and contrib/analyze_brprob script, I've decided to replace the old script with a Python implementation. Improvements: + fixed horizontal formatting + remove ugly utilization of bc that is used for arithmetics + script is a bit faster (tramp3d

[PATCH] Reduce compile time hog in symbol-summary.h

Hello. For every created function_summary, we validate (with flag_checking) that all cgraph_nodes have summary_uid > 0. It produces a compile hog. It's sufficient to validate that for nodes that really utilize a function summary. Patch can bootstrap on ppc64le-linux-gnu. Ready for trunk?

Re: [PATCH] Replace old AWK script (utilizing bc) with Python implementation

On 04/25/2016 09:01 PM, Matthias Klose wrote: > please could you make the shebang python3? Not sure if it's good to replace > one old implementation with a soon to become old implementation. > > Matthias Sure, thanks for pointing out. Attaching v2, where I changed: + switched from python2 to

Re: [PATCH] Prevent LTO wrappers to process a recursive execution

On 04/25/2016 09:30 PM, Andi Kleen wrote: > Does that really work? When the executable is found in $PATH > av[0] does not contain the full path name. But you seem to assume > it does? > > -Andi Hi. Well, it should be resolved by lrealpath. There's usage from my machine: marxin@marxinbox:~>

Re: [PATCH 2/3] Add profiling support for IVOPTS

On 05/17/2016 12:27 AM, Bin.Cheng wrote: >> As profile-guided optimization can provide very useful information >> about basic block frequencies within a loop, following patch set leverages >> that information. It speeds up a single benchmark from upcoming SPECv6 >> suite by 20% (-O2

Re: [PATCH 1/3] Encapsulate comp_cost within a class with methods.

On 05/16/2016 03:55 PM, Martin Liška wrote: > On 05/16/2016 12:13 PM, Bin.Cheng wrote: >> Hi Martin, >> Could you please rebase this patch and the profiling one against >> latest trunk? The third patch was applied before these two now. >> >> Thanks, >> b

[PATCH] LTO: display file name if LTO version check fails

Hi. During the compilation of chrome, I've noticed that they utilize 'cc' binary. Because of that, I see LTO version check, but it would be quite useful to see which file is affected. Like: lto1: fatal error: bytecode stream in file 'obj/third_party/icu/source/common/icuuc.cmemory.o' generated

[PATCH] Fix PR tree-optimization/71170

Hello. Following patch fixes the ICE as it defensively finds the right place where a new STMT should be inserted. Patch bootstraps on x86_64-linux-gnu and no new regression is introduced. Ready for trunk? Thanks, Martin >From de9f966a20cf08721dc8bdb83144b07f72e6cc59 Mon Sep 17 00:00:00 2001

[PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.

Hello. It's bit confusing for a use that -fsanitize-recover=address does not recover an instrumented binary. As a default value of halt_on_error is set to 0 for address sanitizer, the binary fails on a first error. Following patch attempts to explain the ENV variable. Ready for trunk? Thanks,

Re: [PATCH] Introduce tests for -fsanitize=use-after-scope

On 05/06/2016 01:07 PM, Martin Liška wrote: > Hi. > > This is a new test coverage for the new sanitizer option. > > Martin Hello. This is second version of tests. I fixed a test where a variable overflowed and couple of tests were adopted from LLVM's testsuite (basically

Re: [PATCH 3/3] Enhance dumps of IVOPTS

On 05/10/2016 03:16 PM, Bin.Cheng wrote: > Another way is to remove the use of id for struct iv_inv_expr_ent once > for all. We can change iv_ca.used_inv_expr and cost_pair.inv_expr_id > to pointers, and rename iv_inv_expr_ent.id to count and use this to > record reference number in iv_ca. This

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

On 05/06/2016 02:22 PM, Jakub Jelinek wrote: > On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote: >> I've started working on the patch couple of month go, basically after >> a brief discussion with Jakub on IRC. >> >> I'm sending the initial version

Re: [PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.

On 05/11/2016 04:20 PM, Jakub Jelinek wrote: > On Wed, May 11, 2016 at 04:13:27PM +0200, Martin Liška wrote: >> It's bit confusing for a use that -fsanitize-recover=address does not recover >> an instrumented binary. As a default value of halt_on_error is set to 0 for >&

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

On 05/12/2016 12:41 PM, Jakub Jelinek wrote: > On Wed, May 11, 2016 at 02:54:01PM +0200, Martin Liška wrote: >> On 05/06/2016 02:22 PM, Jakub Jelinek wrote: >>> On Fri, May 06, 2016 at 01:04:30PM +0200, Martin Liška wrote: >>>> I've started working on the patch coupl

Re: [PATCH 3/3] Enhance dumps of IVOPTS

On 05/12/2016 03:51 PM, Bin.Cheng wrote: > On Thu, May 12, 2016 at 1:13 PM, Martin Liška <mli...@suse.cz> wrote: >> On 05/10/2016 03:16 PM, Bin.Cheng wrote: >>> Another way is to remove the use of id for struct iv_inv_expr_ent once >>> for all.

[PATCH] Fix ASAN bootstrap (uninitialized variable warning)

Hi. Following patch is needed to survive --with-build-config=bootstrap-asan: ../../gcc/tree-vect-patterns.c: In function ‘gimple* vect_recog_mask_conversion_pattern(vec*, tree_node**, tree_node**)’: ../../gcc/tree-vect-patterns.c:3612:34: error: ‘lhs’ may be used uninitialized in this

Re: [PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.

On 05/11/2016 04:56 PM, Jakub Jelinek wrote: > I think it better should say that: > Even if a recovery mode is turned on the compiler side, it needs to be also > enabled on the runtime library side, otherwise the failures are still fatal. > The runtime library defaults to ... and this can be

Re: [PATCH 1/3] Encapsulate comp_cost within a class with methods.

On 05/16/2016 12:13 PM, Bin.Cheng wrote: > Hi Martin, > Could you please rebase this patch and the profiling one against > latest trunk? The third patch was applied before these two now. > > Thanks, > bin Hello. Sending the rebased version of the patch. Martin >From

Re: [PATCH 2/3] Add profiling support for IVOPTS

Hello. Sending the rebased version of the patch. Martin >From a91b1578f3907e05543b2acea0081b6e4744ade9 Mon Sep 17 00:00:00 2001 From: marxin Date: Mon, 16 May 2016 15:52:56 +0200 Subject: [PATCH 2/2] Add profiling support for IVOPTS gcc/ChangeLog: 2016-04-25 Martin Liska

Re: Enable inlining into thunks

On 05/16/2016 12:22 AM, Jan Hubicka wrote: > Hi, > this patch teach inliner to inline into thunks. This is easy to do - all we > need > is to produce a gimple body when we decide to do so. This fixes some ages old > xfails > and enables some 40k inlines in Firefox. Not all those inlines are win,

Re: [PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.

On 05/13/2016 01:03 PM, Jakub Jelinek wrote: > On Fri, May 13, 2016 at 12:26:57PM +0200, Martin Liška wrote: >> On 05/12/2016 02:44 PM, Jakub Jelinek wrote: >>> I think it isn't obvious that one needs to put halt_on_error=0 or >>> halt_on_error=1 into those options

Re: [PATCH 3/3] Enhance dumps of IVOPTS

On 05/13/2016 02:11 PM, H.J. Lu wrote: > On Fri, May 13, 2016 at 3:44 AM, Martin Liška <mli...@suse.cz> wrote: >> On 05/13/2016 11:43 AM, Bin.Cheng wrote: >>> On Thu, May 12, 2016 at 5:41 PM, Martin Liška <mli...@suse.cz> wrote: >>>> On 05/12/2016 03:51

Re: [PATCH, DOC] Document ASAN_OPTIONS="halt_on_error" env variable.

On 05/12/2016 02:44 PM, Jakub Jelinek wrote: > I think it isn't obvious that one needs to put halt_on_error=0 or > halt_on_error=1 into those options and what to do if you need multiple > options in there. What about changing the last sentence to: This can be overridden through a corresponding

Re: [PATCH 3/3] Enhance dumps of IVOPTS

On 05/13/2016 02:46 PM, Richard Biener wrote: > Use them for HOST_WIDE_INT printing, for [u]int64_t use the PRI stuff. > > Richard. Thanks you both, installed as r236208. Martin

Re: [PATCH 3/3] Enhance dumps of IVOPTS

On 05/13/2016 11:43 AM, Bin.Cheng wrote: > On Thu, May 12, 2016 at 5:41 PM, Martin Liška <mli...@suse.cz> wrote: >> On 05/12/2016 03:51 PM, Bin.Cheng wrote: >>> On Thu, May 12, 2016 at 1:13 PM, Martin Liška <mli...@suse.cz> wrote: >>>> On 05/10/2016 03

RUN_UNDER_VALGRIND statistics for GCC 7

Hello. I've tried to apply the same patch for the current trunk and tried to separate reported errors to a different categories by a simple script ([1]). There are number (complete report: [2]): SECTION: gfortran error types: 3534, total errors: 113282 error types: 90.15%, total errors:

Re: [PATCH] Fix PR fortran/70856

On 05/18/2016 01:24 PM, Richard Biener wrote: > Ok. > > Richard. Thanks, I'll install the same patch to GCC 6 branch after finishing of tests, ok? Martin

[PATCH] Fix PR fortran/70856

Hello. Following patch add support for IPA ICF, where we miss support for a proper DECL_PT_UID update in situations where we merge variables. Patch can bootstrap and no new regression is introduced for x86_64-linux-gnu. Ready for trunk? Thanks, Martin >From

Re: [RFC][PATCH][PR40921] Convert x + (-y * z * z) into x - y * z * z

On 05/18/2016 10:38 AM, Kugan Vivekanandarajah wrote: > Is this Still OK. Bootstrap and regression testing on ARM, AARCH64 and > x86-64 didn’t have any new regressions. > > Thanks, > Kugan Hello. I see various ICE after your commit r236356: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71170

Re: [PATCH 3/3] Enhance dumps of IVOPTS

On 05/10/2016 03:16 PM, Bin.Cheng wrote: > Another way is to remove the use of id for struct iv_inv_expr_ent once > for all. We can change iv_ca.used_inv_expr and cost_pair.inv_expr_id > to pointers, and rename iv_inv_expr_ent.id to count and use this to > record reference number in iv_ca. This

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

On 05/06/2016 03:25 PM, Jakub Jelinek wrote: > Well, we already have the gimple poisoning/unpoisoning code on RTL (emitted > after the prologue and before the epilogue), so it shouldn't be that hard. > I'd only do the most common/easy cases inline though, like 1/2/4/8/16/32 > bytes long variables.

[PATCH, RFC] Introduce -fsanitize=use-after-scope

Hello. I've started working on the patch couple of month go, basically after a brief discussion with Jakub on IRC. I'm sending the initial version which can successfully run instrumented tramp3d, postgresql server and Inkscape. It catches the basic set of examples which are added in following

[PATCH] Introduce tests for -fsanitize=use-after-scope

Hi. This is a new test coverage for the new sanitizer option. Martin >From 753bfb3edb12c9f3fd13f320e308556f63330c97 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 4 May 2016 12:57:05 +0200 Subject: [PATCH 2/2] Introduce tests for -fsanitize=use-after-scope

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

Hello. One more issue I forgot to mention in the previous email: e) As one can come up with a source code which jumps to a label within a block scope (use-after-scope-goto-1.c): // { dg-do run } // { dg-additional-options "-fsanitize=use-after-scope -fstack-reuse=none" } int main(int argc, char

Re: [PATCH 3/3] Enhance dumps of IVOPTS

Hi. Honza asked me to explain the change more verbosely. The patch simplify enhances verbose dump of IVOPTS so that # of iterations is printed. Apart from that it also prints invariant expression that are used during the algorithm which considers a set of candidates which is improved. Main

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

On 05/06/2016 02:38 PM, Jakub Jelinek wrote: > On Fri, May 06, 2016 at 02:48:30PM +0300, Yury Gribov wrote: >>> 6) As the use-after-scope stuff is already included in libsanitizer, no >>> change is needed for the library >> >> Note that upstream seems to use a different cmdline interface. They

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

On 05/06/2016 01:48 PM, Yury Gribov wrote: > On 05/06/2016 02:04 PM, Martin Liška wrote: >> Hello. >> >> I've started working on the patch couple of month go, basically after >> a brief discussion with Jakub on IRC. >> >> I'm sending the initial version

Re: [PATCH] Fix memory leak in tree-inliner

On 05/06/2016 12:56 PM, Richard Biener wrote: > Hmmm. But this means debug stmt remapping calls > remap_dependence_clique which may end up bumping > cfun->last_clique and thus may change code generation. > > So what debug stmts contain MEM_REFs? If you put an assert > processing_debug_stmt == 0

[PATCH] Fix memory leak in tree-if-conv.c

On 05/03/2016 11:07 AM, Bin.Cheng wrote: > Patch applied as suggested at r235808. > > Thanks, > bin Hi. Following patch introduces memory leak: /home/marxin/Programming/gcc2/objdir/gcc/xgcc -B/home/marxin/Programming/gcc2/objdir/gcc/-fno-diagnostics-show-caret -fdiagnostics-color=never

[PATCH] Fix coding style in tree-ssa-uninit.c

On 11/26/2015 10:04 PM, Bernd Schmidt wrote: > As I said previously, the one to just replace whitespace is ok for now. > Please ping the other one when stage1 opens (I expect it'll need changes by > then). > > > Bernd Hello. This part of the part remains to be installed from the previous

[PATCH] Fix memory leak in tree-inliner

Hi. I've spotted couple of occurrences of following memory leak seen by valgrind: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) operator new(unsigned long) (new_op.cc:50) remap_dependence_clique(copy_body_data*, unsigned short) (tree-inline.c:845)

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

On 05/06/2016 04:39 PM, Jakub Jelinek wrote: > Depends on how exactly it is defined. It could be enabling just its own > sanitizer bit and nothing else, then users would need to use > -fsanitize=address,use-after-scope > or > -fsanitize=kernel-address,use-after-scope I'm inclined to the second

[HSA, PATCH] Load an HSA runtime via dlopen mechanism

Hello. After brief discussions about packaging of an HSA runtime, we've decided to load an HSA runtime via dlopen mechanism. Following patch introduces necessary header files and all functions within the HSA plug-in are loaded via dlsym. Patch survives HSA regression tests, installed to the HSA

Re: [PATCH] Fix memory leak in tree-inliner

On 05/09/2016 12:57 PM, Richard Biener wrote: > does that resolve the issue? If so, this is ok for trunk and branches. It does. I'll commit the patch to trunk after it finishes regression tests. Related patches for branches will be prepared after that. Martin >From

[COMMITTED] Fix dump output typo

Hi. This is simple correction of a dump printf in ipa-inline.c. Installed as obvious. Martin >From 1a8bff73f48641df20dddf8cbcee52f8541b2910 Mon Sep 17 00:00:00 2001 From: marxin Date: Wed, 25 May 2016 13:13:42 +0200 Subject: [PATCH] Fix dump output typo gcc/ChangeLog:

[PATCH] Fix PR tree-optimization/71239

Hi. Following patch checks that we do not call operand_equal_p with the first argument equals to NULL. Patch survives regression tests and bootstraps on x86_64-linux-gnu. Ready for trunk? Thanks, Martin >From 46c4b641778d42a5567f2e12cf987bb25f501ce7 Mon Sep 17 00:00:00 2001 From: marxin

Re: [PATCH 2/3] Run profile feedback tests with autofdo

On 07/26/2016 06:28 AM, Andi Kleen wrote: > And do you have autofdo installed? (create_gcov) > > -Andi Ah, sorry for the false alarm, create_gcov is really missing on my distribution. Martin

[PATCH] Introduce no_profile_instrument_function attribute (PR gcov-profile/68025)

Hi. As mentioned in the PR gcov-profile/68025, there's a request not to instrument some functions (e.g. a in linux kernel). Thus, I come with a new attribute no_profile_instrument_function which skips any profiling instrumentation. Patch can bootstrap on ppc64le-redhat-linux and survives

Re: [PATCH] predict.c: merge multi-edges

On 07/25/2016 07:52 PM, Jeff Law wrote: > Can you turn this into a test as well? > > With that change this patch is OK for the trunk. > > jeff Sure, thanks for the review. Installed as r238781. Martin >From e88a89a85f2d7b4d37d44397d2abe9775cb1cbfb Mon Sep 17 00:00:00 2001 From: marxin

[PATCH, DOC] Enhance documentation of -fipa-ra option.

Hello. I accidentally learned that -fipa-ra option is disabled if: /* Do not use IPA optimizations for register allocation if profiler is active or port does not emit prologue and epilogue as RTL. */ if (profile_flag || !targetm.have_prologue () || !targetm.have_epilogue ())

Re: [PATCH] Amend dump expectation in slsr-8.c (PR, tree-optimization/71490)

On 07/14/2016 01:21 PM, Richard Biener wrote: > On Thu, Jul 14, 2016 at 1:06 PM, Martin Liška <mli...@suse.cz> wrote: >> On 07/13/2016 07:21 PM, Jeff Law wrote: >>> Isn't that a code quality regression? So instead shouldn't we be keeping >>> the same e

Re: [PATCH] Amend dump expectation in slsr-8.c (PR, tree-optimization/71490)

On 07/13/2016 07:21 PM, Jeff Law wrote: > Isn't that a code quality regression? So instead shouldn't we be keeping the > same expectation, but xfailing the test? > > jeff Hello. Disabling a pass before slsr makes the test to catch both opportunities. Is the patch fine? Thanks, Martin >From

[PATCH] Fix memory leak introduced in r238336

Hi. This is quite obvious change. I've been waiting for bootstrap and regression tests on ppc64le-redhat-linux. Ready after it finishes? Martin >From 2f416d7feca35d9075124f4dc74f3560a18beefb Mon Sep 17 00:00:00 2001 From: marxin Date: Fri, 22 Jul 2016 12:46:08 +0200 Subject:

Re: [PATCH 2/3] Run profile feedback tests with autofdo

On 07/15/2016 10:37 AM, Bin.Cheng wrote: > On Thu, Jul 14, 2016 at 11:33 PM, Andi Kleen wrote: > I haven't seen that. Unstable in what way? For GCC doesn't support FDO, it run below tests as you said: PASS: gcc.dg/tree-prof/20041218-1.c compilation, -g

[PATCH] Handle loops with loop->latch == NULL (PR gcov-profile/71868)

Hi. As discussed with Honza, we should sum all edge frequencies when a loop has multiple latches. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin >From 07dc9092511aedfe2786630d72419b16ef660d0c Mon Sep 17 00:00:00 2001 From: marxin

[PATCH] Don't call get_working_sets w/ LTO and -fauto-profile (PR, gcov-profile/70993)

Hi. Currently, call to get_working_sets is only called from tree_profiling (called from 'pass_ipa_tree_profile' and is guarded in gate with !flag_auto_profile). I would like to apply the same logic in lto-cgraph.c. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Re: [PATCH] Call get_ops just for SSA_NAMEs (PR tree-optimization/71987)

On 07/25/2016 11:51 AM, kugan wrote: > Sorry about the breakage. Since final_range_test_p allows either lhs or rhs > to be SSA_NAME (for the different cases it accepts), we should indeed check > for TREE_CODE being SSA_NAME. Unfortunately it didn't trigger in my testing. > Lets wait for the

[PATCH] Call get_ops just for SSA_NAMEs (PR tree-optimization/71987)

Hi. As other calls of get_ops is guarded with TREE_CODE (x) == SSA_NAME, I guess the same should be done for the call that causes the ICE. Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. Ready to be installed? Martin >From 9dd5cc00eb3c271fad91fede6a9b06df356e001f Mon

Re: [PATCH] Adapt the numbering scheme (PR gcov-profile/64874)

On 07/22/2016 03:20 PM, Jakub Jelinek wrote: > On Fri, Jul 22, 2016 at 01:46:44PM +0200, Martin Liška wrote: >> As described in the PR, current numbering scheme in gcov-io.h would overflow >> in couple of years. >> Thus, I'm suggesting to switch from: >> &g

Re: [PATCH] Introduce no_profile_instrument_function attribute (PR gcov-profile/68025)

On 07/27/2016 11:33 PM, Jeff Law wrote: > On 07/27/2016 02:27 AM, Martin Liška wrote: >> Hi. >> >> As mentioned in the PR gcov-profile/68025, there's a request not to >> instrument >> some functions (e.g. a in linux kernel). Thus, I come with a new attribute

[PATCH] predict.c: merge multi-edges

Hi. Following patch enhances prediction for basic blocks with >2 successor edges. Currently, even probability is set and the patch considers unlikely edges, where even probability is set for the remaining edges. I run SPEC2006 benchmark, where aforementioned BBs have following predictor

Re: [RFC, v2] Test coverage for --param boundary values

On 07/28/2016 11:26 PM, Joseph Myers wrote: > On Mon, 18 Jul 2016, Martin Liška wrote: > >> Well, I can imaging a guard which will test whether >> "$objdir/../../params.options" file exits, and if so, then the tests are >> executed? Is it acceptable appr

Re: [PATCH 1/4] Cherry-pick fprofile-generate-atomic from google/gcc-4_9 branch

On 08/01/2016 02:22 PM, Nathan Sidwell wrote: > As I just wrote, this patch needs work. the general points are: Thank for the comments. > 1) exposing integers 0-3 to the user as switch values. Don't do that, give > them names. In this case a comma separated list of orthogonal names seems

[PATCH] Change dump expectation in PR71857

Hello. After changing the expected number of loop iterations, IVOPTS decides to pick up an another IV. Bin agreed that the test-case still makes sense with changed expectation. Ready to be installed? Martin >From 8073251d3827e0c7cd26680e97aa416e23132386 Mon Sep 17 00:00:00 2001 From: marxin

<    1   2   3   4   5   6   7   8   9   10   >