BACKGROUND (optional)
I've now reached the point of writing the GCC middle/back end interface
for my Cobol compiler. See
http://cobolforgcc.sourceforge.net/
Previously I wrote two front ends but that was a while ago. These were
the original iteration of cobolforgcc 1998-2003, and the now defunc
On Sat, 2008-04-12 at 18:16 +1000, Tim Josling wrote:
> On Fri, 2008-04-11 at 17:05 -0400, Daniel Jacobowitz wrote:
> > On Sat, Apr 12, 2008 at 06:59:28AM +1000, Tim Josling wrote:
> > > > Why not get it out of GCC later? You don't need to hack up GCC to do
> > > > that.
> You're right... That's
On Tue, 2008-04-15 at 11:27 +0530, Mohamed Shafi wrote:
> On Mon, Apr 14, 2008 at 11:44 PM, Jim Wilson <[EMAIL PROTECTED]> wrote:
> > A simple grep command shows that both arm and rs6000 already both support
> > long call pragmas.
> I did see those but i coudn't determine whether it is possible t
Denys Vlasenko wrote:
> Only in my case, $prefix contain neither as nor ld. gcc lives in
Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
--with-{as,ld}.
> it's much better for sanity that way.
I would a
On Thursday 17 April 2008 04:04, Brian Dessent wrote:
> > What happened to the good old concept of looking up executables'
> > location in $PATH if they have no slashes on the name?
> >
> > (Oh well)^2. Recompiling with --with-as="/usr/bin/$CROSS-as"...
>
> Why do you think it's necessary to spec
On Thursday 17 April 2008 03:35, Denys Vlasenko wrote:
> On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
> > I believe I solved it with --with-sysroot...
> > Will try again and let you know.
I got over the problem of includes not being found using --with-sysroot,
and reached
"/usr/bin/x86_6
Denys Vlasenko wrote:
> (Is it necessary to do this "/../../../../" thing?)
A useful trick to make this easier for a human to read is to pipe the
output through
sed -e :a -e "s,[^/]*/\.\.\/,," -e ta
I don't guarantee that this will always result in the correct semantics
in all situations but it
On Thursday 17 April 2008 02:40, Denys Vlasenko wrote:
> I believe I solved it with --with-sysroot...
> Will try again and let you know.
So far I only discovered that --with-as="$CROSS-as" is not going to work.
Fixing configure is not enough:
23651 access("x86_64-linux-uclibc-as", X_OK) = -1 ENOE
On Thursday 17 April 2008 00:42, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
> > It seems that 4.2.1 was testing "/usr/lib/../x86_64-linux-uclibc/include",
> > i.e. "$libdir/../x86_64-linux-uclibc/include". From the listing above
> > I see them 4.3.0 d
Snapshot gcc-4.2-20080416 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080416/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Apr 16, 2008 at 10:24:35PM +0200, Denys Vlasenko wrote:
> It seems that 4.2.1 was testing "/usr/lib/../x86_64-linux-uclibc/include",
> i.e. "$libdir/../x86_64-linux-uclibc/include". From the listing above
> I see them 4.3.0 does not do that anymore - there is no
> "/../x86_64-linux-uclibc/i
On Wednesday 16 April 2008 21:59, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote:
> > #include "..." search starts here:
> > #include <...> search starts here:
> > include
> > libbb
> >
> > /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x
On Wed, Apr 16, 2008 at 09:55:09PM +0200, Denys Vlasenko wrote:
> #include "..." search starts here:
> #include <...> search starts here:
> include
> libbb
>
> /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include
>
> /.share/usr/app/gcc-4.3.0-x86_64-l
On Wednesday 16 April 2008 21:17, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
> > As I mentined in the first mail, it's not the end of a story.
> > Next issue: can't find header files. This used to work with 4.2.1:
>
> Try -v to see where it is search
On Wed, Apr 16, 2008 at 09:01:44PM +0200, Denys Vlasenko wrote:
> As I mentined in the first mail, it's not the end of a story.
> Next issue: can't find header files. This used to work with 4.2.1:
Try -v to see where it is searching.
--
Daniel Jacobowitz
CodeSourcery
On Wednesday 16 April 2008 17:21, Denys Vlasenko wrote:
> I do it not not only for gcc but for almost everything.
>
> I discovered that a lot of packages will "remember" patchs given
> to configure and use those at runtime. I want them to use
> /ust/bin/something rather than /usr/app/bar/bin/somet
On Wed, Apr 16, 2008 at 07:02:30PM +0200, Denys Vlasenko wrote:
> The patch is below. Do you think it makes sense?
No opinion. There is room for confusion about relocation...
--
Daniel Jacobowitz
CodeSourcery
On Wednesday 16 April 2008 17:43, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
> > Maybe gcc can use paths relative to executable's location?
> > readlink("/proc/self/exe") and all that.
> > It will make gcc installation movable without rebuilding.
>
>
Boris Boesler wrote:
> The following "program" can be compiled without problems.
>
> extern void something(char *s);
> char msg[] = "123456";
> int main(int argc, char **argv)
> {
> something(msg);
> return 0;
> }
>
> But I can't compile it correctly with my backend. The content of msg is
Sent from my iPhone
On Apr 16, 2008, at 6:52, Ogier Maitre <[EMAIL PROTECTED]> wrote:
Hello.
I'm student in master, and I'm at this time in a internship named
"Parallelization on Cell processor".
We are interested in porting libgomp an cell processor.
Like you maybe know, cell proc uses t
On Wed, Apr 16, 2008 at 05:21:55PM +0200, Denys Vlasenko wrote:
> Maybe gcc can use paths relative to executable's location?
> readlink("/proc/self/exe") and all that.
> It will make gcc installation movable without rebuilding.
It already does. That's exactly what the code causing you a problem
i
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Ok , looking at another reply from Jim
> (http://gcc.gnu.org/ml/gcc/2008-04/msg00311.html), where he suggests
> to use shorten_branhes in reorg and generate indirect branch, it looks
> like i will have to reserve a register. Am i right?
You will ha
Hi!
The following "program" can be compiled without problems.
extern void something(char *s);
char msg[] = "123456";
int main(int argc, char **argv)
{
something(msg);
return 0;
}
But I can't compile it correctly with my backend. The content of msg
is not emitted; there is only the label
On Wednesday 16 April 2008 16:23, Daniel Jacobowitz wrote:
> On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
> > --bindir=/usr/bin \
>
> > bindir=$STATIC/bin \
>
> Why are you configuring for one set of paths which are half in $STATIC
> a
On Mon, Apr 14, 2008 at 11:07 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>
> > I have read in the internals that indirect_jump and jump pattern are
> > necessary in any back-end for the compiler to be build and work
> > successfully. For any b
On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
> --bindir=/usr/bin \
> bindir=$STATIC/bin \
Why are you configuring for one set of paths which are half in $STATIC
and half in /usr, and installing in paths which are all in $STATIC?
That'
Hello.
I'm student in master, and I'm at this time in a internship named
"Parallelization on Cell processor".
We are interested in porting libgomp an cell processor.
Like you maybe know, cell proc uses two different compiler, spu-gcc and
ppu-gcc.
Both are 4.1.1 version of gcc, which doesn't s
On Tue, Apr 15, 2008 at 11:27 AM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
>
> On Mon, Apr 14, 2008 at 11:44 PM, Jim Wilson <[EMAIL PROTECTED]> wrote:
> >
> > Mohamed Shafi wrote:
> >
> > > For a function call will i be able to implement long call/short call
> > > for the same function at diff
Hi,
> I'm trying to add a simple function to the callgraph using
> cgraph_add_new_function() ( new function body is obtained by function
> actually processed) .
> I put my pass in pass_tree_loop.sub as first pass just after
> pass_tree_loop_init pass, but I have some problems because the code
> th
Hi all,
I am trying to port GCC to a new DSP architecture (hopefully will be
made public soon) and I am having a little bit of difficulty in making
GCC to generate code. The reason is that our DSP architecture has
non-orthogonal and segmented (disjoint) address register files (e.g.
A, B and D). A
> Yes. Any help?
This doesn't make any sense to me. I would put a breakpoint on the few lines
that update pbi->reg_live in flow.c and see why one of them triggers.
--
Eric Botcazou
Yes. Any help?
On Wed, Apr 16, 2008 at 7:20 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > Start from the bb's live out and calculate each insn's live in&out.
> > Where the first insn's live in must be the bb's live in, but the
> > assertion failed.
>
> So you're dumping pbi->reg_live after the
> Start from the bb's live out and calculate each insn's live in&out.
> Where the first insn's live in must be the bb's live in, but the
> assertion failed.
So you're dumping pbi->reg_live after the call to propagate_one_insn as "insn
live in", right?
--
Eric Botcazou
Sorry for misleading. Here, before propagation, the first fprintf
dumps the last insn's live in ( which is also the current insn's live
out in bb, and dumped by the second fprintf before propagation )
What I do is:
Start from the bb's live out and calculate each insn's live in&out.
Where the first
> I don't want to update insn_live_in, I just want to get each insn's
> live in and live out, so I start from the end of basic block and
> propagate backward.
But how can the output of
fprintf(file, "before propagate, insn live in:\n");
debug_bitmap_file (file, insn_live_in);
and
I don't want to update insn_live_in, I just want to get each insn's
live in and live out, so I start from the end of basic block and
propagate backward.
I also make an assertion that when current insn meets block's first
insn this backward calculate the same result as block's live in.
More simple
> Yes, I'm talking about propagate one insn in flow.c. How I map live in
> and live out, please see the code below.
Thanks, but AFAICS this code doesn't update insn_live_in at all.
--
Eric Botcazou
> Yes, I'm talking about propagate one insn in flow.c. How I map live in
> and live out, please see the code below.
Thanks, but AFAICS this code doesn't update insn_live_in at all.
--
Eric Botcazou
-- Forwarded message --
From: 袁立威 <[EMAIL PROTECTED]>
Date: Wed, Apr 16, 2008 at 6:03 PM
Subject: Re: A live analysis problem on gcc4.2.3
To: Eric Botcazou <[EMAIL PROTECTED]>
Yes, I'm talking about propagate one insn in flow.c. How I map live in
and live out, please see the code
Hi,
I'm trying to add a simple function to the callgraph using
cgraph_add_new_function() ( new function body is obtained by function
actually processed) .
I put my pass in pass_tree_loop.sub as first pass just after
pass_tree_loop_init pass, but I have some problems because the code
that I put into
> I use propagate_one_insn to get the current insn's live in. But it
> seems wrong when propagate.
> Before propagate one insn, there is no reg111 in live out and current
> insn def the reg111, how can reg111
>
> appear in live in after propagate???
>
> My flag to propagate is:
> flags = PROP_DEA
I use propagate_one_insn to get the current insn's live in. But it
seems wrong when propagate.
Before propagate one insn, there is no reg111 in live out and current
insn def the reg111, how can reg111
appear in live in after propagate???
My flag to propagate is:
flags = PROP_DEATH_NOTES;
flag
Ian Lance Taylor wrote:
"John Maddock" <[EMAIL PROTECTED]> writes:
The crux of the issue is this: if gcc/g++ is configured with the
pthread threading model, then are object files always binary
compatible irrespective of whether they are compiled with the
-pthread command line option or not?
Hello,
At least in GCC 4.2.1, it prints out "restrict" in gimple format so that
I can track how restrict is passed along optimizations. But it
disapprears in GCC 4.3.0
tst.c.004t.gimple produced by GCC 4.3.0
tst2 (a, b, c)
{
unsigned int i.0;
unsigned int D.1591;
V2W * D.1592;
V2W * D.15
Jan,
The second patch worked (now building libgfortran).
Thanks
Dominique
45 matches
Mail list logo
