headers
Dong Phuong | 1 Dec 2008 08:14
Picon
Favicon

Re: How to control code segments ?


"Linker relaxation" is maybe what I'm looking for. 

But I've searched it on google , but there are few
doccuments about it, now I haven't imagined yet how to
implement Linker Relaxation. 

Could you tell me some of doccuments about it and
where in the binutils that it was implemented ? 

--- Alan Lehotsky <qsmgmt <at> earthlink.net> wrote:

> Look at the implementation of the IP2K compiler and
> linker.
> It uses a segmented paged architecture just like the
> machine you are  
> describing.
> 
> In essence what we did was implement linker
> relaxation to deal with  
> this.
> When we called any function, we emitted the
> appropriate long-call by  
> setting
> the page register and jumping to the location on
> that page.
> 
> In the linker, we implemented relaxation code that
> looked to see if
> we were changing to the SAME page, and if so deleted
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Botcazou | 1 Dec 2008 11:50
Favicon

Re: CSE bug when narrowing constants

> cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC,
> and is the routine that writes the REG_EQUAL note.

OK, thanks.  But I'm a little at a loss as to why this problem arises only
now: the problematic code in lookup_as_function is one decade old.  Do you 
happen to have older compilers around (say GCC 4.1.x based) that correctly 
compile the testcase?  If so, what happens differently with them?

--

-- 
Eric Botcazou
Permalink | Reply | 3 comments |
headers
Graham Stott | 1 Dec 2008 12:15

Re: CSE bug when narrowing constants

All,

One thing that may or may not be related is that the current main
fails to bootstrap on x86_64 with fold checking enabled. 

It aborts due to a fold-checking failure (i.e fold has modified 
it's inputs) using the stage1 compiler. I don't recall exactly which 
file it triggers on (I think it was one of the host-ieee*.c files
in libdecnumber library). 

The last bootstrap I did was about 8 weeks ago and that passed with
all checking enabled so its a *recent* regression.

I'll look into the cause this evening.

Cheers
Graham     

--- On Mon, 1/12/08, Eric Botcazou <ebotcazou <at> adacore.com> wrote:

> From: Eric Botcazou <ebotcazou <at> adacore.com>
> Subject: Re: CSE bug when narrowing constants
> To: "Gary Funck" <gary <at> intrepid.com>
> Cc: gcc <at> gcc.gnu.org
> Date: Monday, 1 December, 2008, 10:50 AM
> > cse_insn() calls lookup_as_function() ultimately
> through fold_rtx(), IIRC,
> > and is the routine that writes the REG_EQUAL note.
> 
> OK, thanks.  But I'm a little at a loss as to why this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Angela.Intermite | 1 Dec 2008 13:40
Picon

g77 correct version


Dear all,

I would like to install a g77 on my version of Linux that is Scientific
Linux SL-52-062608-i386.
I tried to install 3 packages of g77 but I don't know what is the package
suitable for me and my Linux version.
Could you be so kind to indicate me the correct link for downloading g77
package? And also I would like to know if I should install g77 as a root
or as a simple user.
Thank you very much.

Angela Intermite

--

-- 
Angela Intermite
c/o Max Planck Institut fuer Kerphysik
Saupfercheckweg 1
69117 Heidelberg
Germany
Permalink | Reply | 1 comment |
headers
Cheng bin | 1 Dec 2008 14:42
Picon

About the procedure of fixinclude in building gcc

Hi All:
     Now I am working on the procedure of fixinclude in building gcc
and got following concepts.
Take three PATH as example to illustrate,
     ginclude    : which provided by gcc source includes system
headers wanted by gcc;
     sys_inc     : the location of system header files;
     local         : the locattion for system headers fixed by gcc;

When building gcc, there are two steps to finish the job of fixing headers:
STEP1:    fixinc.sh will fix system headers in PATH: sys_inc and put
fixed ones into
               PATH:local ;
STEP2:    gcc(actually is building makefiles) will copy all files from
PATH:ginclude to
               PATH:local. In this step, it will copy anything into
PATH:local even if there
               is one as the result of STEP1.

After all, gcc will search system headers in PATH:local firstly and
then in PATH:sys_inc.

I'am not sure about my comprehension, am I right?

And there is a question about ./fixincludes/Makefile.
I think the gcc's top level Makefile will configure fixincludes and
create that Makefile,
and then will do such "make ./fixincludes/Makefile" thing, But I found
following rules in
./fixincludes/Makefile:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack Howarth | 1 Dec 2008 14:59
Picon

pruning in gcc/testsuite/lib/gcc.exp

Doug,
   Is there a reason why prune.exp is loaded in lib/gcc.exp and lib/g++.exp
but never actually used? I need to prune a linker warning with..

regsub -all "(^|\n)ld: warning: can't make compact unwind encoding from dwarf for \[^\n\]* in \[^\n\]*"
$text "" text

on x86_64-apple-darwin10 to suppress false failures in dg-struct-layout-1
for gcc.dg and g++.dg. Elsewhere in the testsuite, I can suppress these
warnings easily by placing that line in lib/prune.exp. However it is
unclear how I should code this pruning into lib/g++.exp and lib/gcc.exp
so that the dg-struct-layout-1 false excessive error failures are
suppressed. Any advice would be appreciated.
                   Jack
Permalink | Reply | 1 comment |
headers
Steve Kargl | 1 Dec 2008 15:48
Picon

Re: optimization removes a __builtin_memcpy?

On Sun, Nov 30, 2008 at 10:18:22PM +0100, Richard Guenther wrote:
> On Sun, Nov 30, 2008 at 5:28 AM, Steve Kargl
> <sgk <at> troutmask.apl.washington.edu> wrote:
> >
> >     ERRMSG.12 = &"Attempt to deallocate an unallocated object"[1]{lb: 1 sz: 1};
> > -    ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) &err, (void *) ERRMSG.12, 30) : (void) 0;
> > +    ERRMSG.12 = stat.11 != 0 ? err = *(character(kind=1)[1:30] * {ref-all}) ERRMSG.12 : (void) 0;
> 
> Btw, you assign "void" to ERRMSG.12 - this is certainly invalid GENERIC and not
> what you want to do, right?
> 

