On 04/07/2014 07:10 PM, Jan Hubicka wrote:
I added new graph for 'xloc.column = 0' hack, just applied this
single patch to trunk.
Link:
https://drive.google.com/file/d/0B0pisUJ80pO1MW11WHdjMk9KQnc/edit?usp=sharing
Good, does these two patches combine together well? (they are rater orthogonal,
On Mon, Apr 7, 2014 at 8:20 PM, Jan Hubicka wrote:
>> AFAIK we settled on a simpler one dropping columns at stream-out time
>> that also helped.
>>
>> As for the correct way to do the optimization we agreed(?) that streaming
>> the locations elsewhere and using references to them is more appropria
Hi everybody,
When playing with a toolchain built with --with-newlib switch, I recently
noticed that libgcc.a includes __eprintf among its objects. However,
gcc/doc/install.texi states that --with-newlib switches "causes
@code{__eprintf} to be omitted from @file{libgcc.a} on the assumption that
Try to make a gcc cross compiler ,
0 perpare vars in env
export HOST=x86_64-pc-linux-gnu
export BUILD=$HOST
export TARGET=x86_64-none-linux-gnu
export CROSS_TOOL=/vita/cross-tool
export CROSS_GCC_TMP=/vita/cross-gcc-tmp
export SYSROOT=/vita/sysroot
Can you check whether crt1.o and crt1.o exist? And the path where they do live.
Also it would be interesting to know the exact commandline (check config.log).
2014-04-08 14:13 GMT+02:00 Mo Jia :
> Try to make a gcc cross compiler ,
>
> 0 perpare vars in env
>
> export HOST=x86_64-pc-linux
On Tue, Apr 8, 2014 at 1:42 AM, Thomas Preud'homme
wrote:
>
> When playing with a toolchain built with --with-newlib switch, I recently
> noticed that libgcc.a includes __eprintf among its objects. However,
> gcc/doc/install.texi states that --with-newlib switches "causes
> @code{__eprintf} to
2014-04-08 20:22 GMT+08:00 David Guillen :
> Can you check whether crt1.o and crt1.o exist? And the path where they do
> live.
> Also it would be interesting to know the exact commandline (check config.log).
Do you mean the commanline I build , here is :
The total command list
0 perpare var in e
Hi all,
I'm looking at some curious pre-reload scheduling behaviour and I noticed this:
At the add_branch_dependences function sched-rgn.c there is a comment that says
"branches, calls, uses, clobbers, cc0 setters, and instructions that can throw
exceptions" should be scheduled at the end of t
I'm porting gcc to a 16 bit processor. Occasionally compiling
source such as
short v1;
long global;
global = (long)v1;
results in ...
(insn 11 10 12 2 (set (subreg:HI (mem/c:SI (symbol_ref:HI
("global") ) [2 global+0 S4 A16]) 2)
(const_int 0 [0])) t.c:15 -1
(nil))
(insn
> From: Ian Lance Taylor [mailto:i...@google.com]
>
> I don't think anything uses __eprintf any more. The function has been
> left behind for very very very old systems. Actually we could
> probably remove it now. Probably the old support for not building
> __eprintf when --with-newlib was spec
On Tue, Apr 8, 2014 at 8:14 PM, Thomas Preud'homme
wrote:
>> From: Ian Lance Taylor [mailto:i...@google.com]
>>
>> I don't think anything uses __eprintf any more. The function has been
>> left behind for very very very old systems. Actually we could
>> probably remove it now. Probably the old s
On Tue, Apr 8, 2014 at 8:19 PM, Andrew Pinski wrote:
> On Tue, Apr 8, 2014 at 8:14 PM, Thomas Preud'homme
> wrote:
>>> From: Ian Lance Taylor [mailto:i...@google.com]
>>>
>>> I don't think anything uses __eprintf any more. The function has been
>>> left behind for very very very old systems. Ac
> From: Andrew Pinski [mailto:pins...@gmail.com]
>
> I think your patch is broken since the object file (_eprintf.o) should
> not be pulled in unless it is used and it is part of an archive and
> for archives cause the linker to only bring in object files which have
> things referenced to them.
I
13 matches
Mail list logo
