Re: Which patch added R_ARM_GOTOFF32 support?

[Richard Earnshaw]

On Thu, 2006-06-29 at 03:47, Daniel Jacobowitz wrote:
> On Wed, Jun 28, 2006 at 03:54:29PM -0600, Shaun Jackman wrote:
> > On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > >On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
> > >> I'm not terribly familiar with the GCC source tree. I scanned
> > >> config/arm/arm.c and its SVN log for changes that might affect
> > >> GOTOFF32, but came up empty. Do you know where the decision of GOT or
> > >> GOTOFF would be handled?
> > >
> > >Sorry, it was written quite a while ago.  I don't know.
> > 
> > Do you know who added this feature? What is you, or perhaps Nick
> > Clifton or Richard Earnshaw? If I could find the person and the file
> > that added this feature, I could probably track down the patch in svn
> > and modify it for XIP.
> 
> It was probably me.  But why can't you do this yourself?  Look at the
> assembly.  See what the output string is.  Search for it in
> config/arm/.  Use svn blame, as already suggested.

No, it was PhilB, but it must have been two or three years ago now.

R.

Re: [uClinux-dev] Re: XIP on an ARM processor (R_ARM_GOTOFF32)

[Richard Earnshaw]

On Wed, 2006-06-28 at 16:51, Shaun Jackman wrote:
> On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote:
> > AFAIK,  you need to drop the -FPIC in favour of -fpic everywhere.
> 
> >From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
> PowerPC and SPARC.' For my purposes, it makes no difference on the
> ARM.

We don't currently do this, but we could make a distinction between
-fpic and -fPIC on ARM by exploiting the R_ARM_GOT_BREL12 relocation. 
This would limit the GOT to 1024 entries (a really smart linker might be
able to push that to 2047) which would handle most shared libs, but not
all.  -fpic code would then be faster by one load per GOT look-up.

Someday I'll try to come up with a patch to do that on the EABI ports of
the compiler.

R.

Re: How to use gcc4 to compile FreeBSD6.0 ?

[Rene Rebe]

On Thursday 29 June 2006 08:30, Beyond.Luo wrote:
> Hi,  all
>When I compile FreeBSD6.0 using gcc4.1 instead of gcc3,  lots of
> errors are reported.
> I knowes that gcc4.1 checks syntax more strictly, then how can I do now?
> any command-line options?

Fix the code?

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45

RE: How to control to use the function static linked to a shared library

[Hongbo Li]

Hi Ian,

Thanks for the information. I will take a look at the manual. When you
talk about the attribute, does that mean I need to change my source
code? Do you think the new option -fvisibility=hidden in gcc 4.0.0 would
solve this issue? I am using gcc 3.3.2.

Once again, thank you,

Hongbo.



-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 28, 2006 10:09 PM
To: Li, Hongbo [CAR:PK17:EXCH]
Cc: gcc@gcc.gnu.org
Subject: Re: How to control to use the function static linked to a
shared library


"Hongbo Li" <[EMAIL PROTECTED]> writes:

This question would be more appropriate for the gcc-help mailing list
rather than the gcc mailing list.