I have a working patch.  Don't know if it's completely correct;
however, there are no regressions.  The key appeared to be that
I needed to build a pointer to err instead on passing err itself.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Dave Hudson | 1 Dec 2008 15:50

Re: How to control code segments ?

Alan Lehotsky wrote:
> Look at the implementation of the IP2K compiler and linker.
> It uses a segmented paged architecture just like the machine you are 
> describing.
> 
> In essence what we did was implement linker relaxation to deal with this.
> When we called any function, we emitted the appropriate long-call by 
> setting
> the page register and jumping to the location on that page.
> 
> In the linker, we implemented relaxation code that looked to see if
> we were changing to the SAME page, and if so deleted the instruction 
> changing
> the PAGE and did a local jump to the destination.  Now, because a 
> function could cross a page
> boundary (we only had 4kb pages (and 16 bit instructions), all our 
> branches were done this way
> (if I recall correctly).

Yes, every call and branch was emitted in its long form and then relaxed 
back down to the shorter form wherever it was possible.  A later version 
that we had in-house did an even longer sequence that allowed us to 
bounce through an emulator to utilize the holes that the architecture 
allowed but that weren't physically present on the chip and we'd relax 
to either a page-crossing operation or a in-page operation.

Regards,
Dave
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gary Funck | 1 Dec 2008 18:28

Re: CSE bug when narrowing constants

On 12/01/08 11:50:48, Eric Botcazou wrote:
> > cse_insn() calls lookup_as_function() ultimately through fold_rtx(), IIRC,
> > and is the routine that writes the REG_EQUAL note.
> 
> OK, thanks.  But I'm a little at a loss as to why this problem arises only
> now: the problematic code in lookup_as_function is one decade old.  Do you 
> happen to have older compilers around (say GCC 4.1.x based) that correctly 
> compile the testcase?  If so, what happens differently with them?

Yeah, I was surprised as well.  The compiler base line
this problem arose on is 4.2.3, but I think that it will
occur in both older and newer base lines.  The problem is
triggered by code generated by the UPC (Unified Parllel C)
support that we've implemented in a project we call GCC/UPC.
It fails on a small UPC test case, but a number
of factors have to be present to trigger the problem.
I tried developing a vanilla C test case to duplicate the
problem, but have so far been unsuccessful.

Internally, we use VIEW_CONVERT_EXPR to overlay a TImode
container on top of a struct.  There is no exact C
equivalent, though a union comes close.  I tried that,
but couldn't replicate the exact set of events that have
to be present to hit the problem. I send what I tried
to you separately.  Perhaps adding some
sort of logging in lookup_as_function() that indicates
narrowing is occurring, and then running all test cases
(including Ada, because its unchecked_conversion is close
to what we're doing internally) would turn something up?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shaun Jackman | 1 Dec 2008 18:49
Picon
Gravatar

Re: "R_ARM_GOTOFF32" problem on uClinux

2008/12/1 K.J. Kuan-Jau Lin(林寬釗) <kjlin <at> faraday-tech.com>:
> Hi Shaun,
>
> I have trouble in uClinux world.
> After long and painful debugging, i found it is due to the "R_ARM_GOTOFF32"
> relocation type.
> By google, i found you got the same problem before.
> (http://mailman.uclinux.org/pipermail/uclinux-dev/2006-June/039089.html).
> I knew you have tried the gcc-4.0.x & gcc-4.1.x toolchains.
> My toolchian is gcc-4.2.4 and seems still have the same problem.
> Besides changing to gcc-4.0.x, did you have any workaround solutions?
> Any hints will be very appreciated.

Hi KJ,

I never did find a solution. Only two cases in particular bit me:

* strings constants
* addresses of static functions passed as arguments

The first I worked around by placing strings constants in the
read-write memory (RODATA after the GOT) rather than the read-only
memory (RODATA after TEXT), although this does use RAM unnecessarily.
I never did fix the second issue.

A possible quick hack, although not a solution, would be to find
wherever GCC decides to emit a GOTOFF32 relocation and use a GOT32
relocation instead.

This issue has a bug report in bugzilla:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane