Re: gcc addresssanitizer in MIPS

2013-10-28 Thread Yury Gribov
> Yes, we do see this error on ARM. Here is another instance of the same bug: http://permalink.gmane.org/gmane.comp.debugging.address-sanitizer/531 > Full description and suggested patch are available at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543 > I'm curious whether suggested patch

Re: gcc addresssanitizer in MIPS

2013-10-28 Thread Yury Gribov
> Does someone use addresssanitizer in other platform (i386/x64/arm/ppc) > suffer this problem? Hi Jean, Yes, we do see this error on ARM. Full description and suggested patch are available at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543 I'm curious whether suggested patch is going to wor

Re: conflict between scheduler and register allocator

2013-10-28 Thread shmeel gutl
On 09-Aug-13 07:35 PM, Vladimir Makarov wrote: On 13-08-09 7:25 AM, shmeel gutl wrote: I am having trouble meeting the constraints of the scheduler and the register allocator for my back end. The relevant features are: 1) VLIW - up to 4 instructions can be issued each cycle 2) If a vliw bundle

Re: Warning about __DATE__ and __TIME__

2013-10-28 Thread Ian Lance Taylor
On Sun, Oct 27, 2013 at 12:04 PM, Gerald Pfeifer wrote: > To make it easier to reproduce builds of software and entire GNU/Linux > distributions, RMS had the idea of adding a warning to GCC that warns > about the use of __DATE__ and __TIME__. > > Short of "interesting" changes to the environment o

Re: New __atomic builtins generating an unwanted/unneeded stack slot

2013-10-28 Thread Richard Henderson
On 10/28/2013 02:25 AM, Frederic Riss wrote: > Is there a clean way to have the compiler discard the unneeded stack slot? Not yet. There is a rewrite of the atomic support in gcc to move away from using builtins, which will allow two outputs to be ssa allocacted. But this will not be complete fo

Re: gcc addresssanitizer in MIPS

2013-10-28 Thread pinskia
> On Oct 28, 2013, at 2:58 AM, Jean Lee wrote: > > Addresssanitizer was added to GCC since GCC 4.8, and you should > compile with the flag "-fsanitize=address". Moreover, the > addresssanitizer support for MIPS is not implemented in offical GCC. Yes I know that. I saying we back ported asan su

Re: Warning about __DATE__ and __TIME__

2013-10-28 Thread Joseph S. Myers
On Mon, 28 Oct 2013, Frank Ch. Eigler wrote: > Gerald Pfeifer writes: > > > To make it easier to reproduce builds of software and entire GNU/Linux > > distributions, RMS had the idea of adding a warning to GCC that warns > > about the use of __DATE__ and __TIME__. [...] > > How about instead

Re: Warning about __DATE__ and __TIME__

2013-10-28 Thread Jakub Jelinek
On Mon, Oct 28, 2013 at 09:10:08AM -0400, Frank Ch. Eigler wrote: > Gerald Pfeifer writes: > > > To make it easier to reproduce builds of software and entire GNU/Linux > > distributions, RMS had the idea of adding a warning to GCC that warns > > about the use of __DATE__ and __TIME__. [...] >

Re: Warning about __DATE__ and __TIME__

2013-10-28 Thread Joseph S. Myers
On Sun, 27 Oct 2013, Gerald Pfeifer wrote: > In addition to Andreas' comments, can you please make this "@code{__TIME__}, > @code{__DATE__}, or @code{__TIMESTAP__}" > and then also send to gcc-patches@ TIMESTAMP, not TIMESTAP. -- Joseph S. Myers jos...@codesourcery.com

Re: Warning about __DATE__ and __TIME__

2013-10-28 Thread Frank Ch. Eigler
Gerald Pfeifer writes: > To make it easier to reproduce builds of software and entire GNU/Linux > distributions, RMS had the idea of adding a warning to GCC that warns > about the use of __DATE__ and __TIME__. [...] How about instead adding a --time=X option to gcc (cpp?) instead, so that

Re: [RFC] Offloading Support in libgomp

2013-10-28 Thread Ilya Verbin
Hi Jakub, We have a MIC offload runtime library (liboffload), which is an abstraction over COI. Currently it is a part of ICC, but there are plans of open sourcing it. However, liboffload requires somewhat different tables comparing to what we have agreed on. The liboffload tables serve to assoc

Re: gcc addresssanitizer in MIPS

2013-10-28 Thread Jean Lee
Addresssanitizer was added to GCC since GCC 4.8, and you should compile with the flag "-fsanitize=address". Moreover, the addresssanitizer support for MIPS is not implemented in offical GCC. Does someone use addresssanitizer in other platform (i386/x64/arm/ppc) suffer this problem? Thanks, Jean L

New __atomic builtins generating an unwanted/unneeded stack slot

2013-10-28 Thread Frederic Riss
I try to convert my port to the new memory-model-aware atomic builtins, but I'm facing some code generation issue because of the __atomic_compare_exchange prototype (passing the comparison value by reference). For example, for a simple wrapper around __atomic_compare_exchange, the code at the end o

Re: gcc addresssanitizer in MIPS

2013-10-28 Thread pinskia
> On Oct 28, 2013, at 1:36 AM, Jean Lee wrote: > > My port of addresssanitizer is based on GCC 4.8.1. > I modify "asan_emit_stack_protection" function in gcc/asan.c for the > following reason: > Sometimes, the stack variable size > 32 Bytes, and after asan > generates code to poison the shadow b

gcc addresssanitizer in MIPS

2013-10-28 Thread Jean Lee
My port of addresssanitizer is based on GCC 4.8.1. I modify "asan_emit_stack_protection" function in gcc/asan.c for the following reason: Sometimes, the stack variable size > 32 Bytes, and after asan generates code to poison the shadow buffer, it does clear some shadow buffer but not all before fu