Re: Some notes on the Wiki

[Paolo Bonzini]

In fact, i had someone recently send me a *104 page PDF file* on how RTL
really works organized in a way that most developers would probably find
better.


If the guy has copyright assignment on file, I can volunteer to convert 
this.  Is the PDF made from latex?  If so I have some scripts to aid.


Paolo

Re: Some notes on the Wiki

[Paolo Bonzini]

> It was reviewed the very same day it was submitted:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html

>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html


where you said:

> (and possibly to your tutorial as a separate page if
> it still seems desirable to have it as a coherent tutorial).

The page ended up on the wiki rather than wwwdocs.

Paolo

Re: Some notes on the Wiki

[Paolo Bonzini]

> It was reviewed the very same day it was submitted:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html

>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html


where you said:

> (and possibly to your tutorial as a separate page if
> it still seems desirable to have it as a coherent tutorial).

The page ended up on the wiki rather than wwwdocs.

Paolo

Re: Built gcc 4.0.0, without C++ support

[Jeroen Scheerder]

Rainer Orth (25/4/05 12:28 +0200) [Re: Built gcc 4.0.0, without C++
support]:

>> Partial success only.  I think I'll be able to build it without C++
>> support, but compilation per your instruction does choke on
>>libstdc++.so.6.0.4.
>
>I've had the same problem and think I know what's going on.

[...]

>So obviously Sun ld doesn't have the necessary support for COMDAT groups
>(even with GNU ld, a quite recent version seems to be required).
>Unfortunately, gcc's configure.ac doesn't check for this, but should.

FWIW, I just started building gcc 4.0.1, and ran into this problem once
again; and setting HAVE_GAS_COMDAT_GROUP to 0 in gcc/auto-host.h seems
once again to be a valid workaround.

Re: Some notes on the Wiki

[Michael Cieslinski]

I converted this patch because I thought it would be helpful after
reading this message from Giovanni Bajo:
http://gcc.gnu.org/ml/gcc/2005-03/msg00552.html
> 
> I had provided this patch in the past, but was rejected:
> http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
> 
> I never had time to split, rewrite in tex, and update it as requested.
> Janis recently incorporated some parts into the internal manuals, but I
> believe that we still nedd provide a "tutorial for GCC testcase 
> writing". Like I'm trying to explain in another thread, I believe that
> we are being way too picky on www/documentation patches than we should
> be.
> 
> For instance, my patch could have been committed immediatly and been
> refined over time. In fact, I should find a couple of hours to add it
> to the Wiki.
> -- 
> Giovanni Bajo
> 

>From my point of view the wiki is THE place for documentation. It is very
easy to put new things in, edit or correct it. I'm familiar with it but I
never used texinfo nor did I ever sent a patch.

I look daily at the wiki and check if somebody puts spam in it. 

I would also propose to make the wiki the primary source of documentation
and derive a static html page from it which could be downloaded and used
locally.

I volunteer to convert the 104 page RTL pdf into wiki pages (if Daniel
sends it to me).

I also could convert parts of the ggcinternals manual into wiki pages.
But only if there is a consensus about this being the way to go.


Michael Cieslinski

Re: Some notes on the Wiki (was: 4.1 news item)

[Giovanni Bajo]

Gerald Pfeifer <[EMAIL PROTECTED]> wrote:

> It was reviewed the very same day it was submitted:
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html

Yes. And the review was very detailed, and suggested that I had to redone to
work almost from scratch, scattering the infos across a dozen of files in
both WWW and TeX format where they really belong (including Dejagnu's
documentation), *plus* I could also provide the existing page as a tutorial
with references.

I would like to thank you and Joseph Myers for the accurate and fast review.
The point is that it took me already long enough to prepare that patch, and
I never had time (nor will, let me admit) to go back and redo the work in a
different way.

What happened next is that I started providing the link to the gcc-patches
mail over IRC, and then in the list, and then in private mail. And people
were thanking me for it, because it was very helpful. So, I realized that,
while the improvements you suggested were legitimate and correct, that text
was already very useful *the way it is* *right now*. So, it was put in the
Wiki. And I know many people have read it and found it useful. If you want,
you can add a plea at the bottom of the Wiki page, summing the reviews and
asking volunteers to incorporate it into the documentation in the proper
places.

I already expressed my concerns about the way documentation patches work in
other threads. I myself am uninterested in contributing documentation
patches to TeX (and pretty discouraged about the WWW patches, even if I do
that regularly, as you well know). Instead, I contributed many things to the
Wiki. Given the way things like Wikipedia work out, I think we need to
either review our documentation system, or, if there is too much politics
going on with the FSF, accept the fact that the documentation *is* going to
be forked, and setup a workflow to contribute stuff back from the wiki to
the official documentation.

My personal position is that making documentation patches *blocked* by
review (as happens with code) is wrong. The worst thing it can happen is
that the documentation patch is wrong, and the doc maintainer can revert it
in literally seconds (using the Wiki; in minutes/hours using the TeX).
Nobody is going to be blocked by this; no bootstrap will be broken; no wrong
code will be generated. This ain't code. In many common cases, the
documentation will be useful effectively immediatly, and
typos/subtleties/formatting can be refined by others over time.
-- 
Giovanni Bajo

Re: Some notes on the Wiki (was: 4.1 news item)

[Joseph S. Myers]

On Mon, 11 Jul 2005, Giovanni Bajo wrote:

> My personal position is that making documentation patches *blocked* by
> review (as happens with code) is wrong. The worst thing it can happen is
> that the documentation patch is wrong, and the doc maintainer can revert it
> in literally seconds (using the Wiki; in minutes/hours using the TeX).

It's not for the doc maintainer to know whether most doc patches are 
correct or not; it should be the maintainer of the relevant parts of the 
compiler who reviews them in general.

> Nobody is going to be blocked by this; no bootstrap will be broken; no wrong
> code will be generated. This ain't code. In many common cases, the

Wrong code will be generated when someone relies on subtly wrong 
information in the documentation.  It is a well-established failure mode 
even on the best wikis (i.e. Wikipedia) that someone inserts subtly wrong 
information because of not knowing better (or not knowing that there is 
controversy among experts about which of two versions is correct) and this 
does not get corrected soon if at all.  There may be *policies* of 
providing references to back up claims made, but (a) that can't work in 
the context of GCC and (b) I don't see Wikipedia edits routinely getting 
reverted simply for lack of substantiating evidence.  We're dealing with 
subtle matters where there may be no one expert on the subject, and where 
reversion may not in general be any better than applying the patch: where 
the proper response will involve discussion of the individual edit to 
clarify the basis for the claims made and whether things should be 
refined.

Perhaps the wiki could automatically send all changes to gcc-patches to 
assist in review?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Calling a pure virtual function

[Jonathan Wakely]

On Sat, Jul 09, 2005 at 08:41:47PM +1000, Adam Nielsen wrote:

> Hi all,
> 
> I was expecting the following code snippet to work, so am I doing
> something wrong, or is there an issue with GCC?  I was under the
> impression that this is allowed, according to
> http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.1

As you've discovered, FAQ 23.3 gives more detail.

> It seems like GCC initially allows it as it starts to compile okay, but
> then I get an undefined reference error from the linker (because it
> seems to be actually calling Base::number(), which obviously won't work
> as it's a pure virtual function.)

It's allowed, and will work, but you have to provide a definition for
the function.  Calling number() from the base constructor calls
Base::number() so you have to define it.

GOTW 31 discusses topics related to this: http://www.gotw.ca/gotw/031.htm

GCC is doing exactly the right thing here, it's not possible to tell
that the definition of Base::number() is missing until link time.

jon

Re: Some notes on the Wiki (was: 4.1 news item)

[Giovanni Bajo]

Joseph S. Myers <[EMAIL PROTECTED]> wrote:

>> Nobody is going to be blocked by this; no bootstrap will be broken; no
>> wrong code will be generated. This ain't code. In many common cases, the
>
> Wrong code will be generated when someone relies on subtly wrong
> information in the documentation.  It is a well-established failure mode
> even on the best wikis (i.e. Wikipedia) that someone inserts subtly wrong
> information because of not knowing better (or not knowing that there is
> controversy among experts about which of two versions is correct) and this
> does not get corrected soon if at all.

That is right, but there are level of interests. The debate can be on some
small detail, while the big picture is still good enough for beginners or
intermediates. Having something which is possibly wrong on some subtle
details is still better than having nothing at all. As I said, I am a strong
sustainer of "commit now, refine later".

> (b) I don't see Wikipedia edits routinely getting
> reverted simply for lack of substantiating evidence.

Yeah, but I widely use it and it is still very useful. It may not be 1000%
correct in each word, so what? Are printed books any better? Or is there a
real only truth? We're entering philosphy here. What is certain is that
Wikipedia wouldn't be 1/1000th of that if there was a review process for
each patch being submitted.

> Perhaps the wiki could automatically send all changes to gcc-patches to
> assist in review?


I strongly support this (and was going to suggest this myself). I'd rather
it be another list though, say wiki-patches or doc-patches, because of the
amount of traffic that is going to be generated (think of all those small
typo fixes, or spam reverts).
-- 
Giovanni Bajo

Re: Re: Some notes on the Wiki

[Joseph S. Myers]

On Mon, 11 Jul 2005, Michael Cieslinski wrote:

> I also could convert parts of the ggcinternals manual into wiki pages.
> But only if there is a consensus about this being the way to go.

I'm sure it's the wrong way to go.  I find a properly formatted and 
indexed book far more convenient for learning about substantial areas of 
compiler internals, or for finding what some particular macro is specified 
to do, than a wiki.  And since some people seem to think the internal 
manual is of no use: it's the first place I refer to for information on 
the areas of internals it covers; after that source code and mailing list 
archives, the wiki very rarely.

I think the wiki is certainly useful for rough notes such as 
, synthesised from 
mailing list discussions.

It may be useful as an intermediate step in putting together 
reverse-engineered information about internals in order to specify it 
properly in the internals manual - but only provided authorship and 
copyright assignment information is rigorously tracked as required by the 
FSF.

But in general internals documentation should include the *specification* 
written before the implementation and submitted with it for review 
together, and the specification should not need to be reverse-engineered 
later (see Kenner's comments passim about the importance of comments being 
written at the time of code or at least by its author, not backfilled 
later).

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Some notes on the Wiki

[Russell Shaw]

Joseph S. Myers wrote:

On Mon, 11 Jul 2005, Michael Cieslinski wrote:


I also could convert parts of the ggcinternals manual into wiki pages.
But only if there is a consensus about this being the way to go.


I'm sure it's the wrong way to go.  I find a properly formatted and 
indexed book far more convenient for learning about substantial areas of 
compiler internals, or for finding what some particular macro is specified 
to do, than a wiki.  And since some people seem to think the internal 
manual is of no use: it's the first place I refer to for information on 
the areas of internals it covers; after that source code and mailing list 
archives, the wiki very rarely.


I think the wiki is certainly useful for rough notes such as 
, synthesised from 
mailing list discussions.


It may be useful as an intermediate step in putting together 
reverse-engineered information about internals in order to specify it 
properly in the internals manual - but only provided authorship and 
copyright assignment information is rigorously tracked as required by the 
FSF.


Just put in a clause that copyright of all additions automatically
reverts to FSF.

Re: Built gcc 4.0.0, without C++ support

[Rainer Orth]

Jeroen Scheerder writes:

> Rainer Orth (25/4/05 12:28 +0200) [Re: Built gcc 4.0.0, without C++
> support]:
> 
> >> Partial success only.  I think I'll be able to build it without C++
> >> support, but compilation per your instruction does choke on
> >>libstdc++.so.6.0.4.
> >
> >I've had the same problem and think I know what's going on.
> 
> [...]
> 
> >So obviously Sun ld doesn't have the necessary support for COMDAT groups
> >(even with GNU ld, a quite recent version seems to be required).
> >Unfortunately, gcc's configure.ac doesn't check for this, but should.
> 
> FWIW, I just started building gcc 4.0.1, and ran into this problem once
> again; and setting HAVE_GAS_COMDAT_GROUP to 0 in gcc/auto-host.h seems
> once again to be a valid workaround.

I think this was fixed on mainline by this patch (or a slightly modified
version actually committed):

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00540.html

It should probably be backported to the 4.0 branch.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

why are there many copies of function_decls that have the same information including the same uid?

[Kenneth Zadeck]

Is this a bug or a feature?

Re: why are there many copies of function_decls that have the same information including the same uid?

[Daniel Berlin]

On Mon, 2005-07-11 at 08:40 -0400, Kenneth Zadeck wrote:
> Is this a bug or a feature?
Bug.
where is it occurring?

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Paul Koning]

