> Any suggestions?
I would double check that you are indeed using the freshly built
corresponding native. Maybe your native installation didn't work as
expected and your building from an older compiler. That's the
most likely explanation.
Alternatively, there have been changes recently in the lib
I forked the vta branch into a var-tracking-assignments-4_3-branch,
created and merged from gcc-4_3-branch on Wednesday, and I've just
finished merging the trunk onto the var-tracking-assignments-branch.
Both merges were mostly trivial, although the trunk merge required the
tuplification of debug s
Arnaud Charlet wrote:
Any suggestions?
I would double check that you are indeed using the freshly built
corresponding native. Maybe your native installation didn't work as
expected and your building from an older compiler. That's the
most likely explanation.
Alternatively, there have been chan
4.2.3 insn-attrtab.c takes "a long time" to
compile on djgpp (build=host=target=i586-pc-msdosdjgpp, bootstrapping
from 4.2.3) with the default -g -O2.
I let it go, walked away for a few days, laptop
power was pulled in the meantime (moved to another laptop),
so it ran till the battery ran out. P
Eric,
this patch of yours
2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
* gcc-interface/utils.c (convert_vms_descriptor): Add gnu_expr_alt_type
parameter.
Convert the expression to it instead of changing its type in place.
(build_function_stub): Adjust call to ab
> this patch of yours
>
> 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
>
> * gcc-interface/utils.c (convert_vms_descriptor): Add
> gnu_expr_alt_type parameter.
> Convert the expression to it instead of changing its type in place.
> (build_function_stub): Adjust call to abo
> 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
>
> * gcc-interface/utils.c (convert_vms_descriptor): Add
> gnu_expr_alt_type parameter.
> Convert the expression to it instead of changing its type in place.
> (build_function_stub): Adjust call to above function.
Now revert
Eric Botcazou writes:
> > 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
> >
> > * gcc-interface/utils.c (convert_vms_descriptor): Add
> > gnu_expr_alt_type parameter.
> > Convert the expression to it instead of changing its type in place.
> > (build_function_stub): Adjust
> > 2008-08-01 Eric Botcazou <[EMAIL PROTECTED]>
> >
> > * gcc-interface/utils.c (convert_vms_descriptor): Add
> > gnu_expr_alt_type parameter.
> > Convert the expression to it instead of changing its type in place.
> > (build_function_stub): Adjust call to above function.
[ Moved to gcc@gcc.gnu.org ]
On Fri, Aug 1, 2008 at 03:33, Bill Maddox <[EMAIL PROTECTED]> wrote:
> I am continuing to make progress with the LTO streamer on C++ code,
> and finding a considerable amount of front-end specific crud hanging
> off of the GIMPLE, particularly related to templates.
Paolo Bonzini wrote:
Arnaud Charlet wrote:
Any suggestions?
I would double check that you are indeed using the freshly built
corresponding native. Maybe your native installation didn't work as
expected and your building from an older compiler. That's the
most likely explanation.
Alte
Diego Novillo wrote:
My assertion is that the langhook must go, and that mangled names
should be generated before invoking the middle-end. Given the baroque
treatment of the assembler name, however, I don't think it will be
sufficient simply to make a pass over the declarations in
free_lang_spe
Hi Bill,
On Fri, 1 Aug 2008, Diego Novillo wrote:
> > Finding that DECL_CONTEXT might include portions of what looked like
> > template definitions, and surmising that lexical nesting was a
> > language artifact that should no longer be of significance beyond the
> > front-end, I attempted to cl
> You forgot to look at PowerPC :
>
> http://cvs.opensolaris.org/source/xref/ppc-dev/ppc-dev/usr/src/lib/libc/ppc/gen/memcpy.s
>
> is that nice and small ?
I had to clear/check the whole 256 Mbytes SDRAM on a PPC system,
and the fastest way I got (excluding DMA access) is by playing with the
laye
Hello,
A naive question. For the same toolchain (gcc-3.2, binutils-2.11.94,
glibc-2.3.1) I've got the following binary sizes (busybox, built
with -Os):
MIPS:
bash# size busybox
textdata bss dec hex filename
1650805564 10168 180812 2c24c busybox
bash# ls -l busy
Dear all
I receive in linux the following error.
gmake: ***[go-opt] Error 12
Could any one help me?
Thanks
Luis Gonçalves
Luis Gonçalves wrote on 01 August 2008 18:05:
> Dear all
>
>I receive in linux the following error.
>
>
>
> gmake: ***[go-opt] Error 12
>
> Could any one help me?
>
> Thanks
>
> Luis Gonçalves
The GCC list is for discussion and questions about the coding and
development of the GCC c
Snapshot gcc-4.4-20080801 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080801/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Aug 1, 2008 at 7:53 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> That's going to make -flto slow. If we do it in a way that affects normal
> -O0 compilation, this would be a bad thing. Maybe we should consider a
> strategy where the front-end data structures live until the point of LTO
Bill Maddox wrote:
To move toward a language-independent IR, however, it is good hygiene
to strip this stuff so we aren't fooling ourselves.
Yes, the question is just when to do the stripping. My point is that
stripping early implies that the FE must generate everything you might
ever want
20 matches
Mail list logo
