RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

> >>> + memmove (*line, l, len); >>> + (*line)[len - 1] = '\0'; >>> + *line_len = --len; >> >> Generally, I would prefer to use memcpy, >> if it is clear that the memory does not overlap. > > I don't mind. I'll change that in my local copy. Thanks. > >> You copy one char too much and set it to zero

Re: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Bernd Edlinger writes: >> + memmove (*line, l, len); >> + (*line)[len - 1] = '\0'; >> + *line_len = --len; > > Generally, I would prefer to use memcpy, > if it is clear that the memory does not overlap. I don't mind. I'll change that in my local copy. Thanks. > You copy one char too much and

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

../../gnatmake ../../gnatlink ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg -gnata -I- -I../rts -I. -I/opt/gcc/work/gcc/ada /opt/gcc/work/gcc/ada/make.adb -o make.o /opt/gcc/work/gcc/ada/make.adb: In function 'Make.Compile_Sources.Start_Compile_If_Possible': /opt/gcc/work/gcc/ada/make

Re: Revert libsanitizer patches or fix 59009

Many thanks, Jakub. I don't want to appear in this situation again. Would you suggest a place to create a wiki page which would list all required steps to test libsanitizer? libsanitizer is (unfortunately) a very system-dependent beast and our upstream commits will break other platforms regularly

[PATCH] PR59063

This patch is supposed to fix PR59063 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063). The original bug results from libasan providing clock_gettime wrapper and then trying to call the "real" clock_gettime. The "real" symbol is supposed to come from librt.so which was not necessarily linke

RE: [patch] [arm] ARM Cortex-M3/M4 tuning

Janis, can you please take a look at test case changes. Thanks, Joey > -Original Message- > From: Ramana Radhakrishnan > Sent: Friday, November 08, 2013 17:11 > To: Joey Ye > Cc: gcc-patches@gcc.gnu.org; jani...@codesourcery.com > Subject: Re: [patch] [arm] ARM Cortex-M3/M4 tuning > > >>

RE: [patch] [arm] New option for PIC offset unfixed

> -Original Message- > From: Richard Earnshaw > Sent: Tuesday, November 12, 2013 18:49 > To: Joey Ye > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [patch] [arm] New option for PIC offset unfixed > > The name of the option and the documentation highlights that the > option's concept is confu

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

../../gnatmake ../../gnatlink ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg -gnata -I- -I../rts -I. -I/opt/gcc/work/gcc/ada /opt/gcc/work/gcc/ada/make.adb -o make.o /opt/gcc/work/gcc/ada/make.adb: In function 'Make.Compile_Sources.Start_Compile_If_Possible': /opt/gcc/work/gcc/ada/make

Re: [PATCH] Implement -fsanitize=null + new sanopt pass

On 2013.11.13 at 00:13 +0100, Marek Polacek wrote: > 2) bootstrap-ubsan almost passes, but the bootstrap fails when building >all-fixincludes. The problem here is that libiberty.a is built >with -fsanitize=undefined, but fixincludes, when linking, >don't link libubsan in. My attemps t

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

../../gnatmake ../../gnatlink ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg -gnata -I- -I../rts -I. -I/opt/gcc/work/gcc/ada /opt/gcc/work/gcc/ada/make.adb -o make.o /opt/gcc/work/gcc/ada/make.adb: In function 'Make.Compile_Sources.Start_Compile_If_Possible': /opt/gcc/work/gcc/ada/make

RE: Honnor ix86_accumulate_outgoing_args again

> we are going to have some AMD CPU with AVX2 support soon, the question is > if it will prefer 256-bit vmovups/vmovupd/vmovdqu or split, but even > if it will prefer split, the question is if like bdver{1,2,3} it will > be X86_TUNE_AVX128_OPTIMAL, because if yes, then how 256-bit unaligned > loads

Re: [PATCH, i386] Fix -mpreferred-stack-boundary

On Tue, Nov 12, 2013 at 5:17 PM, Sriraman Tallam wrote: > On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger > wrote: >> Hi, >> >> >> On Tue, 12 Nov 2013 10:30:16, Sriraman Tallam wrote: >>> >>> On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote: There was something wrong with Bernd's address

Re: [PATCH, i386] Fix -mpreferred-stack-boundary

