Re: make proto fails

[Andreas Jaeger]

Andreas Schwab <[EMAIL PROTECTED]> writes:

> Andreas Jaeger <[EMAIL PROTECTED]> writes:
>
>> /cvs/gcc-svn/trunk/gcc/protoize.c: In function ‘edit_fn_definition’:
>> /cvs/gcc-svn/trunk/gcc/protoize.c:3506: warning: argument ‘clean_text_p’ 
>> might be clobbered by ‘longjmp’ or ‘vfork’
>
> 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?

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


pgpMgq4V6DyM3.pgp
Description: PGP signature

GCC 4.1.1

[François P. Rotzinger]

Dear colleagues,

Many thanks for the development of GCC!

I built GCC 4.1.1 on 32 and 64 bit computers; the pertinent data is 
given below:


32 bit (Intel Pentium4 1.5 GHz):
---

i686-pc-linux-gnu

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/opt
Thread model: posix
gcc version 4.1.1

Welcome to SuSE Linux 9.3 (i586) - Kernel \r (\l).

uname (GNU coreutils) 5.3.0
Written by David MacKenzie.

Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

glibc-2.3.4-23

--

64 bit (AMD64):
-

x86_64-unknown-linux-gnu

Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.1/configure --prefix=/opt/gcc4
Thread model: posix
gcc version 4.1.1

Welcome to SuSE Linux 9.3 (x86-64) - Kernel \r (\l).

Linux master 2.6.11.4-21.9-smp #1 SMP Fri Aug 19 11:58:59 UTC 2005 
x86_64 x86_64 x86_64 GNU/Linux


glibc-2.3.4-23.4




The GAMESS quantum chemistry program was compiled with GCC 4.1.1 on 32 
and 64 bit machines (Pentium4 and AMD64): all of the 39 test examples 
were executed succesfully.




Please let me know, if you need additional information.

Have a nice day, best regards, Francois P. Rotzinger

Information about .debug and .line section in elf files

[Oliver Eichler]

Hi,

as the subjects states I try to find information about the .debug and
.line section in elf files. My elf files are build with gcc for ARC. The
 elf man page is quite sparse about these sections. Can anyone give me a
hint where to find more information? Or where to look within the gcc
source for stucture definitions.

Thanks,

Oliver

-- 
Ingenieure Kellermann, Voigt, Hoepfl, Eichler und Weidner, Partnerschaft

DSP Solutions http://www.dspsolutions.de

Re: Source code of CIL back-end

[Erven ROHOU]

Joe Buck wrote:

On Thu, Jun 22, 2006 at 11:49:45AM +0200, Roberto COSTA wrote:

By the way, is there any news about the status of the CIL issue?
I'm sorry to bother the list readers about this, but whom could I 
directly ask?


Sorry for the delay in answering, Robert.  I was out of town, and
apparently people thought I'd post the answer on this one, since I
brought up the topic for SC discussion.

The SC discussed it with Richard Stallman, and he agrees that it is not
"dangerous" (the FSF had raised objections to byte-code systems in the
past, so many of us assumed there would be a problem).  So there is no
political/legal objection to including a CIL back end.  If it passes
technical review, it can be included.



Hello,

Thanks for the answer, this is great news!

We have to start working on the paperwork. Could anybody point us at the 
relevant forms for the copyright assignment?


My understanding is that the next step is the creation of a development 
branch. Is it dependent on the paperwork, or can it be done in parallel?


Thanks,

--
Erven.

Re: Information about .debug and .line section in elf files

[Saurabh Verma]

Hello Olivier,
I would suggest looking at ELF and DWARF specifications [1] for the
standards documentation, and gcc/dwarf2out.c for the implementation.

HTH
Best regards
saurabh

Links:
~
1. http://refspecs.freestandards.org/



On Wed, 2006-06-28 at 09:01 +0200, Oliver Eichler wrote:
> Can anyone give me a
> hint where to find more information? Or where to look within the gcc
> source for stucture definitions.

Re: Source code of CIL back-end

[Paolo Bonzini]