> "Falk" == Falk Hueffner <[EMAIL PROTECTED]> writes:

 >> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
 >> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
 >> core_cia.i

 Falk> I don't see any fault on gcc's side here. You could argue that
 Falk> the command line option for as should override the ".arch", but
 Falk> I think it's been like this forever. So you should probably
 Falk> just add ".arch ev6" inside the asm (annoyingly, gas doesn't
 Falk> seem to have ".arch any" or similar).

More appropriate would be to make the command line consistent with the
code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
appropriate.  Conversely, if the code really is supposed to run on an
ev5, then -Wa,mev5 is the right fix and the inline assembly should
stick to instructions that exist on that machine.

  paul

Re: Re: Some notes on the Wiki

[Paul Koning]

> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:

 Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
 >> I also could convert parts of the ggcinternals manual into wiki
 >> pages.  But only if there is a consensus about this being the way
 >> to go.

 Joseph> I'm sure it's the wrong way to go.  I find a properly
 Joseph> formatted and indexed book far more convenient for learning
 Joseph> about substantial areas of compiler internals, or for finding
 Joseph> what some particular macro is specified to do, than a wiki.

I'll second that.  Unlike some other major GNU projects, GCC's
internals manual is substantial and very good.  Yes, it needs ongoing
improvement, but I'd prefer that rather than flipping to Twiki.

 paul

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Paul Koning wrote:

"Falk" == Falk Hueffner <[EMAIL PROTECTED]> writes:



 >> $ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
 >> -mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
 >> core_cia.i

 Falk> I don't see any fault on gcc's side here. You could argue that
 Falk> the command line option for as should override the ".arch", but
 Falk> I think it's been like this forever. So you should probably
 Falk> just add ".arch ev6" inside the asm (annoyingly, gas doesn't
 Falk> seem to have ".arch any" or similar).

More appropriate would be to make the command line consistent with the
code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
appropriate.  Conversely, if the code really is supposed to run on an
ev5, then -Wa,mev5 is the right fix and the inline assembly should
stick to instructions that exist on that machine.


The code is in linux-2.6.*/asm-alpha/compiler.h.
Inspection shows that the code really is supposed to run on an ev5;
it uses the LDBU in inline assembly and expects the
assembler to expand that to something that can run on ev4,
which should work according to
http://msdn.microsoft.com/library/en-us/aralpha98/html/load_byte_unsigned_ldbu.asp
The problem is then the -Wa,-mev6.  And voila, linux-2.6.*/arch/alpha/Makefile
seems to add that unconditionally:

# For TSUNAMI, we must have the assembler not emulate our instructions.
# The same is true for IRONGATE, POLARIS, PYXIS.
# BWX is most important, but we don't really want any emulation ever.
CFLAGS += $(cflags-y) -Wa,-mev6

I'll punt this to the alpha linux kernel folks.

Thanks for the help!
- Dan

--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: why are there many copies of function_decls that have the same information including the same uid?

[Andrew Pinski]

On Jul 11, 2005, at 8:50 AM, Daniel Berlin wrote:


On Mon, 2005-07-11 at 08:40 -0400, Kenneth Zadeck wrote:

Is this a bug or a feature?

Bug.
where is it occurring?


I want to say the C++ front-end since that is where a couple of
ICEs have showed up because of that.

-- Pinski

Offset and Bit Mask for Bit Fields?

[Dimitry Golubovsky]

Hi,

If one wants to automatically determine offset of a regular field in a
C structure, one uses `offsetof'

According to the documentation, 

==
This macro (offsetof) won't work if member is a bit field; you get an
error from the C compiler in that case.
==

Do there exist any means in gcc to measure offsets (of enclosing
integer field) and bit mask for bit fields?

If not, any chance to add them in the future?

-- 
Dimitry Golubovsky

Anywhere on the Web

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 15:54, Paul Koning wrote:
> > "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
>
>  Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
>  >> I also could convert parts of the ggcinternals manual into wiki
>  >> pages.  But only if there is a consensus about this being the way
>  >> to go.
>
>  Joseph> I'm sure it's the wrong way to go.  I find a properly
>  Joseph> formatted and indexed book far more convenient for learning
>  Joseph> about substantial areas of compiler internals, or for finding
>  Joseph> what some particular macro is specified to do, than a wiki.
>
> I'll second that.  Unlike some other major GNU projects, GCC's
> internals manual is substantial and very good.  Yes, it needs ongoing
> improvement, but I'd prefer that rather than flipping to Twiki.

So, contribute to the manual then.  And let the folks who prefer to
work on the wiki work on the wiki.

Unless we are going to require reviewing for wiki changes now, too,
there is no point in this entire discussion.  And if we are going
to require reviewing for the wiki, there is no point in having the
wiki.

Gr.
Steven

Re: Offset and Bit Mask for Bit Fields?

[Andrew Haley]

Dimitry Golubovsky writes:
 > 
 > If one wants to automatically determine offset of a regular field in a
 > C structure, one uses `offsetof'
 > 
 > According to the documentation, 
 > 
 > ==
 > This macro (offsetof) won't work if member is a bit field; you get an
 > error from the C compiler in that case.
 > ==

Yes, because it's not addressable.

 > Do there exist any means in gcc to measure offsets (of enclosing
 > integer field) and bit mask for bit fields?

No.

 > If not, any chance to add them in the future?

I doubt it.  We're very reluctant to add new language extensions to C,
and this one would be very problematic.

Andrew.

'main' enters in gcc-4.1

[Perret Yannick]

(second send, as I never saw my first send on the mailing list.
sorry if duplicated).

Hello,

I'm using '-finstrument-functions' for a while
to make function-level profiling.
Recently, I compiled gcc-4.1 (without problem)
and used it for the same purpose.

Here is the result :
>>>
 Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=0
 Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
 Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=0
 Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=6
 Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
 Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=176
 Enter main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=0
 Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
 Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=1
 Enter orig (essai.c:23) [0x8048f20] from 0x8049448 - PID=1774 - elaps=1
(...)
 Exit main (essai.c:41) [0x80490b0] from 0x4003be36 - PID=1774 - elaps=198
<<<

This test program is a very small C program with 'main' calling two
functions in a loop, compiled with -O2. These messages are
generated by my __cyg_profile_{enter|exit} functions.

as you can see GCC generates 3 consecutive calls to 'main', then 2
exits, 2 enters, and 2 exits.
At last it is coherent, but this behavior does not appear in older
versions of GCC.

Can you explain me why I see that behavior? Is it "good" or is it a bug?
Of cours this is a little disturbing for people that make the assumption
that 'main' is called once :o)

Thanks in advance.

Regards,
--
Yannick Perret

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 16:19, Diego Novillo wrote:
> Would a blanket statement at the start of the wiki be enough?
> Who gets to decide this?

I guess that, apart from the legal discussion of whether this enough,
such a statement would not apply to existing content.  It was certainly
not my intention to sign over the various Wiki contributions I have
made to the FSF.

Gr.
Steven

Re: Some notes on the Wiki

[Diego Novillo]

On Mon, Jul 11, 2005 at 04:10:56PM +0200, Steven Bosscher wrote:

> So, contribute to the manual then.  And let the folks who prefer to
> work on the wiki work on the wiki.
> 
I believe the Wiki is an invaluable documentation tool, precisely
because it allows such an unencumbered contribution process.
Also, some of the things documented in the wiki are either
inappropriate for the manual or too dynamic in nature.  I can see
both co-existing for a long time.

However, it would be very useful for us to transfer information
from the wiki into the manual from time to time.  And we cannot
do that if we don't have cleared out the copyright assignment of
wiki content.

Would a blanket statement at the start of the wiki be enough?
Who gets to decide this?


Diego.

Warnings when build gcc-4.0.2

[Feng Wang]

When building gcc-4.0.2 I find many warnings about redefined HAVE_DECL_GETOPT.
Are they what we expect?

version: 4.0.2 20050711 (prerelease)
configuration: ../gcc/configure --prefix=/home/wf/local
--enable-languages=c,f95
host and target: i686-pc-linux-gnu

#grep warning buildlog.txt
[snip]
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
defi
[snip]


Best Regards,
Feng Wang

--
Creative Compiler Research Group,
National University of Defense Technology, China.

__
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com

Re: Some notes on the Wiki

[Haren Visavadia]

--- Diego Novillo wrote:
> And we cannot
> do that if we don't have cleared out the copyright
> assignment of
> wiki content.

And so?





___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: Warnings when build gcc-4.0.2

[H. J. Lu]

On Mon, Jul 11, 2005 at 10:27:52PM +0800, Feng Wang wrote:
> When building gcc-4.0.2 I find many warnings about redefined HAVE_DECL_GETOPT.
> Are they what we expect?
> 
> version: 4.0.2 20050711 (prerelease)
> configuration: ../gcc/configure --prefix=/home/wf/local
> --enable-languages=c,f95
> host and target: i686-pc-linux-gnu
> 
> #grep warning buildlog.txt
> [snip]
> ./auto-host.h:250:1: warning: "HAVE_DECL_GETOPT" redefined
> ../../gcc/gcc/tsystem.h:40:1: warning: this is the location of the previous
> defi

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21388


H.J.

Re: Some notes on the Wiki

[Diego Novillo]

On Mon, Jul 11, 2005 at 03:41:25PM +0100, Haren Visavadia wrote:
> --- Diego Novillo wrote:
> > And we cannot
> > do that if we don't have cleared out the copyright
> > assignment of
> > wiki content.
> 
> And so?
> 
Sorry, I don't understand what you're asking.

My line of thought was described in the text that you removed:
"However, it would be very useful for us to transfer information
from the wiki into the manual from time to time."


Diego.

Re: Some notes on the Wiki

[Bernd Schmidt]

Steven Bosscher wrote:

I guess that, apart from the legal discussion of whether this enough,
such a statement would not apply to existing content.  It was certainly
not my intention to sign over the various Wiki contributions I have
made to the FSF.


This strikes me as shortsighted.  If we're getting into a situation 
where we can't freely move documentation from one place to another, 
we're shooting ourselves in the foot.



Bernd

Re: Offset and Bit Mask for Bit Fields?

[Manu Abraham]

Andrew Haley wrote:


Dimitry Golubovsky writes:
> 
> If one wants to automatically determine offset of a regular field in a