>   I currently hit an issue that I would like to use a function 
> statically linked to a shared library but my program use the same 
> function from another shared library. Here is what I do:
> 
>   1. I have toto.cxx that has one function called: toto() {cout <<

> "static toto" << endl;}
>   2. I create an archive say toto.a has the toto.o
>   3. I have toto1.cxx that has one functin called toto() {cout
cout 
> <<"shared toto"<   4. I create a shared libtoto1.so
>   5. I have use_toto.cxx that has one function called use_toto() {
> toto();}:
>   6. I create a shared libuse_toto.so that statically link to
toto.a
>   7. My main program test.cxx calling use_toto()
> 
>   I would like to always see the output of "static toto" but the
output 
> depends on the order of linking toto1.so and use_toto.so
> 
>   I will see "static toto" when I do this
>   g++ -o test -L./ -luse_toto -ltoto1.so ./test.o
> 
>   But I see "shared toto" if I change the order:
>   g++ -o test -L./ -ltoto1.so -luse_toto ./test.o
> 
> 
>   My question: do we have any way during the compilation/link to 
> control the program so that toto() in toto.cxx is always used? Since I

> may not have way to control how to build the main program, is there a 
> way to build libuse_toto.so so that toto() in toto.cxx is always used?

As you have discovered, the order on the link line determines when
symbols will be used.

You can force a few other possibilities by using a linker version script
or by setting the visibility attributes.  See the linker manual for
version scripts and the gcc manual for attributes.

Ian

Re: why are we not using const?

[Richard Guenther]

On 6/29/06, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:

 > Notice that the value of the parameter "b" is never changed in the
 > function body.  Consequently, if the current optimizers cannot figure
 > that simple cases out (where "b" is not annotated const), then the
 > optimizers in deficient in that respect.  That is the point.
 > -- Gaby

I agree that the compiler should/could be better at optimizing.

However my feeling is that 'const' is more important as documentation
and enforcement of APIs rather than an optimization hint.  From this
perspective, what "b" points to not getting changed is more important
to the caller than whether the function body changes the value of "b"
itself, since the caller doesn't see the latter.

I'd like to do for tree and rtx what I did for const char *, namely
constify those tree/rtx functions that aren't supposed to modify their
arguments.  This would require introducing the const_tree and
const_rtx typedefs Tristan suggested.


But with C language constructs you cannot assume that an object
passed to a function via a const pointer is not modified.  So, there
is no real "const" regarding to objects pointed to.  Consider

void foo(const int *i)
{
 int *k = (int *)i;
 *k = 0;
}
int bar(void)
{
 int i = 1;
 foo(&i);
 return i;
}

should return 0, not 1.

Richard.



Something for stage1, obviously.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

RE: why are we not using const?

[Dave Korn]

On 29 June 2006 14:44, Richard Guenther wrote:

> But with C language constructs you cannot assume that an object
> passed to a function via a const pointer is not modified.  So, there
> is no real "const" regarding to objects pointed to.  Consider
> 
> void foo(const int *i)
> {
>   int *k = (int *)i;
>   *k = 0;
> }
> int bar(void)
> {
>   int i = 1;
>   foo(&i);
>   return i;
> }
> 
> should return 0, not 1.

   That's cheating!  You casted away const, it's a blatant aliasing violation,
you deserve everything you get.  The compiler is specifically *allowed* to
assume you don't pull stunts like this *in order to* make const-optimisation
possible and useful.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: why are we not using const?

[Andrew Pinski]

On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:

   That's cheating!  You casted away const, it's a blatant aliasing  
violation,

you deserve everything you get.


No it is not, in fact it is legal C and there is no aliasing  
violation as you

are still accessing the memory as an "int".



-- Pinski

RE: why are we not using const?

[Dave Korn]

On 29 June 2006 14:55, Andrew Pinski wrote:

> On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
> 
>>That's cheating!  You casted away const, it's a blatant aliasing
>> violation, you deserve everything you get.
> 
> No it is not, in fact it is legal C and there is no aliasing
> violation as you
> are still accessing the memory as an "int".

  Sorry, 'aliasing' was the wrong choice of word.  But it's really legal to
cast away const?  I'm boggled.  In that case it simply might as well not exist
at all; it conveys no usable semantic information.  I would argue that const
should be removed from the language if this is the case; if all you want is to
document the properties of function args, it makes more sense to do it with
macros that #define to nothing, like M$ does with 'IN', 'OUT', 'OPTIONAL' and
so on in all their header files.




cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: why are we not using const?

[Andreas Schwab]

"Dave Korn" <[EMAIL PROTECTED]> writes:

> But it's really legal to cast away const?

All that matters is the effective type of the accessed object, see 6.5#7.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: why are we not using const?

[Richard Guenther]

On 6/29/06, Dave Korn <[EMAIL PROTECTED]> wrote:

On 29 June 2006 14:55, Andrew Pinski wrote:

> On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
>
>>That's cheating!  You casted away const, it's a blatant aliasing
>> violation, you deserve everything you get.
>
> No it is not, in fact it is legal C and there is no aliasing
> violation as you
> are still accessing the memory as an "int".

  Sorry, 'aliasing' was the wrong choice of word.  But it's really legal to
cast away const?  I'm boggled.  In that case it simply might as well not exist
at all; it conveys no usable semantic information.  I would argue that const
should be removed from the language if this is the case; if all you want is to
document the properties of function args, it makes more sense to do it with
macros that #define to nothing, like M$ does with 'IN', 'OUT', 'OPTIONAL' and
so on in all their header files.


;)

It's useful for qualifiers on the actual object like

const int foo = 1;

only for pointer targets it's useless but "needed" to form &foo, which
is const int*.  And it is undefined if you try to modify foo via

int * bar = (int*)&foo;
*bar = 1;

so, it's only the CV qualifier of the object that matters, not the one
you stick to some arbitrary pointer to an object.

The solution is of course to teach the middle-end a new concept
of pointer to non-modifiable memory and do some language extension
to use it.  Maybe there even are languages that have a useful const
concept (like C++ for the this object on const methods).

