> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
>
> The vectorization failures still need to be fixed.
Are these specific to SPARC? If so, I don't think development should be held
off for them at this point. If not
I'm porting GCC 4.0.1 to a new architecture.
Its load/store instructions are similar to ARM's.
The RTL is always generating a symbol_ref RTX to access a global variable,
and the symbol_ref is an immediate which will be determined at the
assembling/linking time.
The addressing modes of my archite
On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote:
> Are these specific to SPARC?
No.
r~
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
>> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
>>
>> The vectorization failures still need to be fixed.
>
> Are these specific to SPARC? If so, I don't think development s
> The struct-layout-1 failures in 64-bit mode are IMHO more annoying, but
> these tests are easy to break so I'm not really worried either.
Huh, I was wrong, they are quite problematic. Testcase attached.
We have as initial RTL:
(insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-sta
> On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote:
> > Are these specific to SPARC?
>
> No.
I believe Andrew mentioned that there is a patch for this? (it is lack
of sync in between operands and stmt itself)
Honza
>
>
> r~
Is there any progress in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029 ?
--
Cheers,
/ChJ
On Fri, 20 May 2005 19:24:07 +0100, Dave Korn wrote:
> Absolutely so, no problem
Absolutely not, there will be lots of problems. This whole thread is about
how you *can't* just do that. Your app still won't run on older systems
(reliably) even if you target old APIs and use dlopen for the rest. Th
On Fri, 20 May 2005, Gary Funck wrote:
> OK, thanks. I (now) understand that the reference to a warning about a
> missing protoype
> does not apply. However, I don't see anything in section 6.5.2.2
> (rev. 1999-12-01) that says that a function declaration or prototype
> declaration must (or shou
[EMAIL PROTECTED] (Peter Barada) wrote on 17.05.05 in <[EMAIL PROTECTED]>:
> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
> BogoMips of my workstation, and with an NFS rootfs, it gets network
BogoMips are called BogoMips because they are not comparable among
different CPUs.
>> Its a 266Mhz ColdFire v4e machine, about 263 BogoMips, 1/20 the
>> BogoMips of my workstation, and with an NFS rootfs, it gets network
>
>BogoMips are called BogoMips because they are not comparable among
>different CPUs. All they measure is how often the CPU needs to run a
>particular near
Hi,
I've been pushing, locally, the compilation of GCC sources with g++.
So far, I've gotten past libiberty, fixincludes, libcpp, the C
front-end specific files, RTL files with no much pain. However, the
files tree-* and associated headers seem to be the most resolutely C++
unfriendly (I guess
Hi again,
I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
/* Initialize dominance frontier. */
dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Hi again,
>
> I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
>
> /* Initialize dominance frontier. */
> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));
>^^^
Andreas Jaeger <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > Hi again,
| >
| > I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
| >
| > /* Initialize dominance frontier. */
| > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));
| >
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> |
> | > Hi again,
> | >
> | > I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
Note update_ssa has the same problem.
> | >
> | > /* Initial
On Sat, May 21, 2005 at 10:59:44AM +0200, Jan Hubicka wrote:
> I believe Andrew mentioned that there is a patch for this? (it is lack
> of sync in between operands and stmt itself)
The last state I saw is that the patch needed some minor updates.
I was hoping that one of the original authors woul
Hi
I am working on gcc-4.0. I have edited some files in code and the
remaking of gcc works well, and even files compile with it. But when i try
to run a compiled program it gives segmentaion fault. I checked
that assembly code produced is fine and i just compiled file to file.s and
then ass
> "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
Gabriel> I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
Gabriel> /* Initialize dominance frontier. */
Gabriel> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));
Gabriel>
On Sat, 2005-05-21 at 18:55 +0200, Andreas Jaeger wrote:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
> > Hi again,
> >
> > I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
> >
> > /* Initialize dominance frontier. */
> > dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bit
On Sat, 2005-05-21 at 20:33 +0200, Gabriel Dos Reis wrote:
> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
> | Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> |
> | > Hi again,
> | >
> | > I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
> | >
> | > /* Initialize dominance frontier. *
Tom Tromey <[EMAIL PROTECTED]> writes:
| > "Gabriel" == Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| Gabriel> I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
| Gabriel> /* Initialize dominance frontier. */
| Gabriel> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bi
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-05-21 at 18:55 +0200, Andreas Jaeger wrote:
| > Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| >
| > > Hi again,
| > >
| > > I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
| > >
| > > /* Initialize dominance frontier. */
| >
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > Parenthetically, I was wondering who is freeing those extensive
| > regions of storage xmalloc/xcalloc()ed here and there?
|
| 1. The people who write the code to do the xmalloc'ing.
| 2. Every couple of months, people run gcc through valgrind
On Sat, May 21, 2005 at 10:46:19AM +0200, Eric Botcazou wrote:
> We have as initial RTL:
>
> (insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-stack-vars)
> (const_int -5120 [0xec00])) [0 S16 A128])
> (reg:TF 110 [ D.1221 ])) -1 (nil)
> (nil))
>
On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | > Parenthetically, I was wondering who is freeing those extensive
> | > regions of storage xmalloc/xcalloc()ed here and there?
> |
> | 1. The people who write the code to do the
> The new implementation of instantiate_virtual_regs requires that the
> insn be valid *before* instantiation.
I see. I didn't find it written anywhere so I thought I should ask.
> The bug is in sparc_emit_float_lib_cmp,
>
> 5807 slot0 = assign_stack_temp (TFmode, GET_MODE_SIZE(TFmo
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | > Parenthetically, I was wondering who is freeing those extensive
| > | > regions of storage xmalloc/xcalloc()ed here and t
On Sat, 2005-05-21 at 22:59 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sat, 2005-05-21 at 22:00 +0200, Gabriel Dos Reis wrote:
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > [...]
> | >
> | > | > Parenthetically, I was wondering who is freein
On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> Btw, is it me or the individual RTL dump options are broken?
The initial rtl dump is broken. The rest work.
I think one of Jan's IPA pass manager changes broke it.
r~
On Saturday 21 May 2005 22:15, Daniel Berlin wrote:
> > where the storage is returned/reused as soon as done, as opposed to
> > waiting for the end of the compilation.
>
> Uh, nobody waits for the end of compilation to free their xmalloc'd
> things.
Except the alloc pools of et-forest :-)
Gr.
Ste
I just applied the following patch and will update the gccadmin account
on gcc.gnu.org after tomorrow's snapshot of GCC 4.1 has been made. (The
new schedule is more in line what we originally had.)
Gerald
2005-05-21 Gerald Pfeifer <[EMAIL PROTECTED]>
* crontab: Spread snapshot building
Hi,
the GCC Timeline doesn't seem ok: a wide 'internal version' field and
4.0.0 completely missing. Is this a known issue?
Thanks,
Paolo.
> On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> > Btw, is it me or the individual RTL dump options are broken?
>
> The initial rtl dump is broken. The rest work.
>
> I think one of Jan's IPA pass manager changes broke it.
What are the symptoms? -fdump-tree-expand seems to wo
On Sun, 22 May 2005, Paolo Carlini wrote:
> the GCC Timeline doesn't seem ok: a wide 'internal version' field and
> 4.0.0 completely missing. Is this a known issue?
I'll see what I can do about the formatting, but the missing release
is a feature (so that our release managers do not have to perfor
While moving FIELD_DECL to it's own substruct, the following questions
have come up. I figured one of you might know:
1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
place where we would actually try to *output* a FIELD_DECL directly, but
maybe i've missed something. I ask b
Gerald Pfeifer wrote:
>I'll see what I can do about the formatting,
>
Thanks!
> but the missing release
>is a feature (so that our release managers do not have to perform that
>many manual steps during the process).
>
>That's why the page states:
>
> Please refer to our development plan for rele
On Sun, 22 May 2005, Paolo Carlini wrote:
>> I'll see what I can do about the formatting,
> Thanks!
I installed the following patch.
Gerald
Streamline the reference to our binaries page. Remove references to egcs
internal version numbers.
Index: releases.html
==
Daniel Berlin <[EMAIL PROTECTED]> writes:
| While moving FIELD_DECL to it's own substruct, the following questions
| have come up. I figured one of you might know:
|
| 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think of a
| place where we would actually try to *output* a FIELD_DEC
On Sunday 22 May 2005 00:16, Jan Hubicka wrote:
> (not sure of -fdump-rtl-expand ever worked, but I
> might try to restore it if it did).
It very definitely did work, and quite nicely too.
Try -fdump-rtl-expand-details.
Gr.
Steven
On Sun, 22 May 2005, Paolo Carlini wrote:
> Maybe you may want to have a look to web/21679 too, anyway, I think Dave
> Abrahams has a point.
I installed the patch below. If this is not sufficient, we could
consider creating a download page of its own, though this would add
yet another level of in
On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | While moving FIELD_DECL to it's own substruct, the following questions
> | have come up. I figured one of you might know:
> |
> | 1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't
On Sun, 2005-05-22 at 00:16 +0200, Jan Hubicka wrote:
> > On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> > > Btw, is it me or the individual RTL dump options are broken?
> >
> > The initial rtl dump is broken. The rest work.
> >
> > I think one of Jan's IPA pass manager changes
Daniel Berlin <[EMAIL PROTECTED]> wrote:
>> $ ./xgcc -c -Os -B. btst.c && size btst.o
>>textdata bss dec hex filename
>>5339 0 0533914db btst.o
>> $ ./xgcc -c -Os -fno-tree-sra -B. btst.c && size btst.o
>>textdata bss dec hex filename
Snapshot gcc-4.0-20050521 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050521/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050521
You'll
Andreas Jaeger <[EMAIL PROTECTED]> writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
>> Hi again,
>>
>> I just hit this one from tree-ssa-into.c:rewrite_into_ssa()
>>
>> /* Initialize dominance frontier. */
>> dfs = (bitmap *) xmalloc (last_basic_block * sizeof (bitmap *));
>>
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | While moving FIELD_DECL to it's own substruct, the following questions
| > | have come up. I figured one of you might know:
| > |
| > |
On Sun, 2005-05-22 at 03:13 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Sun, 2005-05-22 at 02:14 +0200, Gabriel Dos Reis wrote:
> | > Daniel Berlin <[EMAIL PROTECTED]> writes:
> | >
> | > | While moving FIELD_DECL to it's own substruct, the following questi
Daniel Berlin <[EMAIL PROTECTED]> writes:
> I've actually discovered that we set the assembler name on a field that
> is the vtable, but never actually use it again, at least for DWARF2 and
> STABS (it's set to a constant called VFIELD_NAME).
> I grepped .s file from all of libjava and the stl tes
Hi
I guess there must be people watching this list, interested in this.
I hope I now finally found the way I was looking for, to formulate a
reduction rule for Kleene's Closure which can be used in replacement
of Thompson's algorithm, or so I hope. I could be wrong about it,
however.
http://eri
50 matches
Mail list logo