> C structure, one uses `offsetof'
> 
> According to the documentation, 
> 
> ==

> This macro (offsetof) won't work if member is a bit field; you get an
> error from the C compiler in that case.
> ==

Yes, because it's not addressable.

 

I ask this question in this thread because i think it is very much 
similar ..


Suppose i have a struct like this ?

struct stream {
 uint8_tstream_type: 8;
 uint16_treserved_1: 3;
 uint16_telementary_pid: 13;
 uint16_treserved_2: 4;
 uint16_tes_info_length: 12;

 void*descriptor;
};

struct pmt {
 uint8_ttable_id: 8;
 uint16_tsection_syntax : 1;
 uint16_treserved_1: 1;
 uint16_treserved_2: 2;
 uint16_tsection_length: 12;
 uint16_tprogram_number: 16;
 uint8_treserved_3: 2;
 uint8_tversion_number: 5;
 uint8_tcurrent_next: 1;
 uint8_tsection_number: 8;
 uint8_tlast_section: 8;
 uint16_treserved_4: 3;
 uint16_tpcr_pid: 13;
 uint16_treserved_5: 4;
 uint16_tprogram_info_length: 12;

 void*descriptor;

 struct stream*streams;
};

The incoming bitsream is bigendian. My target platform is a desktop PC , 
little endian.


I was looking at how i can implement a parser based upon this structure, 
without having to do a


* get_bits() using shifts and a mask
* or a shift and a mask alone.

I initially had the idea of copying the bitstream straight away to the 
struct considering memory allocated is the same, trying to handle 
endianness in some manner in the copy procedure.


If somebody could comment on what would be the best way to about it, 
that would be quite helpful.



Thanks,
Manu

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> Steven Bosscher wrote:
> > I guess that, apart from the legal discussion of whether this enough,
> > such a statement would not apply to existing content.  It was certainly
> > not my intention to sign over the various Wiki contributions I have
> > made to the FSF.
>
> This strikes me as shortsighted.

Call it what you will.  For me it is a matter of choice and freedom.

> If we're getting into a situation 
> where we can't freely move documentation from one place to another,
> we're shooting ourselves in the foot.

We already can't do that.  We can't move documentation from the manual
into the code, and vice versa, because of the GPL vs. GFDL issue.  It
is that kind of thing that completely takes away any motivation I might
otherwise have to contribute to the manual.

And again, if you're going to require reviewing and copyright assignment
for wiki contributions, we might as well not have a wiki at all.

Gr.
Steven

Where does the C standard describe overflow of signed integers?

[Nicholas Nethercote]

Hi,

There was recently a very long thread about the overflow behaviour of 
signed integers in C.  Apparently this is undefined according to the C 
standard.  I searched the standard on this matter, and while I did find 
some paragraphs that described how unsigned integers must wrap around upon 
overflow, I couldn't find anything explicit about signed integers.  Can 
someone point me to the relevant part(s) of the standard?


Also, does anyone know what the required behaviour for Fortran integers is 
on overflow?


(I realise this isn't exactly on-topic for this list, but I thought it 
reasonable to ask since this topic was discussed so enthusiastically 
recently :)


Thanks very much.

Nick

Re: Some notes on the Wiki

[Haren Visavadia]

> --- Diego Novillo wrote:
> > Sorry, I don't understand what you're asking.
> > 
> > My line of thought was described in the text that
> > you removed:
> > "However, it would be very useful for us to
> transfer
> > information
> > from the wiki into the manual from time to time."
> > 
I am suggesting is if the content is on Wiki and not
in the manual and you can not get the copyright
assignment, there is nothing you can do about it
except live with it.
 
In fact, you would be lucky to have the content on
Wiki.
 



___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

RE: Where does the C standard describe overflow of signed integers?

[Dave Korn]

Original Message
>From: Nicholas Nethercote
>Sent: 11 July 2005 15:59

> Hi,
> 
> There was recently a very long thread about the overflow behaviour of
> signed integers in C.  Apparently this is undefined according to the C
> standard.  I searched the standard on this matter, and while I did find
> some paragraphs that described how unsigned integers must wrap around upon
> overflow, I couldn't find anything explicit about signed integers.

  Anything not defined is undefined, by definition!

>  Can someone point me to the relevant part(s) of the standard?

  :) I can only point you at the whole thing, where it doesn't define it
anywhere.

  See also 3.4.3/3, and H.2.2.

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

Re: ix86_value_regno and callers

[Richard Guenther]

On Wed, 6 Jul 2005, Richard Henderson wrote:

> On Tue, Jul 05, 2005 at 05:14:44PM +0200, Richard Guenther wrote:
> > I'm lost in the mysteries of expansion of the indirect call, also
> > ix86_value_regno gets called all over the place, so the "interesting"
> > call-site is hard to find.
> 
> We'll have to change the FUNCTION_VALUE interface to handle this.
> 
> I suggest doing this as a target hook:
> 
>   rtx function_value (tree ret_type, tree fn_decl_or_type, bool outgoing)

Ok, the fix (that is only working for i386 ATM, I guess) looks 
like something along attached below.  To make this a clean interface
I'd suggest making hard_function_value take an extra argument, the
fntype, and also FUNCTION_OUTGOING_VALUE/FUNCTION_VALUE, and possibly
making that a target hook like you suggested (though this was a
cleaup only?  Or did you mean to bail out for TYPE_P func in the
default implementation?)

Richard.



2005-07-11  Richard Guenther  <[EMAIL PROTECTED]>

* calls.c (expand_call): Pass fntype to hard_function_value,
if decl is not available.
* explow.c (hard_function_value): Document we also can get
a function type as argument.
* config/i386/i386.c (ix86_value_regno): Deal with both type
and decl argument.


Index: calls.c
===
RCS file: /cvs/gcc/gcc/gcc/calls.c,v
retrieving revision 1.392
diff -c -3 -p -r1.392 calls.c
*** calls.c 26 Jun 2005 05:27:05 -  1.392
--- calls.c 11 Jul 2005 15:00:44 -
*** expand_call (tree exp, rtx target, int i
*** 2519,2525 
valreg = hard_function_value (build_pointer_type (TREE_TYPE (exp)),
  fndecl, (pass == 0));
  else
!   valreg = hard_function_value (TREE_TYPE (exp), fndecl, (pass == 0));
}
  
/* Precompute all register parameters.  It isn't safe to compute 
anything
--- 2519,2526 
valreg = hard_function_value (build_pointer_type (TREE_TYPE (exp)),
  fndecl, (pass == 0));
  else
!   valreg = hard_function_value (TREE_TYPE (exp), fndecl ? fndecl : 
fntype,
! (pass == 0));
}
  
/* Precompute all register parameters.  It isn't safe to compute 
anything
Index: explow.c
===
RCS file: /cvs/gcc/gcc/gcc/explow.c,v
retrieving revision 1.147
diff -c -3 -p -r1.147 explow.c
*** explow.c25 Jun 2005 01:59:47 -  1.147
--- explow.c11 Jul 2005 15:00:44 -
*** probe_stack_range (HOST_WIDE_INT first, 
*** 1405,1412 
  /* Return an rtx representing the register or memory location
 in which a scalar value of data type VALTYPE
 was returned by a function call to function FUNC.
!FUNC is a FUNCTION_DECL node if the precise function is known,
!otherwise 0.
 OUTGOING is 1 if on a machine with register windows this function
 should return the register in which the function will put its result
 and 0 otherwise.  */
--- 1405,1412 
  /* Return an rtx representing the register or memory location
 in which a scalar value of data type VALTYPE
 was returned by a function call to function FUNC.
!FUNC is a FUNCTION_DECL or FUNCTION_TYPE node if the precise function
!is known, otherwise 0.
 OUTGOING is 1 if on a machine with register windows this function
 should return the register in which the function will put its result
 and 0 otherwise.  */
Index: config/i386/i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.841
diff -c -3 -p -r1.841 i386.c
*** config/i386/i386.c  11 Jul 2005 09:35:16 -  1.841
--- config/i386/i386.c  11 Jul 2005 15:00:47 -
*** ix86_value_regno (enum machine_mode mode
*** 3349,3355 
   SSE math is enabled or for functions with sseregparm attribute.  */
if (func && (mode == SFmode || mode == DFmode))
  {
!   int sse_level = ix86_function_sseregparm (TREE_TYPE (func), func);
if ((sse_level >= 1 && mode == SFmode)
  || (sse_level == 2 && mode == DFmode))
  return FIRST_SSE_REG;
--- 3349,3356 
   SSE math is enabled or for functions with sseregparm attribute.  */
if (func && (mode == SFmode || mode == DFmode))
  {
!   int sse_level = ix86_function_sseregparm (DECL_P (func) ? TREE_TYPE 
(func) : func,
!   DECL_P (func) ? func : 0);
if ((sse_level >= 1 && mode == SFmode)
  || (sse_level == 2 && mode == DFmode))
  return FIRST_SSE_REG;

Re: Where does the C standard describe overflow of signed integers?

[Nathan Sidwell]

Nicholas Nethercote wrote:

Hi,

There was recently a very long thread about the overflow behaviour of 
signed integers in C.  Apparently this is undefined according to the C 
standard.  I searched the standard on this matter, and while I did find 
some paragraphs that described how unsigned integers must wrap around 
upon overflow, I couldn't find anything explicit about signed integers.  
Can someone point me to the relevant part(s) of the standard?


c99 6.5 para 5 (overflow is undefined) & 6.3.1.3 (conversions to unsigned type 
obey modulo laws)


c++ 5 para 5 (overflow is undefined, unless otherwise stated) & 3.9.1 para 4 
(unsigned types obey modulo laws)


I cannot find, in c99, a statement that all unsigned arithmetic obeys modulo 
laws -- only that integral conversions to them do.


nathan

--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Overflow in Fortran (was: Where does the C standard describe overflow of signed integers?)

[Paul Brook]

On Monday 11 July 2005 15:58, Nicholas Nethercote wrote:
> Also, does anyone know what the required behaviour for Fortran integers is
> on overflow?

Section 7.1.7 "Evaluation of operation"

"The evaluation of any numeric operation whose result is not defined by the 
arithmetic used by the processor[1] is prohibited"

Section 13.7.1 "Models for integer and real data"

The model set for integer i is defined by:
[sign + magnitude]


ie. overflow is not defined, and we can do whatever the hell we want.

Paul

[1] In this context "processor" means language processor, ie. a combination 
the compiler, OS and target hardware.

Re: Some notes on the Wiki

[Joseph S. Myers]

On Mon, 11 Jul 2005, Steven Bosscher wrote:

> On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> > Steven Bosscher wrote:
> > > I guess that, apart from the legal discussion of whether this enough,
> > > such a statement would not apply to existing content.  It was certainly
> > > not my intention to sign over the various Wiki contributions I have
> > > made to the FSF.
> >
> > This strikes me as shortsighted.
> 
> Call it what you will.  For me it is a matter of choice and freedom.
> 
> > If we're getting into a situation 
> > where we can't freely move documentation from one place to another,
> > we're shooting ourselves in the foot.
> 
> We already can't do that.  We can't move documentation from the manual
> into the code, and vice versa, because of the GPL vs. GFDL issue.  It
> is that kind of thing that completely takes away any motivation I might
> otherwise have to contribute to the manual.

1. If GCC developers wish to move documentation from the GPL code to the 
GFDL manuals, or vice versa, what procedures need to be followed?

2. Do existing GCC copyright assignments cover the GCC Wiki 
?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Some notes on the Wiki

[Andrew Haley]

Steven Bosscher writes:
 > On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
 > > Steven Bosscher wrote:
 > > > I guess that, apart from the legal discussion of whether this enough,
 > > > such a statement would not apply to existing content.  It was certainly
 > > > not my intention to sign over the various Wiki contributions I have
 > > > made to the FSF.
 > >
 > > This strikes me as shortsighted.
 > 
 > Call it what you will.  For me it is a matter of choice and freedom.
 > 
 > > If we're getting into a situation 
 > > where we can't freely move documentation from one place to another,
 > > we're shooting ourselves in the foot.
 > 
 > We already can't do that.  We can't move documentation from the manual
 > into the code, and vice versa, because of the GPL vs. GFDL issue.

Actually, that's not true because *we* (or to be accurate the FSF) own
the copyright on both.

 > It is that kind of thing that completely takes away any motivation
 > I might otherwise have to contribute to the manual.
 > 
 > And again, if you're going to require reviewing and copyright assignment
 > for wiki contributions, we might as well not have a wiki at all.

Good idea.

Andrew.

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 16:22 +0200, Steven Bosscher wrote:
> On Monday 11 July 2005 16:19, Diego Novillo wrote:
> > Would a blanket statement at the start of the wiki be enough?
> > Who gets to decide this?
> 
> I guess that, apart from the legal discussion of whether this enough,
> such a statement would not apply to existing content.  It was certainly
> not my intention to sign over the various Wiki contributions I have
> made to the FSF.
We can't get copyright assignments, we can however get effective online
estoppel agreements, like wikipedia does.

This should be enough for documentation, one would hope.

RE: Where does the C standard describe overflow of signed integers?

[Dave Korn]

Original Message
>From: Nathan Sidwell
>Sent: 11 July 2005 16:15

> c99 6.5 para 5 (overflow is undefined) 

  Have I got an old draft or something, or is that the paragraph that begins
"If an _exceptional_ _condition_ occurs ..." ?

> I cannot find, in c99, a statement that all unsigned arithmetic obeys
> modulo laws -- only that integral conversions to them do.

  Like I say, I'm not sure exactly what draft/version/spec I have here in
front of me, except that it says "ISO/IEC 9899:1999 (E)" at the top of each
page, but I've got a para 9 in 6.2.5 that says 

" ... A computation involving unsigned operands can never overflow, because
a  result that cannot be represented by the resulting unsigned integer type
is reduced modulo the number that is one greater than the largest value that
can be
represented by the resulting type."

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

Re: Some notes on the Wiki

[Steven Bosscher]

On Monday 11 July 2005 17:21, Andrew Haley wrote:
>  > We already can't do that.  We can't move documentation from the manual
>  > into the code, and vice versa, because of the GPL vs. GFDL issue.
>
> Actually, that's not true because *we* (or to be accurate the FSF) own
> the copyright on both.

To play the Devil's advocate: One could argue that someone contributing
to the GCC code under the GPL does not agree with the GFDL, and therefore
the FSF can't live up to its promise (that iirc it makes in the copyright
assignment) to keep the code under a free license.

In practice, people have already contributed significants amount of
documentation as comment because they disagree with the GFDL.

Gr.
Steven

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 15:19 +, Joseph S. Myers wrote:
> On Mon, 11 Jul 2005, Steven Bosscher wrote:
> 
> > On Monday 11 July 2005 16:50, Bernd Schmidt wrote:
> > > Steven Bosscher wrote:
> > > > I guess that, apart from the legal discussion of whether this enough,
> > > > such a statement would not apply to existing content.  It was certainly
> > > > not my intention to sign over the various Wiki contributions I have
> > > > made to the FSF.
> > >
> > > This strikes me as shortsighted.
> > 
> > Call it what you will.  For me it is a matter of choice and freedom.
> > 
> > > If we're getting into a situation 
> > > where we can't freely move documentation from one place to another,
> > > we're shooting ourselves in the foot.
> > 
> > We already can't do that.  We can't move documentation from the manual
> > into the code, and vice versa, because of the GPL vs. GFDL issue.  It
> > is that kind of thing that completely takes away any motivation I might
> > otherwise have to contribute to the manual.
> 
> 1. If GCC developers wish to move documentation from the GPL code to the 
> GFDL manuals, or vice versa, what procedures need to be followed?
> 
> 2. Do existing GCC copyright assignments cover the GCC Wiki 
> ?
> 

No, and again, i don't understand why we can't do what *everyone else on
the planet who transfers docs between the two do* and just make users
agree that they are giving the right to do that when they submit
contributions to the wiki.


See, for example, the wikipedia contribution page.
"

DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!
  * you agree that all contributions to any page on Wikipedia are
released under the GNU Free Documentation License (see
Project:Copyrights for details).
  * If you do not want your writing to be edited mercilessly and
redistributed at will, do not submit it.
  * By submitting your work you promise you wrote it yourself, or
copied it from public domain resources—this does not include
most web page."

Re: Some notes on the Wiki

[Steven Bosscher]

*sigh*

> To play the Devil's advocate: One could argue that someone contributing
> to the GCC code under the GPL does not agree with the GFDL, and therefore
> the FSF can't live up to its promise (that iirc it makes in the copyright
> assignment) to keep the code under a free license.
... if comments from that code are moved into the manual,

Re: ix86_value_regno and callers

[Richard Guenther]

On Mon, 11 Jul 2005, Richard Guenther wrote:

> On Wed, 6 Jul 2005, Richard Henderson wrote:
> 
> > On Tue, Jul 05, 2005 at 05:14:44PM +0200, Richard Guenther wrote:
> > > I'm lost in the mysteries of expansion of the indirect call, also
> > > ix86_value_regno gets called all over the place, so the "interesting"
> > > call-site is hard to find.
> > 
> > We'll have to change the FUNCTION_VALUE interface to handle this.
> > 
> > I suggest doing this as a target hook:
> > 
> >   rtx function_value (tree ret_type, tree fn_decl_or_type, bool outgoing)
> 
> Ok, the fix (that is only working for i386 ATM, I guess) looks 
> like something along attached below.  To make this a clean interface
> I'd suggest making hard_function_value take an extra argument, the
> fntype, and also FUNCTION_OUTGOING_VALUE/FUNCTION_VALUE, and possibly
> making that a target hook like you suggested (though this was a
> cleaup only?  Or did you mean to bail out for TYPE_P func in the
> default implementation?)

Uh, you said so.  Patch in the works.

Richard.

RE: Where does the C standard describe overflow of signed integers?

[Nicholas Nethercote]

On Mon, 11 Jul 2005, Dave Korn wrote:


There was recently a very long thread about the overflow behaviour of
signed integers in C.  Apparently this is undefined according to the C
standard.  I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned integers must wrap around upon
overflow, I couldn't find anything explicit about signed integers.


Dave, Nathan and Paul:  thanks for the quick replies.

The difference between signed and unsigned integer overflow is a little 
unclearly expressed, I think.


3.4.3/3 says:

  "EXAMPLE  An example of undefined behavior is the behavior on integer
   overflow"

6.5/5 says:

  "If an _exceptional condition_ occurs during the evaluation of an
   expression (that is, if the result is not mathematically defined or not
   in the range of representable values for its type), the behavior is
   undefined."

These two paragraphs would seem to indicate that overflow is undefined for 
both signed and unsigned integers.


But then 6.2.5 para 9, sentence 2 says:

  "A computation involving unsigned operands can never overflow, because a
   result that cannot be represented by the resulting unsigned integer
   type is reduced modulo the number that is one greater than the largest
   value that can be represented by the resulting type."

Which requires that unsigned ints must wrap on overflow.  (Actually, I 
guess it defines "overflow" such that unsigned ints never "overflow", so 
3.4.3/3 and 6.5/5 don't apply!)


But I think the paragraphs together are good enough to communicate that: 
unsigned ints must wrap on overflow, signed ints need not.  Thanks again 
for your help.


N

Re: Some notes on the Wiki

[Richard Kenner]

I believe the Wiki is an invaluable documentation tool, precisely
because it allows such an unencumbered contribution process.

I agree.  I wasn't suggesting that the Wiki has no value, but rather
that it's not a substitute for the more formal documentation.  Were it
not for copyright issues, one could view the Wiki as an ongoing draft
process for the documentation.

Re: should libgcc depend on libc?

[Richard Henderson]

On Sat, Jul 09, 2005 at 07:48:47PM +, Thorsten Glaser wrote:
> Should I really not use -nostandardlibs for libgcc_s ?

Yes, I'm pretty sure you should not do that.

> I just got a linker warning because I had bumped libc
> from .36.1 to .37.0 and am recompiling gcc... this
> yields executables linking against libgcc_s (.1.1)
> and libc (.37.0 AND .36.1). No problems, but a warning.

Welcome to the pain of bumping so versions.

> Also, libgcc could be used with libc-replacements this
> way (not truly an issue with libgcc.so, but think of
> bootloaders).
> 
> Do I overlook something?

Static linking?  That would seem to be standard-operating procedure
with bootloaders.


r~

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote:
> More appropriate would be to make the command line consistent with the
> code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
> appropriate.

No, this code is protected by various system checks.

We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
but we require these specific instructions on specific ev56/ev6 systems
for i/o.


r~

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 08:57:58AM +0200, Falk Hueffner wrote:
> The "ldbu" instruction is only available on ev56 and above, however,
> gcc4.1 emits ".arch ev5" because of "-mcpu=ev5", which overrides as's
> "-mev6". This used to work because 4.0 didn't output ".arch ev5"
> because it doesn't actually do anything important.
> 
> I don't see any fault on gcc's side here. You could argue that the
> command line option for as should override the ".arch", but I think
> it's been like this forever. So you should probably just add ".arch
> ev6" inside the asm (annoyingly, gas doesn't seem to have ".arch any"
> or similar).

It'd probably be easier to go back to suppressing the .arch 
in this case.


r~

Re: why are there many copies of function_decls that have the same information including the same uid?

[Kenneth Zadeck]

I was wrong, I misread some debugging output.

Sorry,

kenny

Andrew Pinski wrote:


On Jul 11, 2005, at 8:50 AM, Daniel Berlin wrote:


On Mon, 2005-07-11 at 08:40 -0400, Kenneth Zadeck wrote:

Is this a bug or a feature?

Bug.
where is it occurring?


I want to say the C++ front-end since that is where a couple of
ICEs have showed up because of that.

-- Pinski

Bugzilla is temporarily down

[Daniel Berlin]

While we free some space on the server.
Sorry about that.

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Richard Henderson wrote:

On Mon, Jul 11, 2005 at 08:54:34AM -0400, Paul Koning wrote:


More appropriate would be to make the command line consistent with the
code.  If there's inline assembly that requires ev6, then -mcpu=ev6 is
appropriate.



No, this code is protected by various system checks.

We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
but we require these specific instructions on specific ev56/ev6 systems
for i/o.


rth, can you eyeball the summary I posted at 
http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?
My limited understanding is that gcc is fine, no need to revert anything,
but the linux kernel configury needs to stop doing
  -mcpu=ev5 -Wa,-mev6
for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
really aren't there on real ev5 machines, and passing
-Wa,-mev6 keeps it from substituting
a macro.  (Or are there no pure ev5 machines in the world?)
- Dan

--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

RE: Where does the C standard describe overflow of signed integers?

[Dave Korn]

Original Message
>From: Nicholas Nethercote
>Sent: 11 July 2005 17:08

> On Mon, 11 Jul 2005, Dave Korn wrote:
> 
>>> There was recently a very long thread about the overflow behaviour of
>>> signed integers in C.  Apparently this is undefined according to the C
>>> standard.  I searched the standard on this matter, and while I did find
>>> some paragraphs that described how unsigned integers must wrap around
>>> upon overflow, I couldn't find anything explicit about signed integers.

  Mangled attribution there, I didn't say that, you did!  There's no reason
to leave in the "So-and-so wrote" line if you haven't quoted a single word
of what so-and-so actually wrote

> The difference between signed and unsigned integer overflow is a little
> unclearly expressed, I think.
> 
> 3.4.3/3 says:
> 
>"EXAMPLE  An example of undefined behavior is the behavior on integer
> overflow"
> 
> 6.5/5 says:
> 
>"If an _exceptional condition_ occurs during the evaluation of an
> expression (that is, if the result is not mathematically defined or
> not in the range of representable values for its type), the behavior
> is undefined."
> 
> These two paragraphs would seem to indicate that overflow is undefined for
> both signed and unsigned integers.

  Not quite; you have to read all the implications at once.  3.4.3/3 says
that the behaviour "on integer overflow" is undefined, but because it
elsewhere says that unsigned ints don't overflow, that para only applies to
signed ints.  Likewise, because unsigned ints are defined to use modulo
arithmetic, no "exception condition" occurs, because the result _is_ defined
and the modulo rule keeps it within the "range of representable values for
its type".

> But then 6.2.5 para 9, sentence 2 says:
> 
>"A computation involving unsigned operands can never overflow, because
> a result that cannot be represented by the resulting unsigned integer
> type is reduced modulo the number that is one greater than the largest
> value that can be represented by the resulting type."
> 
> Which requires that unsigned ints must wrap on overflow.  (Actually, I
> guess it defines "overflow" such that unsigned ints never "overflow", so
> 3.4.3/3 and 6.5/5 don't apply!)
> 
> But I think the paragraphs together are good enough to communicate that:
> unsigned ints must wrap on overflow, signed ints need not.  Thanks again
> for your help.

  Ah, I see you've already worked out for yourself what I wrote above.  Yes,
the language in these standards is very hard to read, because you can't
consider any individual point by itself; they don't all explicitly itemise
the other points that might interact with or modify them, as you've seen, so
it requires a good familiarity with the standard to know if some other part
of it might make a difference to the interpretation of the bit you're
examining on any given occasion.


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

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:
> >No, this code is protected by various system checks.
> >
> >We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
> >but we require these specific instructions on specific ev56/ev6 systems
> >for i/o.
> 
> rth, can you eyeball the summary I posted at 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?
> My limited understanding is that gcc is fine, no need to revert anything,
> but the linux kernel configury needs to stop doing
>   -mcpu=ev5 -Wa,-mev6
> for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
> really aren't there on real ev5 machines, and passing
> -Wa,-mev6 keeps it from substituting a macro.

Absolutely not.  While one can argue about which in the gcc+binutils
pair is buggy, the kernel is *not* buggy.

Please re-read my problem description above, and recall that this is
for a GENERIC kernel, that runs on ALL alpha systems.


r~

Re: Some notes on the Wiki

[Mike Stump]

On Monday, July 11, 2005, at 08:30 AM, Steven Bosscher wrote:

In practice, people have already contributed significants amount of
documentation as comment because they disagree with the GFDL.


I'm of the opinion we never should have allowed the GFDL into our 
source tree, no thanks should have been our response.  I'd like to urge 
the SC to pester the FSF on this point continuously until they relent.  
I keep hoping it was just an experiment that one day the FSF will see 
the errors of their ways and just stop.  That, or they will try and 
introduce yet more non-freeisms into the source code base, we should 
uniformly reject all such incursions.

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Dan Kegel]

Richard Henderson wrote:

On Mon, Jul 11, 2005 at 09:52:22AM -0700, Dan Kegel wrote:


No, this code is protected by various system checks.

We want -mcpu=ev5 such that the kernel as a whole will run everywhere,
but we require these specific instructions on specific ev56/ev6 systems
for i/o.


rth, can you eyeball the summary I posted at 
http://marc.theaimsgroup.com/?l=linux-kernel&m=112109202911699&w=2 ?

My limited understanding is that gcc is fine, no need to revert anything,
but the linux kernel configury needs to stop doing
 -mcpu=ev5 -Wa,-mev6
for CONFIG_ALPHA_EV5/CONFIG_ALPHA_GENERIC, since those specific instructions
really aren't there on real ev5 machines, and passing
-Wa,-mev6 keeps it from substituting a macro.



Absolutely not.  While one can argue about which in the gcc+binutils
pair is buggy, the kernel is *not* buggy.

Please re-read my problem description above, and recall that this is
for a GENERIC kernel, that runs on ALL alpha systems.


Maybe I'm missing something.  include/asm-alpha/compiler.h says:

#if defined(__alpha_bwx__)
#define __kernel_ldbu(mem)  (mem)
...
#else
#define __kernel_ldbu(mem)  \
   ({ unsigned char __kir;   \
  __asm__("ldbu %0,%1" : "=r"(__kir) : "m"(mem));\
  __kir; })

For -mcpu=ev5, the #else branch is taken, and the ldbu instruction
is given to the assembler, right?
And since arch/alpha/Makefile does
  CFLAGS += $(cflags-y) -Wa,-mev6
unconditionally, real ldbu instructions are used instead of
the emulation.  And that means that __kernel_ldbu(mem) won't
work on pure ev5 machines.  Are you saying that __kernel_ldbu(mem)
is never called on pure ev5 machines, then?

Thanks,
Dan

--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: 'main' enters in gcc-4.1

[Mike Stump]

On Monday, July 11, 2005, at 07:15 AM, Perret Yannick wrote:

(second send, as I never saw my first send on the mailing list.
sorry if duplicated).


I've seen it twice now, a third time is not necessary.

Can you explain me why I see that behavior? Is it "good" or is it a 
bug?


Sounds like a bug doesn't it.  If you want, file a bug report.

Bugzilla back up (was Re: Bugzilla is temporarily down)

[Daniel Berlin]

On Mon, 2005-07-11 at 12:55 -0400, Daniel Berlin wrote:
> While we free some space on the server.
> Sorry about that.
> 
> 

And now it's back up

Re: gcc-4.1-20050709: alpha: "macro requires $at register while noat in effect" while compiling Linux kernel

[Richard Henderson]

On Mon, Jul 11, 2005 at 10:20:08AM -0700, Dan Kegel wrote:
> Are you saying that __kernel_ldbu(mem)
> is never called on pure ev5 machines, then?

Yes, that is what I am saying.


r~

RE: 'main' enters in gcc-4.1

[Dave Korn]

Original Message
>From: Mike Stump
>Sent: 11 July 2005 18:40

> On Monday, July 11, 2005, at 07:15 AM, Perret Yannick wrote:
>> (second send, as I never saw my first send on the mailing list.
>> sorry if duplicated).

  Perret, next time you aren't certain if your post got through, go to the
web archive (http://gcc.gnu.org/ml/gcc) and look for it, instead of sending
every single person on the mailing list the exact same email twice!  Your
first post arrived at

http://gcc.gnu.org/ml/gcc/2005-07/msg00269.html

and this duplicate is at 

http://gcc.gnu.org/ml/gcc/2005-07/msg00402.html


> I've seen it twice now, a third time is not necessary.

  Nothing I read into Perret's post suggested he was about to send it a
third time.


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

attribute initialized

[Sylvester Diehl]

Hello

why doesn't gcc (-Wall -Wuninitalized -O) detect 
an uninialized variable passed by reference
decleared as  const * ?

Do we need an attribute like (("initialized")) in the
function prototype to give gcc an hint to force
checking of uninitalized parameters ?

example
file foo.c:
- cut here
/*
gcc -Wall -Wuninitialized -O foo.c

*/
#include 
int foo(int const *p)
{
static int sum = 0;

sum += *p;
return sum;
}

int main(int argc, char **argv)
{
int k;

return printf("%d\n", foo(&k));
}

- cut here  end of file foo.c

p.s. i know i could pass the variable by value
 to get a warning of an uninitalized variable.

-- 
Sylvester Diehl
marco Systemanalyse und Entwicklung GmbHTel   +49 8131 5161 42
Hans-Böckler-Str. 2, D 85221 Dachau Fax   +49 8131 5161 66
http://www.marco.de/Email [EMAIL PROTECTED]

Re: HEADS-UP: tree-optimize.c and passes.c heavily modified

[Diego Novillo]

On Tue, Jul 05, 2005 at 06:17:46PM +0200, Paolo Bonzini wrote:

> Other conflicts could be caused by added include files or by adding code 
> to the bottom of the files implementing the RTL passes.  These are not 
> as bad.
> 
No conflicts in gomp, but I think your patch may have introduced this:

a.c.t00.tu
a.c.t02.original
a.c.t03.gimple
a.c.t06.vcg
a.c.t08.useless
a.c.t10.cleanup_cfg <-- Both files are
a.c.t10.lower   <-- labeled with '10'.
a.c.t11.eh

(reproducible with today's mainline)


Thanks.  Diego.

Re: attribute initialized

[Joe Buck]

On Mon, Jul 11, 2005 at 08:07:20PM +0200, Sylvester Diehl wrote:
> why doesn't gcc (-Wall -Wuninitalized -O) detect 
> an uninialized variable passed by reference
> decleared as  const * ?

There are no uninitialized variables in your program.  For the
kind of access checking you seem to be asking for, you'll need
something like valgrind or mudflap.

> int foo(int const *p)
> {
>   static int sum = 0;
> 
>   sum += *p;
>   return sum;
> }

it happens that the memory that p points to is unitialized, but
that is not what -Wuninitialized does.  Similarly, in

> int main(int argc, char **argv)
> {
>   int k;
> 
>   return printf("%d\n", foo(&k));
> }

there are no uninitialized variables, as the address of k is
perfectly well defined.

> p.s. i know i could pass the variable by value
>  to get a warning of an uninitalized variable.

Yes, because then there will *be* an unitialized variable.

Re: Some notes on the Wiki

[Robert Thorpe]

> I believe the Wiki is an invaluable documentation tool, precisely
> because it allows such an unencumbered contribution process.
>
> I agree.  I wasn't suggesting that the Wiki has no value, but rather
> that it's not a substitute for the more formal documentation.  Were it
> not for copyright issues, one could view the Wiki as an ongoing draft
> process for the documentation.

A comment from a user...

Please, please, please don't move GCC internals documentation to a Wiki.

Even to users the internals documentation is useful.  It's useful when trying 
to find out why GCC is doing the things it does with the code given to it, it 
indicates where to look to find things in the source.  This would be much 
harder if it were a wiki, in particular finding information on the version of 
GCC you're using would be much more difficult.

Also, a web-browser is much slower than an info-browser, especially when doing 
searchs.

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
> > I believe the Wiki is an invaluable documentation tool, precisely
> > because it allows such an unencumbered contribution process.
> >
> > I agree.  I wasn't suggesting that the Wiki has no value, but rather
> > that it's not a substitute for the more formal documentation.  Were it
> > not for copyright issues, one could view the Wiki as an ongoing draft
> > process for the documentation.
> 
> A comment from a user...
> 
> Please, please, please don't move GCC internals documentation to a Wiki.
> 
Nobody has suggested that we wouldn't ship docs.

> Even to users the internals documentation is useful.  It's useful when trying 
> to find out why GCC is doing the things it does with the code given to it, it 
> indicates where to look to find things in the source. 

>  This would be much harder if it were a wiki, in particular finding 
> information on the version of GCC you're using would be much more difficult.

However, this isn't true.  The wiki stores every version of a page. We
could make sure we know what versions of the wiki pages refer to what
releases, and link them accordingly.


> 
> Also, a web-browser is much slower than an info-browser, especially when 
> doing searchs.

You must be close to the only user i've met who uses the info browser :)

> 
> 
> 
> 

Re: Some notes on the Wiki

[Kevin Handy]

Paul Koning wrote:


"Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
   



Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
>> I also could convert parts of the ggcinternals manual into wiki
>> pages.  But only if there is a consensus about this being the way
>> to go.

Joseph> I'm sure it's the wrong way to go.  I find a properly
Joseph> formatted and indexed book far more convenient for learning
Joseph> about substantial areas of compiler internals, or for finding
Joseph> what some particular macro is specified to do, than a wiki.

I'll second that.  Unlike some other major GNU projects, GCC's
internals manual is substantial and very good.  Yes, it needs ongoing
improvement, but I'd prefer that rather than flipping to Twiki.

 


In order to show how good the internals documents are, try to
build a very simple front end using ONLY the documentation.
Make it of the order of a hardwired "int main() { return 0}".
Or better yet, find an outsider who knows C, but not GCC
internals, to write it.

No outside source can be used (i.e. no source code not included
in the documentation).

It cannot be done. Not even close. Not even if you allow tree.def.

Too much stuff exists outside of the documentation.

4.0.1, Solaris10/x86, bootstrap failed

[Guenter Feldmann]

Hi

I had no luck in installing gcc-4.0.1 on Solaris10/x86.

My environment:
Solaris10 on AMD64,
binutils:   2.16.1
bootstrap compiler:   gcc-3.4.4
libtool:1.5.18


I tried three configurations:

1)  Sun as, Sun ld:
compiling crtstuff.c  failed

2)  Gnu as, Gnu ld
linking  libgcc_s.sofailed

3)  Gnu as, Sun ld
both compilers (c and c++) built but
linking  of libstdc++.so  failed


-- Guenter

Details :

first try (Sun as, Sun ld);

../gcc-4.0.1/configure --prefix=/usr/local/lang -program-suffix=_4.0.1  
--with-as=/usr/ccs/bin/as  --with-ld=/usr/ccs/bin/ld 
--enable-version-specific-runtime-libs --enable-languages=c,c++

make bootsrap
[ ... ]
./xgcc -B./ -B/usr/local/lang/i386-pc-solaris2.10/bin/ 
-isystem /usr/local/lang/i386-pc-solaris2.10/include 
-isystem /usr/local/lang/i386-pc-solaris2.10/sys-include 
-L/home/src/gnu/gcc/x86/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include  -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/. 
-I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include   
-g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions 
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fPIC \
   -c ../../gcc-4.0.1/gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o
Assembler: crtstuff.c
"/var/tmp//cc3H1H3W.s", line 34 : Illegal mnemonic
"/var/tmp//cc3H1H3W.s", line 34 : Syntax error
"/var/tmp//cc3H1H3W.s", line 48 : Illegal mnemonic
"/var/tmp//cc3H1H3W.s", line 48 : Syntax error
"/var/tmp//cc3H1H3W.s", line 79 : Illegal mnemonic
"/var/tmp//cc3H1H3W.s", line 79 : Syntax error



second try (Gnu as, Gnu ld);

../gcc-4.0.1/configure --prefix=/usr/local/lang -program-suffix=_4.0.1 
--with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld 
--with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs 
--enable-languages=c,c++ 

make bootstrap
[ ... ]
./xgcc -B./ -B/usr/local/lang/i386-pc-solaris2.10/bin/ 
-isystem /usr/local/lang/i386-pc-solaris2.10/include 
-isystem /usr/local/lang/i386-pc-solaris2.10/sys-include 
-L/home/src/gnu/gcc/x86/gcc/../ld -O2  -DIN_GCC-W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 
-Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp  
libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o 
libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o 
libgcc/./_ucmpdi2_s.o libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o 
libgcc/./_fixunsdfsi_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfdi_s.o 
libgcc/./_fixdfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixsfdi_s.o 
libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o 
libgcc/./_fixunsxfsi_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o 
libgcc/./_floatditf_s.o libgcc/./_clear_cache_s.o 
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o 
libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o 
libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o 
libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o 
libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o 
libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o 
libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o 
libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o 
libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o 
libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o 
libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o 
libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o 
libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o 
libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o 
libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o 
libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde_s.o libgcc/./unwind-sjlj_s.o 
libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if 
[ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; 
else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s 
libgcc_s.so.1 ./libgcc_s.so
/usr/local/bin/gnu-ld: cannot open linker script file ldscripts/elf_i386.xsc: 
No such file or directory




third try (Gnu as, Sun ld);

../gcc-4.0.1/configure --prefix=/usr/local/lang -program-suffix=_4.0.1 
--with-gnu-as --with-as=/usr/local/bin/gnu-as --with-ld=/usr/ccs/bin/ld 
--enable-version-specific-runtime-libs --enable-languages=c,c++

make bootstrap
[ ... ]
/home/src/gnu/gcc/x86/gcc/xgcc -shared-libgcc -B/home/src/gnu/gcc/x86/gcc/ 
-nostdinc+

Re: Some notes on the Wiki

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

[...]

| > Also, a web-browser is much slower than an info-browser, especially when 
doing searchs.
| 
| You must be close to the only user i've met who uses the info browser :)

Ahem; is your world that small?

-- Gaby

Re: 4.0.1, Solaris10/x86, bootstrap failed

[Joseph S. Myers]

On Mon, 11 Jul 2005, Guenter Feldmann wrote:

> 3)Gnu as, Sun ld
>   both compilers (c and c++) built but
>   linking  of libstdc++.so  failed

Please try --with-as=/usr/sfw/bin/gas as recommended in the documentation 
.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Some notes on the Wiki

[Paul Koning]

> "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes:

 Kevin> Paul Koning wrote:
 >>> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
 >>> 
 >>> 
 >>
 Joseph> On Mon, 11 Jul 2005, Michael Cieslinski wrote:
 >> >> I also could convert parts of the ggcinternals manual into wiki
 >> >> pages.  But only if there is a consensus about this being the
 >> way >> to go.
 >> 
 Joseph> I'm sure it's the wrong way to go.  I find a properly
 Joseph> formatted and indexed book far more convenient for learning
 Joseph> about substantial areas of compiler internals, or for finding
 Joseph> what some particular macro is specified to do, than a wiki.
 >> I'll second that.  Unlike some other major GNU projects, GCC's
 >> internals manual is substantial and very good.  Yes, it needs
 >> ongoing improvement, but I'd prefer that rather than flipping to
 >> Twiki.
 >> 
 Kevin> In order to show how good the internals documents are, try to
 Kevin> build a very simple front end using ONLY the documentation.
 Kevin> Make it of the order of a hardwired "int main() { return 0}".
 Kevin> Or better yet, find an outsider who knows C, but not GCC
 Kevin> internals, to write it.

 Kevin> No outside source can be used (i.e. no source code not
 Kevin> included in the documentation).

 Kevin> It cannot be done. Not even close. Not even if you allow
 Kevin> tree.def.

Quite true.  On the other hand, for backends things are in far better
shape.  And for my comment on other projects, compare the GCC
internals doc with the internals doc for GDB -- you'll see the point.

  paul

Re: Some notes on the Wiki

[Nicholas Nethercote]

On Mon, 11 Jul 2005, Daniel Berlin wrote:

Also, a web-browser is much slower than an info-browser, especially 
when doing searchs.


You must be close to the only user i've met who uses the info browser :)


I use it.  Info pages suck in many ways, but they're fast to load from an 
xterm, fast to search, and even faster when you know where they are in the 
docs (eg. I find myself looking at the GCC C extensions quite often, and I 
can get there very quickly).


Nick

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 2005-07-11 at 22:47 +0200, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> | > Also, a web-browser is much slower than an info-browser, especially when 
> doing searchs.
> | 
> | You must be close to the only user i've met who uses the info browser :)
> 
> Ahem; is your world that small?

No, i'm actually talking about ~50 users from all walk of life and no
relation to each other (which is a pretty statistically significant
sample)

In fact, a lot of projects don't even bother to distribute anything but
HTML docs anymore (regardless of how they browse it).

> 
> -- Gaby

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 11 Jul 2005, Nicholas Nethercote wrote:


On Mon, 11 Jul 2005, Daniel Berlin wrote:

Also, a web-browser is much slower than an info-browser, especially when 
doing searchs.


You must be close to the only user i've met who uses the info browser :)


I use it.  Info pages suck in many ways, but they're fast to load from an 
xterm, fast to search, and even faster when you know where they are in the 
docs (eg. I find myself looking at the GCC C extensions quite often, and I 
can get there very quickly).


Most people i've met can't undertand the commands for info (pinfo is 
nicer in this regard).
Those who use info religiously seem to be emacs users, not "info browser" 
users.

Hence my surprise.

--Dan

Re: Some notes on the Wiki

[Andreas Schwab]

Daniel Berlin <[EMAIL PROTECTED]> writes:

> Most people i've met can't undertand the commands for info (pinfo is 
> nicer in this regard).

There exist many alternative info browsers (this includes konqueror).

> Those who use info religiously seem to be emacs users, not "info browser" 
> users.

I bet you have never used any recent version of info (the program).

Andreas.

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

Re: Some notes on the Wiki

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Paolo Bonzini wrote:
>>> It was reviewed the very same day it was submitted:
>>>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00313.html
>>>   http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00321.html
> where you said:
>> (and possibly to your tutorial as a separate page if
>> it still seems desirable to have it as a coherent tutorial).
> The page ended up on the wiki rather than wwwdocs.

I don't necessarily disagree, but that was Joseph, not me.

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Giovanni Bajo wrote:
>> Perhaps the wiki could automatically send all changes to gcc-patches to
>> assist in review?
> I strongly support this (and was going to suggest this myself). I'd rather
> it be another list though, say wiki-patches or doc-patches, because of the
> amount of traffic that is going to be generated (think of all those small
> typo fixes, or spam reverts).

Sounds like an interesting idea!

(For example, it might help those volunteering to integrate stuff from 
Wiki to the gcc/doc or wwwdocs documentation, modulo the open copyright
assignment question.)

Gerald

Re: Some notes on the Wiki (was: 4.1 news item)

[Steven Bosscher]

On Monday 11 July 2005 23:34, Gerald Pfeifer wrote:
> On Mon, 11 Jul 2005, Giovanni Bajo wrote:
> >> Perhaps the wiki could automatically send all changes to gcc-patches to
> >> assist in review?
> >
> > I strongly support this (and was going to suggest this myself). I'd
> > rather it be another list though, say wiki-patches or doc-patches,
> > because of the amount of traffic that is going to be generated (think of
> > all those small typo fixes, or spam reverts).
>
> Sounds like an interesting idea!
>
> (For example, it might help those volunteering to integrate stuff from
> Wiki to the gcc/doc or wwwdocs documentation, modulo the open copyright
> assignment question.)

Another idea that was coined on IRC is to have reviewing and commit
after approval rules for the user manual, but to allow patches to the
internals manual in without review.  Is that something people are
willing to consider and discuss?

Gr.
Steven

Re: Some notes on the Wiki (was: 4.1 news item)

[Joseph S. Myers]

On Mon, 11 Jul 2005, Steven Bosscher wrote:

> Another idea that was coined on IRC is to have reviewing and commit
> after approval rules for the user manual, but to allow patches to the
> internals manual in without review.  Is that something people are
> willing to consider and discuss?

Rather than getting rid of review for the internals manual altogether, I 
think we should appoint more maintainers who can commit without review and 
review other people's patches.

It's *already* the case that if you are the listed maintainer of part of 
the compiler you also maintain documentation related to that part and 
don't need review for such documentation.  Perhaps some parts of the 
compiler need more maintainers.  In addition, if someone makes good 
contributions to the documentation in a particular area they can be made a 
maintainer for that part of the documentation.

Note that a maintainer who isn't confident of a patch within an area they 
maintain can still ask for review if they wish.  Review isn't meant to get 
in the way of people who know what they are doing in an area and know 
enough to know when they need review.  It is meant to provide a check on 
work by people with insufficient expertise to tell when review is 
appropriate.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Steven Bosscher <[EMAIL PROTECTED]> writes:

| On Monday 11 July 2005 23:34, Gerald Pfeifer wrote:
| > On Mon, 11 Jul 2005, Giovanni Bajo wrote:
| > >> Perhaps the wiki could automatically send all changes to gcc-patches to
| > >> assist in review?
| > >
| > > I strongly support this (and was going to suggest this myself). I'd
| > > rather it be another list though, say wiki-patches or doc-patches,
| > > because of the amount of traffic that is going to be generated (think of
| > > all those small typo fixes, or spam reverts).
| >
| > Sounds like an interesting idea!
| >
| > (For example, it might help those volunteering to integrate stuff from
| > Wiki to the gcc/doc or wwwdocs documentation, modulo the open copyright
| > assignment question.)
| 
| Another idea that was coined on IRC is to have reviewing and commit
| after approval rules for the user manual, but to allow patches to the
| internals manual in without review.  Is that something people are
| willing to consider and discuss?

the idea that we don't review internal manual is worrysome.  Some
years ago, I based a work on doc/c-tree.texi (thanks Mark!).  But the
fact that it escaped continual revision as code gets added or improved
made it a dangerous documentation, because it led to writing codes
based on semantics that was no longer true.  Got bugs, but don't know
which side is not working prorperly.  Similarly, we don't really want
to let doc patches in without double-check.

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Gerald Pfeifer]

On Mon, 11 Jul 2005, Steven Bosscher wrote:
> Another idea that was coined on IRC is to have reviewing and commit
> after approval rules for the user manual, but to allow patches to the
> internals manual in without review.  Is that something people are
> willing to consider and discuss?

I think this needs to be decided by the current maintainers in question 
(that is, those who generally make or review patches to the internals
manual), but I'd be fine with that.

On Mon, 11 Jul 2005, Joseph S. Myers wrote:
> Perhaps some parts of the compiler need more maintainers.  In addition, 
> if someone makes good contributions to the documentation in a particular 
> area they can be made a maintainer for that part of the documentation.

Absolutely, on both regards.

Gerald

Re: Some notes on the Wiki

[Gabriel Dos Reis]

Daniel Berlin <[EMAIL PROTECTED]> writes:

| On Mon, 11 Jul 2005, Nicholas Nethercote wrote:
| 
| > On Mon, 11 Jul 2005, Daniel Berlin wrote:
| >
| >>> Also, a web-browser is much slower than an info-browser,
| >>> especially when doing searchs.
| >> You must be close to the only user i've met who uses the info
| >> browser :)
| >
| > I use it.  Info pages suck in many ways, but they're fast to load
| > from an xterm, fast to search, and even faster when you know where
| > they are in the docs (eg. I find myself looking at the GCC C
| > extensions quite often, and I can get there very quickly).
| 
| Most people i've met can't undertand the commands for info (pinfo is
| nicer in this regard).

maybe the conclusion to draw is that you've met some special people in
a small part of the community.

-- Gaby

Re: Some notes on the Wiki

[Daniel Berlin]

On Mon, 11 Jul 2005, Andreas Schwab wrote:


Daniel Berlin <[EMAIL PROTECTED]> writes:


Most people i've met can't undertand the commands for info (pinfo is
nicer in this regard).


There exist many alternative info browsers (this includes konqueror).


Yet the amount of docs available in info is dwindling :)
And in fact, most of the ones i see on my system are mostly for the gnu 
development things (ddd, gdb, gcc, make, gmp, glibc) and emacs packages 
(viper, gnus).





Those who use info religiously seem to be emacs users, not "info browser"
users.


I bet you have never used any recent version of info (the program).


Let's see. The last time i tried to use info (the program) was about 6 
weeks ago, 
when i was trying to get info about a function in glibc.
I could not for the life of me determine why it felt the need to jump 
topics when i was just trying to scroll up or down more.


I'm in the "I hate info" camp, and happily so.  I'm happy that most docs 
i want to view are either hyperlinked pdf or searchable html.


Anyhoo, this is offtopic

--Dan

Re: Some notes on the Wiki (was: 4.1 news item)

[Steven Bosscher]

On Tuesday 12 July 2005 00:06, Gabriel Dos Reis wrote:
> Steven Bosscher <[EMAIL PROTECTED]> writes:
> | Another idea that was coined on IRC is to have reviewing and commit
> | after approval rules for the user manual, but to allow patches to the
> | internals manual in without review.  Is that something people are
> | willing to consider and discuss?
>
> the idea that we don't review internal manual is worrysome.  Some
> years ago, I based a work on doc/c-tree.texi (thanks Mark!).  But the
> fact that it escaped continual revision as code gets added or improved
> made it a dangerous documentation, because it led to writing codes
> based on semantics that was no longer true.  Got bugs, but don't know
> which side is not working prorperly.  Similarly, we don't really want
> to let doc patches in without double-check.

Think about what you are saying: "Because almost nobody is working on
the internals manual, the documentation bit-rotted."

One way to get more people to work on the internals manual is by taking
away the barriers.

Gr.
Steven

Re: Some notes on the Wiki (was: 4.1 news item)

[Joe Buck]

On Tue, Jul 12, 2005 at 12:07:01AM +0200, Gerald Pfeifer wrote:
> On Mon, 11 Jul 2005, Steven Bosscher wrote:
> > Another idea that was coined on IRC is to have reviewing and commit
> > after approval rules for the user manual, but to allow patches to the
> > internals manual in without review.  Is that something people are
> > willing to consider and discuss?
> 
> I think this needs to be decided by the current maintainers in question 
> (that is, those who generally make or review patches to the internals
> manual), but I'd be fine with that.

What if we had a clean way to flag reviewed and unreviewed text for the
internals manual?  This could be easier with a wiki; when first entered
the text might be (for example) red, and then it would change to black
when a reviewer approves it.  That way material can be added quickly by
developers and we can keep track of what has been checked or not checked.

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

Steven Bosscher <[EMAIL PROTECTED]> writes:

| On Tuesday 12 July 2005 00:06, Gabriel Dos Reis wrote:
| > Steven Bosscher <[EMAIL PROTECTED]> writes:
| > | Another idea that was coined on IRC is to have reviewing and commit
| > | after approval rules for the user manual, but to allow patches to the
| > | internals manual in without review.  Is that something people are
| > | willing to consider and discuss?
| >
| > the idea that we don't review internal manual is worrysome.  Some
| > years ago, I based a work on doc/c-tree.texi (thanks Mark!).  But the
| > fact that it escaped continual revision as code gets added or improved
| > made it a dangerous documentation, because it led to writing codes
| > based on semantics that was no longer true.  Got bugs, but don't know
| > which side is not working prorperly.  Similarly, we don't really want
| > to let doc patches in without double-check.
| 
| Think about what you are saying: "Because almost nobody is working on
| the internals manual, the documentation bit-rotted."

In fact, you just invented that and you're trying to credit me fort
it?  No, thanks.  Stick to what I wrote and if you think there is
something unclear, please ask.  But refrain from crediting me for
something I did not say.

-- Gaby

Re: Some notes on the Wiki (was: 4.1 news item)

[Gabriel Dos Reis]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

| On Mon, 11 Jul 2005, Steven Bosscher wrote:
| 
| > Another idea that was coined on IRC is to have reviewing and commit
| > after approval rules for the user manual, but to allow patches to the
| > internals manual in without review.  Is that something people are
| > willing to consider and discuss?
| 
| Rather than getting rid of review for the internals manual altogether, I 
| think we should appoint more maintainers who can commit without review and 
| review other people's patches.

I 100% agree.  

-- Gaby

Re: Some notes on the Wiki

[chris jefferson]

Gabriel Dos Reis wrote:

>Daniel Berlin <[EMAIL PROTECTED]> writes:
>
>| On Mon, 11 Jul 2005, Nicholas Nethercote wrote:
>| 
>| > On Mon, 11 Jul 2005, Daniel Berlin wrote:
>| >
>| >>> Also, a web-browser is much slower than an info-browser,
>| >>> especially when doing searchs.
>| >> You must be close to the only user i've met who uses the info
>| >> browser :)
>| >
>| > I use it.  Info pages suck in many ways, but they're fast to load
>| > from an xterm, fast to search, and even faster when you know where
>| > they are in the docs (eg. I find myself looking at the GCC C
>| > extensions quite often, and I can get there very quickly).
>| 
>| Most people i've met can't undertand the commands for info (pinfo is
>| nicer in this regard).
>
>maybe the conclusion to draw is that you've met some special people in
>a small part of the community.
>
>  
>
I just had a quick quiz in the C++ IRC channel I was in, and very few
people there like info, and very few are comfortable using it. There was
a general agreement HTML, PDF and docbook are the best ways to recieve
documentation.

Chris

Re: Some notes on the Wiki

[Daniel Berlin]

> >  
> >
> I just had a quick quiz in the C++ IRC channel I was in, and very few
> people there like info, and very few are comfortable using it. There was
> a general agreement HTML, PDF and docbook are the best ways to recieve
> documentation.
> 
> Chris

It's possible these people ride the short development bus too, which
apparently i do :(

Re: Some notes on the Wiki (was: 4.1 news item)

[Daniel Berlin]

On Mon, 2005-07-11 at 15:21 -0700, Joe Buck wrote:
> On Tue, Jul 12, 2005 at 12:07:01AM +0200, Gerald Pfeifer wrote:
> > On Mon, 11 Jul 2005, Steven Bosscher wrote:
> > > Another idea that was coined on IRC is to have reviewing and commit
> > > after approval rules for the user manual, but to allow patches to the
> > > internals manual in without review.  Is that something people are
> > > willing to consider and discuss?
> > 
> > I think this needs to be decided by the current maintainers in question 
> > (that is, those who generally make or review patches to the internals
> > manual), but I'd be fine with that.
> 
> What if we had a clean way to flag reviewed and unreviewed text for the
> internals manual?  This could be easier with a wiki; when first entered
> the text might be (for example) red, and then it would change to black
> when a reviewer approves it.  That way material can be added quickly by
> developers and we can keep track of what has been checked or not checked.
> 
> 

This is probably possible, but may be easier with other wiki software,
but if that was the direction we wanted to take, i'm happy to convert
us.

Re: Some notes on the Wiki

[Andreas Schwab]

Daniel Berlin <[EMAIL PROTECTED]> writes:

> Let's see. The last time i tried to use info (the program) was about 6 
> weeks ago, 

I was refering to a recent version, not a recent use.

Andreas.

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

Re: Some notes on the Wiki

[Kurt Wall]

On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write:
> On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:
> > Also, a web-browser is much slower than an info-browser, especially 
> > when doing searchs.
> 
> You must be close to the only user i've met who uses the info browser :)

We haven't met, but I use the info browser. :-) I used to hate it but
finally decided that since texi was the format that existed, I might
as well suck it up and learn to use it.

Kurt
-- 
"I thought you were trying to get into shape."
"I am. The shape I've selected is a triangle."

Reducing debug info for C++ ctors/dtors

[Devang Patel]

Our analysis suggests that reducing certain stabs info for C++ ctors/ 
dtors can lead to significant final size reduction without noticeable  
change in quality of debugging (in STABS world, at least).


For example,

class Base1 {
  public: int x;
  Base1(int i) { x = i; }
  int getx (void) { return x; }
};
int main () {
  Base1 myobj(5);
  return myobj.getx();
}

will emit a class definition LSYM of

.stabs  "Base1:Tt(0,41)=s4x:(0,9),0,32;__base_ctor ::(0,42)=# 
(0,41),(0,36),(0,43)=*(0,41),(0,9),(0,36);:_ZN5Base1C2Ei; 
2A.;__comp_ctor ::(0,42):_ZN5Base1C1Ei;2A.;getx::(0,44)=#(0,41),(0,9), 
(0,43),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0



However, it is good enough to have

.stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;getx::(0,44)=#(0,41), 
(0,9),(0,43)=*(0,41),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0


and keep the stabs for the cdtors in other contexts, most obviously  
the FUN stab where the function is defined.  e.g.


__ZN5Base1C1Ei:
.stabd  46,0,0
.stabd  68,0,3
LFB4:
stmw r30,-8(r1)
[...]
lmw r30,-8(r1)
blr
LFE4:
.stabs  "_ZN5Base1C1Ei:F(0,36)",36,0,3,__ZN5Base1C1Ei
.stabs  "this:p(0,45)=k(0,43)",160,0,3,72
.stabs  "i:p(0,9)",160,0,3,76
Lscope0:
.stabs  "",36,0,0,Lscope0-__ZN5Base1C1Ei
.stabd  78,0,0


Our GDB folks are still analyzing compiler output with included  
patch. Initial response is - it looks good.  I'd like to get your  
feedback on this. Is it a good idea in general for other debugging  
formats also ?


If peopler thinks this is a good idea then I can prepare patch for  
mainline.  Do we need a switch to control this ? I do not know. If  
you can think of better name for this switch, feel free to suggest.


-
Devang

[ I am intentionally including this patch to make it easier to read.  
This patch is against apple-local branch so it may not apply cleanly  
to FSF mainline. As I said, if this looks good then I'll prepare  
actual patch. ]


Index: c-common.c
===
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.604.2.12
diff -Idpatel.pbxuser -c -3 -p -r1.604.2.12 c-common.c
*** c-common.c  15 Jun 2005 16:18:32 -  1.604.2.12
--- c-common.c  11 Jul 2005 21:34:24 -
*** int flag_access_control = 1;
*** 454,459 
--- 454,463 

  int flag_check_new;

+ /* APPLE LOCAL begin 4167759 */
+ /* Nonzero if we want to omit debug info for certain constructors and
+destructors.  */
+ int flag_compact_debug_info;
  /* Nonzero if we want the new ISO rules for pushing a new scope  
for `for'

 initialization variables.
 0: Old rules, set by -fno-for-scope.