The SC discussed it with Richard Stallman, and he agrees that it is not
"dangerous" (the FSF had raised objections to byte-code systems in the
past, so many of us assumed there would be a problem).  So there is no
political/legal objection to including a CIL back end.  If it passes
technical review, it can be included.


Hello,

Thanks for the answer, this is great news!


It is indeed.  It's good to see GCC moving forward on these aspects!

We have to start working on the paperwork. Could anybody point us at the 
relevant forms for the copyright assignment?


I am almost sure that you do not need that, because ST Microelectronics 
has an assignment for many projects including GCC.  But just in case, 
please wait for a confirmation.


If you want to assign copyright personally to FSF, it would mean that 
you could keep working on GCC (in the FSF repository) even if you leave 
ST.  If that is the case, just ask for the relevant forms.


My understanding is that the next step is the creation of a development 
branch. Is it dependent on the paperwork, or can it be done in parallel?


It is dependent on the paperwork.  However, as I said, I am almost sure 
that your employer took care of that for you.  As soon as somebody 
confirms that no further paperwork is necessary, you can create the branch.


Paolo

Re: Boehm-gc performance data

[Geoffrey Keating]

"Laurynas Biveinis" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> > > combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
> > > (0.61) 4% (4%). User running time: 0m16 (0m14).
> >
> > Are these with checking on or off?  Normally checking is on, you have
> > to go out of your way to turn it off.  If it were on, the real
> > numbers are going to look much worse than the ones you're presented.
> 
> Both sets of numbers are with checking on, I guess that makes them comparable?
> 
> > Also, I've not been following real closely, but the GTY markers are
> > used by PCH and the dual use of them by GC allow one to find PCH bugs
> > more quickly and easily.  If we moved entirely to Boehm's, did you
> > have a plan for the GTY markers and PCH?
> 
> As Andrew already has noted, I still use GTY markers at least for
> registering additional roots. I don't really have a plan for PCH yet;
> I guess that some additional bookkeeping would have to be done in
> allocation routines using some weak-pointer based data structure... I
> don't know yet.

All you should need to do to support PCH is implement the ggc_pch_*
routines, specified and declared in ggc.h, for your garbage collector.
Only ggc_pch_write_object actually requires you to do something,
everything else is to help your implementation know what's going on.
For performance, it is necessary that you don't write to many objects
in the PCH file (and so freeing and re-using them is a bad idea).  You
need to be able to mark the pointers placed in objects read from a PCH
as they may refer to newly-allocated memory.

Re: Visibility and C++ Classes/Templates

[Geoffrey Keating]

Jason Merrill <[EMAIL PROTECTED]> writes:

> Gabriel Dos Reis wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> writes:
> > | I'm just not comfortable with the idea of #pragmas affecting
> > | instantiations.  (I'm OK with them affecting specializations, though; in
> > | that case, the original template has basically no impact, so I think
> > | it's fine to treat the specialization case as if it were any other
> > | function.)
> > I'm undecided whether #pragmas should not affect explicit
> > instantiations.  They really are not like implicit instantiations
> > (which, I agree with you, should not be affected).  Explicit
> > instantiations behave more like real declarations than implicit
> > instantiations.
> 
> Yep.  I'm sympathetic to Mark's position, but still tend to believe
> that the #pragma should affect explicit instantiations.  Explicit
> instantiations are a way to make template instantiations conform more
> to the traditional declaration/definition model.  We ignore the
> #pragmas for implicit instantiations because the user doesn't control
> the point of instantiation; with explicit instantiations, they do.
> 
> Explicit instantiations don't behave just like implicit
> instantiations; there are other differences.

A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no #pragma is in effect, because the other module
may have a specific idea about what visibility should be used.

I'm not sure how exactly they can do this.  Is there a visibility
pragma for "no setting"?

It seems like this would be a common enough mistake that there should
be a way to get a warning about it.

In the traditional declaration/definition model, if you try to change
the linkage of something you get an error...

Re: why are we not using const?

[Gabriel Dos Reis]

