On Mon, Oct 28, 2013 at 02:42:37PM +0400, Ilya Verbin wrote:
> 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 wh
Hi Yury, try to use the patch for asan.c to see if it solve your problem.
pinskia, thank you. I compiled asan with libssp which mean the stack grows down.
I disassembled the compiled code and debuged the bin time to time
before I thought it was a bug.early this month.
I tried GCC 4.8.1 and GCC 4.9
Dear All,
It is my pleasure and honour to announce the MELT 1.0 plugin for GCC 4.7
& 4.8, a GPLv3+ licensed free software and FSF copyrighted plugin for
the GCC compiler http://gcc.gnu.org/
MELT is a Lispy like domain specific language to extend GCC. See
http://gcc-melt.org/ ; you'll be able to e
> Hi Yury, try to use the patch for asan.c to see if it solve your problem.
I tried but unfortunately it did not work for me. Could you try the
patch suggested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
(I've attached it) when you have time? This was verified against gcc
testsuite on
Hi Jakub,
I wonder how compiler is going to choose which target binaries should
be created for offload? Will compiler make choice on its own or it is
the user who should add specific options like --offload-target=...
How does compiler know paths to target compilers? Will it use
environment variabl
On Sun, Oct 27, 2013 at 1:50 AM, Hannes Frederic Sowa
wrote:
> On Sat, Oct 26, 2013 at 09:29:12PM +0200, Ondřej Bílka wrote:
>> Hi, as I brainstormed how prevent possible overflows in memory allocation I
>> came with heretic idea:
>>
>> For gcc -D_FORTIFY_SOURCE=2 we expand all multiplication with
On Tue, Oct 29, 2013 at 01:33:17PM +0400, Andrey Turetskiy wrote:
> I wonder how compiler is going to choose which target binaries should
> be created for offload? Will compiler make choice on its own or it is
> the user who should add specific options like --offload-target=...
> How does compiler
On Mon, Oct 28, 2013 at 7:33 PM, Richard Henderson wrote:
> 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
Yury Gribov writes:
> diff --git a/gcc/asan.c b/gcc/asan.c
> index 32f1837..acb00ea 100644
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -895,7 +895,7 @@ asan_clear_shadow (rtx shadow_mem, HOST_WIDE_INT len)
>
>gcc_assert ((len & 3) == 0);
>top_label = gen_label_rtx ();
> - addr = force_re
> "copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0))" would be more direct.
> But it looks good to me with that change FWIW.
Thanks, Richard. Note that Jakub has proposed an optimized patch on
gcc-patches ML (in Re: [PATCH] Invalid unpoisoning of stack redzones on
ARM).
-Y
The core development team is very pleased to announce the availability
of PPL 1.1, a new release of the Parma Polyhedra Library.
This release includes support for "positive time elapse," a new operator
on polyhedra, improvements to the Java interface, several portability
improvements and a few bu
Hi Richard/Vladimir,
I believe I finally understand one of the issues with LRA and mips16 but I
can't see how to solve it. Take the following instruction:
(insn 5 18 6 2 (set (reg:SI 4 $4)
(plus:SI (reg/f:SI 78 $frame)
(const_int 16 [0x10]))) test.c:6 13 {*addsi3_mips16}
Thanks. I will try Jakub patch listed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543.
2013/10/29 Yury Gribov :
>> "copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0))" would be more direct.
>> But it looks good to me with that change FWIW.
>
> Thanks, Richard. Note that Jakub has proposed an opti
On Tue, 29 Oct 2013, Richard Biener wrote:
> LLVM covers addition, subtraction and multiply on signed and unsigned
> int, long and long long types. Not sure why they offer anything for
> unsigned - possibly for size_t arithmetic and security concerns with
> malloc? For practicability and to be l
On 10/29/2013 03:06 AM, Richard Biener wrote:
> On Mon, Oct 28, 2013 at 7:33 PM, Richard Henderson wrote:
>> 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 t
On 24/10/13 07:05, Andi Kleen wrote:
> Tom de Vries writes:
>> ...
>> Can you translate the last sentence into shell/git command(s)?
>
> It would be far better to just centrally mirror all branches in SVN as
> standard git branches. Then all these problems wouldn't occur.
>
> As far as I can te
Tom de Vries writes:
> I've tried that now:
> ...
> $ git clone git://gcc.gnu.org/git/gcc.git
> $ git svn init -Ttrunk --prefix=svn/ svn+ssh://vr...@gcc.gnu.org/svn/gcc
> $ git svn fetch
> $ git svn show-ignore >> .git/info/exclude
> $ git config remote.origin.fetch 'refs/heads/*:refs/remotes/ori
On 10/29/2013 09:43 AM, Matthew Fortune wrote:
> Hi Richard/Vladimir,
>
> I believe I finally understand one of the issues with LRA and mips16 but I
> can't see how to solve it. Take the following instruction:
>
> (insn 5 18 6 2 (set (reg:SI 4 $4)
> (plus:SI (reg/f:SI 78 $frame)
>
Thanks for looking at this.
Matthew Fortune writes:
> Hi Richard/Vladimir,
>
> I believe I finally understand one of the issues with LRA and mips16 but
> I can't see how to solve it. Take the following instruction:
>
> (insn 5 18 6 2 (set (reg:SI 4 $4)
> (plus:SI (reg/f:SI 78 $frame)
>
> On 10/29/2013 09:43 AM, Matthew Fortune wrote:
> > Hi Richard/Vladimir,
> >
> > I believe I finally understand one of the issues with LRA and mips16 but I
> can't see how to solve it. Take the following instruction:
> >
> > (insn 5 18 6 2 (set (reg:SI 4 $4)
> > (plus:SI (reg/f:SI 78 $fram
Are the following testsuite errors known for the version below?
./gcc/xgcc --version
xgcc (GCC) 4.9.0 20131028 (experimental)
/gcc/xgcc -dumpmachine
x86_64-unknown-linux-gnu
FAIL: libgomp.graphite/bounds.c scan-tree-dump-times graphite "0 loops
carried no dependency" 1
FAIL: libgomp.graphite/for
Hi Balaji,
On Wed, 23 Oct 2013, Iyer, Balaji V wrote:
> Is there anything you were thinking about that I missed?
the question was in a different context, but making the code a
bit more portable would be good.
Right now FreeBSD bootstrap is broken due to the following in
runtime/config/x86/cilk-a
I have run into a obscure corner case while building and was wondering if
anyone can help me with it. I am doing a canadian cross build, building
on x86 linux to create a GCC that runs on x86 windows and generates code
for bare-metal MIPS. Most everything is working but I have run into one
probl
> On Oct 29, 2013, at 4:12 PM, "Steve Ellcey " wrote:
>
>
> I have run into a obscure corner case while building and was wondering if
> anyone can help me with it. I am doing a canadian cross build, building
> on x86 linux to create a GCC that runs on x86 windows and generates code
> for bare-
There are a couple of places in gcc where wierd-sized pointers are an
issue. While you can use a partial-integer mode for pointers, the
pointer *math* is still done in standard C types, which usually don't
match the modes of pointers and often result in suboptimal code.
My proposal is to allow t
On Tue, Oct 29, 2013 at 05:28:40PM +0100, Tom de Vries wrote:
> On 24/10/13 07:05, Andi Kleen wrote:
> > Tom de Vries writes:
> >> ...
> >> Can you translate the last sentence into shell/git command(s)?
> >
> > It would be far better to just centrally mirror all branches in SVN as
> > standard g
26 matches
Mail list logo