Richard.

__float128 runtime support

[H. J. Lu]

On Tue, Jun 27, 2006 at 11:18:13AM +, Joseph S. Myers wrote:
> On Mon, 26 Jun 2006, H. J. Lu wrote:
> 
> > I have no strong opinion on the support for __float80. But the current
> > behavior seems odd to me. Also, we have incomplete support for
> > __float128. There is no runtime support for __float128 at all on
> > x86-64.
> 
> Feel free to add such support using soft-fp as described at the bottom of 
> .
> 

There are 2 problems with __float128 runtime support if it is different
from single, double and long double:

1. __float128 isn't enabled even if gcc supports it.
2. __float128 I/O isn't supported even if __float128 is enabled.

My patch:

http://sources.redhat.com/ml/libc-alpha/2004-05/msg00049.html

tried to address those.


H.J.

Re: Visibility and C++ Classes/Templates

[Jason Merrill]

Hmm, I'm starting to be convinced that ignoring #pragma visibility for 
all template instantiations and specializations will be a simpler rule 
for users to understand.  So the #pragma affects namespace-scope 
declarations, but not declarations that in any sense "belong" to another 
namespace-scope declaration (class, function or template).  I think 
that'll be more straightforward than making a subtle distinction between 
class members and template specializations.


Jason

RE: why are we not using const?

[Dave Korn]

On 29 June 2006 15:12, Andreas Schwab wrote:

> "Dave Korn" <[EMAIL PROTECTED]> writes:
> 
>> But it's really legal to cast away const?
> 
> All that matters is the effective type of the accessed object, see 6.5#7.
> 
> Andreas.


  Ah yes, now I remember... we had a long thread on this sometime last year,
didn't we, and decided that the compiler was in the right to ignore the
qualifiers on the pointer if it also knew that the pointer had been
initialised to point to an object for which it could see the declaration and
therefore know the real underlying type.  Thanks for the pointer.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: How to control to use the function static linked to a shared library

[Ian Lance Taylor]

"Hongbo Li" <[EMAIL PROTECTED]> writes:

> Thanks for the information. I will take a look at the manual. When you
> talk about the attribute, does that mean I need to change my source
> code?

Yes.

> Do you think the new option -fvisibility=hidden in gcc 4.0.0 would
> solve this issue?

It would change what happens.  You would have to decide whether it
does what you actually want.

> I am using gcc 3.3.2.

I don't think these features are supported in that old version,
unfortunately.

Ian

Re: why are we not using const?

[Kaveh R. Ghazi]

 > On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
 > 
 > That's cheating! You casted away const, it's a blatant aliasing
 > violation, you deserve everything you get.
 > 
 > No it is not, in fact it is legal C and there is no aliasing violation
 > as you are still accessing the memory as an "int".
 > -- Pinski

"Legal" does not mean it's a good idea.  Bypassing const through casts
is like ignoring documentation.  You get what you deserve.

E.g. if the object referred to by the pointer is in a read-only
section, casting away const-ness and modifying it leads to a core
dump...

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

RE: why are we not using const?

[Dave Korn]

On 29 June 2006 16:15, Kaveh R. Ghazi wrote:

>  > On Jun 29, 2006, at 9:51 AM, Dave Korn wrote:
>  >
>  > That's cheating! You casted away const, it's a blatant aliasing
>  > violation, you deserve everything you get.
>  >
>  > No it is not, in fact it is legal C and there is no aliasing violation
>  > as you are still accessing the memory as an "int".
>  > -- Pinski
> 
> "Legal" does not mean it's a good idea.  Bypassing const through casts
> is like ignoring documentation.  You get what you deserve.
> 
> E.g. if the object referred to by the pointer is in a read-only
> section, casting away const-ness and modifying it leads to a core
> dump...
> 
>   --Kaveh

  I believe that's basically what Andreas was pointing out; in that case, you
*are* violating the type of the underlying object.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: why are we not using const?

[Chris Lattner]

On Jun 29, 2006, at 6:51 AM, Dave Korn wrote:

  That's cheating!  You casted away const, it's a blatant aliasing  
violation,
you deserve everything you get.  The compiler is specifically  
*allowed* to
assume you don't pull stunts like this *in order to* make const- 
optimisation

possible and useful.


As others have said, casting away const (and then dereferencing the  
pointer) is perfectly legal unless the underlying variable's  
definition is const.


However, you don't even need to do this to illustrate why const  
pointers can't be used for optimization:


int G;

void foo(const int *P1) {
  G = *P1 + 1;
}

int bar() {
   int tmp = G;
   foo(&G);
   return G-tmp;
}