On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger wrote: > Hi, > > > On Tue, 12 Nov 2013 10:30:16, Sriraman Tallam wrote: >> >> On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote: >>> There was something wrong with Bernd's address, retrying. >>> > Currently on trunk the option -mpreferred-stac

[PATCH] [Vectorization] Fixing a bug in alias checks merger.

The current alias check merger does not consider the DR_STEP of data-refs when sorting data-refs. For the following loop: for (i = 0; i < N; ++i) a[i] = b[0] + b[i] + b[1]; The data ref b[0] and b[i] have the same DR_INIT and DR_OFFSET, and after sorting three DR pairs, the following order can

Add testcase for C11 complex divide bug fix

C11 Annex G corrects a bug in the sample complex divide implementation from C99 that was identified in . GCC's implementation of complex divide is different enough from the Annex G implementation not to have this bug. I've applied this

Add __auto_type C extension, use it in

contains what C11 describes as "generic functions". Although DR#419 makes clear that users cannot #undef these macros (or otherwise suppress use of a macro definition) and expect to find an underlying function, they still need to behave like functions as regards evaluating their arguments exactly

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On Tue, 12 Nov 2013, Jeff Law wrote: > On 11/12/13 16:42, Joseph S. Myers wrote: > > On Tue, 12 Nov 2013, Dominique Dhumieres wrote: > > > > > Bootstrapping with ada id broken by revision 204708 > > > (at least on x86_64-apple-darwin13): > > > > I also see this on x86_64-unknown-linux-gnu. > I'l

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On 11/12/13 16:42, Joseph S. Myers wrote: On Tue, 12 Nov 2013, Dominique Dhumieres wrote: Bootstrapping with ada id broken by revision 204708 (at least on x86_64-apple-darwin13): I also see this on x86_64-unknown-linux-gnu. I'll look at it later tonight (presumably you're both seeing the same

Re: [RFC] libgcov.c re-factoring and offline profile-tool

The patch was checked in as r204730. Tested with configure with --enable-languages=all,obj-c++ (ada is currently broken, so I was not be able test) bootstrap and profiledbootstrap regression for -m32 and -m64. spec2006 The only semantic change is __gcov_flush() used to be under L_gcov. I put the

[PATCH/AARCH64] Emit brk #0 for __builtin_trap

Hi all, This patch implements the trap pattern for the AARCH64 back-end. I used the "brk #0" instruction as that is the breakpoint instruction that GDB uses. I looked at what other targets did when the instruction set did not have a trap instruction and found that using the breakpoint instructi

Re: Revert libsanitizer patches or fix 59009

On Wed, Nov 13, 2013 at 12:47:04AM +0100, Jakub Jelinek wrote: > On Tue, Nov 12, 2013 at 08:30:15PM +0100, Jakub Jelinek wrote: > > Anyway, the following #ifdefs out tons of dead code and still builds just > > fine, the only difference is that those symbols nothing really uses from > > libasan/libt

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 08:30:15PM +0100, Jakub Jelinek wrote: > Anyway, the following #ifdefs out tons of dead code and still builds just > fine, the only difference is that those symbols nothing really uses from > libasan/libtsan are no longer exported, but nothing else changes. Actually, ifdefi

RE: [PATCH] preprocessor/58580 - preprocessor goes OOM with warning for zero literals

