Re: Bootstrap failure on i686-apple-darwin9
Jan, The second patch worked (now building libgfortran). Thanks Dominique
RE: Where is restrict keyword used in dependence analysis?
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.1593;
vector int D.1594;
V2W * D.1595;
vector int D.1596;
vector int D.1597;
int i;
i = 0;
goto ;
:;
i.0 = (unsigned int) i;
D.1591 = i.0 * 8;
D.1592 = c + D.1591;
i.0 = (unsigned int) i;
D.1591 = i.0 * 8;
D.1593 = a + D.1591;
D.1594 = *D.1593;
i.0 = (unsigned int) i;
D.1591 = i.0 * 8;
D.1595 = b + D.1591;
D.1596 = *D.1595;
D.1597 = D.1594 + D.1596;
*D.1592 = D.1597;
i = i + 1;
:;
if (i <= 255)
{
goto ;
}
else
{
goto ;
}
:;
}
tst.c.004t.gimple produced by GCC 4.2.1
tst2 (a, b, c)
{
unsigned int i.0;
unsigned int D.1891;
V2W * D.1892;
V2W * D.1893;
V2W * D.1894;
vector int D.1895;
V2W * D.1896;
vector int D.1897;
vector int D.1898;
int i;
i = 0;
goto ;
:;
i.0 = (unsigned int) i;
D.1891 = i.0 * 8;
D.1892 = (V2W * restrict) D.1891;
D.1893 = D.1892 + c;
i.0 = (unsigned int) i;
D.1891 = i.0 * 8;
D.1892 = (V2W * restrict) D.1891;
D.1894 = D.1892 + a;
D.1895 = *D.1894;
i.0 = (unsigned int) i;
D.1891 = i.0 * 8;
D.1892 = (V2W * restrict) D.1891;
D.1896 = D.1892 + b;
D.1897 = *D.1896;
D.1898 = D.1895 + D.1897;
*D.1893 = D.1898;
i = i + 1;
:;
if (i <= 255)
{
goto ;
}
else
{
goto ;
}
:;
}
> At the RTL level, restrict ends up being transformed into a different
alias set.
Could you elaborate a little bit more? Which function/structure should I
look at? I tried to grep restrict/alias/.., no much clue. Thanks.
Bingfeng Mei
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Daniel Berlin
Sent: 15 April 2008 18:03
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: Where is restrict keyword used in dependence analysis?
On Tue, Apr 15, 2008 at 12:01 PM, Bingfeng Mei <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> I am porting to GCC 4.3.0 for our VLIW processor, and try to utilize
> improved restrict keyword support. Somehow, I find for normal data
> types, including vector types up to 8bytes, the restrict keyword
works
> just fine. But for wider vector, such as 4 32-bit word type, the
> restrict keyword doesn't work any more. For example, for the first
two
> following functions, compiler can unroll (-funroll-all-loops) loops
and
> produces good schedule, where load instructions of next iteration can
be
> moved beyond store instruction of this iteration. But for the third
> example, it is different. As suggested in .sched2 file, the compiler
can
> only resolve dependence of next load instructions after store
> instruction of this iteration is scheduled. I tried to print out
> tree-ssa files by using -fdump-tree-all. Unliked previous GCC
(4.2.1),
> the information in those files is not helpful at all.
How not?
If we don't know, we can't fix them :)
> I don't know
> where to look at now. Could someone point me some
files/functions/data
> structures by which restrict keyword is used and passed to dependence
> anaylsis part? Thanks in advance.
You mean the dependence analysis used by the scheduler?
That stuff is in sched-deps.c
At the RTL level, restrict ends up being transformed into a different
alias set.
At the tree level, restrict info is not used very much right now.
> Example code:
>
> typedef intV4W __attribute__ ((vector_size (16)));
> typedef intV2W __attribute__ ((vector_size (8)));
>
> void tst(int * restrict a, int * restrict b, int * restrict c)
> {
> int i;
> for(i = 0; i < 256; i++){
> c[i] = a[i] + b[i];
> }
> }
>
> void tst2(int * restrict a, int * restrict b, int * restrict c)
> {
> int i;
> for(i = 0; i < 256; i++){
> c[i] = a[i] + b[i];
> }
> }
>
> void tst3(V4W * restrict a, V4W * restrict b, V4W * restrict c)
> {
> int i;
> for(i = 0; i < 256; i++){
> c[i] = a[i] + b[i];
> }
> }
>
>
>
Re: -pthread switch and binary compatibitity
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? Yes, modulo the #define of _REENTRANT. If the answer is yes, then is it commonplace to link object files compiled with and without -pthread? Yes. In general, all the -pthread option does is turn on -D_REENTRANT during compilation and -lpthread during linking. There is some cross-platform variation--different -D and -l options--but in no case does -pthread lead to a different ABI. OK thanks, that sounds pretty definitive :-) John.
A live analysis problem on gcc4.2.3
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;
flags &= ~(PROP_SCAN_DEAD_CODE | PROP_SCAN_DEAD_STORES
| PROP_KILL_DEAD_CODE);
This is the dump:
current insn:
(insn/f 43 42 44 2 (set (reg/f:DI 111 r35)
(reg/f:DI 12 r12)) -1 (nil)
(nil))
before propagate, insn live in:
first = 0x6011b0b0 current = 0x6011b0b0 indx = 0
0x6011b0b0 next = 0x6011b0d8 prev = (nil) indx = 0
bits = { 0 1 12 }
0x6011b0d8 next = (nil) prev = 0x6011b0b0 indx = 2
bits = { 320 328 }
before propagate, insn live out:
first = 0x6011b000 current = 0x6011b000 indx = 0
0x6011b000 next = 0x6011b028 prev = (nil) indx = 0
bits = { 0 1 12 }
0x6011b028 next = (nil) prev = 0x6011b000 indx = 2
bits = { 320 328 }
after propagate, insn live in:
first = 0x6011b0b0 current = 0x6011b0b0 indx = 0
0x6011b0b0 next = 0x6011b0d8 prev = (nil) indx = 0
bits = { 0 1 12 111 }
0x6011b0d8 next = (nil) prev = 0x6011b0b0 indx = 2
bits = { 320 328 }
after propagate, insn live out:
first = 0x6011b000 current = 0x6011b000 indx = 0
0x6011b000 next = 0x6011b028 prev = (nil) indx = 0
bits = { 0 1 12 }
0x6011b028 next = (nil) prev = 0x6011b000 indx = 2
bits = { 320 328 }
Re: A live analysis problem on gcc4.2.3
> 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; > flags &= ~(PROP_SCAN_DEAD_CODE | PROP_SCAN_DEAD_STORES > >| PROP_KILL_DEAD_CODE); > > This is the dump: > > current insn: > (insn/f 43 42 44 2 (set (reg/f:DI 111 r35) > (reg/f:DI 12 r12)) -1 (nil) > (nil)) Are you talking about flow.c:propagate_one_insn? If so, how do you map "live in" and "live out" exactly, given that flow.c doesn't use these but operates on a struct propagate_block_info instead? -- Eric Botcazou
Out of ssa form only for some basic block
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 the new function ( using move_sese_region_to_fn() ) is already in ssa form. Unfortunately I have to use gcc version 4.2.2 and so I think that the only solution is to put the code out of the ssa form. Could someone point me to the right direction? What am I doing wrong? Regards, Mario Fanelli
Re: A live analysis problem on gcc4.2.3
> 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
Re: A live analysis problem on gcc4.2.3
> 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
Re: A live analysis problem on gcc4.2.3
-- 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 below.
I'm sorry that I don't quite understand what do you mean by "given
that flow.c doesn't use these but operates on a struct
propagate_block_info instead?"
FOR_EACH_BB (cur_bb)
{
bb_live_in = cur_bb->il.rtl->global_live_at_start;
bb_live_out = cur_bb->il.rtl->global_live_at_end;
bitmap_copy (insn_live_out, bb_live_out);
bitmap_copy (insn_live_in, insn_live_out);
pbi = init_propagate_block_info (cur_bb, insn_live_in, NULL, NULL, flags);
for (insn = BB_END (cur_bb); ; insn = prev)
{
fprintf(file, "current insn:\n");
print_rtl_single(file, insn);
fprintf(file, "before propagate, insn live in:\n");
debug_bitmap_file (file, insn_live_in);
fprintf(file, "before propagate, insn live out:\n");
debug_bitmap_file (file, insn_live_out);
prev = propagate_one_insn (pbi, insn);
assert ( pbi->reg_live==insn_live_in );
fprintf(file, "after propagate, insn live in:\n");
debug_bitmap_file (file, insn_live_in);
fprintf(file, "after propagate, insn live out:\n");
debug_bitmap_file (file, insn_live_out);
if (insn == BB_HEAD (cur_bb))
break;
bitmap_copy (insn_live_out, insn_live_in);
}
if (!bitmap_equal_p (insn_live_in, bb_live_in)){
fprintf(file, "Not equal!!\n");
fprintf(file, "insn live in:\n");
debug_bitmap_file(file, insn_live_in);
fprintf(file, "bb live in:\n");
debug_bitmap_file(file, bb_live_in);
assert(0);
}
free_propagate_block_info (pbi);
}
On Wed, Apr 16, 2008 at 5:32 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > 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;
> > flags &= ~(PROP_SCAN_DEAD_CODE | PROP_SCAN_DEAD_STORES
> >
> >| PROP_KILL_DEAD_CODE);
> >
> > This is the dump:
> >
> > current insn:
> > (insn/f 43 42 44 2 (set (reg/f:DI 111 r35)
> > (reg/f:DI 12 r12)) -1 (nil)
> > (nil))
>
> Are you talking about flow.c:propagate_one_insn? If so, how do you map
> "live in" and "live out" exactly, given that flow.c doesn't use these
> but operates on a struct propagate_block_info instead?
>
> --
> Eric Botcazou
>
Re: A live analysis problem on gcc4.2.3
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 to say is: I use basic block's last insn's live out to deduce this basic block's first insn's live in (which must be this block's live in). On Wed, Apr 16, 2008 at 6:27 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > 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 >
Re: A live analysis problem on gcc4.2.3
> 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 fprintf(file, "after propagate, insn live in:\n"); debug_bitmap_file (file, insn_live_in); be different if you don't update insn_live_in? You need to say what you're really dumping here. -- Eric Botcazou
Re: A live analysis problem on gcc4.2.3
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 insn's live in must be the bb's live in, but the assertion failed. Besides, this code won't get assertion failed on gcc4.1.1. On Wed, Apr 16, 2008 at 6:50 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > 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 > > fprintf(file, "after propagate, insn live in:\n"); > debug_bitmap_file (file, insn_live_in); > > be different if you don't update insn_live_in? You need to say what you're > really dumping here. > > -- > Eric Botcazou >
Re: A live analysis problem on gcc4.2.3
> 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
Re: A live analysis problem on gcc4.2.3
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 call to propagate_one_insn as "insn > live in", right? > > -- > Eric Botcazou >
Re: A live analysis problem on gcc4.2.3
> 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
Disjoint address register problem during GCC port
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). Also, all arithmetic operations access memory through
indirect addressing and have restrictions on which register files can
be used as which operand or destination. In addition, they support
offset addressing and post-increment and post-decrement modes.
For example, MULToperation have the restriction
that must be a register from REG_D. The operand must be a
register from REG_A and operand from REG_B and vice-versa.
I have defined three register classes (REG_D={d0, ..., d3}, REG_A,
REG_B), set up BASE_REGISTER_CLASS appropriately to make GCC generate
the code of the following form:
MULT [d0], [a0], [b0] // d[i] = a[i] * b[i]
However, I am having problems for GCC to generate the code of the
following form:
MULT [d0], [a0+1], [b0+2] // d[i] = a[i+1] * b[i+2]
I am using EXTRA_CONSTRAINT to segregate address registers according
to the address classes.
#define EXTRA_CONSTRAINT(OP, C) \
( (C) == 'Q' ? pica_A_constraint(op,c) \
: (C) == 'R' ? pica_B_constraint(op,c) \
: (C) == 'S' ? pica_D_constraint(op,c) \
: 0)
I have also defined EXTRA_MEMORY_CONSTRAINT appropriately. However, I
keep on getting "error: impossible constraint in 'asm'" error. Any
help on this aspect of GCC would be very much appreciated.
On this issue, I also would like to ask:
(a) Is it possible to have segmented (disjoint) address classes in GCC?
(b) I am using GCC 4.0.2 and I noticed that in the gcc version 4.3.0
has EXTRA_CONSTRAINT is marked as obsolete. Should I use
EXTRA_CONSTRAINT or should I use some other way of specifying an
address register class?
Regards,
Manish
PS: Thanks Andrew for directing me to the right mailing list.
-
Manish Verma
Altera European Technology Centre,
High Wycombe, UK
Re: Out of ssa form only for some basic block
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 the new function ( using move_sese_region_to_fn() ) is > already in ssa form. > Unfortunately I have to use gcc version 4.2.2 and so I think that the > only solution is to put the code out of the ssa form. if at all possible, try to use the mainline for new development (it will usually make your life much easier, and it will also make it possible to contribute any bugfixes/improvements you may make during your project, whatever it is). That being said, if for whatever reason you cannot affect this decision, have a look at parloop branch (tree-outof-ssa.c:go_out_of_ssa and its users) -- the early version of loop parallelization had to solve the same problem, Zdenek
Re: A query regarding the implementation of pragmas
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 different locations?
> > > Say fun1 calls bar and fun2 calls bar. I want short-call to be
> > > generated for bar in fun1 and long-call to be generated in fun2.
> > > Is to possible to implement this in the back-end using pragmas?
> > >
> >
> > A simple grep command shows that both arm and rs6000 already both support
> > long call pragmas.
> >
>
Using Pragmas will i be able to do something like this
int main (void)
{
short sh;
# pragma longcall
sh = fun3();
# pragma shortcall
sh = fun3();
return 0;
}
Regards,
Shafi.
Gomp cell,...
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 support OpenMP of course. Current gcc version can be compiled on Cell (like cell is a kind of ppc). But It cannot replace the spu version of gcc. I'm thinking about extract some part of the GIMPLE tree from a gcc for ppc and give this part of tree as an entry for the spu-gcc. Then my question is: Does the tree contain all informations for compiling? Ogier Maitre
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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's causing this:
> 30816
> stat64("/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1",
> 0xffde613c) = -1 ENOENT (No such file or directory)
At this point it's clear something is wrong. The libexec directory is
not in the same relation to bindir that it was at configure time.
You've moved parts of the toolchain pretty much arbitrarily, so it's
not surprising at all to me that it can't find itself...
--
Daniel Jacobowitz
CodeSourcery
Re: A Query regarding jump pattern
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 back-end there will be some limitation as to how > > big the offset used in the jump instructions can be. If the offset is > > too big then the indirect_jump pattern has to utilized. Now my > > question is how will i be able to specify the limit of the offset so > > the gcc generates indirect_jump pattern instead of the jump pattern? I > > hope i am clear. > > From the perspective of insn names, it's not quite accurate to say > that jump turns into indirect_jump. It would be more correct to say > that when there is a limit to the offset for jump, it needs to use a > register. > > The way to handle this is to set the "length" attribute correctly for > each insn, and to change code generation based on the length. See, > e.g., the mips.md "jump" insn for an example. > 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? If that is the case it seems that there is no need for a indirect_jump pattern. So can you tell me when exactly are the indirect_jump patterns will be utilized by gcc? Regards, Shafi
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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
> and half in /usr, and installing in paths which are all in $STATIC?
Because I install gcc into /usr/app/gcc-N.N.N-target/{bin,lib,whatever}
and then I create links for every binary in bin/*
/usr/bin/foo -> /usr/app/gcc-N.N.N-target/foo
Same for lib/* etc.
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/something.
I found that usually giving bindir=/usr/bin to configure
but giving bindir=/usr/app/bar/bin to "make install" will do the trick.
> That's causing this:
>
> > 30816
> > stat64("/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1",
> > 0xffde613c) = -1 ENOENT (No such file or directory)
>
> At this point it's clear something is wrong. The libexec directory is
> not in the same relation to bindir that it was at configure time.
Yes, I see... I will try giving bindir=/usr/app/gcc-N.N.N-target/bin
to configure. Will let you know if it still doesn't work.
> You've moved parts of the toolchain pretty much arbitrarily, so it's
> not surprising at all to me that it can't find itself...
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.
(Actually it's my biggest gripe about the way Linux packages
are built: generally you can't move them
and expect them to work).
--
vda
String content not emitted
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. It will be emitted when it
the size is at least 8 characters.
I assume the problem is that I set BITS_PER_UNIT to 1 and that there
is some size computation that depends on BITS_PER_UNIT >= 8. Is that
possible? How can I fix that?
Thanks,
Boris
Re: A Query regarding jump pattern
"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 have to do something. Having the jump pattern require a scratch register is one approach. For a much more complicated approach, see sh.md. > If that is the case it seems that there is no need for a indirect_jump > pattern. > So can you tell me when exactly are the indirect_jump patterns will be > utilized by gcc? indirect_jump jumps to a value held in a register. jump jumps to a constant location. indirect_jump is used for things like the gcc &&label extension. Ian
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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
is for. So if you don't try to work around the lack of a feature
which is in fact present, everything will just work :-)
It's configured to live in /usr/bin. So from there it searches
../app*/lib/gcc/wherever to find cc1. When it discovers that you ran
it from /usr/app*/bin instead (by following the symlink to the real
binary), it searches /usr/app*/bin/../app*/lib/gcc/wherever. But
cc1's not there.
--
Daniel Jacobowitz
CodeSourcery
Re: Gomp cell,...
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 two different compiler, spu-gcc and ppu-gcc. Both are 4.1.1 version of gcc, which doesn't support OpenMP of course. Current gcc version can be compiled on Cell (like cell is a kind of ppc). But It cannot replace the spu version of gcc. Huh??? Spu support is in gcc 4.3.0. I'm thinking about extract some part of the GIMPLE tree from a gcc for ppc and give this part of tree as an entry for the spu-gcc. Then my question is: Does the tree contain all informations for compiling? Ogier Maitre
Re: String content not emitted
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
> not emitted; there is only the label. It will be emitted when it the
> size is at least 8 characters.
>
> I assume the problem is that I set BITS_PER_UNIT to 1 and that there is
> some size computation that depends on BITS_PER_UNIT >= 8. Is that
> possible? How can I fix that?
C requires BITS_PER_UNIT to be at least 8. char must always be large
enough to hold a character, and sizeof (char) == 1.
Andrew.
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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.
>
> It already does. That's exactly what the code causing you a problem
> is for. So if you don't try to work around the lack of a feature
> which is in fact present, everything will just work :-)
>
> It's configured to live in /usr/bin. So from there it searches
> ../app*/lib/gcc/wherever to find cc1. When it discovers that you ran
> it from /usr/app*/bin instead (by following the symlink to the real
> binary), it searches /usr/app*/bin/../app*/lib/gcc/wherever. But
> cc1's not there.
Cool! Giving it a try...
Meanwhile: I decided to get rid of paths in as/ld invocations
by specifying as/ld names without any paths:
--with-gnu-ld \
--with-ld="$CROSS-ld" \
--with-gnu-as \
--with-as="$CROSS-as" \
and it works, I only need to patch configure to not "test x $with_ld"
as that won't work.
I tested in and it works.
The patch is below. Do you think it makes sense?
--
vda
--- gcc-4.2.3.org/gcc/configure Sun Sep 23 23:08:04 2007
+++ gcc-4.2.3/gcc/configure Tue Apr 15 07:35:57 2008
@@ -1751,11 +1751,7 @@
DEFAULT_LINKER="$with_ld"
fi;
if test x"${DEFAULT_LINKER+set}" = x"set"; then
- if test ! -x "$DEFAULT_LINKER"; then
-{ { echo "$as_me:$LINENO: error: cannot execute: $DEFAULT_LINKER: check --with-ld or env. var. DEFAULT_LINKER" >&5
-echo "$as_me: error: cannot execute: $DEFAULT_LINKER: check --with-ld or env. var. DEFAULT_LINKER" >&2;}
- { (exit 1); exit 1; }; }
- elif $DEFAULT_LINKER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
+ if $DEFAULT_LINKER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
gnu_ld_flag=yes
fi
@@ -1811,11 +1807,7 @@
DEFAULT_ASSEMBLER="$with_as"
fi;
if test x"${DEFAULT_ASSEMBLER+set}" = x"set"; then
- if test ! -x "$DEFAULT_ASSEMBLER"; then
-{ { echo "$as_me:$LINENO: error: cannot execute: $DEFAULT_ASSEMBLER: check --with-as or env. var. DEFAULT_ASSEMBLER" >&5
-echo "$as_me: error: cannot execute: $DEFAULT_ASSEMBLER: check --with-as or env. var. DEFAULT_ASSEMBLER" >&2;}
- { (exit 1); exit 1; }; }
- elif $DEFAULT_ASSEMBLER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
+ if $DEFAULT_ASSEMBLER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
gas_flag=yes
fi
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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/something.
>
> I found that usually giving bindir=/usr/bin to configure
> but giving bindir=/usr/app/bar/bin to "make install" will do the trick.
>
> > That's causing this:
> >
> > > 30816
> > > stat64("/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1",
> > > 0xffde613c) = -1 ENOENT (No such file or directory)
> >
> > At this point it's clear something is wrong. The libexec directory is
> > not in the same relation to bindir that it was at configure time.
>
> Yes, I see... I will try giving bindir=/usr/app/gcc-N.N.N-target/bin
> to configure. Will let you know if it still doesn't work.
Builds ok and can find cc1 now. Well, it still does "xxx/../xxx stuff but at
least
end result is ok:
21396
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../libexec/gcc/x86_64-linux-uclibc/4.3.0/cc1",
{st_mode=S_IFREG|0755, st_s
ize=6008611, ...}) = 0
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:
strace -f -o zstrace.log \
x86_64-linux-uclibc-gcc -Wp,-MD,applets/.applets.o.d -std=gnu99 -Iinclude
-Ilibbb -I/.1/usr/srcdevel/bbox/fix/busybox.t8_64prime/libbb -include
include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.11.0.svn)"
-DBB_BT=AUTOCONF_TIMESTAMP -Wall -Wshadow -Wwrite-strings -Wundef
-Wstrict-prototypes -Wunused -Wunused-parameter -Werror -Wold-style-definition
-Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer
-ffunction-sections -fdata-sections -fno-guess-branch-probability
-funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1
-falign-labels=1 -falign-loops=1 -Wdeclaration-after-statement
-Wno-pointer-sign-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(applets)" -D"KBUILD_MODNAME=KBUILD_STR(applets)"
-c -o applets/applets.o applets/applets.c
4.2.1 was finding headers here:
21446 stat64("include/assert.h.gch", 0xff926550) = -1 ENOENT (No such file or
directory)
21446 open("include/assert.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or
directory)
21446 stat64("libbb/assert.h.gch", 0xff926550) = -1 ENOENT (No such file or
directory)
21446 open("libbb/assert.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or
directory)
21446
stat64("/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3/include/assert.h.gch",
0xff926550) =
21446
open("/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3/include/assert.h",
O_RDONLY|O_NOCTTY) =
21446 stat64("/usr/lib/../x86_64-linux-uclibc/include/assert.h.gch",
0xff926550) = -1 ENOENT (No such file or directory)
21446 open("/usr/lib/../x86_64-linux-uclibc/include/assert.h",
O_RDONLY|O_NOCTTY) = 5
but 4.3.0 doesn't:
21397 stat64("include/assert.h.gch", 0xffa710f0) = -1 ENOENT (No such file or
directory)
21397 open("include/assert.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or
directory)
21397 stat64("libbb/assert.h.gch", 0xffa710f0) = -1 ENOENT (No such file or
directory)
21397 open("libbb/assert.h", O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or
directory)
21397
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include/assert.h.gch",
0xffa710f0) =
21397
open("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include/assert.h",
O_RDONLY|O_NOCTTY) =
21397
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed/assert.h.gch",
0xffa710
21397
open("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed/assert.h",
O_RDONLY|O_NOC
21397 write(2, "applets/applets.c:10:20:", 24) = 24
21397 write(2, " ", 1) = 1
21397 write(2, "error: ", 7)= 7
21397 write(2, "assert.h: No such file or direct"..., 35) = 35
21397 write(2, "\n", 1) = 1
Basically, it used to look into /usr/lib/../x86_64-linux-uclibc,
but now it does not.
configure invocation was:
STATIC=/usr/app/gcc-4.3.0-x86_64-linux-uclibc
$SRC/configure \
--prefix=$STATIC\
--exec-prefix=$STATIC \
--bindir=$STATIC/bin\
--sbindir=$STATIC/sbin \
--libexecdir=$STATIC/libexec\
--datadir=$STATIC/share \
--sysconfdir=/etc \
--sharedstatedir=$STATIC/var/com\
--localstatedir=$STATIC/var \
--libdir=$STATIC/lib
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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 searching. 4.2.1 says: #include "..." search starts here: #include <...> search starts here: include libbb /.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3/include /usr/lib/../x86_64-linux-uclibc/include End of search list. 4.3.0 says: #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-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed End of search list. -- vda
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed > End of search list. Read the rest of it, to find the directories it skipped. I assume this is another problem of your mixed configure options. It's probably relocating the header search dir and you're leaving it unrelocated in your installation. -- Daniel Jacobowitz CodeSourcery
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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/x86_64-linux-uclibc/4.3.0/include > > > > /.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed > > End of search list. > > Read the rest of it, to find the directories it skipped. Here is that part too: ignoring nonexistent directory "/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64- linux-uclibc/sys-include" ignoring nonexistent directory "/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64- linux-uclibc/include" ignoring duplicate directory "/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/include " ignoring duplicate directory "/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/include -fixed" ignoring nonexistent directory "/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/../.. /../../x86_64-linux-uclibc/sys-include" ignoring nonexistent directory "/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/../../lib/gcc/x86_64-linux-uclibc/4.3.0/../.. /../../x86_64-linux-uclibc/include" ignoring duplicate directory "/.1/usr/srcdevel/bbox/fix/busybox.t8_64prime/libbb" #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-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/include-fixed End of search list. 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/include"... or maybe there is, in the form of: "xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include" (Is it necessary to do this "/../../../../" thing?) Anyway, by now I feel it can be much easier if configure had a parameter for updating default include path. > I assume this is another problem of your mixed configure options. > It's probably relocating the header search dir and you're leaving it > unrelocated in your installation. But now I don't have mixed configure options anymore, they all point to /usr/app/gcc-4.3.0-x86_64-linux-uclibc[/bin etc], as you suggested: configure invocation was: STATIC=/usr/app/gcc-4.3.0-x86_64-linux-uclibc $SRC/configure \ --prefix=$STATIC\ --exec-prefix=$STATIC \ --bindir=$STATIC/bin\ --sbindir=$STATIC/sbin \ --libexecdir=$STATIC/libexec\ --datadir=$STATIC/share \ --sysconfdir=/etc \ --sharedstatedir=$STATIC/var/com\ --localstatedir=$STATIC/var \ --libdir=$STATIC/lib\ --includedir=$STATIC/include\ --infodir=$STATIC/info \ --mandir=$STATIC/man\ \ --disable-nls \ \ --with-local-prefix=/usr/local \ --with-slibdir=$STATIC/lib \ --with-gxx-include-dir=$STATIC/include/g++-v3 \ \ --build=i386-pc-linux-gnu \ --host=i386-pc-linux-gnu\ --target=$CROSS \ \ --with-gnu-ld \ --with-ld="$CROSS-ld" \ --with-gnu-as \ --with-as="$CROSS-as" \ \ --enable-languages="c,c++" \ --enable-target-optspace\ --disable-shared\ --disable-__cxa_atexit \ --disable-threads \ --disable-tls \ --disable-multilib \ --without-headers \ make invocation was: make \ prefix=$STATIC \ exec-prefix=$STATIC \ bindir=$STATIC/bin \ sbindir=$STATIC/sbin\ libexecdir=$STATIC/libexec \ datadir=$STATIC/share \ sysconfdir=$STATIC/var/etc \ sharedstatedir=$STATIC/var/com \ localstatedir=$STATIC/var \ libdir=$STATIC/lib \ includedir=$STATIC/include \ infodir=$STATIC/info\ mandir=$
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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/include"... or maybe there is, in the form of: > "xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include" Correct. A relocated GCC 4.2.1 installation would still search various directories in their unrelocated paths. This was a bug and I'm sorry to hear that fixing it broke your setup. It could cause all sorts of problems when you have two versions of GCC installed. The documented (well, I think it is?) directory being searched here is $exec_prefix/$target/include. > (Is it necessary to do this "/../../../../" thing?) Yes, because that's how the directories are found. -- Daniel Jacobowitz CodeSourcery
gcc-4.2-20080416 is now available
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/gcc-4_2-branch revision 134368 You'll find: gcc-4.2-20080416.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080416.tar.bz2 C front end and core compiler gcc-ada-4.2-20080416.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080416.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080416.tar.bz2 C++ front end and runtime gcc-java-4.2-20080416.tar.bz2 Java front end and runtime gcc-objc-4.2-20080416.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080416.tar.bz2The GCC testsuite Diffs from 4.2-20080409 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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 does not do that anymore - there is no > > "/../x86_64-linux-uclibc/include"... or maybe there is, in the form of: > > "xxx/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include" > > Correct. A relocated GCC 4.2.1 installation would still search > various directories in their unrelocated paths. This was a bug and > I'm sorry to hear that fixing it broke your setup. It could cause all > sorts of problems when you have two versions of GCC installed. I believe I solved it with --with-sysroot, and then met yet another problem: 4.3.0 tried to link in different crtXXX.o files (those which do not exist on my system). Will try again and let you know. > The documented (well, I think it is?) directory being searched here is > $exec_prefix/$target/include. > > > (Is it necessary to do this "/../../../../" thing?) > > Yes, because that's how the directories are found. Well, it looks like the path like "xxx/bin/../lib/gcc/x86_64-linux-uclibc/4.3.0/../../../../x86_64-linux-uclibc/include" is equivalent to simply "xxx/x86_64-linux-uclibc/include", sans cases where one of those directories (which we go into only to go out again) does not exist. Hmm. Maybe symlinks may make it more complex. Oh well. -- vda
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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 ENOENT (No such file or
directory)
Why? You can just try execvp'ing (instead of access()),
and only if that fails, go try other variants...
23651
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../libexec/gcc/x86_
23651
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../libexec/gcc/as",
23651
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-l
23651
stat64("/.share/usr/app/gcc-4.3.0-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-l
23651 vfork() = 23653
23653 execve("/usr/bin/as", ["as", "-v", "-Iinclude", "-Ilibbb",
"-I/.1/usr/srcdev
and *this* as, being native one, makes 32-bit .o files. :(
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"...
--
vda
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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's not too far off. "readlink -m" would be closer if needed. Denys Vlasenko 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 specify this? Configure will automatically find and use $tooldir/bin/as (= $prefix/$target/bin/as) or $target-as in PATH. Brian
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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_64-linux-uclibc-ld: crtbegin.o: No such file: No such file or directory" problem. This is the final link command I use: x86_64-linux-uclibc-gcc -v -Wall -Wshadow -Wwrite-strings -Wundef \ -Wstrict-prototypes -Wunused -Wunused-parameter -Werror -Wold-style-definition \ -Os -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer \ -ffunction-sections -fdata-sections -fno-guess-branch-probability \ -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 \ -falign-labels=1 -falign-loops=1 -Wdeclaration-after-statement \ -Wno-pointer-sign -o busybox_unstripped -Wl,--sort-common -Wl,--gc-sections \ -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a \ console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a \ debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a \ libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a \ networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a \ printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a \ sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o \ archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o \ coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o \ editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o \ libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o \ modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o \ networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o \ runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o \ util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group \ -Wl,--start-group -lcrypt -lm -Wl,--end-group 4.2.3 works: Using built-in specs. Target: x86_64-linux-uclibc Configured with: ../gcc-4.2.3/configure --prefix=/usr/app/gcc-4.2.3-x86_64-linux-uclibc --exec-prefix=/usr/app/gcc-4.2.3-x86_64-linux-uclibc --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/libexec --datadir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/share --sysconfdir=/etc --sharedstatedir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/var/com --localstatedir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/var --libdir=/usr/lib --includedir=/usr/include --infodir=/usr/info --mandir=/usr/man --disable-nls --with-local-prefix=/usr/local --with-slibdir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/lib --with-gxx-include-dir=/usr/app/gcc-4.2.3-x86_64-linux-uclibc/include/g++-v3 --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=x86_64-linux-uclibc --with-gnu-ld --with-ld=x86_64-linux-uclibc-ld --with-gnu-as --with-as=x86_64-linux-uclibc-as --enable-languages=c,c++ --enable-target-optspace --disable-shared --disable-__cxa_atexit --disable-threads --disable-tls --disable-multilib --without-headers Thread model: single gcc version 4.2.3 /usr/app/gcc-4.2.3-x86_64-linux-uclibc/libexec/gcc/x86_64-linux-uclibc/4.2.3/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld64-uClibc.so.0 -o busybox_unstripped /usr/lib/../x86_64-linux-uclibc/lib/crt1.o /usr/lib/../x86_64-linux-uclibc/lib/crti.o /.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3/crtbegin.o -L/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc/x86_64-linux-uclibc/4.2.3 -L/.share/usr/app/gcc-4.2.3-x86_64-linux-uclibc/bin/../lib/gcc -L/usr/lib/../x86_64-linux-uclibc/lib --sort-common --gc-sections --start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o --end-group --start-group -lcrypt -lm --end-group -lgcc -lc -lgcc /.
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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 specify this?
I don't think that it is necessary. I find it useful.
It's useful in a following way:
if gcc will invoke as and ld by execvp("x86_64-linux-uclibc-as"...),
I can trivially fix all cases where it calls "wrong" as/ld
by either installing working one or changing the $PATH.
*I can do it without recompiling gcc or having to put as/ld in some
obscure multi-level directories* - this is what I like the most.
> Configure will
> automatically find and use $tooldir/bin/as (= $prefix/$target/bin/as) or
> $target-as in PATH.
Only in my case, $prefix contain neither as nor ld. gcc lives in
/usr/app/gcc-4.3.0-x86_64-linux-uclibc/*
while binutils lives in
/usr/app/binutils-2.18-x86_64-linux-uclibc/*
it's much better for sanity that way.
--
vda
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
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 argue that it's not, since simply using the same $prefix
JustWorks(tm) without worrying about modifying PATH or any --with-foo.
Brian
Re: A query regarding the implementation of pragmas
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 to > change the attribute of the same function at different points of > compilation. Configure and build an arm and/or rs6000 compiler, and then try it, and see what happens. In theory, it should work as you expect. Jim
Re: Getting host and target size and alignment information at build time?
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 more or less what I think I will do. I'm working > on a proof of concept at the moment. Here is the proof of concept for getting the type information out of the gcc back end. It was not as hard as I expected in the end. cob2.c: http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcb/cob2.c?revision=1.1&view=markup See get_build_types () and get_target_types () Called from script cob1.sh: http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcb/cob1.sh?revision=1.1 Used by type-info.lisp: http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcb/type-info.lisp?revision=1.1&view=markup See defun init-type-info Any comments or suggestions welcome. Thanks for your ideas Daniel. Tim Josling
Some questions about writing a front end
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 defunct treelang of similar vintage. I also translated and updated the "how to write a front end document", now sadly out of date http://cobolforgcc.sourceforge.net/cobol_14.html But that was all a while ago and a lot has happened. I read the GCC Summit papers and the GCC Wiki but a few questions remain and there are some things I'm not quite sure about. QUESTIONS 1. Sample front-end: Given treelang no longer exists and "is not a good example anyway" what would be the best front end to use as a model and to plagiarize code? I have found that the Ada front end, while large, is quite easy to follow and I've been using that. C/C++ seem to have the back end interface very enmeshed in the hand coded parsers. The Java front end is reasonably small (only handles class files?) but the back end (BE) interface is spread among 30 files. The fortran Front End (FE) has 58 files with BE interfaces. Objective C/++ are mostly just add-ons to C. What I don't know is how up-to-date the various front ends are and how good an example they are. 2. Most-Gimplified front-end: Allied to Q1, which front ends have been most thoroughly converted to GIMPLE? 3. LANG_HOOKS: There has been some discussion about LANG_HOOKS being removed in the future. From memory this was in the context of the "optimization in the linker (LTI)" projects. Is there a replacement I should use now, or is there anything I should do to prepare for the replacement? 4. What does Gimple cover: What is the scope of GIMPLE? Most of the discussion is about procedural code. Does it also cover variable definition, function prototype definition etc. 5. What is deprecated: Is there any time-effective way to identify constructs, header files, macros, variable and functions that are "deprecated". 6. Tuples: I am a bit confused about tuples. Tuples seem to be really just structs by another name, unless I have missed the point. The idea is not a bad one - I went through the same process in the Lisp code in the front end where initially I stored everything in arrays and later switched to structs/tuples. In lisp this provided the advantages of run-time type-checking and the ability to use mnemonic names. The first email about tuples that I can find seems to assume a reasonable amount of background on the part of the reader: http://www.mailinglistarchive.com/gcc@gcc.gnu.org/msg01669.html Some clarification about what the tuples project is trying to do, and in particular how I should position for the advent of tuples would be very useful. I have read the material in the Wiki and from the GCC summit. 7. Should I target GENERIC, High Gimple or Low Gimple? Would I miss optimizations if I went straight to a Gimple representation? Is one interface more likely to change radically in the future? The assumption here is that the front end will be using an entirely different representation so there is no question of using one of these in the Front End. It is just a question of which format to convert into. Thank you all for any help you can provide, Tim Josling