bar returns 1, not 0, and there is no pointer casting happening.

-Chris

Re: why are we not using const?

[Gabriel Dos Reis]

"Dave Korn" <[EMAIL PROTECTED]> writes:

| On 29 June 2006 14:44, Richard Guenther wrote:
| 
| > But with C language constructs you cannot assume that an object
| > passed to a function via a const pointer is not modified.  So, there
| > is no real "const" regarding to objects pointed to.  Consider
| > 
| > void foo(const int *i)
| > {
| >   int *k = (int *)i;
| >   *k = 0;
| > }
| > int bar(void)
| > {
| >   int i = 1;
| >   foo(&i);
| >   return i;
| > }
| > 
| > should return 0, not 1.
| 
|That's cheating!  You casted away const, it's a blatant aliasing violation,
| you deserve everything you get.  The compiler is specifically *allowed* to
| assume you don't pull stunts like this *in order to* make const-optimisation
| possible and useful.

Not from the C language point of view.

-- Gaby

Re: why are we not using const?

[Paolo Bonzini]

int G;

void foo(const int *P1) {
  G = *P1 + 1;
}

int bar() {
   int tmp = G;
   foo(&G);
   return G-tmp;
}

bar returns 1, not 0, and there is no pointer casting happening.


Well, G is known to escape anyway here.  Even worse is this:


-- f1.c --
extern int G;

void foo(const int *P1) {
  int a = *P1;
  G = *P1 + 1;  /* optimizable even for non-const int *P1 */
  return *P1 - a;   /* non-optimizable anyway */
}

-- f2.c --
int G;

int bar() {
   return foo(&G);
}

where there is not even the possibility to optimize *P1 in foo. While 
compiling f1.c, the compiler does not even know that G escapes and must 
assume the worse.


It's a different story for static variables or for -fwhole-program, but 
then the compiler (as for the second load from *P1) can optimize the 
third load anyway, independent of whether P1 is const or not.


Paolo

bootstrap of trunk fails for x86-64

[Andreas Jaeger]

Current svn does not build, it fails for me with:

build/genpreds /cvs/gcc-svn/trunk/gcc/config/i386/i386.md > tmp-preds.c
/bin/sh /cvs/gcc-svn/trunk/gcc/../move-if-change tmp-constrs.h tm-constrs.h
build/genpreds: Internal error: RTL check: expected elt 0 type 'e' or 'u', have 
's' (rtx match_code) in write_match_code_switch, at genpreds.c:546
make[3]: *** [s-preds] Error 1

Roger, is this is a result of your changes?

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpNsY5lXAiXy.pgp
Description: PGP signature

Re: why are we not using const?

[Chris Lattner]

On Jun 29, 2006, at 9:20 AM, Paolo Bonzini wrote:

Well, G is known to escape anyway here.  Even worse is this:



...

where there is not even the possibility to optimize *P1 in foo.  
While compiling f1.c, the compiler does not even know that G  
escapes and must assume the worse.


It's a different story for static variables or for -fwhole-program,  
but then the compiler (as for the second load from *P1) can  
optimize the third load anyway, independent of whether P1 is const  
or not.


