Re: Designs for better debug info in GCC. Choice A or B?
Ye, Joey wrote: A) Whole-optimized but with dirty debugged information if possible. When there is coredump from crash then its debugged information can be not complete (with losses) but can be readable for humans. This kind of strategy can't work well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is whole-optimized same as stripped program. B) Whole-debugged but partially optimized because of restricted requirements to maintain the full debugged information without losses. The word "full" worries me a bit, I am afraid of it being interpreted as a requirement to be 100% "correct" in all cases, and this may be too severe. What we are looking for is good enough in practice, which is a vaguer criterion, but a more useful one. For instance as I mentioned early, i would be happy to live with not being able to reliably modify local variables. This kind of strategy works well in "step to step" debuggers like gdb, ddd, kgdb, ... but its code is less whole-optimized and bigger than stripped program. Sincerely, J.C.Pizarro
Re: Designs for better debug info in GCC
On Nov 26, 2007 7:57 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
>
> > No, hashing is fine, but doing walks over a hashtable when your algorithm
> > depends on ordering is not.
>
> Point.
>
> > I have patches to fix the instance of walking over all referenced
> > vars. Which is in the case of UIDs using bitmaps and a walk over a
> > bitmap (which ensures walks in UID order).
>
> Why is such memory and CPU overhead better than avoiding the
> divergence of UIDs in the first place?
Actually my patches should be an overall memory savings. But, as you (and
me and others) look at bugs that happen because of UID divergence, it is
easier to use UIDs in a way that guarantees that generated code does not
change in such cases. Otherwise what's the point in using UIDs? If you
later do hashtable walks anyway you can hash on the pointer as well.
So, IMHO an algorithm should produce the same result if for an ordered set
of UIDs M { u1, u2, u3 } instead an ordered set M' { u1', u2', u3' } is used
where element correspondence is u1 : u1', u2 : u2', u3 : u3' independent
on the actual values uN or differences between values uN - uM.
Anything else is a bug. And compensating for those bugs in other places
by trying to preserve the exact values of UIDs is broken (and in this case,
as it delays memory optimization, actually bad).
Just my few euro-cents,
Richard.
Re: [RFC] [PATCH] 32-bit pointers in x86-64
>You can't use conventional 32-bit x86 code, so there seems little or no >benefit in allowing 32 and 64-bit code to be mixed. Why not? Switching between 32- and 64-bit modes doesn't involve anything (apart from knowing the proper selector register values) that cannot be done purely in user mode. Specifically, I once successfully tried executing 64-bit code in a 32-bit process. Jan
RE: Re: Does gcc support compiling for windows x86-64?
On 23 November 2007 23:32, Howard Chu wrote: > And it looks > like current bash on cygwin doesn't handle case/esac constructs correctly, > so e.g. > the configure script for BerkeleyDB 4.6.21 fails there. Could you possibly send a testcase to the cygwin mailing list? We haven't had any reports of this yet, but not a lot of us use win64. cheers, DaveK -- Can't think of a witty .sigline today
Re: [RFC] [PATCH] 32-bit pointers in x86-64
>>You can't use conventional 32-bit x86 code, so there seems little or no >>benefit in allowing 32 and 64-bit code to be mixed. > >Why not? Switching between 32- and 64-bit modes doesn't involve anything >(apart from knowing the proper selector register values) that cannot be done >purely in user mode. Specifically, I once successfully tried executing 64-bit >code in a 32-bit process. Oh, I didn't see the original post first (the spam filter ate it for some reason). Of course, if the intention of running this in 64-bit mode makes my comment void (except for the rumor-like thing I heard a few times that there's an undocumented EFER bit allowing x86-32 mode in the sense intended here, but that again would require a kernel running in the same mode underneath). Jan
Re: Designs for better debug info in GCC. Choice A or B?
2007/11/26, Robert Dewar <[EMAIL PROTECTED]> wrote: > The word "full" worries me a bit, I am afraid of it being interpreted as > a requirement to be 100% "correct" in all cases, and this may be too > severe. What we are looking for is good enough in practice, which is a > vaguer criterion, but a more useful one. For instance as I mentioned > early, i would be happy to live with not being able to reliably > modify local variables. You've reason, the world "full" can mean one of many scenarios depending in how wants it to "be filled"! So, it's afraid unknownly in what scenario has to be filled. But, the most important thing is the idea of separation to two choices of debugging, not only the correctness 100% of its implementation. In the context of this topic, the phrase "full debugged information" means all thing that needs the "step to step" debugger as line by line, frame by frame, expression by expression, etc not overenginnering it. Too, it means that it doesn't lack any thing needed by the "step to step" debugger. Its "fullness" depends in what "step to step" debugger we go to use it? Sincerely, J.C.Pizarro
Re: Does gcc support compiling for windows x86-64?
Dave Korn wrote: On 23 November 2007 23:32, Howard Chu wrote: And it looks like current bash on cygwin doesn't handle case/esac constructs correctly, so e.g. the configure script for BerkeleyDB 4.6.21 fails there. Could you possibly send a testcase to the cygwin mailing list? We haven't had any reports of this yet, but not a lot of us use win64. I wasn't able to reproduce it in isolation; it must be something getting corrupted during the course of running BDB's configure script. I'll send a note to the cygwin folks. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Designs for better debug info in GCC. Choice A or B?
2007/11/26, Robert Dewar <[EMAIL PROTECTED]> wrote: > J.C. Pizarro wrote: > > > You've reason, the world "full" can mean one of many scenarios depending > > in how wants it to "be filled"! > > > > So, it's afraid unknownly in what scenario has to be filled. > > > > But, the most important thing is the idea of separation to two choices > > of debugging, not only the correctness 100% of its implementation. > > > > In the context of this topic, the phrase "full debugged information" means > > all thing that needs the "step to step" debugger as line by line, > > frame by frame, expression by expression, etc not overenginnering it. > > > > Too, it means that it doesn't lack any thing needed by the "step to step" > > debugger. > > > > Its "fullness" depends in what "step to step" debugger we go to use it? > > > > Sincerely, J.C.Pizarro > > I tried hard to understand the above, but I am afraid it got so garbled > in the english that it is impossible to understand what you are saying :-( Paradoxing the "fullness": - To you, "I want a full drink of water". And you say me, "what? a glass? a bottle? a jug? a barrel? a deposit? a reservoir?" J.C.Pizarro (sorry, i'm a bad english speaker)
Re: Idea to refine -Wtype-limits
On 25 Nov 2007 21:26:21 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > > I have no implementation strategy at the moment. But I do have a > request: Please, whatever you do, please, don't make it noisy with > template codes and `reasonable' codes. (We have had PRs for that > behaviour in template codes). > Well, the goal is to define a syntax to allow avoiding the warnings. See my proposal previously in this thread about why I think an explicit cast would be better than using 0U in template code. Yet, with template code perhaps we could just avoid warning completely but I don't see how to check at the point of warning that the type comes from the instantiation of a template. If there is some way to check that that I have missed while looking into this, please let me know. Cheers, Manuel.
Re: Idea to refine -Wtype-limits
On Mon, 26 Nov 2007, Manuel López-Ibáñez wrote: | On 25 Nov 2007 21:26:21 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | > | > I have no implementation strategy at the moment. But I do have a | > request: Please, whatever you do, please, don't make it noisy with | > template codes and `reasonable' codes. (We have had PRs for that | > behaviour in template codes). | > | | Well, the goal is to define a syntax to allow avoiding the warnings. | See my proposal previously in this thread about why I think an | explicit cast would be better than using 0U in template code. Yet, I'm no believer in `explicit cast'. | with template code perhaps we could just avoid warning completely but | I don't see how to check at the point of warning that the type comes | from the instantiation of a template. If there is some way to check | that that I have missed while looking into this, please let me know. Template are tricky. During phase one, we usually do as much of semantics analysis as we can, e.g. non dependent things get checked. In phase two, we check only things that were dependent. So, if the enclosing function is generated from a template (and there is a way to know that), then we are checking something that was dependent in the first place. -- Gaby
PR1634: Request for gcc-cvs-patches list
Hello, Back when God hadn't invented the dinosaurs yet (7 years ago) Joseph opened a bug report requesting the creation of a gcc-cvs-patches mailing list. The bug report can be found here: http://gcc.gnu.org/PR1634. Then, nothing happened for many years, a few comments aside. Joseph wants to keep this bug report open to help "actively remembering" people about this open issue, and to track this issue over time. To me it seems there is nothing to track if no-one follows up on te bug report. And with >4500 open bug report, I also don't see how people are going to find this one simple requests. It is like a needle in the hay stack, and nobody is even looking for the needle. So I'm taking the issue here. Do people think it is a good idea to have a gcc-cvs-patches list (or gcc-svn-patches, also fine), where all patches automatically get sent to, exactly as they are committed to SVN (maybe in gzip'ed form)? This would have been especially useful before GCC started using SVN, but even today there are some reasons to have this, as discussed in the bug report. Personally, I like the idea. But someone (probably Joseph, as the requester) should persue the idea. If sufficient people thing this is a good idea, we can think about how to implement it. Or the idea can be rejected. In either case, the enhancement can finally be closed. Gr. Steven
gcc 4.2.2, libgomp under cygwin
Hi, I tried to compile gcc-4.2.2 with openmp support under cygwin. To do so, I previously installed gmp-4.2.2 and mpfr-2.3.0. Now I start configure and up like this: $ ./configure --prefix=/usr/local/ --enable-languages=c loading cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether ln works... (cached) yes checking whether ln -s works... (cached) yes checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gnatbind... no checking whether compiler driver understands Ada... (cached) no checking how to compare bootstrapped objects... (cached) cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... yes checking for correct version of mpfr.h... yes checking for any version of mpfr.h... yes *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgomp target-libffi target-zlib target-libjava t arget-libada gnattools target-libstdc++-v3 target-libgfortran zlib target-libobj c target-boehm-gc (Any other directories should still work fine.) Now I am a bit confused. What is still missing? Because target-libgomp is of course required for the openmp-support. Thanks a lot for any suggestion. Yours sincerely, Joerg -- http://www.joerg.frochte.de/en/
A question
Hi, can we avoid the limitation for template member functions not to be virtual in C++, if we construct v-tables and fill in indices in them at link time, when all member functions are known? May be it's wrong, but now I don't see why. Sincerely yours, Dmitri
Re: Designs for better debug info in GCC
On Nov 26, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote: > On Nov 26, 2007 7:57 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote: >> >> > No, hashing is fine, but doing walks over a hashtable when your algorithm >> > depends on ordering is not. >> >> Point. >> >> > I have patches to fix the instance of walking over all referenced >> > vars. Which is in the case of UIDs using bitmaps and a walk over a >> > bitmap (which ensures walks in UID order). >> >> Why is such memory and CPU overhead better than avoiding the >> divergence of UIDs in the first place? > Actually my patches should be an overall memory savings. Err... I don't see how using a bitmap in addition to a hashtable can save memory over using only a hashtable. Or are you saying you do away with the hashtables? I can see that this is possible and desirable. > But, as you (and me and others) look at bugs that happen because of > UID divergence, it is easier to use UIDs in a way that guarantees > that generated code does not change in such cases. Agreed, this property is desirable. But I wouldn't say it is enough. Ensuring UIDs remain constant across compilations has helped tremendously in locating other compilation divergences, for comparing debug dumps becomes much easier. So, even if we use algorithms that don't depend on UIDs remaining constant across compilations, I believe it is highly desirable that we keep them constant across compilations. > Otherwise what's the point in using UIDs? There are several different reasons for having UIDs, some of which could be having some unique identifier for an object, even in the presence of a moving garbage collector; being able to create fully-ordered sets of objects; being able to easily identify objects across a single compilation; being able to easily identify objects even across multiple compilations; and I'm sure it's possible to come up with other reasons that would justify the idea of UIDs on their own. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
Hi, On Fri, 23 Nov 2007, Alexandre Oliva wrote: > Yep. Nowhere does that bug report request parameters to be forced live. Not in that bug report perhaps, but we got requests for exactly this, i.e. to be able to introspect all parameters of all functions, be they inlined or not, at all time. I think that's a reasonable request even (which in some situations comes at a cost). > 2. function is inlined, the argument is unused and thus optimized > away, but the function does some other useful computation > > At the inlined entry point, we have a note that binds the argument to > its expected value. As we transform the program and optimize away the > argument, we retain and update the note, As far as possible. If it's not possible you loose (with our requirements). > > For us it also happened in the kernel in namei.c, where real_lookup is > > inlined sometimes, and it's arguments are missing. That might or > > might not be reversible functions, so your scheme perhaps would have > > helped there. But generally it won't solve the problem for good. > > It looks like you're trying to solve a different problem. We work on two fronts: 1) increasing the precision of debug information 2) forcing values life Our branch, and our ssa-name<->user-name map (and the SET<->decls association) is concerned with the first topic. The second topic can be implemented (or hacked) already now, but will potentially be more usefull when we also have (1). So, as in your branch, we are not trying to limit optimizers to reach the goal, that's the concern of (2), and happens somewhere else. > I'm trying to get GCC to emit debug information that correctly matches > the instructions it generated. > > If the value of a variable is completely optimized away at a point in > the porogram, the correct representation for its location at that point > is an empty set. I think this is academic. If a value is dead, but happens to lie in a place which isn't yet overwritten with something else, it is harmless to reveal this value. It's the "last" value the variable had. If OTOH the place _is_ already overwritten then it's important that we _don't_ say the dead variable lies therein. So, for me correctness is defined a bit different than for you: 1) if location L contains value X, then debug info should say so (as much as possible, i.e. here the quality of the info comes into play) 2) if location L does not contain value X, debug info should not say that it does. This is the correctness part. Where we differ in opinion (I think) is, when location L doesn't contain value X anymore. For you it's when X becomes dead. For me it's when X is dead and when location L is overwritten (with something different than X). I think for users there is no practical difference between our approaches, but there's a higher cost of implementation for your definition. > > Then I'm probably still confused what problem you're actually trying to > > solve. If you don't want to be sure you get precise location information > > 100% of the time, then what percentage are you required to get? > > Accuracy comes first. If we ever emit debug information saying 'this > variable is here' for a point in the program in which it's in fact > elsewhere I agree here ... > or unavailable, that's a bug to be fixed. ... and disagree here. If a value is dead it's not necessarily unavailable in my world. I think a world requiring this (and hence the constraints you were given) is unreasonable. Ciao, Michael.
Re: Designs for better debug info in GCC
Hi, On Fri, 23 Nov 2007, Alexandre Oliva wrote: > On Nov 13, 2007, Michael Matz <[EMAIL PROTECTED]> wrote: > > > The nice thing is, that there are only few places which really get rid of > > SETs: remove_insn. You have to tweak that to keep the information around, > > not much else (though that claim remains to be proven :) ). > > And then, you have to tweak everything else to keep the note that > replaced the set up to date as you further optimize the code. No. remove_insn() would replace the SET with a note. It would look at other SETs where the information could be put in which is lost. After all, there must have been a reason for the SET to be deleted: the destination is dead, hence whatever user-variables were associated with it also are dead. (if they also lie in other places, those are not affected). So it's okay to completely get rid of the SET and decl associations. One special case of the above is, when a SET is deleted which is a copy, where the LHS was associated with some variables, but the RHS was not. >From that point on we can (under certain circumstances) associate the RHS with the decls (by changing it's initial SET). Ciao, Michael.
Re: PR1634: Request for gcc-cvs-patches list
Do people think it is a good idea to have a gcc-cvs-patches list (or gcc-svn-patches, also fine), where all patches automatically get sent to, exactly as they are committed to SVN (maybe in gzip'ed form)? This would have been especially useful before GCC started using SVN, but even today there are some reasons to have this, as discussed in the bug report. If this is meant for usage by a program, I think that this can be done as easily with svn in the program, based on gcc-cvs messages. Even for semi-automated usage, I think that this is too hard to do with the filters in mail program, and one would resort to procmail (Joseph, what did you have in mind?). Put the recipe in contrib, and you get the same result as a public gcc-cvs-patches mailing list. On the other hand, if it is meant for human usage the file list is already a clue to spot "wrong" commits. Then, an equivalent but more versatile feature request would be to have patches visible online, with URLs like http://gcc.gnu.org/viewcvs/?r1=11r2=12&view=patch (which would do a "svn diff -x -u -r11 -r12"). Such URLs currently work with files but not with directories. I don't know how fundamental a problem with ViewVC and svn-python bindings this is. Note that the latter solution would be nice because gzipped patches sent to a mailing list wouldn't be visible from a browser. Paolo
Re: A question
On Mon, Nov 26, 2007 at 06:55:00PM +0300, Dmitri Lebedinski wrote: > Hi, > can we avoid the limitation for template member functions not to be > virtual in C++, if we construct v-tables and fill in indices in them at > link time, when all member functions are known? May be it's wrong, but > now I don't see why. Maybe. But what about shared libraries? In any case, you're talking about an extension (the feature you ask for isn't standard C++), and the developers have their hands full just supporting the standard language.
Re: Designs for better debug info in GCC
On Nov 26, 2007, "Alexandre Oliva" <[EMAIL PROTECTED]> wrote:
> On Nov 26, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> > On Nov 26, 2007 7:57 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> On Nov 24, 2007, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
> >>
> >> > No, hashing is fine, but doing walks over a hashtable when your algorithm
> >> > depends on ordering is not.
> >>
> >> Point.
> >>
> >> > I have patches to fix the instance of walking over all referenced
> >> > vars. Which is in the case of UIDs using bitmaps and a walk over a
> >> > bitmap (which ensures walks in UID order).
> >>
> >> Why is such memory and CPU overhead better than avoiding the
> >> divergence of UIDs in the first place?
>
> > Actually my patches should be an overall memory savings.
>
> Err... I don't see how using a bitmap in addition to a hashtable can
> save memory over using only a hashtable. Or are you saying you do
> away with the hashtables? I can see that this is possible and
> desirable.
>
> > But, as you (and me and others) look at bugs that happen because of
> > UID divergence, it is easier to use UIDs in a way that guarantees
> > that generated code does not change in such cases.
>
> Agreed, this property is desirable. But I wouldn't say it is enough.
> Ensuring UIDs remain constant across compilations has helped
> tremendously in locating other compilation divergences, for comparing
> debug dumps becomes much easier. So, even if we use algorithms that
> don't depend on UIDs remaining constant across compilations, I believe
> it is highly desirable that we keep them constant across compilations.
>
> > Otherwise what's the point in using UIDs?
>
> There are several different reasons for having UIDs, some of which
> could be having some unique identifier for an object, even in the
> presence of a moving garbage collector; being able to create
> fully-ordered sets of objects; being able to easily identify objects
> across a single compilation; being able to easily identify objects
> even across multiple compilations; and I'm sure it's possible to come
> up with other reasons that would justify the idea of UIDs on their
> own.
Hashtables? Bitmaps? Why not to use a database manager?
Maintaining UIDs only in memory isn't a good idea if many re-compilations
has to make.
I've a better idea to maintain the UIDs (unique identifiers of objects)
across compilations using the fastest database's manager "Tokyio Cabinet"
( http://tokyocabinet.sourceforge.net/ ) LGPLed instead of "Berkeley DB".
To use MD4 (128), MD5 (128) or SHA1 (160) as one-way hashing function of UIDs.
The implementor must to decide how to be the coding of input for the hashing
function of UID and how to store the complex object of UID in the DB.
The info to store each object, it's an example:
{ UID, compiled version of GCC, name of object, path of object, creation date,
type of object, namespace that is using, number of parameters, options
passed to GCC, last access data for elimination from bigger cache, etc. }
Sincerely, J.C.Pizarro
Suggestion for removing flex/bison as a dependancy
Hi,
I would like to propose a set of diffs to enable compilation of gcc
without requiring flex/bison. I feel that this would greatly benefit
the variety of users building gcc.
The only files which really need these are:
gcc/gengtype-lex.l
gcc/treelang/lex.l
gcc/treelang/parse.y
One more thing to note is that, in the toplevel directories: intl/
(for libintl) and libjava/ already ship with the bison-ed .y files (as
plural.c and XQueryParser.java) respectively; They are also present in
the svn repository. So I fell it wouldn't be against the rule to ship
these as part of the core-distro as well.
I wish that this same procedure is applied to the files I have mentioned above.
Things to be done:
1. flex gcc/gengtype-lex.l into gcc/gengtype-lex.c
2. flex gcc/treelang/lex.l into gcc/treelang/lex.c
3. bison gcc/treelang/parse.y into gcc/treelang/parse.h,
gcc/treelang/parse.c, gcc/treelang/parse.output (bison's output)
And finally:
4. Cleanup gcc/Makefile.in, gcc/treelang/Make-lang.in, gcc/configure.ac
5. Rerun autoconf in gcc/.
Because the version of flex/bison/autoconf on my build system may be
newer than what is used by the maintainers, I am not unable to send
patches for 1, 2, 3 and 5. I am sending the diffs for 4. If someone
can help me with the rest/in submitting a diff, Please reply to this.
I hereby request for comments/acknowledgments/suggestions;
--
Karthik
--- gcc/configure.ac 2007-11-08 22:09:59.0 +0530
+++ ../configure.ac 2007-11-26 16:31:16.0 +0530
@@ -865,14 +865,6 @@
MISSING="${CONFIG_SHELL-/bin/sh} $ac_aux_dir/missing"
-# How about lex?
-dnl Don't use AC_PROG_LEX; we insist on flex.
-dnl LEXLIB is not useful in gcc.
-AC_CHECK_PROGS([FLEX], flex, [$MISSING flex])
-
-# Bison?
-AC_CHECK_PROGS([BISON], bison, [$MISSING bison])
-
# Binutils are not build modules, unlike bison/flex/makeinfo. So we
# check for build == host before using them.
--- gcc/Makefile.in 2007-11-13 19:23:33.0 +0530
+++ ../Makefile.in 2007-11-26 16:36:00.0 +0530
@@ -209,10 +209,6 @@
AWK = @AWK@
CC = @CC@
-BISON = @BISON@
-BISONFLAGS =
-FLEX = @FLEX@
-FLEXFLAGS =
AR = @AR@
AR_FLAGS = rc
NM = @NM@
@@ -933,12 +929,8 @@
export slibdir
FLAGS_TO_PASS = \
- "BISON=$(BISON)" \
- "BISONFLAGS=$(BISONFLAGS)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
- "FLEX=$(FLEX)" \
- "FLEXFLAGS=$(FLEXFLAGS)" \
"LN=$(LN)" \
"LN_S=$(LN_S)" \
"MAKEINFO=$(MAKEINFO)" \
--- gcc/Makefile.in 2007-11-13 19:23:33.0 +0530
+++ ../Makefile.in 2007-11-26 16:07:33.0 +0530
@@ -1718,8 +1718,7 @@
srcextra: gcc.srcextra lang.srcextra
-gcc.srcextra: gengtype-lex.c
- -cp -p $^ $(srcdir)
+gcc.srcextra:
c-incpath.o: c-incpath.c c-incpath.h $(CONFIG_H) $(SYSTEM_H) $(CPPLIB_H) \
intl.h prefix.h coretypes.h $(TM_H) cppdefault.h $(TARGET_H) \
@@ -3251,10 +3250,6 @@
build/gengtype$(build_exeext) : build/gengtype-lex.o build/gengtype-parse.o \
$(BUILD_ERRORS)
-# Generated source files for gengtype.
-gengtype-lex.c : gengtype-lex.l
- -$(FLEX) $(FLEXFLAGS) -o$@ $<
-
#
# Remake internationalization support.
intl.o: intl.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) intl.h Makefile
--- gcc/treelang/Make-lang.in 2007-11-22 21:52:14.0 +0530
+++ ../../gcc-mainline-dp/gcc/treelang/Make-lang.in 2007-11-26 16:50:21.0 +0530
@@ -53,7 +53,7 @@
# GCC_FOR_TREELANG = ./xgcc $(GCC_EXTRAS)
-TREE_GENERATED = lex.c parse.c parse.h parse.output
+TREE_GENERATED =
# We need to use something other than treelang here because the directory
# is called treelang
TREE_EXES = gtreelang
@@ -123,21 +123,6 @@
$(TM_H) $(DIAGNOSTIC_H) $(TREE_H) treelang/treelang.h input.h \
treelang/parse.h toplev.h
-# generated files the files from lex and yacc are put into the source
-# directory in case someone wants to build but does not have
-# lex/yacc
-
-treelang.srcextra: treelang/parse.c treelang/parse.h treelang/lex.c
- -cp -p $^ $(srcdir)/treelang
-
-treelang/lex.c: treelang/lex.l
- -$(FLEX) $(FLEXFLAGS) -o$@ $<
-
-treelang/parse.c treelang/parse.h treelang/parse.output: treelang/parse.y
- -$(BISON) $(BISONFLAGS) -v --defines --output=treelang/parse.c $<
-
-# -v
-
#
# Build hooks:
Re: PR1634: Request for gcc-cvs-patches list
On Mon, 26 Nov 2007, Paolo Bonzini wrote: > On the other hand, if it is meant for human usage the file list is already a > clue to spot "wrong" commits. Then, an equivalent but more versatile feature > request would be to have patches visible online, with URLs like > http://gcc.gnu.org/viewcvs/?r1=11r2=12&view=patch (which would do a > "svn diff -x -u -r11 -r12"). Such URLs currently work with files but > not with directories. I don't know how fundamental a problem with ViewVC and > svn-python bindings this is. The primary function is for a human reading the list (where patches directly inline in the message are by far preferable to URLs). I believe the SVN log mailer supports mailing patches anyway. So you could get 90% of the benefit by having the SVN mailer run twice for each commit, once with the present configuration for gcc-cvs and once with a different configuration (including patches, 10MB message size limit (and a similarly large limit for the list itself), truncating rather than splitting anything larger) for gcc-cvs-patches. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Designs for better debug info in GCC
On Nov 26, 2007, J.C. Pizarro <[EMAIL PROTECTED]> that i wrote: > ..., last access data for elimination from bigger cache, etc. } I'm sorry, it's date, not data: ..., last access date for elimination from bigger cache, etc. } Sincerely, J.C.Pizarro
Re: Suggestion for removing flex/bison as a dependancy
On Mon, Nov 26, 2007 at 11:39:47PM +0530, Karthik Kumar wrote: > I would like to propose a set of diffs to enable compilation of gcc > without requiring flex/bison. I feel that this would greatly benefit > the variety of users building gcc. Please be more concrete. I strongly disagree that there is benefit. Note that only building from a checkout requires flex and bison; release tarballs do not. -- Daniel Jacobowitz CodeSourcery
why are stl template classes not mangled as other classes and templates
hi, it seem stl templates are not mangled as other classes and templates I was wondering why and where in the g++ source code is that special case implemented? it seem to cause a problem with -fleading-underscore -- Stephane Hockenhull SSC-Studios.com PS: why would someone wants to underscore a flea's "ding" is beyond me ;)
Re: Suggestion for removing flex/bison as a dependancy
Daniel Jacobowitz wrote: On Mon, Nov 26, 2007 at 11:39:47PM +0530, Karthik Kumar wrote: I would like to propose a set of diffs to enable compilation of gcc without requiring flex/bison. I feel that this would greatly benefit the variety of users building gcc. Please be more concrete. I strongly disagree that there is benefit. I'm with Daniel on this one. Note that only building from a checkout requires flex and bison; release tarballs do not. Do we verify this? I seem to recall bison and makeinfo being needed for a recent release tarball, although I don't remember the details (perhaps it was with binutils 2.18). David Daney
Re: why are stl template classes not mangled as other classes and templates
On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote: > > hi, it seem stl templates are not mangled as other classes and templates > > I was wondering why and where in the g++ source code is that special case > implemented? > > it seem to cause a problem with -fleading-underscore AFAIK there is no special case, however there might be a bug lurking somewhere. Do you have a specific case where -fleading-underscore messes up?
Re: Suggestion for removing flex/bison as a dependancy
On Mon, Nov 26, 2007, Karthik Kumar wrote: > I would like to propose a set of diffs to enable compilation of gcc > without requiring flex/bison. I feel that this would greatly benefit > the variety of users building gcc. Dear Karthik Kumar, why not flex/bison? It's bad idea not using them. The tools flex/bison are required as any tool ( e.g. patch, diff, binutils, sed, bash, gzip, cvs, m4, etc. ) and they are smaller executables to be stored in a CD. The generated files from flex/bison are a lot of "trashing hexadecimals" that don't must to be commited to any cvs/svn/git/hg because it consumes a lot of diskspace for only a modification of few lines of flex/bison sources. J.C.Pizarro
Fwd: Suggestion for removing flex/bison as a dependancy
Hi, On Nov 27, 2007 12:13 AM, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > On Mon, Nov 26, 2007, Karthik Kumar wrote: > > I would like to propose a set of diffs to enable compilation of gcc > > without requiring flex/bison. I feel that this would greatly benefit > > the variety of users building gcc. > > Dear Karthik Kumar, why not flex/bison? It's bad idea not using them. I'm not saying we don't use flex/bison. I am only saying we can remove that as a build dependancy; Many people have to use specific versions of lex (flex) and yacc (bison) if they wish to compile gcc. All directories which have configure scripts also have their autoconf files (configure.ac) in the tree. And many directories which have Makefile.in have Makefile.am as well. It is generally a good idea for the user to keep the autotools as well; But there is no need to use those if the configure and Makefile.in files are already there. Besides, taking a look at the tree, libintl and libjava have processed .y files. I only suggest that we keep the C versions of these files in the tree as well. > > The tools flex/bison are required as any tool > ( e.g. patch, diff, binutils, sed, bash, gzip, cvs, m4, etc. ) and > they are smaller executables to be stored in a CD. > > The generated files from flex/bison are a lot of "trashing hexadecimals" that > don't must to be commited to any cvs/svn/git/hg because it consumes > a lot of diskspace for only a modification of few lines of flex/bison sources. The configure/Makefile.in scripts are significantly large as well. -- Karthik
Re: Progress on GCC plugins ?
> "Taras" == Taras Glek <[EMAIL PROTECTED]> writes: Tom> LD_PRELOAD would work just as well as having gcc directly support Tom> plugins, provided that certain internal things are never made Tom> file-local. Someone could write a helper library to make it Tom> relatively simple to hook in. But... I looked at this recently, and Tom> since gcc is not linked with -rdynamic, it is a non-starter. Taras> Tom, I don't know much about linkers and LD_PRELOAD. Would making Taras> LD_PRELOAD work be easier than making an unstable plugin API? Not really. The difference would be that with LD_PRELOAD the gcc change would be very small -- just linking with -rdynamic. Maybe you could lobby a Linux distro for this :-) But even if the gcc change is small, you'd still want to write and maintain about the same amount of code to let plugins interface with the pass manager. Tom
Re: why are stl template classes not mangled as other classes and templates
On Monday 26 November 2007 13:40, Joe Buck wrote: > On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote: > > hi, it seem stl templates are not mangled as other classes and templates > > > > I was wondering why and where in the g++ source code is that special case > > implemented? > > > > it seem to cause a problem with -fleading-underscore > > AFAIK there is no special case, however there might be a bug lurking > somewhere. Do you have a specific case where -fleading-underscore messes > up? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166 the .stabs section differ from the actual call by 1 underscore prefix -- Stephane Hockenhull SSC-Studios.com
Re: why are stl template classes not mangled as other classes and templates
On Mon, Nov 26, 2007 at 10:40:35AM -0800, Joe Buck wrote: > On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote: > > > > hi, it seem stl templates are not mangled as other classes and templates > > > > I was wondering why and where in the g++ source code is that special case > > implemented? > > > > it seem to cause a problem with -fleading-underscore > > AFAIK there is no special case, however there might be a bug lurking > somewhere. Do you have a specific case where -fleading-underscore messes > up? There are a few special cases, e.g. for std::string and std::basic_string; the C++ ABI documents have the details. _ZSi -> std::basic_istream > -- Daniel Jacobowitz CodeSourcery
Re: Progress on GCC plugins ?
Tom Tromey wrote:
"Taras" == Taras Glek <[EMAIL PROTECTED]> writes:
Tom> LD_PRELOAD would work just as well as having gcc directly support
Tom> plugins, provided that certain internal things are never made
Tom> file-local. Someone could write a helper library to make it
Tom> relatively simple to hook in. But... I looked at this recently, and
Tom> since gcc is not linked with -rdynamic, it is a non-starter.
Taras> Tom, I don't know much about linkers and LD_PRELOAD. Would making
Taras> LD_PRELOAD work be easier than making an unstable plugin API?
Not really.
The difference would be that with LD_PRELOAD the gcc change would be
very small -- just linking with -rdynamic. Maybe you could lobby a
Linux distro for this :-)
I'm not fully convinced that just LD_PRELOAD is enough to add poor man's
plugin into GCC.
Plugins into GCC are expected to add optimisation passes (see file
gcc/passes.c function init_optimization_passes and I don't understand
what exactly LD_PRELOAD trick (unless you also redefine this very
function init_optimization_passes in your ld_preload-ed plugin) would
enable this.
So Tom or Taras, could you please elaborate on this? What tricks are you
thinking of?
However, you are right in the sense that implementing naive plugins is
technically easy; apparently the issue is political, not technical (i.e.
let RMS accept or bless it).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Fwd: Suggestion for removing flex/bison as a dependancy
> "Karthik" == Karthik Kumar <[EMAIL PROTECTED]> writes: Karthik> All directories which have configure scripts also have their Karthik> autoconf files (configure.ac) in the tree. And many Karthik> directories which have Makefile.in have Makefile.am as well. Yes. The rule is, or ought to be, that if you have the needed dependencies you should be able to check out gcc, run configure, and then run make. Checking in configure and Makefile.in supports this mode of operation. Checking in lex- or yacc-generated files does not. Karthik> Besides, taking a look at the tree, libintl and libjava have Karthik> processed .y files. I only suggest that we keep the C Karthik> versions of these files in the tree as well. libintl and those parts of libjava are externally maintained. The distinction here is (at least for libjava, I'm not up on libintl any more) that it is simpler to just follow whatever upstream does. Tom
Re: why are stl template classes not mangled as other classes and templates
On Mon, Nov 26, 2007 at 02:01:30PM -0500, Daniel Jacobowitz wrote: > On Mon, Nov 26, 2007 at 10:40:35AM -0800, Joe Buck wrote: > > On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote: > > > > > > hi, it seem stl templates are not mangled as other classes and templates > > > > > > I was wondering why and where in the g++ source code is that special case > > > implemented? > > > > > > it seem to cause a problem with -fleading-underscore > > > > AFAIK there is no special case, however there might be a bug lurking > > somewhere. Do you have a specific case where -fleading-underscore messes > > up? > > There are a few special cases, e.g. for std::string and > std::basic_string; the C++ ABI documents have the details. > > _ZSi -> std::basic_istream > Oh, right, I forgot about that one. My guess is that no one thought about the interaction between this special case and -fleading-underscore.
Re: Suggestion for removing flex/bison as a dependancy
On 2007/11/26, Karthik Kumar <[EMAIL PROTECTED]> wrote: > Hi, > > > On Nov 27, 2007 12:13 AM, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 26, 2007, Karthik Kumar wrote: > > > I would like to propose a set of diffs to enable compilation of gcc > > > without requiring flex/bison. I feel that this would greatly benefit > > > the variety of users building gcc. > > > > Dear Karthik Kumar, why not flex/bison? It's bad idea not using them. > > I'm not saying we don't use flex/bison. I am only saying we can remove > that as a build dependancy; Many people have to use specific versions > of lex (flex) and yacc (bison) if they wish to compile gcc. All > directories which have configure scripts also have their autoconf > files (configure.ac) in the tree. And many directories which have > Makefile.in have Makefile.am as well. It is generally a good idea for > the user to keep the autotools as well; But there is no need to use > those if the configure and Makefile.in files are already there. > Besides, taking a look at the tree, libintl and libjava have processed > .y files. I only suggest that we keep the C versions of these files in > the tree as well. > > > > > The tools flex/bison are required as any tool > > ( e.g. patch, diff, binutils, sed, bash, gzip, cvs, m4, etc. ) and > > they are smaller executables to be stored in a CD. > > > > The generated files from flex/bison are a lot of "trashing hexadecimals" > > that > > don't must to be commited to any cvs/svn/git/hg because it consumes > > a lot of diskspace for only a modification of few lines of flex/bison > > sources. > > The configure/Makefile.in scripts are significantly large as well. I hate considering temporary files as sources of the tree. They aren't sources. It's good idea to remove ALL generated files from sources: A) generated *.c, *.h from lex/bison sources *.l/*.y B) generated not-handwritten configure, makefile, aclocal.m4, config.h.in, makefile.in from the configure.ac and makefile.am sources. [the handwritten configure and makefile have to be rewritten to *.ac/*.am] C) generated binary objects *.class, *.o, *.a, *.so, ... D) generated *.c, *.h, *.cpp, *.hpp, ... from *.java E) any generated from any available source by available tool. The only exception is when the project need a bootstrapping system. See to understand http://en.wikipedia.org/wiki/GNU_build_system easy! So, the cvs/svn/git/hg repositories of sources will be "small and clean" without "trashing generated files, hexadecimals, ..." This recommendation is an advantage to navigate by web to clean cvs/svn/git/hg repositories. In another case, it's an inconvenient. J.C.Pizarro
Installation Problem
I am attempting to install gcc-4.2.2 on an SGI Octane running IRIX 6.5.26 I untar'd the gcc-4.2.2.tar file in the target directory /usr/local/gcc4x I went through the traditional 'configure' step as a prelude to the 'make install' step That produced the following => configure creating cache ./config.cache checking host system type... mips-sgi-irix6.5 checking target system type... mips-sgi-irix6.5 checking build system type... mips-sgi-irix6.5 checking for a BSD compatible install... ./install-sh -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. I do have other prior version of gcc installed => versions | grep gcc I fw_gcc 06/05/2007 gcc-3.3 GNU Compiler Suite I fw_gcc.man 06/05/2007 gcc-3.3 man pages I fw_gcc.man.gcc 06/05/2007 gcc-3.3 man pages I fw_gcc.man.info 06/05/2007 gcc-3.3 info pages I fw_gcc.man.relnotes 06/05/2007 gcc-3.3 release notes I fw_gcc.sw06/05/2007 gcc-3.3 execution only env I fw_gcc.sw.gcc06/05/2007 gcc-3.3 execution only env I fw_gcc.sw.libstdc++ 06/05/2007 gcc-3.3 libstdc++-v3 I fw_gcc.sw.utils 06/05/2007 gcc-3.3 other languages, utilities I neko_gcc 11/18/2007 gcc-3.4.6 GNU Compiler Collection I neko_gcc.man 11/18/2007 gcc-3.4.6 man pages I neko_gcc.man.gcc 11/18/2007 gcc-3.4.6 man pages I neko_gcc.sw 11/18/2007 gcc-3.4.6 execution only env I neko_gcc.sw.gcc 11/18/2007 gcc-3.4.6 execution only env I neko_gcc.sw.utils11/18/2007 gcc-3.4.6 other languages, utilities Could you advise? BTW: I would like to use the Fortran f77 or f95 compiler when installed, are there any special nuances to observe? Thanks!
Re: Progress on GCC plugins ?
> "Basile" == Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes: Basile> Plugins into GCC are expected to add optimisation passes (see file Basile> gcc/passes.c function init_optimization_passes and I don't understand Basile> what exactly LD_PRELOAD trick (unless you also redefine this very Basile> function init_optimization_passes in your ld_preload-ed plugin) would Basile> enable this. FWIW I don't think this is an especially fruitful avenue of discussion. Let's take future conversation about LD_PRELOAD off-list. Basile> So Tom or Taras, could you please elaborate on this? What tricks are Basile> you thinking of? I think it isn't extremely hard for a preloaded .so to look up the pass list and dynamically modify it. This would be a big hack of course. I don't really recommend it. I do wonder if there is a platform out there that acts as if -rdynamic were the default. On such a platform you could already write plugins. Tom
Re: why are stl template classes not mangled as other classes and templates
On Monday 26 November 2007 14:01, Daniel Jacobowitz wrote: > On Mon, Nov 26, 2007 at 10:40:35AM -0800, Joe Buck wrote: > > On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote: > > > hi, it seem stl templates are not mangled as other classes and > > > templates > > > > > > I was wondering why and where in the g++ source code is that special > > > case implemented? > > > > > > it seem to cause a problem with -fleading-underscore > > > > AFAIK there is no special case, however there might be a bug lurking > > somewhere. Do you have a specific case where -fleading-underscore messes > > up? > > There are a few special cases, e.g. for std::string and > std::basic_string; the C++ ABI documents have the details. > > _ZSi -> std::basic_istream > those cause problem with -fleading-underscore. it seem there is more than one data path for the mangling and one of those misses adding the extra underscore which cause missing symbols at linking. -- Stephane Hockenhull SSC-Studios.com
Fwd: label conflict resolution for global variables
When using g++, one can get label conflicts in assembler code by using
specific names for globals that match up against functions. e.g.:
void a () {}
int _Z1av;
since the 'a' function is mapped to the label "_Z1av". (compile with
-S and look at the .s file.) This occurs even when the global variable
isn't declared within an extern "C" {} block. Should non-'extern "C"
{}' global variable names also be decorated?
Re: label conflict resolution for global variables
On 11/26/07, Andrew Ducore <[EMAIL PROTECTED]> wrote:
> since the 'a' function is mapped to the label "_Z1av". (compile with
> -S and look at the .s file.) This occurs even when the global variable
> isn't declared within an extern "C" {} block. Should non-'extern "C"
> {}' global variable names also be decorated?
It does not matter as _Z1av is in the implementation identifier space
so any use in user sources is undefined.
Thanks,
Andrew Pinski
Re: Suggestion for removing flex and bison as a dependancy
I suppose this is related to what I said to you on IRC, so I ought to chime in here. I agree with Daniel and David - your patch is not appropriate. As long as we actually have the .l and .y files, the associated .c/.h files should not be checked in, and flex/bison should be required when building from a SVN checkout. To do otherwise risks that someone changes the .l/.y file and forgets to check in the updated .c/.h files, which produces an invalid state in the repository. (Yes, this is a problem with the autoconf-generated files as well, and we *have* had this problem with them in the past. I would actually support removing those generated files from SVN - but that is a separate discussion.) What I was trying to encourage you to do, on IRC, was *replace* gengtype-lex.l with hand-written code. I suggested the use of cpplib because it's existing code that should do the job, and besides, it knows how to do macro expansion, which gengtype badly needs - some terrible hacks could go away. However, it might be tricky to make it work; it's possible that an entirely new lexer would be a better choice. If you do the work, you get to make the call. :-) I do not think it is worth bothering to do anything about the use of flex and bison in treelang. If anything, that entire subdirectory could be dropped; my impression is that it is unmaintained and not particularly useful even as an example. It is already not built nor installed by default. zw
gcc-4.1-20071126 is now available
Snapshot gcc-4.1-20071126 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071126/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 130452 You'll find: gcc-4.1-20071126.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20071126.tar.bz2 C front end and core compiler gcc-ada-4.1-20071126.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20071126.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20071126.tar.bz2 C++ front end and runtime gcc-java-4.1-20071126.tar.bz2 Java front end and runtime gcc-objc-4.1-20071126.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20071126.tar.bz2The GCC testsuite Diffs from 4.1-20071119 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Designs for better debug info in GCC
On Nov 26, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Fri, 23 Nov 2007, Alexandre Oliva wrote:
>> Yep. Nowhere does that bug report request parameters to be forced live.
> Not in that bug report perhaps, but we got requests for exactly this, i.e.
> to be able to introspect all parameters of all functions, be they inlined
> or not, at all time. I think that's a reasonable request even (which in
> some situations comes at a cost).
Fair enough. And we agree this is not about debug info, it's about
limiting optimizations, so this is indeed a different problem from the
one I was asked to address.
>> 2. function is inlined, the argument is unused and thus optimized
>> away, but the function does some other useful computation
>>
>> At the inlined entry point, we have a note that binds the argument to
>> its expected value. As we transform the program and optimize away the
>> argument, we retain and update the note,
> As far as possible. If it's not possible you loose (with our
> requirements).
If the argument is completely removed, yes, you won't be able to get
to it by merely improving debug information. You actually have to
change the generated code.
>> If the value of a variable is completely optimized away at a point in
>> the porogram, the correct representation for its location at that point
>> is an empty set.
> I think this is academic. If a value is dead, but happens to lie in a
> place which isn't yet overwritten with something else, it is harmless to
> reveal this value. It's the "last" value the variable had. If OTOH the
> place _is_ already overwritten then it's important that we _don't_ say the
> dead variable lies therein.
Exactly. Full agreement. I wasn't talking about the *location* of
the variable, or the variable itself. I was talking about the value.
And I wrote "completely optimized away", not "dead". Liveness has
very little to do with this issue.
The only catch is that, once a variable should be *expected* to hold a
different value, if debug information still claims the variable still
holds the old value it shouldn't hold any more, just because the value
happens to be around and the assignment of the new value could be
optimized away, then I'd say debug information is incorrect.
> So, for me correctness is defined a bit different than for you:
> 1) if location L contains value X, then debug info should say so (as much
>as possible, i.e. here the quality of the info comes into play)
> 2) if location L does not contain value X, debug info should not say that
>it does. This is the correctness part.
Your definition is exactly what I've been trying to communicate. It
looks like we're in complete agreement as to the goals and the two
different metrics (1 being completeness, 2 being correctness). So
either there's some other underlying difference or you'll soon realize
that the simple SSA name<->variable mapping is insufficient to get you
correctness.
> Where we differ in opinion (I think) is, when location L doesn't contain
> value X anymore. For you it's when X becomes dead. For me it's when X is
> dead and when location L is overwritten (with something different than X).
For me, it's when X is overwritten. That's the point at which the
user is entitled to expect the variable to no longer hold its previous
value (assuming they're different).
Consider this program:
int foo(int x) {
int i;
i = x;
p1();
i++;
p2(i);
i++;
p3();
}
int main() {
foo(1);
}
If you set a breakpoint in p1(), go up one frame and print i, you
should ideally get 1 (although "unavailable" is always correct, even
if undesirable). If you set a breakpoint in p2(int), you should get
2, but "unavailable" is quite likely in the presence of optimization,
depending on the calling conventions. If you set a breakpoint in
p3(), you should get 3, but "unavailable" is quite likely, given that
the value is not even computed, and it's based on a value that is dead
and thus may have been overwritten.
Getting any other values at any of these points would be a bug in the
compiler.
Does this sound sound to you?
Did you somehow get the impression that the SSA<->names mapping can
get you correct results?
>> Accuracy comes first. If we ever emit debug information saying 'this
>> variable is here' for a point in the program in which it's in fact
>> elsewhere
> I agree here ...
>> or unavailable, that's a bug to be fixed.
> ... and disagree here. If a value is dead it's not necessarily
> unavailable in my world.
I never said "dead", you did. I said "unavailable", and by that I
don't mean "dead", I really mean "unavailable". The value I'm talking
about is not "whatever was last assigned to something that resembles
the variable after numerous optimizations" but rather "a value the
user might expect the variable to hold at that point in the program",
given some user tolerance to reordering and other optimizations.
One reason I use separate func
Re: why are stl template classes not mangled as other classes and templates
On Mon, Nov 26, 2007 at 04:02:48PM -0500, Stephane Hockenhull wrote: > On Monday 26 November 2007 14:01, Daniel Jacobowitz wrote: > > On Mon, Nov 26, 2007 at 10:40:35AM -0800, Joe Buck wrote: > > > On Mon, Nov 26, 2007 at 01:33:54PM -0500, Stephane Hockenhull wrote: > > > > hi, it seem stl templates are not mangled as other classes and > > > > templates > > > > > > > > I was wondering why and where in the g++ source code is that special > > > > case implemented? > > > > > > > > it seem to cause a problem with -fleading-underscore > > > > > > AFAIK there is no special case, however there might be a bug lurking > > > somewhere. Do you have a specific case where -fleading-underscore messes > > > up? > > > > There are a few special cases, e.g. for std::string and > > std::basic_string; the C++ ABI documents have the details. > > > > _ZSi -> std::basic_istream > > > those cause problem with -fleading-underscore. > > it seem there is more than one data path for the mangling and one of those > misses adding the extra underscore which cause missing symbols at linking. Hm. But -fleading-underscore is there to support an old ABI, the one that BSD Unix used to use, and the _ZSi is for the newer common ABI. Probably no one tested the interaction, so I don't know what the correct solution is. But why are you using -fleading-underscore?
Re: Designs for better debug info in GCC
On Nov 26, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> Hi,
> On Fri, 23 Nov 2007, Alexandre Oliva wrote:
>> On Nov 13, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
>>
>> > The nice thing is, that there are only few places which really get rid of
>> > SETs: remove_insn. You have to tweak that to keep the information around,
>> > not much else (though that claim remains to be proven :) ).
>>
>> And then, you have to tweak everything else to keep the note that
>> replaced the set up to date as you further optimize the code.
> No. remove_insn() would replace the SET with a note.
What information would this note convey?
> After all, there must have been a reason for the SET to be deleted:
> the destination is dead, hence whatever user-variables were
> associated with it also are dead.
Note quite. The destination could be merely redundant. And the
difference is crucial.
If you delete a copy (or some other redundant computation, you don't
seem to handle this case) that would install a value in a variable
that is available elsewhere, and then adjust the uses of the variable
such that they use the value elsewhere, you ought to note that the
variable holds that value, and at that point.
If you delete a computation because the result is completely unused,
then you ought to note that you no longer know the value of the
variable (or, ideally, that the variable would hold the result of that
computation if there was code to compute it).
In both cases, you ought to note that earlier values of the variable
are no longer current at that point.
In both cases, the notion of "at that point" is crucial, especially
when you deal with conditional assignments. You don't want to make it
seem like a conditional assignment applies when the condition doesn't
hold. Consider:
int foo(bool p, int x, int y) {
int i = x;
p1();
if (p)
i = y;
p2();
i++;
p3(i);
}
int main() {
foo (false, 3, 5);
}
At p1()'s caller's frame, you want i to hold the value 3. At p2()'s,
you want i to still hold the value 3. At p3(int)'s, it should be 4.
Now, if you change the program such that p is true, then at p1 i is
still 3, but at p2 it ought to be 5, and at p3(int)'s it should be 6.
How do you get that if you drop the assignments on the floor, or even
if you replace them assignments with notes that don't keep the correct
values associated not only with the names, but also with the points in
the program?
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
BITS_PER_UNIT larger than 8 -- word addressing
I'm working with a target that has 32-bit word addressing, so there is a define of BITS_PER_UNIT = 32. This causes a problem: an error saying that there is no emulation for 'DI'. DImode has a precision of 128 bits, which is clearly incorrect. (All the other integer modes were incorrect as well.) DI is defined in machmode.def as INT_MODE (DI, 8). This is sort-of correct, DI is an 8 byte or 2 word value. When this is used to generate insn-modes.c, its size is generated as 8*BITS_PER_UNIT, not 2*BITS_PER_UNIT, because, it seems, genmodes assumes that size in bits is is bytesize*BITS_PER_UNIT. In emit_mode_precision() in genmodes.c the assumption is pretty clear. I built the c4x target, since that's the only example of a target with BITS_PER_UNIT set. It looks like this target is defunct and slated for removal. It gets the same error. If BITS_PER_UNIT should alway be bytesize, then it seems unnecessary to have the definition of BITS_PER_UNIT. Or it looks like genmodes.c needs to have another define, BYTES_PER_UNIT, so that it can correctly convert from bytesize to the number of units for the target. Or the definition of integer sizes should be directly in bits, without any reference to bytesize. Is there a different way to define word-addressed targets? Or should I just pretend it has byte addressing? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Installation Problem
Joseph Maxwell wrote: > > I am attempting to install gcc-4.2.2 on an SGI Octane running IRIX 6.5.26 > I untar'd the gcc-4.2.2.tar file in the target directory /usr/local/gcc4x >checking for gcc... gcc >checking whether the C compiler (gcc ) works... no >configure: error: installation or configuration problem: C compiler > cannot create executables. > > Could you advise? Someone will have to look at config.log and try to figure out how to make your previous gcc work. Why not you? > > BTW: I would like to use the Fortran f77 or f95 compiler when installed, > are there any special nuances to observe? gcc-4.2 includes gfortran; should do the job for you.
Re: BITS_PER_UNIT larger than 8 -- word addressing
Miceal Eagar writes: >I'm working with a target that has 32-bit word addressing, >so there is a define of BITS_PER_UNIT = 32. According to the documentation, this changes the size of a byte to 32 bits, instead of the more usual 8 bits. >This causes a problem: an error saying that there is >no emulation for 'DI'. DImode has a precision of 128 bits, >which is clearly incorrect. (All the other integer modes >were incorrect as well.) DImode is defined to be 8 bytes long so with a 32-bit byte I'd expect it to be 256 bits. Trying use QImode and HImode for 32-bit and 64-bit operations respectively. Ross Ridge
Re: why are stl template classes not mangled as other classes and templates
On Mon, Nov 26, 2007 at 04:29:35PM -0800, Joe Buck wrote: > But why are you using -fleading-underscore? It's the default for a lot of targets. I'd still like to see a concrete example of the problem... -- Daniel Jacobowitz CodeSourcery
Re: gcc 4.2.2, libgomp under cygwin
Joerg Frochte wrote: > *** This configuration is not supported in the following subdirectories: > target-libmudflap target-libgomp target-libffi target-zlib > target-libjava t > arget-libada gnattools target-libstdc++-v3 target-libgfortran zlib > target-libobj > c target-boehm-gc > (Any other directories should still work fine.) > > > Now I am a bit confused. What is still missing? > Because target-libgomp is of course required for the openmp-support. Cygwin is not a target where libgomp is enabled by default, though it probably should be since it strives for POSIX. You have to --enable-libgomp explicitly if you want to build it. Brian
Re: BITS_PER_UNIT larger than 8 -- word addressing
Ross Ridge wrote: Miceal Eagar writes: I'm working with a target that has 32-bit word addressing, so there is a define of BITS_PER_UNIT = 32. According to the documentation, this changes the size of a byte to 32 bits, instead of the more usual 8 bits. This causes a problem: an error saying that there is no emulation for 'DI'. DImode has a precision of 128 bits, which is clearly incorrect. (All the other integer modes were incorrect as well.) DImode is defined to be 8 bytes long so with a 32-bit byte I'd expect it to be 256 bits. Trying use QImode and HImode for 32-bit and 64-bit operations respectively. Well, can't do that. This is not target dependent. DImode gets defined, and used, for long long in unwind-dw2.c. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
