Re: Incorrect default options for h8300 target

[Jim Blandy]

On 11/14/05, Jim Wilson <[EMAIL PROTECTED]> wrote:
> Well, maybe not.  My subversion check-out is screwed up, and I don't see
> how to fix it.  An update failed because of a bug with my external diff
> program.  I fixed that.  I fumbled around a bit trying to find the right
> svn command I need to recover from this.  Now I've got a locked working
> copy, and I'm getting errors from svn cleanup.  I need something
> equivalent to "cvs update -A" here.  I know my tree is screwed up, I
> just want svn to ignore everything I have in my working copy and give me
> the most recent copy of everything.  I think I need to check out a new
> tree from scratch at this point.

'svn revert' doesn't work for you?  What does 'svn status' say?

Re: Directly generating binary code [Was Re: Link-time optimzation]

[Jim Blandy]

On 11/18/05, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote:
> > A nightmare scenario is debugging the compiler when its behaviour
> > changes due to using "-S".  Assembly source is something that we
> > maintainers use more than anyone else.
>
> If we go the direct generation route, I think it would be more
> efficient (if possible) to add whatever extra information is needed in
> the object file (like the asm template string, compiler comments, ...)
> so that object code dumper will get it back to you on request. So skip
> the -S altogether, always use the object dumper to "look at assembly".

The point Andrew's raising here is that you are replacing an
intermediate form that is very useful for isolating problems --- the
assembly language file --- with an in-core form that is much more
difficult to inspect.

And there are various side consequences: for example, you know the
compiler isn't going to go and tweak the assembly-language file you're
looking at, because it's exited.  But with an in-core representation
(and a non-type-safe language like C), compiler bugs can still be
mangling the assembly code "after" it's been generated.

For a 2% speedup?  That hasn't been carefully measured?

Re: Overwrite a file with "svn update"?

[Jim Blandy]

On 11/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote:
> which is indeed correct.  So, is there an option to tell
> svn to blow away files that conflict with files in the
> repository.

Subversion is reluctant to blow away users' files; this was one of the
qualities of CVS we thought we should try to retain.

However, if I'm understanding it right, here Subversion is hesitating
to replace a file with a file of the same name whose contents are the
same.  Is that correct?  It seems to me like Subversion could
reasonably handle that the same way it does when an update brings in
textual changes to an existing file that already has those changes in
it: it says, "Oh, you have this already" and doesn't worry about it.

Has the file in your local repository been added with 'svn add'?  Or
is it an unknown file from Subversion's point of view?

Re: Checksum mismatch

[Jim Blandy]

Since this is a Subversion problem, and not a GCC problem, it would
probably be best to ask this question on [EMAIL PROTECTED]

(I don't know the answer; I don't see anything in the FAQ or in the
book.  So I think this is an excellent question to ask.)

Re: Wiki pages on tests cases

[Jim Blandy]

On 11/27/05, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> Yes, I know it's a wiki and I can do this myself, but I only have so
> much spare time and maybe the second one was added for a good reason.

http://en.wikipedia.org/wiki/Be_bold

Works for them.

Re: LTO, LLVM, etc.

[Jim Blandy]

On 12/5/05, Chris Lattner <[EMAIL PROTECTED]> wrote:
> That said, having a good representation for source-level exporting is
> clearly useful.  To be perfectly clear, I am not against a source-
> level form, I am just saying that it should be *different* than the
> one used for optimization.

Debug information describes two things: the source program, and its
relationship to the machine code produced by the toolchain.  The
second is much harder to produce; each pass needs to maintain the
relation between the code it produces and the compiler's original
input.  Keeping the two representations separate (which I could easily
see being beneficial for optimization) shifts that burden onto some
new party which isn't being discussed, and which will be quite
complicated.

Re: Add revision number to gcc version?

[Jim Blandy]

Subversion provides an "opt-in" version of keyword substitution, and
provides a $Revision$ keyword.  It might take a little scriptery to
get that into the form GCC wants.

http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.keywords

Re: Add revision number to gcc version?

[Jim Blandy]

On 12/19/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2005, at 2:56 PM, Jim Blandy wrote:
> > Subversion provides an "opt-in" version of keyword substitution, and
> > provides a $Revision$ keyword.
>
> But it doesn't do what people really want it to by design.  :-(

And that would be?

Re: Add revision number to gcc version?

[Jim Blandy]

Okay, I see.  Yes, there really ought to be an easy way to provide
enough information to reproduce the tree, and $Revision$ isn't it.

Re: Why is this C++ code incorrect?

[Jim Blandy]

