SoC Project: Finish USE_MAPPED_LOCATION
Is this an appropriate SoC project? Gcc can optionally be configured with --enable-mapped-locations. This sets a conditional USE_MAPPED_LOCATION which changes how line and column numbers are represented in the various data structures. We'd like to switch gcc to use this representation, for various reasons (availability of column numbers in error messages and debug into; hopefully improved memory efficiency; making the various parts of the compiler more consistent). The goal of this project is to fix various functionality so USE_MAPPED_LOCATION works at least as well as the current default does, so we can make it the default, and then soon after remove the old non-USE_MAPPED_LOCATION code. This means investigating test-suite regressions, and fixing/implementing any missing functionality. The main known missing "chunk" is support for pre-compiled-headers (pch). In addition the Ada language front-end does not handle USE_MAPPED_LOCATION. I'm available to advise/mentor on this project. However, as I'm somewhat rusty about the current state of Gcc I'm hoping I can get one more mentor who is more current on what has been happening with Gcc. (I don't consistently monitor the gcc mailing lists, so please cc me on any gcc email you want me to see in a timely manner.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: HTML of -fdump-tree-XXXX proposal.
Without taking a position on the current proposal, using xhtml
for "dump" files has some further advantages:
* Can use hyperlinks, for example from a reference to the declaration,
or from a variable to its type.
* Can use JavaScript to hide/unhide sections of the dump.
* Can use CSS to switch between display styles. This can be
done dynamically with a smidgen of JavaScript.
* Can more easily convert to other formats, or select only desired
elements, using some suitable XML processor such as xsltproc.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: HTML of -fdump-tree-XXXX proposal.
J.C. Pizarro wrote: Your idea with JavaScript, CSS, XSLT, .. is very good! :) Thanks you - but ideas are cheap. Turned a vague idea into something useful is a different matter -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
documentation on writing testcases?
I have an immediate problem and a general frustration.
The immediate problem is that my lexer patches causes a test
failure in gcc.dg/cpp/direct2.c, because an error that used to
be on line 15 ("expected '=', ',', ';', 'asm' or '__attribute__'
before string constant") is now on line 13. Since the string
constant is on line 13, I believe this is a fix rather than a
regression. So I need to move the dg-error on line 15 to line 13
- but there is already a dg-error there, and dejagnu barfs if it
sees two dg-error comments on the same line.
So the immediate question is: how should the testcase be fixed?
The general frustration is: where is dg-error documented?
I looked in:
- the README* files in gcc/testsuite and in gcc.dg;
- the Test Suites chapter of the internals manual
(which mentions "special idioms" but not the basics);
- the "Testsuite Conventions" of codingconventions.html;
- contribute.html;
- install/test.html;
- and of course Google.
In *none* of these did I find documentation on how to write or
understand a test-case, or a link to such documentation. I'm inclined
to think that most of these above places should have such a link.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: documentation on writing testcases?
Janis Johnson wrote: There's some information about test directives in the GCC Internals manual in the Testsuites section. Google was not my friend ... I searched for "dg-error gcc tests" and near the top was a link to the internals manual. But it was some random copy covering 3.4 which did not include the new-ish "Test-Directives" mode. I didn't notice that at first. It might be good to link to http://gcc.gnu.org/onlinedocs/gccint/Testsuites.html in some of the places I mentioned. On the other hand, http://gcc.gnu.org/onlinedocs/gccint/Testsuites.html doesn't mention how to run the testsuite. Perhaps there should be a link to http://gcc.gnu.org/install/test.html from the internals manual. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
converting Ada to handle USE_MAPPED_LOCATION
I fixed the regressions USE_MAPPED_LOCATION for C and C++, and we've now branched, so it's is probably time to get Ada working. (There is a Java problem, for which I have a patch, but it may hurt debugging. Until that is fixed, leave Java out of --enable-languages, or apply this patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01094.html ) Some links to the pervious discussions: http://gcc.gnu.org/ml/gcc/2004-10/msg00012.html http://gcc.gnu.org/ml/gcc/2004-10/msg00200.html http://gcc.gnu.org/ml/gcc/2004-10/msg00229.html http://gcc.gnu.org/ml/gcc/2004-10/msg00248.html http://gcc.gnu.org/ml/gcc/2004-10/msg00261.html http://gcc.gnu.org/ml/gcc/2004-10/msg00265.html There wasn't really a consensus on how to do it. The ideal solution I think is for Ada to use line-map's source_location for Sloc in its lexer. I don't think it would be that hard, but an easier solution may be to leave Sloc alone, and instead translate Sloc integers to source_location when we translate the Ada intermal format to Gcc trees. See: http://gcc.gnu.org/ml/gcc/2004-10/msg00248.html I think this is my current recommendation; to expand on it a little: We can add a new function line-map.h: source_location linemap_get_location (struct line_table*, const char *filename, int line, int column); A simple implementation: (1) check that (file, line, column) can use the current line_map: strcmp (filename, map->to_file) == 0 && line >= map->to_line && column < (1 << map->column_bits) && line not excessively big; The latter is a heuristic to avoid using up line number too greedily; I suspect it may not be an issue. (2) If the test passes, calculate the source_location from (line, column) using map->start_location and map->column_bits. Also update highest_location and highest_line. (3) Otherwise, allocate a new map using linemap_add. In the future we can improve linemap_get_location if it turns out to be necessarily; for example searching previously used map entries and/or keeping a cache of recently used maps. Some people suggested instead that the location_t in the shared Gcc should be a language-defined opaque time, and have language call-backs. The default would be source_location as managed by line_map, but Ada could use a different implementation. That may be a short-term easier for Ada, but I don't think it's the best long-term solution for Gcc as a whole. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: converting Ada to handle USE_MAPPED_LOCATION
Geert Bosch wrote: Of the three proposals: [...] The ideal solution I think is for Ada to use line-map's source_location for Sloc in its lexer. [...] translate Sloc integers to source_location when we translate the Ada intermal format to Gcc trees. [...] the location_t in the shared Gcc should be a language-defined opaque time, and have language call-backs. The first one really is out for the Ada maintainers, as this would couple the front end far too tightly to the back end Ok. and lose the nice property that the exact same front end sources (excluding the few C files for tree conversion) > can be used for any GCC back end from 2.8.1 to 4.1 Does this help with boostrapping? Otherwise, I'm not sure why this is important. But anyway, I'm not going to push for this approach. The second one wouldn't be my preferred choice, as it adds complexity I think this solution is *less* complex than your preferred solution. A simple translaton can be done in just a few lines of code, which are localized to a single file - maybe a single function. (Adding a linemap_get_location as I suggested is not strictly needed, but is probably a good idea.) Making location_t an opaque type seems to have a lot more ramifications, including adding language hooks and making sure they're used where needed. > for no gain, I think call-backs are generally to be avoided. They make the system more fragile and less flexible. Consider a hypothetical Gcc that would allow opimizing modules from multiple languages. After inlining, you might have tree nodes and rtl from either C or Ada, all mixed together. In that environment a language-dependent opaque type isn't going to work; locations have to be translated to a common representation. > but because the code can remain localized to the few C files interfacing the front end to the back end, this would be acceptable. Good. The last would be far preferred, as it would not tie in front ends so much to the back end, Translating locations at the same time you translate to generic tree nodes doesn't seem to involve any extra tying. As it both seems easiest to implement, I suspect not. Simple-seeming changes can end up being quite a pain to implement when multiple modules are involved. Just look at Zack's recent work to clean up version number management. and cleanest. Of course that's in the eye of the beholder. I think a local translation is cleaner and more robust/safer than a global opaque type/call-back. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
dejagnu help needed - tests get confused by column numbers
If you run 'make check' after --enable-mapped-location (even just --enable-languages=c) you'll find some apparant regressions. They aren't real regressions - it's just now we now get column numbers in some of the diagnostic messages, and this confuses dejagnu. Now I'm willing to fix those tests by adding -fno-show-column where necessary, and this fixes those testcases. However, that obviously is a kludge. The Right Thing to do is to fix dejagnu so it doesn't get confused by column numbers. I'm guessing this is a one- or two-line fix, but I don't know dejagnu, I've forgotten most of what little I used to know about tcl, and I don't know where to start. I'm asking for someone who will know the Right Thing, and who will do. Anyone out there? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
PCH versus --enable-mapped-location
I think I have a better handle of where the pch regressions with --enable-mapped-location are coming from. This is a follow-up to some debugging/experimentation that Zack did - in September! I agree with Zack that the problem is that the line_table data structure needs to saved into the gch file along with the other state. But I think Zack missed some subtleties. * The line_table.maps[0] entry represents the main file, and so should *not* be restored from the gch file. * The other line_table.maps[i], i > 0 appear to be "correct" in the sense that their names and location values at gch-generation time can replace the line_table.maps[i], i > 0 at restore time. * However, there is some trickiness with "the tail" of the table: we need to restore the line_table.highest_line and .high_location from the gch file. Furthermore, we need to create a current line_map for "back in the main file again". We also need to make sure the LC_ENTER/LC_RENAME/LC_LEAVE nesting is sane and the new line_map has the MAIN_FILE_P property. * Note that we compile the gch file as it were the main file - i.e. it has the MAIN_FILE_P property, and it is not included from any file. This means the restored line_table is slightly anomalous. One solution to this is when we generate the gch file, we pretend the .h file is included in a dummy file, which we may call . This adds two line_map entries: one for before the LC_ENTER of the .h file, and one at the end to LC_LEAVE the .h file. Then when we restore, we patch both of these to replace "" by the real main file name. * Alternatively, we can keep gch-generation as is. In that case after restoration, we need to add a line_map that does an LC_RENAME back to the main file. * Any source_location values handed out before the #include that restores the gch will become invalid. They will be re-mapped to that in the pre-compiled header. Presumably that's ok - there's no declartions or expressions in the main file at that point, or the restore would have failed. Any declarations that are or in the will presumably be the same either way. * Presumably we need custom code to save and restore the line-map. Zack experimented with having the entire line_table we gc-allocated, and thus making using of the GTY machinery. This addes an extra indirection for each access to the line_table (probably not a big deal - cpplib accesses are via the cpp_reader and thus unchanged). But note we still need custom restore code. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: PCH versus --enable-mapped-location
Geoff Keating wrote: >> * Any source_location values handed out before the #include that restores the gch will become invalid. They will be re-mapped to that in the pre-compiled header. Presumably that's ok - there's no declartions or expressions in the main file at that point, or the restore would have failed. Any declarations that are or in the will presumably be the same either way. Another way of putting this is that source_location values should be in GCed memory. I think they all are, certainly all declarations and macro definitions are. I think you're misunderstanding my concern. The issue is when we're processing a .c file normally we generate source_location cookies for , , and any tokens until we process the #include that restores the pch. At that point we (need to) restore the line number saved in the pch. Any source_location cookies that we've handed out up until then become invalid, because they refer to a line_table that has been replaced. My point is that presumably it doesn't matter, since the source_location cookies and declarations corresponing to and should match, when compared with those at pch-generation time. The ones that don't match are any source_location cookies for tokens in the main file itself. However, they should just be tokens for white space, comments, and the initial #include that triggers the pch-restoration, and there should be nothing except garbage that use those now-invalid source_locations. Custom restore code is problematic because it means doing something at PCH restore time, and so it's always speed-critical. Changing two pointers is not too expensive (especially if you can arrange for those pointers to be on the same page), but copying a data structure (especially a large one) is not a good idea. Then there's something I'm not getting. The data in the line number has to be saved in the gch file, read in, and "patched". This is true whether the data is part of the garbage collected heap, and so gets automatically reatored, or whether it uses special code, like the dependencies. I can see if yoyu're memory-mapping you want to do as much reading implicitly using mapping, rather than explicit reading. Is that it? The line_map entries contain a filename pointer plus various other non-pointer fields. It might be reasonable to split those into two separate arrays: an array of (const char*) and an array of non-relocatable data. I don't know if that would be helpful. It would means fixing client code that references map entries directly. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: PCH versus --enable-mapped-location
Daniel Jacobowitz wrote: > That's exactly what Geoff said. There are two relevant properties of GCed memory here: - Anything in GCed memory will be saved to the PCH - Anything in GCed memory will be overwritten by loading the PCH. So the corrollary: After a restore any pointers from non-gc'd memory to gc'd memory will be a dangling pointer, if we count static variables marked with GTY as "gc'd memory" in this context. Right now, as far as I can tell, the filenames in the line_table are allocated from non-gc'd memory. This complicates using gc. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
I can no longer build Kawa using the 4.0 branch. This is with a 'cvs update' late last night. Kawa did built last time I tried the 4.0 branch. Unfortunately, I don't know how long ago that was, but it wasn't *that* long ago. The cause appears to failure to find a class in the CLASSPATH. That suggests it might be related to Tom's check-in. I'll track it down a little bit further. This is on Fedora Core 3, x86. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Per Bothner wrote:
I can no longer build Kawa using the 4.0 branch.
Some more information:
The failing statement is:
Class.forName("kawa.lib.prim_syntax", false,
getClass().getClassLoader());
prim_syntax.class exists in the current directory,
which is ../../kawa/lib. The program is run with
CLASSPATH=../..
Printing getClass().getClassLoader() yields:
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Note the urls=[file:./]. Looks like it's ignoring the CLASSPATH
environment option.
It works after I do:
mkdir kawa kawa/lib && cp prim_syntax.class kawa/lib
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Mark Wielaard wrote:
I tried to replicate this issue with some simple example,
...
$ gcj -C CL.java
$ CLASSPATH=.:/:/usr:/random gij CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:/,file:/usr/],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
(Of course to be picky "file:/usr/" is not a valid URL ...)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC2
Mark Mitchell wrote:
Sadly, it's become clear there's going to have to be a second release
candidate. In particular, there are some wrong-code bugs that are
popping up on real packages on primary platforms.
I think there is a case for considering the bug discussed in this thread
release-critical:
http://gcc.gnu.org/ml/gcc/2005-04/msg00534.html
Summery: Native-compiled Java code ignores CLASSPATH
This is a recent regression, which prevents building Kawa.
Now there are Kawa work-arounds, but I believe there have been
reports of others seeing what might be the same problem.
Mark Wielard said he's looking into the problem. Unfortunately,
we haven't heard anything from Tom Tromey, the auther of the big
patch that probably causes the problem.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Mark Wielaard wrote:
Hi Per,
On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
I am looking for a real solution.
Does the following work for you?
2005-04-02 Mark Wielaard <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.
Yes, Kawa builds with this patch. Thanks!
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Per Bothner wrote:
2005-04-02 Mark Wielaard <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.
Yes, Kawa builds with this patch. Thanks!
However, the Kawa testsuite fails, raising a ClassNotFoundException.
I'm looking into it.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.0 RC1 Available
Per Bothner wrote: However, the Kawa testsuite fails, raising a ClassNotFoundException. I'm looking into it. Hm. This fails, with or without the patch: clas = Class.forName(cname); This works: clas = Class.forName(cname, true, getClass().getClassLoader()); This is with make all && make install in the libjav directory. I'm doing a 'cvs update' and rebuild from a clean tree in case the problem is an artifact of the way I just rebuilt part of the tree. BTW, I've always though we should have the compiler rewrite: Class.forName(NAME) to: Class.forName(NAME, true, getClass().getClassLoader()) to avoid the fragility and ugliness and performance lossage of doing the stack trace ... -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: line-map question
Devang Patel wrote: From line_map comment at (libcpp/include/line-map.h) /* Physical source file TO_FILE at line TO_LINE at column 0 is represented by the logical START_LOCATION. TO_LINE+L at column C is represented by START_LOCATION+(L*(1< What happens when column number is >= 128 ? The exact same rule applies. There is nothing magic about 128, except it's an initial value that hopefully covers > 90% of the case. If it doesn't, the code will increase column_bits, either by allocating a new line_map, or (in a few cases) tweaking the existing one. The latter is what is happening in PR 20907. > This is PR 20907. I have a patch I'll check in after testing. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Java field offsets [was; GCC 4.0 RC2 Available]
Andrew Haley wrote: However, these fields are real, and they are used, but we shouldn't output any debug info for them. Does Dwarf support "computed field offsets"? (This might be needed for Ada, to.) If so, the Right Thing might be to emit DIEs so gdb can calculate the field offsets, mimicing the normal "indirect dispatch". Not to say this is worth doing, even if possible. It would probably be a lot of work to have gdb understand computed offsets, and unless it is needed for something else, it's not worth it for Java. That is because we want a solution that also works for dynamically loaded interpreted classes, and the solution is to get the offsets from the run-time data structures, rather than the debug information. There is some partially-bit-rotted code in gdb to extract type information from run-time Class information, but it was fragile because it didn't fit well with gdb's obstack-based memory management. The situation might be different now. OTOH, just like we now use Dwarf2 unwind-info for exception handling, perhaps we could use Dwarf debug information for reflection information. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.1: Buildable on GHz machines only?
Mark Mitchell wrote: Building libjava takes forever on any platform, relative to the rest of the compiler build. In addition to fixing/replacing libtool (could it be rewritten as a C program?) there are a number of other known gcj performance problems. When compiling A.java, gcj needs to read a lot of other classes that A depends on. It seems to be reason a lot more classes than it needs to: it is a lot less agressive about loading a class than it should be. On the other hand, much time spend improving gcj performance might be wasteful it it will be replaced by Tom's new gcjx. One way to speed up libcgj compilation by quite a bit would be to compile more than one .java file at a time. For example: gcj -c java/util/*.java -o java-util.o This reduces libtool overhead, reduces the duplication in reading dependencies, and probably reduces link overheads. It can also produce better code, since intermodule references get trurned into intramodule references. This just requires Makefile-hacking. Disadvantages: - Static linking (which we don't really support very well anyway) might causes some classes to be needlessly linked in. - Compiling multiple classes at once might increase virtual memory use. I think the net benefit could be large - an experiment would be quite worthwhile. Perhaps somebody could write a post-configure script to munge the Makefile and give us some numbers. Ideally, there'd be a configure flag to control "chunking". -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.1: Buildable on GHz machines only?
Tom Tromey wrote: --enable-libgcj-multifile controls how .class files are built; ... But what Per is talking about is how .o files are built. Both, actually. We could save some time by building .class and .o files at the same time, though that requires jc1 changes. We could also save time by making --disable-static the default. Building static libraries is not very useful on other than embedded-class systems. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GCC 4.1: Buildable on GHz machines only?
Paolo Bonzini wrote: >> But what Per is talking about is how .o files
are built. This change
would probably not be very difficult fwiw; we already have done this
in a place or two where we've needed BC ABI support.
As long as libtool supports it, it should not be very difficult indeed.
It semi-supports it. I build Kawa one directory at a time, using
libtool. (Albeit the CVS version of libtool.)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
preprocessor/21250 and address of
Opinions on how to handle this bug? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250 This came up because we give declarations line 0, but used line 1 in a different date structure. I fixed the code to consistently use line 0, which is needed for the --enable-mapped-location unification. However, we end up with preprocessor output like this: # 1 "any-file" # 0 "" # 1 "" # 1 "any-file" Some assemblers complain about line number 0. This is especially an issue for people who use cpp to preprocessor assembler, which of course we don't really support. My suggested solution: suppress the output of , so we get: # 1 "any-file" # 1 "" # 1 "any-file" There should never be anything following , so it's useless as well as confusing. Also, if we compile multiple files at once (or use a compile server), then logically the declaration *precede* all the actual code, which suggests that if is output it should be the *first* line. But that would break too much code. Simplest and cleanest solution: Just get rid of the line in pre-processor output. This might break some tools that look at cpp output, but it seems unlikely. I'll check that -fpreprocessed doesn't break (I assume the testsuite tests this?), and I'll ask someone to check distcc. Objections to this approach? Other suggestions? One alternative is to fix gas to not complain about line number 0. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: preprocessor/21250 and address of
Zack Weinberg wrote:
Stuff does appear between and with -g3, -dD,
and possibly some of the other -d switches. That is why they're
there. I would have no objection to suppressing it (and
too) when none of those options is in use.
In that case it's probably easiest to just hack c-ppoutput.c so line 0
is printed as line 1.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Question about new warning system
Giovanni Bajo wrote: Actually, the point is that you *never* need to explicitally name the "warn_" variable unless you are optimizing. In other words, code which presently is: if (warn_foo && frobbed) warning (0, "foo is frobbed"); should be replaced with: if (frobbed) warning (OPT_Wfoo, "foo is frobbed"); Perhaps a macro should be defined: maybe_warning (OPT_Wfoo, frobbed, "foo is frobbed"); This tests whether Wfoo is enabled *before* it evaluates frobbed. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Status of --enable-mapped-location
Andrew Pinski wrote: Does anyone know of the status of --enable-mapped-location? I tried to do a bootstrap and test and I got a lot of failures due to getting the wrong line number and file for the error message when dealing with macros. I haven't had time to work on gcc for a while, but I'm hoping Ben Ellison (with my advice) will be able to take a look. The biggest group of remaining trouble spots *used* to be when testing pch, since we don't properly save/resore the line number table. I haven't even done a --enable-mapped-location build in quite a while, so I haven't no idea what regressions there might be. I'll at least do a bootstap+check run to get a feel for the status. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Status of --enable-mapped-location
Andrew Pinski wrote:
> Does anyone know of the status of --enable-mapped-location? I tried to
> do a bootstrap and test and I got a lot of failures due to getting the
> wrong line number and file for the error message when dealing with
macros.
I took a look. The status doesn't seem to have changed much
- for good or ill.
There is a new set of failures from builtin-stringop-chk-1.c,
which is a new testcase. These are the kind you mention.
I believe the issue is that --enable-mapped-location gives
us more precise error locations based on an individual token
rather than at the statement level. If the token associated
with the error comes from a macro expansion text, then we
will see the location in the macro definition.
I don't think the implemented behavor is *wrong*, but it
probably isn't the most *useful*.
Ideally it would be nice to show the "macro nesting" just
like we do for "include nesting". I.e. add "In macro expanded at"
lines. That shouldn't be very difficult with the line-map
framework, though it would require more line_map entries in
the line_table. For that reason, and perhaps because it might be
"too much information" perhaps it shouldn't be the default.
The default should probably be that positions from macro expansion
text should be replaced by the position of the macro call. I don't
know how easily that is available, or if we need a new data structure.
Of course tokens that come from the application site (i.e. macro
parameters) should get the location of the application site, as I
believe the code currently does. Finally, we have to handle macros
that call macros.
Other errors are pch-related, due to the pch machinery not saving and
restoring the line-table, as discussed in this thread:
http://gcc.gnu.org/ml/gcc/2005-03/msg01318.html
I get a bunch of failures in the libstdc++ tests, for example:
FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 209)
The problem is the line number of the "candidates" is garbage.
This is nasty because it appears to be optimization-related: I tried
recompiling without optimization and the problem went away.
Trying to debug an optimized cc1plus I found that diagnostic.location
is trashed when print_z_candidates calls gettext here:
2444 str = _("candidates are:");
Perhaps there is an aliasing bug somewhere?
I really would welcome someone else looking at one or more
of these, as I'm really behind on other (paying) projects.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Tom Tromey as Java maintainer
The steering committee has agreed (as has Andrew Haley and Tom) that Tom
Tromey should be added as a Java maintainer, in addition to libgcj
maintainer. (About time, considering how much Java work Tom has done,
including more and more compiler work.)
Thanks for all the work you've done over the years!
Tom, please add yourself to the MAINTAINERS file.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: backslash whitespace newline
For what it's worth, my opinion: A program whose semantics depends on invisible end-of-line whitespace is erroneous and a disaster waiting to happen. The portability argument wrt other compilers is all very well, but the code fails to be portable in so many other ways, as people have mentioned: cut-and-paste; web archives; reading printed-out code; not to mention virtual 80-column punch cards on VM/CMS ... I'd like to keep the current behavior, but add a warning, which should default to on. I'll go along with a compromise: change the behavior to match the "other compilers", as along as a warning is emitted. The warning can be turned off with our generic turn-off-specific-warnings framework (I'm so out of gcc development I'm not sure we have one - but I vaguely remember reading about it). However, the warning should be on by default. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: resolving backslash newline whisky tango foxtrot: a proposal
Rather than adding new flags, I'd think I'd prefer: 1. Change the behavior (back) so only '\\$', not '\\ *$', causes a line to be continued. 2. Make -Wcomment more useful to it only warns when it might matter: The following line contains non-comment whitespace. 3. Make -Wcomment the default - not just for -Wall, but always. It can be turned off with -Wno-comment -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: resolving backslash newline whisky tango foxtrot: a proposal
Joe Buck wrote: On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote: 1. Change the behavior (back) so only '\\$', not '\\ *$', causes a line to be continued. The problem with your item #1 is that there is then no way of flagging code that won't work with the large numbers of production compilers based on gcc 3.x, as well as code that will break if anyone ever removes trailing whitespace (something that can easily happen in the process of editing the code). My hope was that an improved on-by-default -Wcomment would catch that. I.e. it would warn about any code that act be differently depending on whether trailing whitspace is removed. Any code and only code that starts getting the warning is at risk. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: resolving backslash newline whisky tango foxtrot: a proposal
Joe Buck wrote: So you want the compiler to only consider '\\$" a continuation, Not my preference, but that is my proposal, in the interest of compatibility. but to have an unsilenceable warning about '\\ *$'? Not unsilenceable - but on-by-default. It could be silenced with an explicit -Wno-comment. (Or whatever mechanism we use to control warnings.) The point is that since it's silly and dangerous to depend on trailing whitespace, and it's normally a mistake, we should warn about it even without -Wall, but if people really want to live dangerously they can turn it off. That would appear not to solve the problem of the customers who are wedded to their line art, that started this discussion in the first place. They can use -Wno-comment. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: resolving backslash newline whisky tango foxtrot: a proposal
Dave Korn wrote:
Per, please. We've been through these ***exact*** interchanges before.
You're now just reiterating the entire thread. You aren't adding anything
new,
I didn't see my specific proposal ('\\' follow by space is not a line
continuation *and* an improved -Wcomment defaults to on when no options
are given) in the previous discussion, though of course the issues and
possibilities were covered in excessive depth.
just informing everyone which of the already-discussed possibilities your
own personal opinion happens to be. And you aren't even offering a patch.
You're missing an important point: I'm currently the only person listed
as cpplib maintainer. I very much favored Zack's change to allow
trailing whitespace after a continuation character, and have just said
I'm willing to change this *if* we make -Wcomment the default. So even
though I have very little time to spend on gcc, my "personal opinion"
matters. If my proposal is acceptable to Apple (and I haven't heard
them chime in about it), then we may have a solution that could be
acceptable to everybody, without Apple having to create (another) fork
in their code-base. It means that Apple can produce a patch with
reasonable assurance that it will be approved (assuming we also get
consensus from the global write maintainers on the -Wcomment changes.)
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Patch reviews for 4.1
Mark Mitchell wrote: This rather horrid URL: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=patch&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= will get you the list of 4.1 PRs with the "patch" keyword set. Fixing these PRs may just require than an appropriate person review the patches. Per, there's one preprocessor patch below; would you please take a look? The rest are middle-end patches. Preprocessor 22042 I don't know enough about fine points of the standard to say what is right. If you and Andrew think it is right, I'm ok with it. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
A "function-never-returns-null" attribute doesn't seem like
the right mechanism. Instead, there should be a "never-null"
attribute on pointer types. A "function-never-returns-null" is
just a function whose return-type has the "never-null" attribute.
A type attribute is much more useful. For example it allows:
String x = shared ? "x" : new String("x");
// The type of x [in a single-assignment-world] is non-null.
[If we already have such a mechanism, I apologize.]
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Diego Novillo wrote: On Saturday 12 November 2005 12:05, Per Bothner wrote: A "function-never-returns-null" attribute doesn't seem like the right mechanism. Instead, there should be a "never-null" attribute on pointer types. A "function-never-returns-null" is just a function whose return-type has the "never-null" attribute. I disagree. We would have to prove that every possible instance of this type is non-NULL. I think you're missing the point. The proposal is for a "type variant" - not that different from say "constant". "non-null java.lang.String" is a different POINTER_TYPE object than "[possibly-null] java.lang.String". If you dereference an expression whose type is "non-null java.lang.String" then you know you don't need an null pointer check. If you derefernce an expression of type "[possibly-null] java.lang.String" then you do need the null pointer check. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Per Bothner wrote: A "function-never-returns-null" attribute doesn't seem like the right mechanism. Instead, there should be a "never-null" attribute on pointer types. A "function-never-returns-null" is just a function whose return-type has the "never-null" attribute. Gabriel Does Reis wrote: We already have such mechanism: a reference type -- which morally is implemented as a pointer type. Andrew Pinski wrote: That was mentioned a way ago as being wrong. A reference type can be NULL. There are other differences, at least in C++: If you assign to a pointer, you change the pointer, while if you assign to a reference you modify the referenced object. I.e. if a variable has reference type, then the reference itself is constant. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Diego Novillo wrote:
> int *this_never_returns_NULL (void) __attribute__
((never_returns_null));
>
> We would not want to pin the never-null attribute to 'int *':
Well, of course. That's why we're talking about a type *variant*.
To emphasise: this is a type variant *in the gcc internals* - i.e.
using a distinct POINTER_TYPE node. To what extent this is reflected
at the source level is up to front-ends.
Thus:
int *this_never_returns_NULL(void) __attribute__((never_returns_null));
could be viewed as syntactic sugar for:
(int __attribute__((never_null)) *) this_never_returns_NULL(void);
[Note I'm unsure about __attribute__ and declaration syntax, so it
is possible this wouldn't work. But that's a syntax issue, so it ignore
it in the following.]
>
> foo()
> {
>int *p = this_never_returns_NULL ();
>< ... use p without modifying it ... > <-- p is never NULL here.
>p = other_fn ();
>< ... use p without modifying it ... ><-- p may be NULL here.
> }
We could allow, if desired:
foo()
{
int __attribute__((never_null)) *p = this_never_returns_NULL ();
< ... use p without modifying it ... > <-- p is never NULL here.
p = other_fn (); /* error - caught by the compiler */
}
Consider:
foo()
{
int *p;
if (test)
{
p = this_never_returns_NULL ();
< ... use p without modifying it ... > <-- p never NULL here.
}
else
{
p = other_fn ();
< ... use p without modifying it ... > <-- p may be NULL here.
}
... more uses of p ...;
}
The internal SSA form might be something like:
foo()
{
if (test)
{
int __attribute__((never_null)) *p_1 = this_never_returns_NULL();
< ... use p without modifying it ... > <-- p_1 never NULL here.
}
else
{
int *p_2 = other_fn ();
< ... use p without modifying it ... > <-- p_2 may be NULL here.
}
int *p_3 = PHI(p_1, p_2);
... more uses of p ...;
}
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Diego Novillo wrote: From a user's perspective I see the obvious drawback that you've just forced me to edit a potentially large number of source files just to add the __attribute__((never_null)). I'm clearly not explaining myself ... Of course I'm not proposing that. My point was that my proposal *allows* explicit setting of the __attribute__((never_null)). But more likely it's the *compiler* (optimizer) that sets the attribute. The other approach just needs a single __attribute__ in the function declaration. You missed this > int *this_never_returns_NULL(void) __attribute__((never_returns_null)); > could be viewed as syntactic sugar for: > (int __attribute__((never_null)) *) this_never_returns_NULL(void); I.e. just a single attribute in the function declaration. The phrase "syntactic sugar" means that people can write the former, and it's equivalent to the latter. Another problem I would have as a user is if you suddenly make 'int *' and 'int * __attribute__((non_null))' different/incompatible types. If I have a function that takes 'int *' as argument, I don't want to start adding tons of type casts to get around compiler warnings/errors. Bad example. The 'int *' type is more general than 'int*__attribute__((non_null))', so assigning an expression that has type 'int*__attribute__((non_null))' to a variable or parameter that has type 'int*' is always safe, and shouldn't warn. As to the other way round, that is a user interface issue, orthognal to the semantic issue. But if a variable is explicitly declared 'int * __attribute__((non_null))' and you pass it an 'int *' expression then a warning is probably in order, since you're doing something dangerous. One more point: If someone writes: int *x = this_never_returns_NULL(); Then the type of x is 'int *' and that of this_never_returns_NULL() is 'int __attribute__((never_null)) *'. This is fine and safe. However, ideally the compiler should realize that x actually has the more specific type 'int __attribute__((never_null)) *', and should use that information to generate better code. It seems this should be straightforward using SSA, as I sketched in my previous message. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Null pointer check elimination
Tom Tromey wrote:
"Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A type attribute is much more useful. For example it allows:
Per> String x = shared ? "x" : new String("x");
Per> // The type of x [in a single-assignment-world] is non-null.
I think we will need extra code to recognize that String references
via the constant pool will never be null.
Since we make direct references to the constant pool (i.e., we don't
emit a function call), a purely function-call-based approach to
handling non-nullity won't be sufficient.
Right - the "type-variant" approach handles that smoothly.
I.e. in Java a string literal would have type
"never-null pointer to java.lang.String".
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Reconsidering gcjx
Technical approach. Historically we've wanted to have a 'native' java-source-code-reading compiler, that is, one which parses java sources and converts them directly to trees. From what I can remember this was based on 3 things: A couple of other factors: * Compile time. It is at least potentially faster to compile directly to trees. However, this is negated in many cases since you want to generate both bytecoe and native code. (This include libgcj.) So generating bytecode first and then generating native code from the bytecode is actually faster. * Debugging. Historically Java degugging information is pretty limited. Even with the latest specifications there is (for example) no support for column numbers. However, the classfile format is extensible, and so if needed we can define extra "attribute" sections. * The .classfile format is quite inefficient. For example there is no sharing of "symbols" between classes, so there is a lot of duplication. However, this is a problem we share with everybody else, and it could be solved at the bytecode level, co-operating with other parties, iseally as a Java Specification Request. An alternative approach would be to directly link ecj to the gcc back end. However, this looks like significantly more work, requiring much more hacking on the internals of the upstream compiler. I suspect that this won't be worth the effort. I think you're right. It could be a project for somebody to tackle later. ecj is written in java. This will complicate the bootstrap process. However, the situation will not be quite as severe as the Ada situation, in that it ought to be possible to bootstrap gcj using any java runtime, including mini ones such as JamVM -- at least, assuming that the suggested implementation route is taken. I don't a "mini java runtime" would be useful. We could offer two bootstrap solution: (1) An existing (installed) Java run-time, which would be an older version of gcj. (2) A bytecode versions of ecj. This is only useful if we also make available a bytecode version of libgcj, I think. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Reconsidering gcjx
Andrew Haley wrote:
I think that from a maintenance point of view this would be a PITA.
Also, as Per mentioned we'd need to extend the .class file format in a
non-standard way to get full debugging information. In particular,
.class files don't contain the full pathnames to source files.
The "SourceDebugExtension" attribute specified by JSR-45
(http://jcp.org/en/jsr/detail?id=45) provides one way to
provide full pathnames.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Reconsidering gcjx
Another concern: I gather there are lots of dependencies
between Eclipse libraries. Does ecj depend on any other
Eclipse libraries? Even if there are no run-time dependencies,
it's awkward if a class statically references some random
Eclipse class that somehow pulls in large parts of Eclipse.
I.e. I'm hoping one can *statically* link ecj without any
dependencies on (say) the SWT toolkit, or the debugger?
This is not an absolute requirement, and if there are just
a couple of troublesome dependencies, it is normally possible
(if ugly) to turn a static dependency into a run-time check,
using reflection.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: Reconsidering gcjx
Tom Tromey wrote:
While investigating I realized that we would also lose a small
optimization related to String "+" operations. When translating from
.java we currently use a non-synchronizing variant of StringBuffer to
do this.
In Java-5-mode I would expect ecj to use the unsynchronized
java.lang.StringBuilder. If not, I'd consider it a bug.
A desirable optimization would be to convert local (non-escaping)
uses of StringBuffer/StringBuilder to be stack allocated. You
could even stack-allocate the actual buffer up to a limited size,
only heap-allocating when it gets over that size.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
I'll take a look at the bootstrap failure if no-one beats me to it. (I'm out in the country-side, and though I have good net access it's a little easier to wait until I'm home Sunday evening.) Is there a volunteer to implement save/restore the line table for PCH? Ben Elliston and I talked about it, but I don't know if he's available. Worst case, I guess I could steal the time to do it, but if nothing else it would be good to get more people comfortable with how this all works. And of course Ada needs MAPPED_LOCATION support. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
Robert Dewar wrote: Right, so it seems quite appropriate to have two representations for source locations, one for the Ada tree, which is completely independent of the tree IL, and one for the back end. That probably means that back end messages will lose the generic instantiation information, but that's not terrible. First, the mapped source_location values can encode nested context. This is used for the C/C++ include file context. I think it is quite possible to use the same mechanism for generic instantiation information. Second, the backend *currently* has no support for "generic instantiation information" so I really don't understand your point about "losing" this information. You *might* lose it if you switch to using source_location in the front-end (but see my first point), as I've argued for in the past, but if you're translating internal source location to back-end representation at tree conversion time, which seems to be your preference, then I don't understand your point. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
Steven Bosscher wrote:
So now we have a half-completed conversion to USE_MAPPED_LOCATION which is
currently broken (doesn't bootstrap for me with --enable-mapped-locations).
Oops. Looks like I made and posted a patch, but never checked it in:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00882.html
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
Robert Dewar wrote:
Can someone point me to a clear high level spec for the proposed
interface for MAPPED_LOCATION support.
I don't know of any high-level spec, except libcpp/include/line-map.h.
A "line_map" (singular) specifies how a sub-range of source_location
integer cookies are to be interpreted. The "line_maps" table (there
is normally only one) is a collection of line_map mappings, in order
of the lowest source_location value mapped by each line_map, so finding
the correct line_map is a matter of binary search. (And of course
normally there is quite a bit of locality, especially when initially
parsing.)
Each line_map has a filename ('to_file') and starting line ('to_line'),
and then it's a simple calculation to map a source_location to a line
and column number.
Each line_map also has an "included_from" field which is normally the
index of the line_map of that included this line_map: i.e. the outer
line_map in the include stack. It seems plausible to generalize the
"included_from" field to also be used for "expanded from" or
"instantiated from", but I haven't tried to think through that.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: GCC SC request about ecj
Richard stallman write last night: I agree to the use of the Eclipse front end to generate Java byte codes. Note this does not mean importing Eclispe code into the gcc source or release tree. We need to decide on a practical way to have people grab a compatible version of ecj. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
MAPPED_LOCATION update
I checked in a couple of patches, so now most front-ends work
more-or-less (i.e with some but not a large number of regressions).
The Java front-end compiles but fails to run, so bootstrapping fails if
java is enabled. I haven't looked into it. This is a regression -
it used to work. If the problem is specific to compiling from source,
that may reduce its importance, if it's in code that will be replaced
by ecj.
I have two tentative volunteers to help finish MAPPED_LOCATION.
Steven Bosscher hopes to find time to work on save/restore of the
line-map table. Ben Elliston will take a look at the other
(non-pch-related) regressions. We all have too many things on our
plates, so if someone else would like to pitch in, just let us know.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: A question about ARG_FINAL_P in the Java frontend.
I just noticed that the Java frontend has ARG_FINAL_P, which uses a
bit in the TREE_LIST node that is pointed to from TYPE_ARG_TYPES.
It's only used in the Java source front-end, which is going away.
We could figure out an alternative, but I'm not sure it's worthwhile.
As a stop-gap, you could probably just remove setting and testing
the flag. That may introduce some regressions in terms of not
catching some errors.
A cleaner fix may be to create the PARAM_DECL at parse time, and set
the final flag on the decl, but that's a bigger change not worth
doing at this point.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: SVN Test Repo updated
Daniel Berlin wrote: Complete alphabetical order is not in the cards for diff, at least for diffs involving server side (diffs that are client side are easily sorted by filename). This is because it would require losing the "streaminess" of the protocol (unlike cvs, the client and the server in svn are really seperate, and the client just gets a stream of results. Sorting would require at least holding all the directory entries in the server at once, before sending them to the client, if not worse), Huh? I don't get this. You sort filenames *in* the server *before* you generate diffs. And you do the sorting within each directory; i.e. early before you do anything else. What does the "streaming protocol" have to do with this? Dogenerate teh stream in order, that's all? How to do this depends on the internal data structures of the repository, and I realize that the possibility of renames does complicate those data structures. But there has to be a data structure and api to navigate the file hierarchy - a "tree walker". That tree walker should sort by filename before doing anything with the contents of a directory. Yes, the sorting does cost some time, but sorting a directory is pretty fast. You can do much better than quicksort: Put each filename in one of 27 buckets, one for each of A/a to Z/z, and one for "other", and the as well as their being locale issues We're talking about filenames for source code. At least for gcc, it's fine to hardcode a case-folding "code point" sort order. Preferably, the sort algorithm should match 'ls'. (Specifically GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong. It's especially ridiculous on a case-folding Mac, but I couldn't convince the BSD peopel of that.) (the server would have to know the client's locale to sort the files so they appeared in the alphabetical order you expect). No problem. The client's request can include the current LOCALE value. However, I'm not sure that's derirable. Obviously the charset and language used for filenames cannot be client-dependent. The sort order could be client-dependent, but since it might not match the server language, I don't think it makes sense. If I'm a German speaker working with repository containing English filenames, the sort order should be English, regardless of my LOCALE. In other words, so far the cost of trying to do it has outweighed the benefit of having diffs appear in some well-specified order. Having output in a well-specified order is very important. How else would I be able to compare two 'diff' runs otherwise? How would I write a regression test for 'svn diff'? Of course I can postprocess the output, but it's much more convenient and efficient to just sort each directory before diffing each file. More generally, any listing that humans are expected to see should be sorted. If you put it in random order people will wonder if there is a meaning to the order. An 'ls' that doesn't by default sort the output is obviously Wrong. Now I'm not suggesting this is a show-stopper issue, or that you should be responsible for fixing it. But clearly, if svn output is not by default in a predictable output, that is most definitely a serious (but not critical) bug. (It's ok to have a "don't sort" option to speed things up, but it shouldn't be the default.) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: SVN Test Repo updated
Andreas Schwab wrote: Per Bothner <[EMAIL PROTECTED]> writes: Preferably, the sort algorithm should match 'ls'. (Specifically GNU ls - IIRC BSD ls doesn't case-fold, which I think is wrong. The sort alghorithm has nothing to do with ls, but with your selection of LC_COLLATE. If we're going to nit-pick. I guess I should have written "sort order" rather than "sort algorithm". Output from svn commands should be sorted by filename, using the same sort order as 'ls'. The collation to use (at least the default collation) should be a repository property, not the client's collation, though this is not very important. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: SVN Test Repo updated
Daniel Berlin wrote: You assume the tree walker ever sees an entire directory at once, for starters. It seems a reasonable assumption that such a tree walker exists or could be written without too much pain. I can imagine a tree walker that iterates over file numbers (a la inodes), and that may be most efficient for some operations. But it's clearly wrong for producing log/summary/diff output for humans. Patches welcome :) Duh. I'm not going to start patching svn. I'm reporting a bug. I'm not saying anything about the priority of the bug. I think it should be reported as a formal bug, but I'm not going to do that myself until I personally witness the buggy behavior, and I don't have time to try out svn quite yet. I haven't looked in detail, but i don't believe it's near as simple as you think, because the structure of how a diff happens isn't what you think it is. I'm quite willing to believe some redesign may be needed to fix the bug. I believe someone is going to try to just store/walk the dirent hash in a sorted order for now when possible, so that everything above the fs level just gets handed this stuff in sorted order. I think that is what I'm proposing. Protocol changes are no simple matter. We can't just arbitrarily break the client/server protocol. There needs to be a graceful fallback for older clients against newer servers, and the reverse, at least until 2.0. Hopefully the protocol is somewhat extensible? In any case, using the client's LC_COLLATE may not be the right thing, and it's certainly not important. (I believe someone is working on it to some degree, soon) Great. As I said: I don't see this issue as a show-stopper for converting gcc to svn. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Resigning from GCC Steering Commitee
I'm sorry to announce that I'm resigning from the GCC Steering Committee. I have been embarrassingly inactive in both GCC development and on the committee the last few years. There doesn't seem to be any likelihood that this will change in the foreseeable future, even less so now that I have a "day job" working for Sun. The Steering Committee and the Gcc community deserve someone more informed and involved with what is going on in the GCC world; The SC have been discussing possible "new blood" to take my place. I have been a member of the Steering Committee since its start almost 10 ago as the egcs project, and I've been involved with GNU and GNU tools quite a bit longer than that. It has been a pleasure working with such a community of dedicated, smart, and (most of the time) reasonable and friendly people! I am still "around", working on GNU and other Free Software (the Kawa project is still going strong, and my job at Sun is also Free Software). If you any questions about code I've written - or just want to say "hi!" - feel free to contact me. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