Andrew Pinski <[EMAIL PROTECTED]> writes:

| On Jun 27, 2006, at 7:58 AM, Gabriel Dos Reis wrote:
| 
| > We we do have numbers that support that claim for real programs, then
| > we have a bug in the optimizers :-)
| 
| Huh?

Yes.

| "Stupid" example where a const argument can change:
| tree a;
| int f(const tree b)
| {
|TREE_CODE(a) = TREE_CODE (b) + 1;
|return TREE_CODE (b);
| }

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

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

[Shaun Jackman]

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.


You could try some experiments using the older toolchain to see how it
puts binaries together etc.  AFAIK,  thumb and most archs are supported
by it, it provides at least a working reference for fixing a new
toolchain at least,


I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that
4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32
relocations. Apparently these are a new feature and preferable in some
instances since they do reduce the number of instructions by one.
However, GOTOFF32 does not work when a the relocation is emitted for a
symbol in the .text segment. As far as I know, any XIP application
with a static callback function should fail if it's compiled with
arm-elf-gcc 4.1.x. If anyone else is using this toolchain, I'd
appreciate the confirmation. The following diff of the output from GCC
4.0.3 to GCC 4.1.1 illustrates the new behaviour.

Cheers,
Shaun

$ cat f.c
void g(void (*h)(void)) {}
static void f(void) { g(f); }
$ diff -u f.s-4.0.3 f.s-4.1.1
--- f.s-4.0.3   2006-06-28 09:32:54.044964568 -0600
+++ f.s-4.1.1   2006-06-28 08:55:49.880089024 -0600
@@ -8,11 +8,12 @@
   .type   g, %function
g:
   push{r7, lr}
-   mov r7, sp
   sub sp, sp, #4
-   sub r3, r7, #4
+   add r7, sp, #0
+   mov r3, r7
   str r0, [r3]
   mov sp, r7
+   add sp, sp, #4
   @ sp needed for prologue
   pop {r7, pc}
   .size   g, .-g
@@ -22,10 +23,9 @@
   .type   f, %function
f:
   push{r7, lr}
-   mov r7, sp
+   add r7, sp, #0
   ldr r3, .L5
   add r3, r3, sl
-   ldr r3, [r3]
   mov r0, r3
   bl  g
   mov sp, r7
@@ -34,6 +34,6 @@
.L6:
   .align  2
.L5:
-   .word   f(GOT)
+   .word   f(GOTOFF)
   .size   f, .-f
-   .ident  "GCC: (GNU) 4.0.3"
+   .ident  "GCC: (GNU) 4.1.1"

Re: Information about .debug and .line section in elf files

[Michael Eager]

Oliver Eichler wrote:

Hi,

as the subjects states I try to find information about the .debug and
.line section in elf files. My elf files are build with gcc for ARC. The
 elf man page is quite sparse about these sections. Can anyone give me a
hint where to find more information? Or where to look within the gcc
source for stucture definitions.


These sections contain DWARF debugging information.

You can find documentation about DWARF at dwarf.freestandards.org.

--
Michael EagerChair, DWARF Workgroup   [EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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

[Shaun Jackman]

On 6/28/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:

I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that
4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32
relocations. Apparently these are a new feature and preferable in some
instances since they do reduce the number of instructions by one.
However, GOTOFF32 does not work when a the relocation is emitted for a
symbol in the .text segment. As far as I know, any XIP application
with a static callback function should fail if it's compiled with
arm-elf-gcc 4.1.x. If anyone else is using this toolchain, I'd
appreciate the confirmation. The following diff of the output from GCC
4.0.3 to GCC 4.1.1 illustrates the new behaviour.

Cheers,
Shaun


I've opened a new bug, GCC #28194 [1], for this matter.

Cheers,
Shaun

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194

Re: Visibility and C++ Classes/Templates

[Mark Mitchell]

Geoffrey Keating wrote:

> In the traditional declaration/definition model, if you try to change
> the linkage of something you get an error...

Indeed, if you consider visibility to be an intrinsic property of the
template (like its type, say), you could argue:

(1) the template gets to specify the visibility
(2) all instantiations (explicit or implicit) always get that visibility
(3) if you want a different visibility, you must use an explicit
specialization

But, I think we all agree that's too restrictive; visibility is an
extra-linguistic instruction about a low-level detail, beyond the scope
of the language itself.  So, I think that it's reasonable to allow the
visibility specification on an explicit instantiation.

I don't think a warning about a mismatch between the visibility
specified by the template and the instantiation is particularly useful
-- but maybe what we should do is try to discourage the use of the
#pragma in favor of the attribute?  (There are no scoping problems with
attributes.)

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFC: __cxa_atexit for mingw32