Index: c-common.h
===
RCS file: /cvs/gcc/gcc/gcc/c-common.h,v
retrieving revision 1.276.6.9
diff -Idpatel.pbxuser -c -3 -p -r1.276.6.9 c-common.h
*** c-common.h  23 Jun 2005 01:30:09 -  1.276.6.9
--- c-common.h  11 Jul 2005 21:34:24 -
*** extern int flag_access_control;
*** 579,584 
--- 579,589 

  extern int flag_check_new;

+ /* APPLE LOCAL begin 4167759 */
+ /* Nonzero if we want to omit debug info for certain constructors and
+destructors.  */
+ extern int flag_compact_debug_info;
+ /* APPLE LOCAL end 4167759 */
  /* Nonzero if we want the new ISO rules for pushing a new scope  
for `for'

 initialization variables.
 0: Old rules, set by -fno-for-scope.
Index: c-opts.c
===
RCS file: /cvs/gcc/gcc/gcc/c-opts.c,v
retrieving revision 1.135.6.8
diff -Idpatel.pbxuser -c -3 -p -r1.135.6.8 c-opts.c
*** c-opts.c1 Jul 2005 00:01:07 -   1.135.6.8
--- c-opts.c11 Jul 2005 21:34:24 -
*** c_common_handle_option (size_t scode, co
*** 688,693 
--- 688,698 
flag_check_new = value;
break;

+   /* APPLE LOCAL begin 4167759 */
+ case OPT_fcompact_debug_info:
+   flag_compact_debug_info = value;
+   break;
+   /* APPLE LOCAL end 4167759 */
  case OPT_fconserve_space:
flag_conserve_space = value;
break;
Index: c.opt
===
RCS file: /cvs/gcc/gcc/gcc/c.opt,v
retrieving revision 1.34.6.8
diff -Idpatel.pbxuser -c -3 -p -r1.34.6.8 c.opt
*** c.opt   1 Jul 2005 00:01:08 -   1.34.6.8
--- c.opt   11 Jul 2005 21:34:24 -
*** fcheck-new
*** 572,577 
--- 572,583 
  C++ ObjC++
  Check the return value of new

+ ; APPLE LOCAL begin 4167759
+ fcompact-debug-info
+ C ObjC C++ ObjC++
+ Avoid verbose debug info related to constructors and destructors
+ ; APPLE LOCAL end 4167759
+
  ; APPLE LOCAL begin structor decloning
  fclone-structors
  C++ ObjC++
Index: cp/class.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/class.c,v
retrieving revision 1.705.2.4
diff -Idpate

Re: Reducing debug info for C++ ctors/dtors

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 05:37:32PM -0700, Devang Patel wrote:
> will emit a class definition LSYM of
> 
> .stabs  "Base1:Tt(0,41)=s4x:(0,9),0,32;__base_ctor ::(0,42)=# 
> (0,41),(0,36),(0,43)=*(0,41),(0,9),(0,36);:_ZN5Base1C2Ei; 
> 2A.;__comp_ctor ::(0,42):_ZN5Base1C1Ei;2A.;getx::(0,44)=#(0,41),(0,9), 
> (0,43),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0
> 
> 
> However, it is good enough to have
> 
> .stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;getx::(0,44)=#(0,41), 
> (0,9),(0,43)=*(0,41),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0
> 
> and keep the stabs for the cdtors in other contexts, most obviously  
> the FUN stab where the function is defined.  e.g.