If the compiler has such a detailed knowledge of aliasing, why would  
it have to depend on "const"?  Assuming "const" were safe for the  
compiler to use (which it isn't, obviously), it would only add value  
if the compiler didn't have perfect knowledge of aliases already.


-Chris

Re: Which patch added R_ARM_GOTOFF32 support?

[Shaun Jackman]

On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

It was probably me.  But why can't you do this yourself?  Look at the
assembly.  See what the output string is.  Search for it in
config/arm/.  Use svn blame, as already suggested.


I did search the assembler text and found the constant and relocation
(GOTOFF) is emitted by arm_assemble_integer. Unfortunately, by this
point the code to use that constant has already been emitted, and so
the decision of which relocation to use has already been made.

All I mean to say in this text, is that if a clueful person has the
knowledge in their head as to which file/function is responsible, it
might take that person 30 seconds and a one-line email to pass that
knowledge on to me, and save me a full day of guessing games.

Cheers,
Shaun

Re: Which patch added R_ARM_GOTOFF32 support?

[Shaun Jackman]

On 6/29/06, Richard Earnshaw <[EMAIL PROTECTED]> wrote:

No, it was PhilB, but it must have been two or three years ago now.


Thanks, Richard. I suspect svn r71881 is responsible. I'll start
testing and hopefully put a patch together. I would suspect r49871,
but this patch is in 4.0.3, which doesn't emit GOTOFF.

Cheers,
Shaun

r49871
2002-02-19  Philip Blundell  <[EMAIL PROTECTED]>

* config/arm/arm.c (arm_encode_call_attribute): Operate on any
decl, not just FUNCTION_DECL.
(legitimize_pic_address): Handle local SYMBOL_REF like LABEL_REF.
(arm_assemble_integer): Likewise.
* config/arm/arm.h (ARM_ENCODE_CALL_TYPE): Allow any decl to be
marked local.

r71881
2003-09-28  Philip Blundell  <[EMAIL PROTECTED]>

* config/arm/arm.c (legitimize_pic_address): Check
SYMBOL_REF_LOCAL_P, not ENCODED_SHORT_CALL_ATTR_P.
(arm_assemble_integer): Likewise.

Re: How to use gcc4 to compile FreeBSD6.0 ?

[Joe Buck]

On Thursday 29 June 2006 08:30, Beyond.Luo wrote:
> > Hi,  all
> >When I compile FreeBSD6.0 using gcc4.1 instead of gcc3,  lots of
> > errors are reported.
> > I knowes that gcc4.1 checks syntax more strictly, then how can I do now?
> > any command-line options?

On Thu, Jun 29, 2006 at 02:51:31PM +0200, Rene Rebe wrote:
> Fix the code?

Better yet, use an appropriate mailing list (a freebsd developer list)
to ask questions like this.

Re: why are we not using const?

[Andrew Haley]

Andreas Schwab writes:
 > "Dave Korn" <[EMAIL PROTECTED]> writes:
 > 
 > > But it's really legal to cast away const?
 > 
 > All that matters is the effective type of the accessed object, see 6.5#7.

It's not clear to me that it's legal to convert (const int*) to
(int*).  6.3.2.3, Pointers, says


2  For any qualifier q, a pointer to a non-q-qualified type may be
   converted to a pointer to the q-qualified version of the type; the
   values stored in the original and converted pointers shall compare
   equal.


It doesn't seem to me to give any permission to do the conversion the
other way.  But that wouldn't make any difference to this case,
because you can still do


int i = 0;

void bar()
{
  i = 2;
}

void foo (const int *pi)
{
   print (*pi);
   bar();
   print (*pi);
}

int main()
{
  foo (&i);
  return 0;
}  


For what it's worth: we have a lot of fields in Java that are known
never to change, and to be able to explain that to the optimizers
would be a big boost.

Andrew.

Re: bootstrap of trunk fails for x86-64

[Roger Sayle]

On Thu, 29 Jun 2006, Andreas Jaeger wrote:
> Current svn does not build, it fails for me with:
> build/genpreds: Internal error: RTL check: expected elt 0 type 'e' or 'u',
> have 's' (rtx match_code) in write_match_code_switch, at genpreds.c:546
>
> Roger, is this is a result of your changes?

Grr!  Sorry again for the second "typo" breakage in what should have been
a very simple patch.  Although I can't reproduce the above failure on my
x86_64 box (or any of the other systems I tested this patch on), the RTL
check is diagnosing a real problem that I'm sorry I zoned on myself.

Fixed with the following patch.  Committed to mainline as obvious as
revision 115076, after a full 3-stage bootstrap of the gcc/ directory
on x86_64-unknown-linux-gnu.

My apologies yet again for the breakage, and especially to Mark.



2006-06-29  Roger Sayle  <[EMAIL PROTECTED]>

* genpreds.c (write_match_code_switch): Correctly use XSTR instead
of XEXP to extract the operands of a MATCH_CODE rtx.


Index: genpreds.c
===
*** genpreds.c  (revision 115074)
--- genpreds.c  (working copy)
*** write_predicate_expr (rtx exp)
*** 543,550 
  static void
  write_match_code_switch (rtx exp)
  {
!   const char *codes = (const char *) XEXP (exp, 0);
!   const char *path = (const char *) XEXP (exp, 1);
const char *code;

fputs ("  switch (GET_CODE (", stdout);
--- 543,550 
  static void
  write_match_code_switch (rtx exp)
  {
!   const char *codes = XSTR (exp, 0);
!   const char *path = XSTR (exp, 1);
const char *code;

fputs ("  switch (GET_CODE (", stdout);


Roger
--

Re: Source code of CIL back-end

[Daniel Berlin]

Joe Buck wrote:
> On Thu, Jun 22, 2006 at 09:06:28PM -0400, Daniel Berlin wrote:
>> As Joe Buck, a Steering Committee member said, you need to talk to RMS
>> directly and get him to accept the idea, before we can do anything about it.
> 
> I already asked RMS directly, and he has approved.  Again, sorry for
> the delay on getting back to the list, I was out of town.
> 

Then I guess, Roberto, need to fill out the approriate assignment
paperwork, and get an existing gcc maintainer to sponsor your write
access, and apply for such access using the approriate form on
gcc.gnu.org after finding a sponsor.

Sortir, se distraire, se cultiver autour du Leman

[redaction]

Vous leur manquez !
 
 Pres de 1000 internautes utilisent quotidiennement ristrette.com.
Ils y trouvent de quoi se distraire, se cultiver, de quoi passer un
bon moment autour de Geneve, en Suisse, en Haute Savoie et dans
l'Ain.
 
 Ristrette est ouvert gratuitement a tous.
 
Deja de nombreux intervenants y inscrivent librement et gratuitement
leurs manifestations ou presentent leur activite.
 
 Parcs de loisisirs, manifestations, guides de montagnes, chambres
d'hotes, spectacles pour enfants, festivals, restaurants etc.. les
internautes vous esperent sur ristrette.com.
 
 Testez ristrette a votre tour en y mettant vos annonces (photos
possibles), vos manifestations.
 
 Cordialement, l'administrateur de ristrette.com
 
 www.ristrette.com <../../../../>

PS : Un probleme technique nous a contraint a retirer les accents de
ce texte. Par ailleur vous avez peut etre recu ce courrier deux fois.
Nous vous prions de nous en excuser.

 

--
Pour vous désinscrire : 
http://ristrette.com/phplist/?p=unsubscribe&uid=8283e186ef57874f0d7aabe5381f1ed8
Pour modifier votre inscription : 
http://ristrette.com/phplist/?p=preferences&uid=8283e186ef57874f0d7aabe5381f1ed8



--
Powered by PHPlist, www.phplist.com --

Sortir, se distraire, se cultiver autour du Leman

[redaction]

Vous leur manquez !
 
 Pres de 1000 internautes utilisent quotidiennement ristrette.com.
Ils y trouvent de quoi se distraire, se cultiver, de quoi passer un
bon moment autour de Geneve, en Suisse, en Haute Savoie et dans
l'Ain.
 
 Ristrette est ouvert gratuitement a tous.
 
Deja de nombreux intervenants y inscrivent librement et gratuitement
leurs manifestations ou presentent leur activite.
 
 Parcs de loisisirs, manifestations, guides de montagnes, chambres
d'hotes, spectacles pour enfants, festivals, restaurants etc.. les
internautes vous esperent sur ristrette.com.
 
 Testez ristrette a votre tour en y mettant vos annonces (photos
possibles), vos manifestations.
 
 Cordialement, l'administrateur de ristrette.com
 
 www.ristrette.com <../../../../>

PS : Un probleme technique nous a contraint a retirer les accents de
ce texte. Par ailleur vous avez peut etre recu ce courrier deux fois.
Nous vous prions de nous en excuser.

 

--
Pour vous désinscrire : 
http://ristrette.com/phplist/?p=unsubscribe&uid=c329c62409aaac0410c92dea127d6e8f
Pour modifier votre inscription : 
http://ristrette.com/phplist/?p=preferences&uid=c329c62409aaac0410c92dea127d6e8f



--
Powered by PHPlist, www.phplist.com --

[PATCH] config/arm/arm.c: Use GOT instead of GOTOFF when XIP

[Shaun Jackman]

This patch forces the use of GOT relocations instead of GOTOFF when
compiling execute-in-place (XIP) code. I've defined XIP as the
combination of -fpic and -msingle-pic-base.

There is room for improvement in using GOTOFF relocations for symbols
that will be in the same addressing space as the GOT (.data likely)
and PC relative relocations for symbols that will be in the same
addressing space as the PC (.text and .rodata likely).

I'm open to suggestions for the name of the new predicate, which I've
named local_symbol_p here. I had named it use_gotoff_p at one point.

Cheers,
Shaun

2006-06-29  Shaun Jackman  <[EMAIL PROTECTED]>

* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.

Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 115074)
+++ config/arm/arm.c(working copy)
@@ -3193,6 +3193,17 @@
  return 1;
}

+static int
+local_symbol_p(rtx x)
+{
+  /* Execute-in-place code fails if a GOTOFF relocation is used to
+   * adress a local symbol in the .text segment. */
+  if (flag_pic && TARGET_SINGLE_PIC_BASE)
+return 0;
+  return GET_CODE (x) == LABEL_REF
+|| (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_LOCAL_P (x));
+}
+
 rtx
 legitimize_pic_address (rtx orig, enum machine_mode mode, rtx reg)
{
@@ -3271,10 +3282,7 @@
  else
emit_insn (gen_pic_load_addr_thumb (address, orig));

-  if ((GET_CODE (orig) == LABEL_REF
-  || (GET_CODE (orig) == SYMBOL_REF &&
-  SYMBOL_REF_LOCAL_P (orig)))
- && NEED_GOT_RELOC)
+  if (NEED_GOT_RELOC && local_symbol_p (orig))
pic_ref = gen_rtx_PLUS (Pmode, cfun->machine->pic_reg, address);
  else
{
@@ -11292,12 +11300,10 @@
  if (NEED_GOT_RELOC && flag_pic && making_const_table &&
  (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF))
{
- if (GET_CODE (x) == SYMBOL_REF
- && (CONSTANT_POOL_ADDRESS_P (x)
- || SYMBOL_REF_LOCAL_P (x)))
+ if ((GET_CODE (x) == SYMBOL_REF
+   && CONSTANT_POOL_ADDRESS_P (x))
+ || local_symbol_p (x))
fputs ("(GOTOFF)", asm_out_file);
- else if (GET_CODE (x) == LABEL_REF)
-   fputs ("(GOTOFF)", asm_out_file);
  else
fputs ("(GOT)", asm_out_file);
}
2006-06-29  Shaun Jackman  <[EMAIL PROTECTED]>

* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.

Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 115074)
+++ config/arm/arm.c(working copy)
@@ -3193,6 +3193,17 @@
   return 1;
 }
 
+static int
+local_symbol_p(rtx x)
+{
+  /* Execute-in-place code fails if a GOTOFF relocation is used to
+   * adress a local symbol in the .text segment. */
+  if (flag_pic && TARGET_SINGLE_PIC_BASE)
+return 0;
+  return GET_CODE (x) == LABEL_REF
+|| (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_LOCAL_P (x));
+}
+
 rtx
 legitimize_pic_address (rtx orig, enum machine_mode mode, rtx reg)
 {
@@ -3271,10 +3282,7 @@
   else
emit_insn (gen_pic_load_addr_thumb (address, orig));
 
-  if ((GET_CODE (orig) == LABEL_REF
-  || (GET_CODE (orig) == SYMBOL_REF &&
-  SYMBOL_REF_LOCAL_P (orig)))
- && NEED_GOT_RELOC)
+  if (NEED_GOT_RELOC && local_symbol_p (orig))
pic_ref = gen_rtx_PLUS (Pmode, cfun->machine->pic_reg, address);
   else
{
@@ -11292,12 +11300,10 @@
   if (NEED_GOT_RELOC && flag_pic && making_const_table &&
  (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF))
{
- if (GET_CODE (x) == SYMBOL_REF
- && (CONSTANT_POOL_ADDRESS_P (x)
- || SYMBOL_REF_LOCAL_P (x)))
+ if ((GET_CODE (x) == SYMBOL_REF
+   && CONSTANT_POOL_ADDRESS_P (x))
+ || local_symbol_p (x))
fputs ("(GOTOFF)", asm_out_file);
- else if (GET_CODE (x) == LABEL_REF)
-   fputs ("(GOTOFF)", asm_out_file);
  else
fputs ("(GOT)", asm_out_file);
}

gcc-4.0-20060629 is now available

[gccadmin]

Snapshot gcc-4.0-20060629 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060629/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch 
revision 115080

You'll find:

gcc-4.0-20060629.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20060629.tar.bz2 C front end and core compiler

gcc-ada-4.0-20060629.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20060629.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20060629.tar.bz2  C++ front end and runtime

gcc-java-4.0-20060629.tar.bz2 Java front end and runtime

gcc-objc-4.0-20060629.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20060629.tar.bz2The GCC testsuite

Diffs from 4.0-20060622 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
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: gcc port based on MIPS

[Ian Lance Taylor]

"kernel coder" <[EMAIL PROTECTED]> writes:

> thanks,There is a macro LEGITIMIZE_RELOAD_ADDRESS.Accroding to gcc internals
> "It is a C compound statement that attempts to replace x, which is an
> address that needs
> reloading, with a valid memory address for an operand of mode mode.
> win will be a
> C statement label elsewhere in the code".
> 
> I'm not been able to comprehend this macro.

LEGITIMIZE_RELOAD_ADDRESS is basically a hook into the reload pass to
do machine specific optimizations.  It is difficult to understand
without a clear notion of what the reload pass does.

> The explaination is saying
> that it tries to replace the address with some suitable address.But
> when will such a situation occur,any example will  be helpful.

You can find examples by doing a grep for LEGITIMIZE_RELOAD_ADDRESS in
gcc/config/*/*.h.

> And what
> is reloading pass.According to gcc internals in this pass
> pseudo-registers  are replaced with hard registers and some are
> assigned stack slots.Is there anything else which happens in this
> phase.

That's pretty much it.  The details get rather complex.  There is some
discussion at http://gcc.gnu.org/wiki/reload.

> Is above mentioned macro also has something to do with pass.

Yes.

Ian

Re: make proto fails

[Jim Wilson]

Andreas Jaeger wrote:

Andreas Schwab <[EMAIL PROTECTED]> writes:

That's probably the same bug as PR21059.

That report even has a patch - but no action since december.  Jim,
will you handle this one?


It isn't exactly the same problem, as there is no auto-inc address here. 
 So my patch in the PR doesn't look like it will help.  We need one of 
the more complicated solutions which require a smarter CFG and/or 
smarter register lifetime check.  I don't know if I can help with that. 
 Others are doing more work in this area than I am.


This isn't a new problem.  The .i file I produced from mainline 
generates the same failure with gcc-4.1 and gcc-4.0, and maybe also 
other gcc versions.  I'm not sure what broke this, maybe it was the 
addition of -Werror to the Makefile.


As for my patch, I would like to finish it now that I'm functional 
again, but I've got a big backlog of stuff so I don't know when I will 
get to it.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

GCC 4.1 on AIX 5.3 POWER 5

[Rajkishore Barik]

Hi All,

I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5 
processors.
I get the following error while trying to compile. Can someone help? "cc" 
is IBM's xlC compiler.

cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/fixincl.c
cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/fixtests.c
cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/fixfixes.c
cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/server.c
cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/procopen.c
cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/fixlib.c
cc -c -g-DHAVE_CONFIG_H -I. 
-I../../gcc-4.1-20060310/fixincludes -I../include 
-I../../gcc-4.1-20060310/fixincludes/../include 
../../gcc-4.1-20060310/fixincludes/fixopts.c
cc -g   -o fixincl fixincl.o fixtests.o fixfixes.o server.o 
procopen.o  fixlib.o fixopts.o ../libiberty/libiberty.a
echo timestamp > full-stamp
srcdir="../../gcc-4.1-20060310/fixincludes" /bin/sh 
../../gcc-4.1-20060310/fixincludes/mkfixinc.sh powerpc-ibm-aix5.3.0.0
sed -e 's/@gcc_version@//' <  > mkheadersT
/bin/sh: 0403-057 Syntax error at line 1 : `>' is not expected.
make: 1254-004 The error code from the last command is 2.


Stop.
make: 1254-004 The error code from the last command is 2.


Stop.
make: 1254-004 The error code from the last command is 2

regards,
Raj

Re: GCC 4.1 on AIX 5.3 POWER 5

[Mike Stump]

On Jun 29, 2006, at 8:27 PM, Rajkishore Barik wrote:

I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.


Then this is the wrong list...  You'd want gcc-help.

Re: GCC 4.1 on AIX 5.3 POWER 5

[Andrew Pinski]

On Jun 30, 2006, at 12:40 AM, Mike Stump wrote:


On Jun 29, 2006, at 8:27 PM, Rajkishore Barik wrote:

I am trying to complie GCC 4.1 on an AIX 5.3 machine having 2 power5
processors.


Then this is the wrong list...  You'd want gcc-help.



They also might want to read: http://gcc.gnu.org/install/
specifically: http://gcc.gnu.org/install/prerequisites.html
Which says:
GNU make version 3.79.1 (or later)
You must have GNU make installed to build GCC.
And:
A “working” POSIX compatible shell, or GNU bash


-- Pinski

PIC code in function prologue

[kernel coder]

hi,
I'm having some trouble while understanding the following pic
code in function prologue of cris architecture.

if (current_function_uses_pic_offset_table)
   {
 /* A reference may have been optimized out (like the abort () in
fde_split in unwind-dw2-fde.c, at least 3.2.1) so check that
it's still used.  */
 push_topmost_sequence ();
 got_really_used
   = reg_used_between_p (pic_offset_table_rtx, get_insns (), NULL_RTX);
 pop_topmost_sequence ();
   }

Is this pic offset table ,the same global offset table.Does
current_function_uses_pic_offset_table means that call to current
function is made through GOT.where this variable
(current_function_uses_pic_offset_table) is being set.

What is happening in next 3 lines
push_topmost_sequence ();
 got_really_used
   = reg_used_between_p (pic_offset_table_rtx, get_insns (), NULL_RTX);
 pop_topmost_sequence ();

what does  pic_offset_table_rtx contain.

thanks,
shahzad