[Mark Mitchell]

Brian Dessent wrote:

>> is a good thing: replace an ISO standard-conformant and perfectly
>> adequate  atexit function already supplied by OS vendor with a new
>> version, perhaps with some licensing strings attached.

As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW.
 I really want MinGW to provide the ability to link to MSVCRT: nothing
more, nothing less.  Cygwin is an excellent solution if I want a more
UNIX-like environment.  I think it would be better to adopt G++ to use
whatever method Microsoft uses to handle static destructions.
Ultimately, I would like to see G++ support the Microsoft C++ ABI --
unless we can convince Microsoft to support the cross-platform C++ ABI. :-)

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFC: __cxa_atexit for mingw32

[Joe Buck]

On Wed, Jun 28, 2006 at 12:40:00PM -0400, Mark Mitchell wrote:
> As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW.
>  I really want MinGW to provide the ability to link to MSVCRT: nothing
> more, nothing less.  Cygwin is an excellent solution if I want a more
> UNIX-like environment.  I think it would be better to adopt G++ to use
> whatever method Microsoft uses to handle static destructions.
> Ultimately, I would like to see G++ support the Microsoft C++ ABI --
> unless we can convince Microsoft to support the cross-platform C++ ABI. :-)

As I understand it, Microsoft has patented aspects of their C++ class
layout.  So I don't think that G++ can support their ABI (though IANAL
and maybe there is some way around it, or maybe a mostly-compatible
approach could be designed).

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

[Hongbo Li]

Hi,

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"<

Which patch added R_ARM_GOTOFF32 support?

[Shaun Jackman]

Hello Richard, Dan,

I'm trying to track down which part of the GCC source tree makes the
decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
reference to a static function. I thought there was a good chance one
of you two might have added this feature. If you're familiar with the
the patch, would you please point me to the relevant ChangeLog entry?
I'm hoping to add an exception for execute in place (XIP) code (-fPIC
-msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32.

Many thanks,
Shaun

See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194

How to deal with 1.#IND?

[truelies]

I am using gcc 3.3.1 (20030804-1) (C/C++ only) inside MinGw in a project. I
have some double data out of range, so it returned
1.#INF,-1.#INF,1.#IND,-1.#IND.
I don't know what's difference between IND and INF?

The INF can use isinf( ) to judge it, how to judge IND?
Also INF can use if(data>0.0) to judge >0 or <0, but IND can't judge >0 or
<0 out this way. Are there other methods?Thank you so much!
-- 
View this message in context: 
http://www.nabble.com/How-to-deal-with-1.-IND--tf1862819.html#a5088616
Sent from the gcc - Dev forum at Nabble.com.

Re: Which patch added R_ARM_GOTOFF32 support?

[Andrew Haley]

Shaun Jackman writes:
 > Hello Richard, Dan,
 > 
 > I'm trying to track down which part of the GCC source tree makes the
 > decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
 > A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
 > reference to a static function. I thought there was a good chance one
 > of you two might have added this feature. If you're familiar with the
 > the patch, would you please point me to the relevant ChangeLog entry?
 > I'm hoping to add an exception for execute in place (XIP) code (-fPIC
 > -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32.
 > 
 > Many thanks,
 > Shaun
 > 
 > See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194

Use "svn blame"

Andrew.

Re: Which patch added R_ARM_GOTOFF32 support?

[Daniel Jacobowitz]

