I'm not dependent on it, although at some point, I'm sure i may take a
closer look at the code to see how they've done certain things.
Just as a reminder, even though the Microchip code is covered by the GPL,
code based on it >>won't be acceptable for inclusion into FSF GCC unless
you can get
I'm not quite sure I follow you.. if its possible to dedicate a register to
act as the data-stack pointer, and implement it that way, why would I want
to "keep the SP as a virtual register"? I'm not being antagonistic when I
say that.. I'm just trying to understand what you're trying to tell me
On 11 April 2006 08:47, Colm O' Flaherty wrote:
> I'm not quite sure I follow you.. if its possible to dedicate a register to
> act as the data-stack pointer, and implement it that way, why would I want
> to "keep the SP as a virtual register"?
Because then you would /not/ have to sacrifice o
On 11 April 2006 02:34, Mark Cuss wrote:
> Hello
>
> I've subscribed to the gcc mailing list from my work account
> ([EMAIL PROTECTED]) but none of my posts appear on the mailing
> list...
Ok. point one:
> The mail doesn't get bounced back so I assume it's getting
> delivered,
That
Florian Weimer wrote:
* Mark Mitchell:
1. What do we do if people do advertise jobs that are not free software
jobs, or not purely free software jobs? How pure is pure? Does "Port
GCC to proprietary OS" count as free or not?
And: Does porting GCC to a new processor, to run on a free operati
On Mon, 10 Apr 2006, Mark Mitchell wrote:
> It seems like we're getting consensus around that approach, despite the
> initial sentiment in the other direction from Mike and Joe. Mike, Joe,
> do either of you care to argue the point? If not, I'll volunteer to
> write some text for the web pages, a
Hello,
> I want to write a pass to walk the gimple tree and add some intrumentation
> code. I read the chapter 9 of "GCC Internals" document, and it seems not to
> describe the Macros to do so.
>
> Can I get some information about this? Specifically, if someone can show me
> which .h file I sh
Hello,
> Dear mailing list,
>
> is there something wrong with the following code?
> --
> basic_block my_basic_block;
> basic_block dup_basic_block;
>
> FOR_EACH_BB(my_basic_block)
> {
> dup_basic_block = duplicate_block(bb, NULL);
> }
I assume you mean
> dup_basic_block = duplicate
On Apr 11, 2006, at 03:46, Colm O' Flaherty wrote:
I'm not quite sure I follow you.. if its possible to dedicate a
register to act as the data-stack pointer, and implement it that
way, why would I want to "keep the SP as a virtual register"? I'm
not being antagonistic when I say that.. I'
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Mike Stump wrote:
|
| >> 3. How do we enforce any of these rules?
| >
| > Shame on those that violate them.
|
| I think we need to do better than that.
I'll vote for keeping the current policy: not job ads on the
development list.
-- Gaby
Thanks,
Can you give me a hint of the three following fields? Some passes defined
them (such as pass_lower_cf), but soem passes leave them as NULL/0.
Thanks,
37 struct tree_opt_pass
38 {
63 /* Sets of properties input and output from this pass. */
64 unsigned int prop
Gerald Pfeifer wrote:
> Personally, I'd be in favor of GCC-releated internships and job offers on
> our lists, but I see that it may be difficult to draw a line. That said,
> I wonder how to handle .signatures: for example, if you added a line like
> "CodeSourcery is hiring. http://.../work4us
Hello
I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My
build setup was:
../gcc-3.4.4/configure --diabled-shared --prefix=dir> --enable-languages=c,c++
make bootstrap
(the install dir is the same directory which I previously compiled and
installed binutils into)
I'm at
> I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My
> build setup was:
> ../gcc-3.4.4/configure --diabled-shared --prefix= dir> --enable-languages=c,c++
> make bootstrap
I see 4 potential problems:
- do not use a relative path to configure,
- "--diabled-shared" is probably no
Thanks Eric
I thought it was OK to use a relative path. From what I understood, it is a
bad idea to build inside the directory that the gcc tar file is uncompressed
into, but I guess I can specifiy the path in full.
Definitely a typo in the email on the disable shared thing
I'm using GNU ma
> I thought it was OK to use a relative path. From what I understood, it is
> a bad idea to build inside the directory that the gcc tar file is
> uncompressed into, but I guess I can specifiy the path in full.
Yes, and while you are at it, use the recommended config shell.
--
Eric Botcazou
I try compile example program
gcc.exe -I"c:\gcc\include" -L"c:\gcc\lib" c:\gcc\bin\program.c
gcc.exe: Internal error: (null) (program as)
Please submit bug report.
Free is bad?
_
Express yourself instantly with MSN Messenger! Downlo
Yes, I meant
--
basic_block my_basic_block;
basic_block dup_basic_block;
FOR_EACH_BB(my_basic_block)
{
dup_basic_block = duplicate_block(my_basic_block, NULL);
}
--
I also got some more precise context. The statement being copied at
that point is:
--
*D.1600 = 0;
--
whose GIMPLE rep
I send a message to John Elliott's listed address yesterday, and I have
not yet received an immediate response. I will post to this list if I
receive anything from him.
So, I'd caution anyone away from basing any work on the dsPIC port until
some specific understanding is established with Mic
Ok - it built this time. I guess I should read the instructions - my
fault...
Thanks for the help!
Mark
- Original Message -
From: "Eric Botcazou" <[EMAIL PROTECTED]>
To: "Mark Cuss" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, April 11, 2006 10:52 AM
Subject: Re: gcc 3.4.4 build fails o
is from an ICE:
- get_expr_operands() on the INDIRECT_REF calls
get_indirect_ref_operands(), and
- get_indirect_ref_operands() tries to look at the var_ann for the
INDIRECT_REF, which is NULL at that point.
Is the var_ann NULL because I need to require something more than
PROP_gimple_any |
On Apr 10, 2006, at 4:30 PM, Mark Mitchell wrote:
It seems like we're getting consensus around that approach, despite
the
initial sentiment in the other direction from Mike and Joe.
Mike, Joe, do either of you care to argue the point?
I'm fine with the status quo. I think comp.compilers a
Thanks Sandro, I have checked this in to the trunk and the 4.1 branch.
It would be great to get a copyright assignment form from you so that we
can check in the rest of your Darwin/x86 patches. Have you started the
copyright assignment process? If not, the form to do so can be found here:
htt
Roger Sayle wrote:
> such a step. Is such a transition safe for stage 3 mainline,
> and/or would front-ends prefer some time to double check that
> this won't cause problems on conformance tests not part of GCC's
> testsuite.
I think it's reasonable to make this change at this point, as there ar
Hi,
First I apologize, if this is the wrong list. :)
I hope someone from the developer's group can't point me in the right
direction? I did not get a response on GCC-help list.
I am trying to compile code that uses the
vector processor (SPE) found on the E500 (i.e. MPC8540)
I am using the SPE
hi,
You know that treelang prescribes the function prototype must give the
storage class type explicitly, for an example, "external_definition
int add(int arg1, int arg2);"
I'd like to know how to modify the parse.y to let the storage type can
be implicitly and the default type is external_definiti
On Monday 10 April 2006 19:48, you wrote:
> Can it at least add (small) immediates to registers?
Nope, sry. The only instructions that take other arguments than registers are
the aforementioned LDL/LDH (load low/high), branch instructions (they take a
memory address) and four bit operations whic
27 matches
Mail list logo