On 12/20/05, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> >   Compiling the following code with g++ will report error:`static void
> > A::operator delete(void*)' is protected.  It's correct If B is derived from
> > A without "virtual".  Why does the "new B" expression need to check the
> > delete operator's accessibility when B is virutally derived from A?
>
> 5.3.4 paras 8, 17 and 18 say so.

I don't see how the below is affected by the use of a virtual base
class, rather than an ordinary base class.

8 A new-expression obtains storage for the object by calling an
  allocation function (3.7.3.1). If the new- expression terminates by
  throwing an exception, it may release storage by calling a
  deallocation function (3.7.3.2). If the allocated type is a
  non-array type, the allocation function's name is operator new and
  the deallocation function's name is operator delete. If the
  allocated type is an array type, the alloca- tion function's name
  is operator new[] and the deallocation function's name is operator
  delete[]. [Note: an implementation shall provide default definitions
  for the global alloca- tion functions (3.7.3, 18.4.1.1, 18.4.1.2). A
  C++ program can provide alternative definitions of these func- tions
  (17.4.3.4) and/or class-specific versions (12.5). ]
...
17 If any part of the object initialization described above71)
   terminates by throwing an exception and a suitable deallocation
   function can be found, the deallocation function is called to free
   the memory in which the object was being constructed, after which
   the exception continues to propagate in the context of the new-
   expression. If no unambiguous matching deallocation function can be
   found, propagating the exception does not cause the object's
   memory to be freed. [Note: This is appropriate when the called
   allocation func- tion does not allocate memory; otherwise, it is
   likely to result in a memory leak. ]

18 If the new-expression begins with a unary :: operator, the
   deallocation function's name is looked up in the global
   scope. Otherwise, if the allocated type is a class type T or an
   array thereof, the deallocation function's name is looked up in
   the scope of T. If this lookup fails to find the name, or if the
   allocated type is not a class type or array thereof, the
   deallocation function's name is looked up in the global scope.

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

[Jim Blandy]

On 1/2/06, Paul Schlie <[EMAIL PROTECTED]> wrote:
> - at the most basic level, I feel like I've too often needlessly wasted
>   time debugging programs at one level of optimization, to only see a
>   different behavior needlessly expressed at a different level of
>   optimization (which I understand means something isn't portable, but
>   isn't the correct way to inform one of non-portable code, but is one
>   hell of a way to unknowingly interject bugs into a program which didn't
>   exist at a different level of optimization); however if a compiler
>   supported the means by which a target could define the semantics left
>   undefined by a language, an optimizing compiler could then both satisfy
>   the formal constrains of language, while simultaneously enabling target
>   specific semantics to be supported, and preserved through optimization.
>   (which seems like a win-win to me)

Okay, this makes sense to me now.  If there were a switch that changed
the language from ISO C to a very similar language that actually
specified a fixed behavior for all the behaviors that ISO C says are
unspecified or undefined, then you'd have a language that might not be
possible to compile as efficiently in some cases, but in which every
program had a unique correct behavior.  (Setting aside inherently
unpredictable things like threads and signals.)  For example, the
language would actually have to specify some default value for all
variables, or require them to be assigned before their first use in a
way that the compiler could statically verify (as in Java).

This is what the Java folks were shooting for, if you ignore the
non-determinism introduced by threads.  Standard ML also specifies a
particular result for all programs.  If my copies of both those specs
weren't still packed, I think I could actually find quotes from each
where they state being fully defined as a goal.  So I think it's clear
there are a lot of people who think this is a worthwhile principle.

Paul is combining this suggestion with the further idea that the
unspecified and undefined behaviors could be tied down in a way
comfortable for the particular target.  I guess he's trying to reduce
the performance impact.  That concession would allow the changes in
behavior that annoy him now when he switches optimization levels to
re-appear when one switches targets.  The opposite extreme to Paul's
concession would be to eliminate all target-dependent characteristics
from the language, including type size differences and alignment
requirements, yielding a language which specified a unique correct
result for all programs (again, setting aside threads and signals) on
all targets.  As ML and Java do.
Or, there could be a middle ground: you could specify some
characteristics (say, integral type sizes and wrap-around on overflow)
for all targets, but leave others (say, pointer size and alignment)
target-specific.

Re: Mapping C code to generated asm code

[Jim Blandy]

On 1/11/06, Perry Smith <[EMAIL PROTECTED]> wrote:
> Is there a way to get some type of debugging output that tells me
> what line of C code produced what lines of asm code?

Do the .loc directives in the .s files produced by gcc -S work for
you?  The arguments to .loc are the file number, line number, and
column number.

Re: Debug infos

[Jim Blandy]

On 1/18/06, Hardy Smith <[EMAIL PROTECTED]> wrote:
> I have to write a symbol reader for some
> gcc-generated, embedded programms. They are for a
> relatifly "unknown" mipsX cpu. The binaries seem to be
> in a.out format.
> Where can I find infos how the debug-symbols are
> organuzed? Is this plattform-depended or gvv-version
> dependend?

If your executables really are in a.out format, then the debugging
information is probably in STABS format.  The GNU manual for STABS is
included in the GDB distribution, as gdb/doc/stabs.texinfo.  On Fedora
Core, at least, the info manual is installed with the GDB package.

Just to make sure you know: the compiler always creates executables
named 'a.out', regardless of the object file format being used.  I
think most MIPS targets use ELF or COFF, which is why I bring this up.
 You should use 'objdump -f' to make sure you're really dealing with
an a.out format executable.

Re: RFD: marking a variable as addressable - need new hook? (pr26004)

[Jim Blandy]

On 1/30/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> gimplify.c:gimplify_modify_expr_rhs tries to optimize calls to functions
> which return their value in memory, if the result is assigned to a
> variable, by using the address of that variable as the location where
> the result is top be stored.  It uses lang_hooks.mark_addressable to
> mark the variable
> as addressable.
> There is a preceding check that is supposed to verify that the variable
> is not a register variable,  but the function called -
> is_gimple_reg_type - is really more a heuristic for optimizations.
> The necessary information to decide if we can safely call
> lang_hooks.mark_addressable is not available in a frontend-independet
> manner.  I think we need a new frontend hook that can tell an optimizer
> if a call to lang_hooks.mark_addressable  would succeed.

Is this optimization really legit?

I've never come across an ABI which actually requires functions that
return structures by value to leave the return value buffer untouched
until just before they return.  Consider code like this:

struct f { int a, b };
struct f x;

struct f foo (void) { struct f y; y.a = 42; y.b = x.a; return y; }

struct f bar () { x = foo (); return x; }

The ABI's I've seen permit foo to actually store the 42 directly into
the 'a' slot of their return buffer, before fetching x.a.  If bar then
passes x itself to foo as its return value buffer, then you wipe out
x.a before you have a chance to reference it.

Re: Coverity Open Source Defect Scan of gcc

[Jim Blandy]

On 3/5/06, Ben Chelf <[EMAIL PROTECTED]> wrote:
>Right now, we're guarding access to the actual defects that we report
> for a couple of reasons: (1) We think that you, as developers of gcc,
> should have the chance to look at the defects we find to patch them
> before random other folks get to see what we found and (2) From a
> support perspective, we want to make sure that we have the appropriate
> time to engage with those who want to use the results to fix the code.

I think it's great that you're contributing the results of your
analysis to the GCC project.  Is this part of the work sponsored by
the U.S. Department of Homeland Security, described in
?

Re: Would like to use gcc source code to improve compiler development skills

[Jim Blandy]

On 3/9/06, Lalit Gidwani <[EMAIL PROTECTED]> wrote:
> I have C/C++/Java programming skills. I have also
> studied a couple of books on compiler development. I
> would like to start with a project that will provide
> me with the experience of having participated in a
> real compiler development effort. I am interested in
> C/C++/Java.
>
> Can you tell me which module I should download from
> your CVS server. I would like to study code for all
> the major phases including lexical analysis, parsing,
> semantic analysis, intermediate code generation,
> optimation, and code generation.

The web page http://gcc.gnu.org/install/ has instructions for
downloading the complete GCC sources and building them.

This list is generally meant for discussion about active development
of GCC.  If you find you need help building GCC, you should ask those
questions on the gcc-help mailing list; see
http://gcc.gnu.org/lists.html.

Re: Creating gcc-newbies mailing list

[Jim Blandy]

On 26 Jul 2007 15:53:09 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> > I think that when we do steer someone to a different list, we could
> > take more care to be polite about it than we sometimes are.
>
> I agree.  I also think we should all try harder to avoid flippant or
> non-responsive replies to new developers.  I think it's important for
> the long-term growth of gcc for us to encourage new developers.

There were several presentations at OSCON that touched on these
issues: Brian Fitzpatrick and Ben Collins-Sussman's "poisonous people"
talk, while mostly about how to deal with difficult people, also
touched on how to establish an expectation of courtesy and respect.
The perceived leaders of the community need to make gentle but public
corrections when someone doesn't reply well, even if the person being
criticized is a leading contributor.  The goal is to have everyone
know the rules, and know that they apply to everyone.

The first and third talks are the ones relevant here:
http://conferences.oreillynet.com/cs/os2007/view/e_spkr/2762

And Karl Fogel's book goes into exactly these issues in detail:
http://producingoss.com/en/setting-tone.html