On Wed, Jun 28, 2006 at 11:20:00AM -0600, Shaun Jackman wrote:
> Hello Richard, Dan,
> 
> I'm trying to track down which part of the GCC source tree makes the
> decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
> A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
> reference to a static function. I thought there was a good chance one
> of you two might have added this feature. If you're familiar with the
> the patch, would you please point me to the relevant ChangeLog entry?
> I'm hoping to add an exception for execute in place (XIP) code (-fPIC
> -msingle-pic-base) to use R_ARM_GOT32 instead of R_ARM_GOTOFF32.

GOTOFF support has been there for a long while.  Only use of it for
static functions is recent.  It should be easy to find.  But this is
not at all the only problem.  GCC's PIC model assumes a fixed
displacement between segments.

We've implemented something similar to what you need for VxWorks.  A
couple of other places had to be changed.  I don't remember if the
VxWorks gcc port was submitted, or just the binutils bits.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Source code of CIL back-end

[Joe Buck]

On Thu, Jun 22, 2006 at 11:49:45AM +0200, Roberto COSTA wrote:
> > By the way, is there any news about the status of the CIL issue?
> > I'm sorry to bother the list readers about this, but whom could I 
> > directly ask?

I wrote:
> Sorry for the delay in answering, Robert.  I was out of town, and
> apparently people thought I'd post the answer on this one, since I
> brought up the topic for SC discussion.

Oops.  s/Robert/Roberto/.  Sorry.

Re: RFC: __cxa_atexit for mingw32

[Mark Mitchell]

Joe Buck wrote:

> As I understand it, Microsoft has patented aspects of their C++ class
> layout.

That might be, and we should investigate that before actually trying to
implement a compatible layout, but it doesn't change my opinion about
the original question regarding __cxa_atexit -- unless Microsoft's
patents extend to destruction of global objects with static storage
duration.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Visibility and C++ Classes/Templates

[Jason Merrill]

Geoffrey Keating wrote:


[#pragma visibility affecting explicit instantiations]


A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no #pragma is in effect, because the other module
may have a specific idea about what visibility should be used.


Can you give an example?  You can also get different visibility 
implicitly, if a template argument has more restricted visibility than 
the template; the instantiation gets the more restricted one.



I'm not sure how exactly they can do this.  Is there a visibility
pragma for "no setting"?


#pragma GCC visibility pop


It seems like this would be a common enough mistake that there should
be a way to get a warning about it.


I think it would be intentional more often than it would be a mistake.


In the traditional declaration/definition model, if you try to change
the linkage of something you get an error...


Yes.  If you try to change the visibility of something you also get an 
error.  But an instantiation need not have the same visibility as its 
template.


For instance, code coming from VC++ will tend to default to hidden 
visibility, but make the interfaces default visibility.  If a particular 
instantiation of a template is part of the interface of a non-template 
class, it must also get default visibility.


Jason

Re: RFC: __cxa_atexit for mingw32

[Joe Buck]

On Wed, Jun 28, 2006 at 02:21:55PM -0400, Mark Mitchell wrote:
> Joe Buck wrote:
> 
> > As I understand it, Microsoft has patented aspects of their C++ class
> > layout.
> 
> That might be, and we should investigate that before actually trying to
> implement a compatible layout, but it doesn't change my opinion about
> the original question regarding __cxa_atexit -- unless Microsoft's
> patents extend to destruction of global objects with static storage
> duration.

See

http://gcc.gnu.org/ml/gcc-help/2001-03/msg00210.html

It appears to concern only the virtual function table layout and
virtual base class layout.

Re: RFC: __cxa_atexit for mingw32

[Ross Ridge]

Mark Mitchell writes:
>As a MinGW user, I would prefer not to see __cxa_atexit added to MinGW.
>I really want MinGW to provide the ability to link to MSVCRT: nothing
>more, nothing less.

Well, even Microsoft's compiler doesn't just to link MSVCRT.DLL (or it's
successors) a certain part of C runtime is implemented as static objects
in MSVCRT.LIB.  MinGW has to provide equivilent functionality in their
static runtime library, or at least what GCC doesn't already provide in
it's runtime library.

> ... I think it would be better to adopt G++ to use whatever method
>Microsoft uses to handle static destructions.

I've looked into handling Microsoft's static constructors correctly when
linking MSC compiled objects with MinGW and I don't think it's an either
or situtation.  MinGW can handle both it's own style of construction and
Microsoft's at the same time.  I didn't look into how Microsoft handles
destructors though, because the objects in particular I was concerned
about didn't seem to use them.

>Ultimately, I would like to see G++ support the Microsoft C++ ABI --
>unless we can convince Microsoft to support the cross-platform C++ ABI. :-)