Eh, no.  You have just lost any information about what constructors
were declared in the class.  Reconstructing this from what constructors
we can find a definition of will be messy and error-prone, because the
debugger will not be able to link a member function back to a
particular member in the definition of the class type.

Dwarf handles clones very differently from stabs.  The abstract
definition goes in the class type and the clones only have concrete
instances.  That is probably what you want for stabs: have one of the
base/complete ctors, but not both.

The effect on dwarf output might be more interesting.

GDB just ignores all but one of each set in stabs anyway.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Reducing debug info for C++ ctors/dtors

[Jason Molenda]

On Mon, Jul 11, 2005 at 08:56:36PM -0400, Daniel Jacobowitz wrote:

> > However, it is good enough to have
> > 
> > .stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;getx::(0,44)=#(0,41), 
> > (0,9),(0,43)=*(0,41),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0

> Eh, no.  You have just lost any information about what constructors
> were declared in the class.  

Yeah, Devang didn't present what we're doing here on the debug side
too well.  We're giving up a bit of information from within gdb --
it won't know what constructors and destructors a class has defined
-- for a large savings in debug info (this can be over 20% of an
application's debug info when lots of templates are in heavy use).

Because the FUN stabs are still present, gdb knows about the
constructors; it can step into them, it can set breakpoints on them.

For most developers, this isn't a worthwhile tradeoff, but for a
certain class of appliations the stabs debug info is enormous and
this helps to ameloriate that by giving up a small bit of gdb
functionality.  This won't be enabled by default even within Apple,
but it is a useful option to have available.


Jason

Re: Reducing debug info for C++ ctors/dtors

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 06:11:58PM -0700, Jason Molenda wrote:
> Yeah, Devang didn't present what we're doing here on the debug side
> too well.  We're giving up a bit of information from within gdb --
> it won't know what constructors and destructors a class has defined
> -- for a large savings in debug info (this can be over 20% of an
> application's debug info when lots of templates are in heavy use).
> 
> Because the FUN stabs are still present, gdb knows about the
> constructors; it can step into them, it can set breakpoints on them.
> 
> For most developers, this isn't a worthwhile tradeoff, but for a
> certain class of appliations the stabs debug info is enormous and
> this helps to ameloriate that by giving up a small bit of gdb
> functionality.  This won't be enabled by default even within Apple,
> but it is a useful option to have available.

Thanks for the explanation.  That makes more sense.  Personally, if
you're going to do this, I don't see why you're keeping debug info for
methods; either ditch all artificial methods (including defaulted
constructors but not manually specified constructors), or ditch all
methods.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Reducing debug info for C++ ctors/dtors

[Jason Molenda]

On Mon, Jul 11, 2005 at 09:18:22PM -0400, Daniel Jacobowitz wrote:

> Thanks for the explanation.  That makes more sense.  Personally, if
> you're going to do this, I don't see why you're keeping debug info for
> methods; either ditch all artificial methods (including defaulted
> constructors but not manually specified constructors), or ditch all
> methods.

We considered that too.

On the question of artifical-vs-actual c/dtors, that's one breakdown
I don't have hard numbers on yet, but my argument is that gdb's
knowledge of a class' cdtors is only useful when you're ptype'ing
that class -- you rarely find yourself needing to call the constructor
or destructor on an object from the gdb CLI.  And these things are
awfully long in stabs.  So this is the kind of minor functionality
that the user can be told "turn this switch on and ptype of the
class won't be accurate" and they'll understand the trade-off.

As for ditching methods, this quickly turns into a loss of functionality
because users can no longer call methods on on object from the gdb
command line.  Many users don't know about inferior function calls,
but the Apple debugger UI exposes a feature that sits on top of
those ("custom data formatters"), where you can specify how objects
of a given type should be displayed in the variables window.  For
complex OO types, these are often expressions involving an inferior
function call.

Jason

gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures

[Christian Joensson]

I'll be posting to gcc-testresults eventually alos, I just had to
start this thread...

This is on

Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc I (SpitFire) sun4u:

binutils-2.15.92.0.2-5.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.3-99.sparcv9
glibc-2.3.3-99.sparc64
glibc-devel-2.3.3-99.sparc
glibc-devel-2.3.3-99.sparc64
glibc-headers-2.3.3-99.sparc64
glibc-kernheaders-2.6-20sparc.sparc
gmp-4.1.4-3sparc.sparc
gmp-4.1.4-3sparc.sparc64
gmp-devel-4.1.4-3sparc.sparc
gmp-devel-4.1.4-3sparc.sparc64
kernel-2.6.11-1.1166sp1.sparc64
package kernel-devel is not installed
package kernel-smp is not installed
libgcc-3.4.2-6.fc3.sparc
libgcc-3.4.2-6.fc3.sparc64
libstdc++-3.4.2-6.fc3.sparc
libstdc++-3.4.2-6.fc3.sparc64
libstdc++-devel-3.4.2-6.fc3.sparc
libstdc++-devel-3.4.2-6.fc3.sparc64
make-3.80-5.sparc
nptl-devel-2.3.3-99.sparcv9
tcl-8.4.7-2.sparc

LAST_UPDATED: Obtained from CVS: -rgcc_4_0_1_release 

Native configuration is sparc64-unknown-linux-gnu

=== gcc tests ===


Running target unix
FAIL: gcc.dg/20020201-1.c execution test
FAIL: gcc.dg/special/gcsec-1.c (test for excess errors)
FAIL: gcc.dg/tls/alias-1.c (test for excess errors)
FAIL: gcc.dg/tls/opt-2.c (test for excess errors)
FAIL: gcc.misc-tests/bprob-1.c execution,-g  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -g  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-g  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-O0  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -O0  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O0  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-O1  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -O1  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O1  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -O2 -DPERFTIME 
-fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME 
-fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -O3 -DPERFTIME 
-fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME 
-fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -g -DPERFTIME  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -O3 -g -DPERFTIME 
-fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -g -DPERFTIME 
-fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-Os  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -Os  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-Os  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-g  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -g  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-g  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-O0  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -O0  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O0  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-O1  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -O1  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O1  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-O2 -DPERFTIME  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -O2 -DPERFTIME 
-fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O2 -DPERFTIME 
-fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-O3 -DPERFTIME  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -O3 -DPERFTIME 
-fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O3 -DPERFTIME 
-fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-O3 -g -DPERFTIME  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -O3 -g -DPERFTIME 
-fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O3 -g -DPERFTIME 
-fbranch-probabilities
FAIL: gcc.misc-tests/bprob-2.c execution,-Os  -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-2.c compilation,  -Os  -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-Os  -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-g 
-ftree-based-profiling -fprofile-arcs
UNRESOLVED: gcc.misc-tests/bprob-1.c compilation,  -g 
-ftree-based-profiling -fbranch-probabilities
UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-g 
-ftree-based-profiling -fbranch-probabilities
FAIL: gcc.misc-tests/bprob-1.c execution,-O0 
-ftree-based-profil