Hi, On Tue, 12 Nov 2013 16:33:41, Dodji Seketeli wrote: > > +/* Reads the next line from FILE into *LINE. If *LINE is too small > + (or NULL) it is allocated (or extended) to have enough space to > + containe the line. *LINE_LENGTH must contain the size of the > + initial*LINE buffer. It's then up

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On Tue, 12 Nov 2013, Dominique Dhumieres wrote: > Bootstrapping with ada id broken by revision 204708 > (at least on x86_64-apple-darwin13): I also see this on x86_64-unknown-linux-gnu. -- Joseph S. Myers jos...@codesourcery.com

Macros taking a function as argument - and evaluating it at least twice

Hello, Here is a non-comprehensive list of macros that are used with a function passed to the macro's argument, and the macro evaluates that argument at least twice: gimple.c: && (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (gs)) gimple-ssa-strength-reduction.c: || !CONVERT_EXPR_COD

[PATCH] Consistently detect traversing back edges in threader

I expect there'll be a follow-up or two with the code that checks EDGE_DFS_BACK when discovering jump thread opportunities, but I already know I need a way to track if *any* edge on a path is a back edge. This patch adds that capability by accumulating state for each edge into a boolean as t

RE: [PATCH] Fix for PR bootstrap/58951

> -Original Message- > From: H.J. Lu [mailto:hjl.to...@gmail.com] > Sent: Tuesday, November 12, 2013 11:30 AM > To: Gerald Pfeifer > Cc: Iyer, Balaji V; Jeff Law; GCC Patches > Subject: Re: [PATCH] Fix for PR bootstrap/58951 > > On Tue, Nov 12, 2013 at 7:16 AM, Gerald Pfeifer > wrote: >

[PATCH] Implement -fsanitize=null + new sanopt pass

Hi! Lately I've been working on the ubsan NULL pointer checking. Its purpose is to detect load from/store to NULL pointer. So, e.g., int *p = NULL; struct S *s = NULL; if (*p) { ... } x = struct s->i; etc. I should explain a bit here about the implementation of it. Firstly, I want

[PATCH] Ensure isolated *0 load does not get removed by DCE

As Marc noted, DCE will remove the isolated *0 which defeats the purpose of the most recent patch. This marks any isolated null pointer dereferences as volatile which ensures they don't go away. This also fixes a comment and tests that the dereferences survive until the optimized dump. Boot

RE: [PATCH, i386] Fix -mpreferred-stack-boundary

Hi, On Tue, 12 Nov 2013 10:30:16, Sriraman Tallam wrote: > > On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote: >> There was something wrong with Bernd's address, retrying. >> Currently on trunk the option -mpreferred-stack-boundary does not work together with #pragma GCC target("sse

Re: [patch] go front end changes to fix compilation break

On Tue, Nov 12, 2013 at 12:30 PM, Andrew MacLeod wrote: > > My latest set of changes (which I just checked in as revision204717) to > restructuring the gimple include files breaks go. It requires a minor > change to the go front end in order for it to compile... > > patch attached: Thanks. C

Re: [gofrontend-dev] Re: libgo patch committed: Implement reflect.MakeFunc for amd64

On Tue, Nov 12, 2013 at 2:23 PM, Ian Lance Taylor wrote: > On Tue, Nov 12, 2013 at 1:40 PM, H.J. Lu wrote: >> >> TestMakeFunc failed on x32: >> >> FAIL: TestMakeFunc (0.00 seconds) >> all_test.go:1457: Call returned 10, 20, 30, [40 0], 60, 70, 80; want 10, >> 20, 30, [40, 50], 60, 70, 80 >>

Re: [PATCH] decide edge's hotness when there is profile info

> On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka wrote: > >> More info on the lto bootstrap failure: > >> > >> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1: > >> warning: Missing counts for called function pex_child_error.isra.1/73 > >> [enabled by default] > >> } > >> >

Re: [PATCH, rs6000] ELFv2 ABI 1/8: Add options and infrastructure

On Tue, 12 Nov 2013, Ulrich Weigand wrote: > > I didn't see anything in this series regarding the ELFv1 ABI feature > > that's the greatest pain from a glibc perspective - the use of IBM long > > double. The idea of moving to IEEE binary128 was floated in > >

Re: [PATCH] Optional alternative base_expr in finding basis for CAND_REFs

Hi Bill, Many thanks for the review. I find your suggestion on using the next_interp field quite enlightening. I prepared a patch which adds changes without modifying the framework. With the patch, the slsr pass now tries to create a second candidate for each memory accessing gimple stateme

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

c -B../../ -c -g -O2 -W -Wall -gnatpg -gnata -I- -I../rts -I. -I/opt/gcc/work/gcc/ada /opt/gcc/work/gcc/ada/make.adb -o make.o /opt/gcc/work/gcc/ada/make.adb: In function 'Make.Compile_Sources.Start_Compile_If_Possible': /opt/gcc/work/gcc/ada/make.adb:3312:7: error: control flow in the mid

Re: [PATCH, rs6000] ELFv2 ABI preparation: Refactor rs6000_arg_partial_bytes

* config/rs6000/rs6000.c (rs6000_arg_partial_bytes): Simplify logic by making use of the fact that for vector / floating point arguments passed both in VRs/FPRs and in the fixed parameter area, the partial bytes mechanism is in fact not used. Okay. + /* If we are passing this arg in the fixe

Re: [gofrontend-dev] Re: libgo patch committed: Implement reflect.MakeFunc for amd64

On Tue, Nov 12, 2013 at 1:40 PM, H.J. Lu wrote: > > TestMakeFunc failed on x32: > > FAIL: TestMakeFunc (0.00 seconds) > all_test.go:1457: Call returned 10, 20, 30, [40 0], 60, 70, 80; want 10, > 20, 30, [40, 50], 60, 70, 80 > > The difference in x32 is x32 puts 2 pointers (32-bit) in one 64-g

Re: [PATCH, rs6000] ELFv2 ABI preparation: Remove USE_FP/ALTIVEC_FOR_ARG_P type arg

* config/rs6000/rs6000.c (USE_FP_FOR_ARG_P): Remove TYPE argument. (USE_ALTIVEC_FOR_ARG_P): Likewise. (rs6000_darwin64_record_arg_advance_recurse): Update uses. (rs6000_function_arg_advance_1):Likewise. (rs6000_darwin64_record_arg_recurse): Likewise. (rs6000_function_arg): Likewise. (rs6000_arg_par

Re: [PATCH, rs0000] ELFv2 ABI preparation: Refactor some uses of ABI_AIX

* config/rs6000/rs6000.c (rs6000_option_override_internal): Replace "DEFAULT_ABI != ABI_AIX" test by testing for ABI_V4 or ABI_DARWIN. (rs6000_savres_strategy): Likewise. (rs6000_return_addr): Likewise. (rs6000_emit_load_toc_table): Replace "DEFAULT_ABI != ABI_AIX" by testing for ABI_V4 (since ABI_

[RS6000] Mangling of IBM long double template literals

Ping this patch: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00686.html -- Alan Modra Australia Development Lab, IBM

Re: [PATCH, rs6000] Fix little-endian bug in linux-unwind.h

libgcc/ChangeLog: 2013-11-11 Ulrich Weigand Alan Modra * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Correct location of CR save area for 64-bit little-endian systems. Okay. Thanks, David

Re: [PATCH, rs6000] Fix corner case in unwinding CR values

2013-11-11 Ulrich Weigand * config/rs6000/rs6000.c (rs6000_emit_prologue): Do not place a RTX_FRAME_RELATED_P marker on the UNSPEC_MOVESI_FROM_CR insn. Instead, add USEs of all modified call-saved CR fields to the insn storing the result to the stack slot, and provide an appropriate REG_FRAME_R

Re: [PATCH] decide edge's hotness when there is profile info

On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka wrote: >> More info on the lto bootstrap failure: >> >> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1: >> warning: Missing counts for called function pex_child_error.isra.1/73 >> [enabled by default] >> } >> >> This is an erro

Re: not too big an alignment

On Tue, Nov 12, 2013 at 01:42:00PM -0800, Mike Stump wrote: > On Nov 12, 2013, at 1:16 PM, Jakub Jelinek wrote: > > On Tue, Nov 12, 2013 at 01:11:04PM -0800, Mike Stump wrote: > >> Alignments are stored in a byte, large alignments don't actually work > >> nicely. This caps the alignment to 128,

Re: libgo patch committed: Implement reflect.MakeFunc for amd64

On Tue, Nov 12, 2013 at 1:40 PM, H.J. Lu wrote: > On Fri, Sep 27, 2013 at 10:54 AM, Ian Lance Taylor wrote: >> The Go standard library has an interesting function named >> reflect.MakeFunc. It takes a Go function F that accepts and returns a >> slice of reflect.Value, and a function type T, and

Re: [PATCH, rs6000] ELFv2 ABI 1/8: Add options and infrastructure

Jakub Jelinek wrote: > On Mon, Nov 11, 2013 at 03:40:48PM +0100, Ulrich Weigand wrote: > > @@ -355,7 +364,11 @@ extern int dot_symbols; > > #define LINK_OS_DEFAULT_SPEC "%(link_os_linux)" > > > > #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1" > > -#define GLIBC_DYNAMIC_LINKER64 "/lib64/ld64.so.1

Re: not too big an alignment

On Nov 12, 2013, at 1:16 PM, Jakub Jelinek wrote: > On Tue, Nov 12, 2013 at 01:11:04PM -0800, Mike Stump wrote: >> Alignments are stored in a byte, large alignments don't actually work >> nicely. This caps the alignment to 128, as most ports would define >> BIGGEST_ALIGNMENT to be smaller than

Re: libgo patch committed: Implement reflect.MakeFunc for amd64

On Fri, Sep 27, 2013 at 10:54 AM, Ian Lance Taylor wrote: > The Go standard library has an interesting function named > reflect.MakeFunc. It takes a Go function F that accepts and returns a > slice of reflect.Value, and a function type T, and returns a pointer to > a function of type T that conve

Re: [PATCH, rs6000] ELFv2 ABI 1/8: Add options and infrastructure

Joseph Myers wrote: > On Mon, 11 Nov 2013, Ulrich Weigand wrote: > > The ELFv2 ABI is the intended ABI for the new powerpc64le-linux port. > > However, it is not inherently tied to the byte order; it it possible > > in principle to use the ELFv2 ABI in big-endian mode too. > > I'd rather, from a g

patch to fix PR58712

The following patch fixes usage of an uninitialized value in record_operand_costs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58712 The single set insn might have less 2 operands, e.g. x86_fnstcw_1. Committed as rev. 204720. 2013-11-12 Vladimir Makarov PR other/58712 * ira-

Re: [PATCH] decide edge's hotness when there is profile info

> More info on the lto bootstrap failure: > > /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1: > warning: Missing counts for called function pex_child_error.isra.1/73 > [enabled by default] > } > > This is an error handling routine that invokes _exit. Looking at the > ipa

Re: not too big an alignment

On Tue, Nov 12, 2013 at 01:11:04PM -0800, Mike Stump wrote: > Alignments are stored in a byte, large alignments don't actually work nicely. > This caps the alignment to 128, as most ports would define BIGGEST_ALIGNMENT > to be smaller than this. The competing change would to be to make it a >

not too big an alignment

Alignments are stored in a byte, large alignments don't actually work nicely. This caps the alignment to 128, as most ports would define BIGGEST_ALIGNMENT to be smaller than this. The competing change would to be to make it a short, but, I'd be happy to punt that until such time as someone act

[patch] go front end changes to fix compilation break

Hey Ian, My latest set of changes (which I just checked in as revision204717) to restructuring the gimple include files breaks go. It requires a minor change to the go front end in order for it to compile... patch attached: Andrew 2013-11-12 Andrew MacLeod * go/gofrontend/expressi

Re: [PATCH, libiberty]: Add a couple of missing casts

On Tue, Nov 12, 2013 at 11:24 AM, Uros Bizjak wrote: > > This was uncovered by x86 lto-profiledbootstrap. The patch allows > lto-profiledbootstrap to proceed further. > > 2013-11-12 Uros Bizjak > > * cp-demangle.c (d_copy_templates): Cast result of malloc > to (struct d_print_template *

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 11:34:48AM -0800, Kostya Serebryany wrote: > On Tue, Nov 12, 2013 at 11:30 AM, Jakub Jelinek wrote: > > On Tue, Nov 12, 2013 at 10:59:12AM -0800, Kostya Serebryany wrote: > >> This is all dead code in gcc repo. This is why I am asking for any > >> quick #ifdef. > >> in clan

Re: [PATCH] decide edge's hotness when there is profile info

On Tue, Nov 12, 2013 at 11:08 AM, Teresa Johnson wrote: > On Mon, Nov 11, 2013 at 9:17 AM, Teresa Johnson wrote: >> On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote: On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote: >> I have a warning like that already in drop_profile(). Is that

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 11:34:48AM -0800, Kostya Serebryany wrote: > > Anyway, the following #ifdefs out tons of dead code and still builds just > > Thanks, that should work. > I am really sorry I couldn't do it myself before -- just got back from travel. So do you have some suggestion for #ifdef

Re: [patch 1/4] Separate gimple.[ch] and gimplify.[ch]

On 11/12/2013 02:23 PM, Jeff Law wrote: On 11/11/13 14:03, Andrew MacLeod wrote: So on to the anomaly that causes the issue. force_gimple_operand* is extensively used by the middle end, but not by the front end at all. The front ends do not use the statement iterators, but 2 of the force_gimple

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 11:30 AM, Jakub Jelinek wrote: > On Tue, Nov 12, 2013 at 10:59:12AM -0800, Kostya Serebryany wrote: >> This is all dead code in gcc repo. This is why I am asking for any >> quick #ifdef. >> in clang repo this code is used by MemorySanitizer (and will be used >> by asan/tsan

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 10:59:12AM -0800, Kostya Serebryany wrote: > This is all dead code in gcc repo. This is why I am asking for any > quick #ifdef. > in clang repo this code is used by MemorySanitizer (and will be used > by asan/tsan later). I can't find how it is used in msan/ in the llvm rep

[PATCH, libiberty]: Add a couple of missing casts

Hello! This was uncovered by x86 lto-profiledbootstrap. The patch allows lto-profiledbootstrap to proceed further. 2013-11-12 Uros Bizjak * cp-demangle.c (d_copy_templates): Cast result of malloc to (struct d_print_template *). (d_print_comp): Cast result of realloc to (struct d_s

Re: [patch 1/4] Separate gimple.[ch] and gimplify.[ch]

On 11/11/13 14:03, Andrew MacLeod wrote: So on to the anomaly that causes the issue. force_gimple_operand* is extensively used by the middle end, but not by the front end at all. The front ends do not use the statement iterators, but 2 of the force_gimple_operand() routines work with gsi's, and

Re: PING Cilk Plus failures on non-LTO targets

On 11/11/13 21:41, Iyer, Balaji V wrote: -Original Message- From: David Edelsohn [mailto:dje@gmail.com] Sent: Monday, November 11, 2013 11:36 AM To: Iyer, Balaji V Cc: GCC Patches; Joseph S. Myers Subject: Re: PING Cilk Plus failures on non-LTO targets On Mon, Nov 4, 2013 at 11:06

Re: [PATCH] decide edge's hotness when there is profile info

On Mon, Nov 11, 2013 at 9:17 AM, Teresa Johnson wrote: > On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote: >>> On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote: >>> >> I have a warning like that already in drop_profile(). Is that >>> > >>> > I think it should be warning (or silent) for COMDA

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 10:57 AM, Jakub Jelinek wrote: > On Tue, Nov 12, 2013 at 10:07:32AM -0800, Kostya Serebryany wrote: >> On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner >> wrote: >> > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote: >> >> or, alternatively, we can disab

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 10:07:32AM -0800, Kostya Serebryany wrote: > On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner > wrote: > > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote: > >> or, alternatively, we can disable libsanitizer on PowerPC if the > >> PowerPC community does

Re: Revert libsanitizer patches or fix 59009

> If we revert the patch now, I will not be able to work on it again in > nearest months, which means 4.9 will not get updated asan. > How bad that is -- I don't know. When you contribute patches, you should allocate enough time with your employer to address any fall out. This problem likely affe

Re: Honnor ix86_accumulate_outgoing_args again

> On Tue, Nov 12, 2013 at 10:39:28AM -0500, Vladimir Makarov wrote: > > >> Shall we also disable argument accumulation for cores? It seems we won't > > >> solve the IRA issues, right? > > > You mean LRA issues here, right? If you are starting to use > > > no-accumulate-outgoing-args much more ofte

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On 11/12/13 10:14, Marc Glisse wrote: I assume the second LHS should be RHS. Don't you want to mark it somehow so the next DCE doesn't remove it? Sigh, yes DCE is removing the load. That can be fixed by just marking the MEM_REF as volatile and updating the statement. It's a pretty trivial ch

Re: [PATCH], PR target/59054, powerpc code regression for power7/power8

On Mon, Nov 11, 2013 at 4:45 PM, Michael Meissner wrote: > This patch fixes PR 59054, which is a bug I introduced in early October, when > I > added initial patches for allowing DFmode values in the traditional Altivec > registers on ISA 2.06, and SFmode values on ISA 2.07. This patch eliminates

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On Tue, Nov 12, 2013 at 07:08:22PM +0100, Marc Glisse wrote: > On Tue, 12 Nov 2013, Jeff Law wrote: > > >On 11/12/13 10:14, Marc Glisse wrote: > >>You didn't like Jakub's comment about __builtin_unreachable? > >No, it's certainly not appropriate for this optimization. The > >problem with using bu

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 10:07:32AM -0800, Kostya Serebryany wrote: > On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner > wrote: > > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote: > >> or, alternatively, we can disable libsanitizer on PowerPC if the > >> PowerPC community does

Re: [PATCH] Time profiler - phase 1

Thanks. I'll have this change included in my libgcov.c re-re-factoring patch. -Rong On Tue, Nov 12, 2013 at 10:18 AM, Martin Liška wrote: > Hi Rong, > you are right, that's the only usage and so that you can declare it > static. > > Thank you, > Martin > > On Nov 12, 2013 7:10 PM, "Rong Xu" w

Re: [PATCH, i386] Fix -mpreferred-stack-boundary

On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote: > There was something wrong with Bernd's address, retrying. > >>> Currently on trunk the option -mpreferred-stack-boundary does not work >>> together with #pragma GCC target("sse") or __attribute__((target("sse"))). >>> >>> There is already a te

Re: PR37132 – RFC patch for generation of DWARF symbol for Fortran's namelists (DW_TAG_namelist)

> One cannot simply also import, e.g., "i" as the code might have: > > subroutine example() > use mod, only: my_nml > integer :: i! < Locally defined variable > read(uid, my_nml) > ... > end subroutine example > > In that case "i" is the local variable. As written, one can creat

Re: [gomp4 simd, RFC] Simple fix to override vectorization cost estimation.

The reason patch was in its original state is because we want to notify user that his assumption of profitability may be wrong. This is not a part of any spec and as far as I know ICC does not notify user about the case. Still it can be a good hint for those users who tries to get as much as possib

Re: [PATCH] Generate a label for the split cold function while using -freorder-blocks-and-partition

>> Isn't this something that should be expressed in DWARF with >> DW_AT_ranges? See DWARF4, section 2.17, >> >> Does GCC generate such ranges? > > GCC does generate these ranges. However, according to Cary many tools > do not rely on dwarf info for locating the corresponding function > name, they j

Re: [PATCH] Generate a label for the split cold function while using -freorder-blocks-and-partition

>>> Is there a format for compiler-defined labels that would not be able >>> to clash with other user-generated labels? >> >> My understanding is that the "." in the generated name ensures that it >> will not clash with user-generated labels which cannot contain ".". So >> this should not be an iss

Re: [PATCH] Time profiler - phase 1

A question about the newly added global variable function_counter. Does it have to be a global? Can I make it a file static, within macro L_gcov_time_profiler? I don't find a use other than in __gcov_time_profiler(). thanks, -Rong On Mon, Nov 11, 2013 at 9:52 AM, Martin Liška wrote: > On 11 N

Re: [PATCH] Small fix: add { dg-require-effective-target vect_int } to testsuite/gcc.dg/vect/pr58508.c

Got it! thanks, Cong On Tue, Nov 12, 2013 at 10:05 AM, Jakub Jelinek wrote: > On Tue, Nov 12, 2013 at 10:04:15AM -0800, Cong Hou wrote: >> Thank you for pointing it out. The updated patch is pasted below. I >> will pay attention to it in the future. > > Ok, thanks. > Note, you can use dg-addit

Re: [RFC] replace malloc with a decl on the stack

On 11/12/13 05:41, Marc Glisse wrote: On Tue, 12 Nov 2013, Ondřej Bílka wrote: I am trying to get something to actually work and be accepted in gcc. That may mean being conservative. That also may mean that you will cover only cases where it is not needed. A malloc will have a small per-thre

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On Tue, 12 Nov 2013, Jeff Law wrote: On 11/12/13 10:14, Marc Glisse wrote: You didn't like Jakub's comment about __builtin_unreachable? No, it's certainly not appropriate for this optimization. The problem with using builtin_unreachable is if you do reach that point, you fall into an unrelat

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner wrote: > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote: >> or, alternatively, we can disable libsanitizer on PowerPC if the >> PowerPC community does not care enough about it being healthy. > > I think there should be a global

Re: [PATCH] Small fix: add { dg-require-effective-target vect_int } to testsuite/gcc.dg/vect/pr58508.c

On Tue, Nov 12, 2013 at 10:04:15AM -0800, Cong Hou wrote: > Thank you for pointing it out. The updated patch is pasted below. I > will pay attention to it in the future. Ok, thanks. Note, you can use dg-additional-options if needed in g*.dg/vect/, just not dg-options. > --- a/gcc/testsuite/Change

Re: Revert libsanitizer patches or fix 59009

On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote: > or, alternatively, we can disable libsanitizer on PowerPC if the > PowerPC community does not care enough about it being healthy. I think there should be a global --enable-libsanitizer or whatever option that would allow people t

Re: [PATCH] Small fix: add { dg-require-effective-target vect_int } to testsuite/gcc.dg/vect/pr58508.c

Hi Jakub Thank you for pointing it out. The updated patch is pasted below. I will pay attention to it in the future. thanks, Cong diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog index 3d9916d..32a6ff7 100644 --- a/gcc/testsuite/ChangeLog +++ b/gcc/testsuite/ChangeLog @@ -1,3 +

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On 11/12/13 10:14, Marc Glisse wrote: On Tue, 12 Nov 2013, Jeff Law wrote: Here's a patch which arranges to leave a null pointer dereferece in the IL. For a memory load through a null pointer, we just leave the statement as-is since the LHS is going to be a throw-away SSA_NAME. For a store thro

Re: Revert libsanitizer patches or fix 59009

or, alternatively, we can disable libsanitizer on PowerPC if the PowerPC community does not care enough about it being healthy. On Tue, Nov 12, 2013 at 9:41 AM, Kostya Serebryany wrote: > [plain text] > So far I was not able to reproduce the compilation failure -- and I am > asking someone from t

Re: Revert libsanitizer patches or fix 59009

[plain text] So far I was not able to reproduce the compilation failure -- and I am asking someone from the PowerPC side to help. Please apply any minimal #ifdef patch to sanitizer_platform_limits_linux.cc to make it compile, while keeping x86_64 tests pass. If we revert the patch now, I will not

Implement C11 _Thread_local

This patch adds support for the C11 keyword _Thread_local. Semantically it's essentially the same as __thread, except that it doesn't have the GNU C ordering restriction on __thread appearing before extern or static. Bootstrapped with no regressions on x86_64-unknown-linux-gnu. Applied to mainlin

Revert libsanitizer patches or fix 59009

It has been a week since the libsanitizer patches were checked in, which broke the PowerPC64 Linux system along with others (PR 59009 for powerpc). Please revert these patches while you are working on proper fixes for all of the hosts and targets. Quoting from the GCC development plan: Patch Rev

Re: [RFC] replace malloc with a decl on the stack

On Tue, 12 Nov 2013, Ondřej Bílka wrote: Seems to be missing some bits. A example, its purpose is to show a idea not to be complete. I agree, but when too many bits are missing or wrong I fail to get the idea :-( How will you find small constant allocations with this in place? I won't.

Re: [patch] Add CONSTRUCTOR_NO_CLEARING flag

> in Ada 2012 it is allowed to omit components of aggregates (the equivalent > of initializers/constructors); in this case, the contents of the > corresponding fields in the record become undefined. Now the gimplifier > implements the C semantics of clearing the missing components, so this > patch

Re: [PATCH] Quash warning in final.c

> This patch quashes a -Wmaybe-uninitialized warning that showed up > when running bootstrap with asan/ubsan. Supposedly in that case > we aren't able to preinitialize label with the first element of the > label_pairs vector. > > Regtested/bootstrapped on x86_64-linux, ok for trunk? > > 2013-11-

Re: [PATCH] Generate a label for the split cold function while using -freorder-blocks-and-partition

On Tue, Nov 12, 2013 at 7:54 AM, Steven Bosscher wrote: > On Tue, Nov 12, 2013 at 3:49 PM, Teresa Johnson wrote: >>> Is there a format for compiler-defined labels that would not be able >>> to clash with other user-generated labels? >> >> My understanding is that the "." in the generated name ensu

Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

On Tue, 12 Nov 2013, Jeff Law wrote: Here's a patch which arranges to leave a null pointer dereferece in the IL. For a memory load through a null pointer, we just leave the statement as-is since the LHS is going to be a throw-away SSA_NAME. For a store through a null pointer, we try to simpli

Re: [RFC] replace malloc with a decl on the stack

On Tue, Nov 12, 2013 at 05:01:31PM +0100, Marc Glisse wrote: > On Tue, 12 Nov 2013, Ondřej Bílka wrote: > > >On Tue, Nov 12, 2013 at 01:41:24PM +0100, Marc Glisse wrote: > >>On Tue, 12 Nov 2013, Ondřej Bílka wrote: > >> > I am trying to get something to actually work and be accepted in > g

Re: RFC: simd enabled functions (omp declare simd / elementals)

+/* Operation to be performed for the parameter in ipa_parm_adjustment + below. */ +enum ipa_parm_op { + IPA_PARM_OP_NONE, + + /* This describes a brand new parameter. + + For new parameters, base_index must be >= the number of + DECL_ARGUMENTS in the function. That is, new argumen

  1   2   >