Hmm... I'm not sure which would be easier. 

btw. regarding Microsoft's patents, Google turned up this link:

http://www.codesourcery.com/archives/cxx-abi-dev/msg00097.html

That message is from 1999, so I wouldn't be surprised if Microsoft has
filed a bunch of new C++ ABI patents since then.

Ross Ridge

Need help

[ammalik]

hello:

 I am a PhD student working on optimal instruction scheduling problems. I want 
to
integrate my scheduler into the GCC. Can you tell me where to start? and
important links which can be helpful for the integration work?


Thanks
Abid Malik


This mail sent through www.mywaterloo.ca

Re: Which patch added R_ARM_GOTOFF32 support?

[Shaun Jackman]

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

GOTOFF support has been there for a long while.  Only use of it for
static functions is recent.  It should be easy to find.  But this is
not at all the only problem.  GCC's PIC model assumes a fixed
displacement between segments.


Even if a fixed displacement is a basic assumption, it doesn't seem to
affect the ARM PIC/XIP code drastically, except for this specific case
of a static callback function. Everything else seems to `just work'. A
simple "Hello, world!" application linked statically against newlib
and using stdio (which is fairly non-trivial) works, for example.

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?


We've implemented something similar to what you need for VxWorks.  A
couple of other places had to be changed.  I don't remember if the
VxWorks gcc port was submitted, or just the binutils bits.


Any chance of this work making it into GCC?

Cheers,
Shaun

Re: Which patch added R_ARM_GOTOFF32 support?

[Daniel Jacobowitz]

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.

> >We've implemented something similar to what you need for VxWorks.  A
> >couple of other places had to be changed.  I don't remember if the
> >VxWorks gcc port was submitted, or just the binutils bits.
> 
> Any chance of this work making it into GCC?

Yes - but we haven't had time to submit it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Which patch added R_ARM_GOTOFF32 support?

[Shaun Jackman]

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.

Cheers,
Shaun

Re: Need help

[Mike Stump]

On Jun 28, 2006, at 1:59 PM, [EMAIL PROTECTED] wrote:
 I am a PhD student working on optimal instruction scheduling  
problems. I want to
integrate my scheduler into the GCC. Can you tell me where to  
start? and

important links which can be helpful for the integration work?


I'd start by downloading gcc and unpacking it and then fire up  
emacs.  :-)


After that, you can read up on what to do next:

  http://gcc.gnu.org/contribute.html

Our web site has hundreds of pages of documentation...  feel free to  
read up on what ever topics you're interested in.

Re: RFC: __cxa_atexit for mingw32

[Danny Smith]

At 
Mark Mitchell wrote: 


> I think it would be better to adopt [mingw-targetted] G++ to use
> whatever method Microsoft uses to handle static destructions.
> Ultimately, I would like to see G++ support the Microsoft C++ ABI --
> unless we can convince Microsoft to support the cross-platform C++
ABI. :-)


FWIW, looking at assembly produced by MS cl.exe for the
old-deja/g++.other testcases init5.C, init18.C, init19.C, the
destructors are registered with atexit, Ditto if I replace main
with DllMain and compile as dll.

I have a patch that allows use of atexit for destructors in the same way
as
__cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next.

Danny

Re: why are we not using const?

[Kaveh R. Ghazi]

 > 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.

Something for stage1, obviously.

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

Re: why are we not using const?

[Andrew Pinski]

On Jun 28, 2006, at 7:14 PM, Kaveh R. Ghazi 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.


Oh.  With SSA, it does not matter because the dataflow is "done for you"
and there is no different between non const and const variables  
(static/global

variables is the exception).

-- Pinski

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

[Ian Lance Taylor]

"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: Visibility and C++ Classes/Templates

[Geoffrey Keating]

On 28/06/2006, at 2:21 PM, Jason Merrill wrote:


Geoffrey Keating wrote:


[#pragma visibility affecting explicit instantiations]

A consequence of this is that if a user instantiates a template that
they don't 'own' (that is, a template from a different module), they
must make sure that no #pragma is in effect, because the other module
may have a specific idea about what visibility should be used.


Can you give an example?  You can also get different visibility  
implicitly, if a template argument has more restricted visibility  
than the template; the instantiation gets the more restricted one.


Suppose a library template has (my syntax may not be quite right):

template struct foo  __attribute__((visibility("default"))) {
  static T my_var;
  T inc (T x) { return my_var += x; }
};

The intention is that all foos share the same my_var.  Obviously  
this won't work right if a #pragma on the instantiation overrides the  
visibility.



I'm not sure how exactly they can do this.  Is there a visibility
pragma for "no setting"?


#pragma GCC visibility pop


... and a way to get back to what you were using before?


It seems like this would be a common enough mistake that there should
be a way to get a warning about it.


I think it would be intentional more often than it would be a mistake.


In the traditional declaration/definition model, if you try to change
the linkage of something you get an error...


Yes.  If you try to change the visibility of something you also get  
an error.  But an instantiation need not have the same visibility  
as its template.


For instance, code coming from VC++ will tend to default to hidden  
visibility, but make the interfaces default visibility.  If a  
particular instantiation of a template is part of the interface of  
a non-template class, it must also get default visibility.


Right; and I'm not saying that there should be no way to achieve  
this, it's just that people are often unsure or unknowing of what  
pragmas might be in effect, so it might be better if they had to  
explicitly use an attribute.  Certainly if someone says


template <> foo __attribute__((visibility("hidden")));

then they ought to get what they asked for.




smime.p7s
Description: S/MIME cryptographic signature

Re: RFC: __cxa_atexit for mingw32

[Mark Mitchell]

Danny Smith wrote:

> I have a patch that allows use of atexit for destructors in the same way
> as
> __cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next.

That sounds great.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Which patch added R_ARM_GOTOFF32 support?

[Daniel Jacobowitz]

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Visibility and C++ Classes/Templates

[Joe Buck]

On Wed, Jun 28, 2006 at 10:24:27PM -0400, Geoffrey Keating wrote:
> Suppose a library template has (my syntax may not be quite right):
> 
> template struct foo  __attribute__((visibility("default"))) {
>   static T my_var;
>   T inc (T x) { return my_var += x; }
> };
> 
> The intention is that all foos share the same my_var.  Obviously  
> this won't work right if a #pragma on the instantiation overrides the  
> visibility.

Right, but it doesn't feel right to me to protect the user from himself.
In this case, the user might say "it hurts when I do that" and we can
reply "then don't do that!"

There might be another case where changing the visibility is exactly
what the user needs to do to solve a problem.

> Right; and I'm not saying that there should be no way to achieve  
> this, it's just that people are often unsure or unknowing of what  
> pragmas might be in effect, so it might be better if they had to  
> explicitly use an attribute.  Certainly if someone says
> 
> template <> foo __attribute__((visibility("hidden")));
> 
> then they ought to get what they asked for.

Agreed.  We shouldn't try to outsmart the user; it makes sense to
use the most specific information we are given (so an attribute
on a specialization would override an attribute on the template).

Re: why are we not using const?

[Gabriel Dos Reis]

"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:

[...]

| 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.

Yes, totally agreed -- that would be more profitable.

-- Gaby

How to use gcc4 to compile FreeBSD6.0 ?

[Beyond.Luo]

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?