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
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.
>
> I
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
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.)
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.
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
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
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?
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.
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 op
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 understan
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 num
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 platt
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
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
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 effo
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 ha
17 matches
Mail list logo
