> "Jason" == Jason Merrill writes:
Jason> Thanks, though I don't think all that code needs to go;
Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
Jason> relies on features from a particular standard. We just don't want
Jason> AC_PROG_CXX to invoke it.
I didn't re
> Do you (or others) have any thoughts about GitLab FOSS?
Dunno about the FOSS edition specifically, but I've used many review
tools in anger in the last 5 years: github, gitlab, gerrit, phabricator,
and a couple that ran in bugzilla ("MozReview", not sure if it had some
other name; and a second o
Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997
Mark> We really should automate this. There are several people running
Mark> scripts by hand. The easiest would be to simply run it from a git
Mark> hook. patchwork comes with a simple script that just calculates the
Mark> hash a
> Indeed. Though Patchwork is another option for patch tracking, that
> glibc seem to be having success with.
We tried this in gdb as well. It was completely unworkable -- you have
to manually clear out the patch queue, meaning it's normally full of
patches that already landed. I know glibc has
Jason> Someone mentioned earlier that gerrit was previously tried
Jason> unsuccessfully.
We tried it and gdb and then abandoned it. We tried to integrate it
into the traditional gdb development style, having it send email to
gdb-patches. I found these somewhat hard to read and in the end we
agre
> "Frank" == Frank Ch Eigler writes:
>> [...] I suggest that a basic principle for such a system is that it
>> should be *easy* to obtain and maintain a local copy of the history
>> of all pull requests. That includes all versions of a pull request,
>> if it gets rebased, and all versions o
> "Florian" == Florian Weimer writes:
Florian> Everyone still pushes their own patches, and there are no
Florian> technical countermeasures in place to ensure that the pushed version is
Florian> the reviewed version.
This is a problem for gdb as well.
Probably we should switch to some kind
> not sure if the current autoregen.py is in sync with that?
I'm curious why "autoreconf -f" is insufficient.
It seems to me that this should work.
> Also... I discovered the existence of an automake rule:
> am--refresh which IIUC is intended to automake the update of Makefile
> and its dependenc
> "Eric" == Eric Gallager writes:
Eric> Also there are the files generated by cgen, too, which no one seems to
Eric> know how to regenerate, either.
I thought I sent out some info on this a while ago.
Anyway what I do is make a symlink to the cgen source tree in the
binutils-gdb source tree
> "David" == David Malcolm via Gcc writes:
David> For example, there's at
David> least one place where I'd have used std::optional, but that's C++14 and
David> so unavailable.
FWIW, gdb had its own gdb::optional (which was really just a
stripped-down copy of the one from libstdc++) to fill e
> "Jason" == Jason Merrill via Gcc writes:
Jason> I think we probably want the same formatting for lambdas in function
Jason> argument lists, e.g.
Jason> algorithm ([] (parms)
Jason> {
Jason> return foo;
Jason> });
Jason> Any other opinions?
FWIW gdb did pretty much this same thing
> "Ben" == Ben Boeckel via Gcc-patches writes:
Ben> - `-fdeps-file=` specifies the path to the file to write the format to.
I don't know how this output is intended to be used, but one mistake
made with the other dependency-tracking options was that the output file
isn't created atomically.
> "Ulrich" == Ulrich Weigand via Gcc writes:
Ulrich> If we do want to byte-swap pointer types, then I guess we need
Ulrich> to still fix the debug info problem, which I guess would at a
Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an
Ulrich> attribute to DW_TAG_pointer_
> "Rob" == Rob Savoye writes:
Rob> Not that team, the folks I talked to thought I was crazy for wanting
Rob> to refactor it. :-)
I don't think refactoring dejagnu is crazy, but I think it's pretty hard
to imagine rewriting the gdb test suite in Python. It's 260 KLOC.
Tom
> "Segher" == Segher Boessenkool writes:
Segher> My point was that this should *never* be part of patches, already.
FWIW, I use a few scripts so that I can keep ChangeLogs as files.
That's what I do when working on gdb.
https://github.com/tromey/git-gnu-changelog
This is easier on the whol
> "Jonathan" == Jonathan Wakely via Gcc writes:
[gerrit]
Jonathan> I think it also only very recently gained the ability to group a
Jonathan> series of patches together, as it wants a single commit per review.
We tried gerrit for gdb for a while, and in the end decided to drop it.
The main
> "Jason" == Jason Merrill writes:
Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git
Jason> send-email command. I don't remember where I found that incantation.
Cool, I did not know about this.
FWIW if you have the ChangeLog merger available, it's actually more
conve
> "Jonathan" == Jonathan Wakely writes:
Jonathan> I have a script that does the opposite, which I've been using for
Jonathan> years. I edit the ChangeLog files as before, and a Git
Jonathan> prepare-commit-msg hook extracts the top changelog entry from each
Jonathan> file in the commit and pr
> "Jason" == Jason Merrill writes:
Jason> Note that std::move is from C++11.
>> I'm not too worried about requiring even a C++14 compiler, for the
>> set of products we still release latest compilers we have newer
>> GCCs available we can use for building them (even if those are
>> not our p
> "Bernd" == Bernd Edlinger writes:
Bernd> I'm currently trying to add -Wshadow=local to the gcc build rules.
Bernd> I started with -Wshadow, but gave up that idea immediately.
Bernd> As you could expect the current code base has plenty of shadowed
Bernd> local variables. Most are trivial t
> "Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove these calls.
Tom
> "Segher" == Segher Boessenkool writes:
>> Section 6.2.5.2 outlines the line number information state machine's
>> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition
>> is:
Segher> How should this work with shrink-wrapping? The whole point of that is
Segher> you do not tea
> "Florian" == Florian Weimer writes:
Florian> To some degree, it's a bit of a chicken-and-egg problem because
Florian> “git am” tends to choke on ChangeLog patches (so we can't
Florian> really use it today)
FWIW, installing a ChangeLog merge driver fixes this.
I use git-merge-changelog from
> "Dan" == Daniel Berlin writes:
Dan> If there are multiple types named Foo<2u>, DWARF needs to be extended to
Dan> allow a pointer from the vtable debug info to the class type debug info
Dan> (unless they already added one).
This is what we did for Rust.
Rust doesn't have a stable ABI yet,
Manuel> Everything is possible! Not sure how hard it would be, though. As
Manuel> said, GJC
"gcj".
Manuel> the Java FE, was doing something similar sometime ago, but
Manuel> it has perhaps bit-rotted now.
It used to, but when we moved to using ecj for parsing java source, we
removed (IIRC) the b
> "Michael" == Michael Matz writes:
Michael> Well, that's a hack. A solution is to design something that
Michael> works generally for garbage collected languages with such
Michael> requirements instead of arbitrarily limiting transformations
Michael> here and there. It could be something li
Martin> The one that's more difficult is 18881 where the debugger cannot
Martin> resolve calls to functions overloaded on the constness of the
Martin> argument. Do you happen to have a trick for dealing with that
Martin> one?
Nothing really convenient to use. Sometimes you can get it to do the
r
> "Martin" == Martin Sebor writes:
Martin> To get around these, I end up using info macro to print the
Martin> macro definition and using whatever it expands to instead. I
Martin> wonder if someone has found a more convenient workaround.
For some of these, like the __builtin_offsetof and __
Manuel> The overall goal of the project is worthwhile, however, it is unclear
Manuel> whether the approach envisioned in the wiki page will lead to the
Manuel> desired benefits. See http://tromey.com/blog/?p=420 which is the last
Manuel> status report that I am aware of.
Yeah. I stopped working o
>> mkoch = mkoch
Jeff> Michael Koch? konque...@gmx.de/
Yes; and he has an entry in /etc/passwd, so maybe the conversion script
has a bug?
Tom
Eric> In the mean time, I'm enclosing a contributor map that will need to be
Eric> filled in whoever does the conversion. The right sides should become
Eric> full names and preferred email addresses.
It's probably worth starting with the map I used when converting gdb.
There is a lot of overlap b
> "Jan" == Jan Kratochvil writes:
Jan> I have problems implementing '@' into GCC, could you suggest at which place
Jan> should I call build_array_type_nelts()? Or is it the right way at all?
Jan> +case ATSIGN_EXPR:
Jan> + orig_op0 = op0 = TREE_OPERAND (expr, 0);
Jan> + orig_op
> "Jakub" == Jakub Jelinek writes:
Jakub> I fear that is going to be too expensive, because e.g. all the
Jakub> caching that dejagnu and our tcl stuff does would be gone, all
Jakub> the tests for lp64 etc. would need to be repeated for each test.
In gdb I arranged to have this stuff saved i
> "Steven" == Steven Bosscher writes:
Steven> Here is a non-comprehensive list of macros that are used with a
Steven> function passed to the macro's argument, and the macro evaluates that
Steven> argument at least twice:
[...]
Steven> Not sure what to do about them (if anything) but I don't t
> "Jeff" == Jeff Law writes:
Jeff> Given the problems Ian outlined around adding Go to the default
Jeff> languages and the build time issues with using Ada instead of Java,
Jeff> I'm unsure how best to proceed.
IIRC from upthread the main reason to keep one of these languages is
-fnon-call-e
> "Richard" == Richard Biener writes:
Richard> Whatever the "core language runtime" would be - I'm somewhat a
Richard> Java ignorant.
The core is quite large, unless you are also willing to track through
all the code and chop out the bits you don't want for testing. This
would mean having a
> "Tobias" == Tobias Burnus writes:
Tobias> Updated version attached – after bootstrapping and regtesting on
Tobias> x86-64-gnu-linux
Tobias> OK?
Sorry, I didn't notice this until today.
Tobias> @@ -925,7 +928,8 @@ enum {
Tobias>CPP_W_NORMALIZE,
Tobias>CPP_W_INVALID_PCH,
Tobias>
> "Matthias" == Matthias Klose writes:
Matthias> A make install from trunk 20131020 seems to be broken, at
Matthias> least when building with Go (last time I successfully
Matthias> installed was 20130917). However, even without Go enabled,
Matthias> dfa.c is rebuilt and and then the dependin
> "Eric" == Eric Botcazou writes:
>> Sorry, I think it requires a review.
>> I'll send it to gcc-patches.
Eric> IMO it clearly falls into the obvious category.
I wasn't so sure; but in any case Jakub quickly approved it and I have
checked it in.
Tom
> "Eric" == Eric Botcazou writes:
Eric> Ping?
Sorry, I think it requires a review.
I'll send it to gcc-patches.
Tom
> "Basile" == Basile Starynkevitch writes:
Basile> I want to merge the current trunk into the MELT branch, and I
Basile> have some trouble understanding how one should add new files
Basile> into GCC (i.e. into a branch)
Nothing much has changed there. You just don't need to list any
discove
Tom> 2013-09-30 Tom Tromey
Tom>* Makefile.in (-DTOOLDIR_BASE_PREFIX): Use $(if), not $(and).
I didn't look at this until later and saw that Emacs guessed wrong.
Here's the corrected ChangeLog entry.
2013-09-30 Tom Tromey
* Makefile.in (DRIVER_DEFINES): Use
le and found that $(and ..) was added in
3.81.
In this particular case it looked easy to reimplement using $(if).
Could you please try this patch with make 3.80?
thanks,
Tom
2013-09-30 Tom Tromey
* Makefile.in (-DTOOLDIR_BASE_PREFIX): Use $(if), not $(and).
Index:
Diego> Thank you, thank you, thank you! A long time in the making, but
Diego> I'm glad you persevered.
FWIW, I had given up on this patch way back when; but then was somewhat
reinvigorated by the Cauldron and happened to notice a few "missing
dependency" bug fixes on the list...
Tom
>>>>> "Tom" == Tom Tromey writes:
Tom> I wanted to mention this explicitly, since last time around this series
Tom> tripped across a GNU make bug. If you see any problems, please report
Tom> them and CC me. I will look into them as soon as I am able.
Oops
Hi all.
I've checked in the automatic dependency tracking patch series.
I wanted to mention this explicitly, since last time around this series
tripped across a GNU make bug. If you see any problems, please report
them and CC me. I will look into them as soon as I am able.
thanks,
Tom
> "Ian" == Ian Lance Taylor writes:
Ian> So you should be good to go for Go.
Thanks. I confirmed it works here. I've merged this and pushed the
needed go/Make-lang.in change to my branch and built with a large -j on
gcc110 with success.
Tom
Tom> There may be more missing dependencies. Please try out this branch if
Tom> you would. You can report bugs to me, just send the build log.
I tried -j33 on a bigger machine and found a problem with Go.
The dependency patch uses the language Makefile conventions to add some
order-only depende
> "Diego" == Diego Novillo writes:
Diego> Have you any plans for other build system work?
Nope, no other plans.
This was just an unfinished item from long ago that Cauldron inspired me
to try to complete.
Tom
Today I started resurrecting my old automatic dependency patch.
I decided, this time, to take a more incremental approach. Thanks to
git, I made a patch series, rather than one monster patch. Now we can
easily test various parts of the change to more easily notice if, or
when, we trip across the
Andrew> I would question the appropriateness of using -Wall -Werror in
Andrew> production code.
Andreas> What matters is whether *some* stages of production code
Andreas> development use this combination of options. It could
Andreas> certainly be argued whether it should also be a project's
Andre
Jakub> Though, for all such changes consider what will happen if people
Jakub> compile with -save-temps, or preprocess separately from
Jakub> compilation (ccache etc.).
Yes, good point.
It is useful as a hack but doubtful in other ways.
Tom
> "Ed" == Ed Smith-Rowland <3dw...@verizon.net> writes:
Ed> I have a situation where I would like to detect if a string is a
Ed> currently defined macro.
Ed> Something like a
Ed> bool cpp_is_macro(const unsigned char *);
Ed> would be great.
Ed> Or perhaps I could construct something from t
> "Joern" == Joern Rennecke writes:
Joern> The likelyhood that a test depends on the outcome of the last few
Joern> n tests is rather low. So you could tests speculatively with an
Joern> incomplete set of defines, and then re-run them when you have
Joern> gathered all the results from the pr
> "Lawrence" == Lawrence Crowl writes:
Lawrence> Are the symbol searches specific to the scope context, or does it
Lawrence> search all globally defined symbols?
I am not totally certain in this case, but in gdb many searches are
global, so that "print something" works even if "something" is
Richard> Did you consider using clang?
Richard>
We may look at it after re-examining g++.
I think there are some reasons to prefer gcc.
Tom
> "Lawrence" == Lawrence Crowl writes:
Tom> Sure, but maybe for a critique of the approach. But only if you are
Tom> interested.
Lawrence> Sure, send it.
I think the intro text of this message provides the best summary of the
approach:
http://sourceware.org/ml/gdb-patches/2010-07/msg00284
> "Lawrence" == Lawrence Crowl writes:
Lawrence> Hm. I haven't thought about this deeply, but I think SFINAE may
Lawrence> not be less of an issue because it serves to remove candidates
Lawrence> from potential instantiation, and gdb won't be instantiating.
Lawrence> The critical distinction
> "David" == David Taylor writes:
David> It appears that STABS is largely in maintenance mode. Are there any
David> plans to deprecate STABS support? If STABS enhancements were made and
David> posted would they be frowned upon? Or would they be reviewed for
David> possible inclusion in a f
> "Gaby" == Gabriel Dos Reis writes:
Richard> Just to add another case which seems to be not covered in the thread.
Richard> When dumping from inside a gdb session in many cases I cut&paste
Richard> addresses literally. For overloading to work I'd need to write casts
Richard> in front of the
> "Diego" == Diego Novillo writes:
Diego> The compiler will then always add 'file', 'function' and 'line' to the
Diego> argument list, which can then be retrieved via builtins or special
Diego> argument names (I think builtins may be safer).
Diego> This would allow us to handle operators. I
> "Steven" == Steven Bosscher writes:
[...]
Steven> java/class.c: switch_to_section (get_section (buf, flags, NULL));
Steven> java/class.c: switch_to_section (get_section (buf, flags, NULL));
Steven> I am not sure how to fix this. I think it could be fixed by having a
Steven> versio
> "Diego" == Diego Novillo writes:
Diego> Nice! What version of gdb has this support?
7.4.
Tom
> "Diego" == Diego Novillo writes:
Diego> Tom, I'm thinking of that patch on black listing functions. There was
Diego> also the idea of a command that would only step in the outermost
Diego> function call of an expression.
That patch went in. The new command is called "skip".
I don't thin
> "Richard" == Richard Guenther writes:
Richard> Oh, and did we address all the annoyances of debugging gcc when it's
Richard> compiled by a C++ compiler? ...
If you mean gdb problems, please file bugs.
Tom
> "Stefano" == Stefano Lattarini writes:
Stefano> On a second though, by double-checking the existing code, I
Stefano> couldn't see how the 'cygnus' option could possibly influence
Stefano> the location of the generated info files -- and it turned out
Stefano> it didn't! Despite what was doc
> "Stefano" == Stefano Lattarini writes:
Stefano> It should still be possible, with the right hack (which is
Stefano> tested in the testsuite, and required by other packages
Stefano> anyway). The baseline is: if you don't want your '.info' files
Stefano> to be distributed, then it should be
> "Stefano" == Stefano Lattarini writes:
Stefano> Sorry if I sound dense, but what exactly is the feature you are
Stefano> talking about here?
I was under the impression that it would no longer be possible to build
info files in the build tree. But, I see that, according to the
Automake man
> "Stefano" == Stefano Lattarini writes:
Stefano> True, and that was even stated in the manual; the whole point
Stefano> of ditching support for cygnus trees is that by now those two
Stefano> big users are basically not making any real use of the 'cygnus'
Stefano> option anymore. To quote my
> "Stefano" == Stefano Lattarini writes:
Stefano> Note there's nothing I'm planning to do, nor I should do, in
Stefano> this regard: the two setups described above are both already
Stefano> supported by the current automake implementation (but the last
Stefano> one is not encouraged, even tho
> "rth" == Richard Henderson writes:
rth> Oh, of course. GDB is seeing the sequence of CFA's:
rth>X foo
rth>X-4 __mips16_call_stub_df_0
rth>X caller
rth> and it is sanity checking the stack is monotonic.
rth> Which seems like a fairly reasonable thing to do...
Re
> "Manuel" == Manuel López-Ibáñez writes:
Manuel> However, to be honest, even if you implement your own source-location
Manuel> manager in your own plugin code, I don't think it will be very precise
Manuel> because the internal representation of GCC C/C++ FE is not very close
Manuel> to the a
> "Robert" == Robert Dewar writes:
Robert> Now the debugging at -O1 is hopeless (even parameters routinely
Robert> disappear), and so I am forced to do everything at -O0.
There's been a lot of work on gcc in this area.
Please file bugs for cases you find.
Tom
> "David" == David Malcolm writes:
David> I maintain gcc-python-plugin [1]. I'm hoping to expose the function
David> decl_as_string() from the C++ frontend from within my plugin.
I think this problem was discussed before, either here or on
gcc-patches, I forget.
David> (b) somehow set thin
> "Cary" == Cary Coutant writes:
Cary> At Google, we've found that the cost of linking applications with
Cary> debug info is much too high.
[...]
Cary> * .debug_macinfo - Macro information, unaffected by this design.
There is also the new .debug_macro section. This section refers to
.debug
> "Iain" == Iain Buclaw writes:
Ian> There is a directory gcc/d/zlib, but gcc already has a top-level zlib
Ian> directory.
Iain> Zlib there is the version released with the D Phobos library, it is
Iain> slightly newer. But is harmless to remove.
You could alternatively update the version in
Gabriel> We are tying to keep pph as "pluginable" as possible (Diego correct me
Gabriel> if I'm wrong), so changing the actual implementation of the linemap
Gabriel> would be our very last resort I think.
Gabriel> However since source_location aren't pointers per se, this wouldn't
Gabriel> work (a
> "Gabriel" == Gabriel Charette writes:
Gabriel> @tromey: We have a question for you: the problem is detailed
Gabriel> here and our question to you is at the bottom. Thanks!
Sure. I have not followed PPH progress very closely and after reading
your message I am not sure I have much to offer
> "David" == David Malcolm writes:
David> This would be good. However, looking at, say,
David> http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html#Tree-SSA-passes
David> I don't see meaningful per-pass anchors there. I'm not familiar with
David> gcc's documentation toolchain; is ther
> "Kevin" == Kevin André writes:
Pierre> I would like user of the plugin to give in arguments the name of
Pierre> the functions on which he would like a test to be run. That
Pierre> means that I must convert the string containing a function name
Pierre> (like "myclass::init") and get either t
> "Tobias" == Tobias Burnus writes:
Tobias> The DWARF spec does not really tell the implications of the
Tobias> accessibility tags, which makes it a tad more difficult to
Tobias> understand what should be done.
That is ok -- the DWARF consumer will see that the CU is Fortran, and
will know t
> "Michael" == Michael T writes:
Michael> I was wondering if it is possible to improve the debugging
Michael> information generated by gcc when resolving C macros?
It could be done, but nobody has tried.
Michael> I wonder whether this couldn't be done by the gcc preprocessor?
Michael> Or do
> "Paolo" == Paolo Bonzini writes:
Paolo> * Put the string at the end of the IDENTIFIER_NODE using the trailing
Paolo> array hack (or possibly in the ht_identifier, see
Paolo> libcpp/include/symtab.h and libcpp/symtab.c)
I implemented this once:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg
> "Janne" == Janne Blomqvist writes:
Jim> Can someone add me to the gcc group? That would help.
Jim> I already have ssh access to sourceware.org.
Janne> I'm not sure if I'm considered to be well-established
Janne> enough, so could someone help Jim out here, please?
I added Jim to the gcc g
> "Joseph" == Joseph S Myers writes:
Joseph> Additional tools for the build (not host) system may be built
Joseph> (not installed) when present in the source tree, if of direct
Joseph> use in building and testing the components in those
Joseph> repositories, and likewise additional libraries
> "Basile" == Basile Starynkevitch writes:
Basile> So I need to understand who is writing the 0x101 in that field.
valgrind can sometimes catch this, assuming that the write is an invalid
one.
Basile> An obvious strategy is to use the hardware watchpoint feature of GDB.
Basile> However, one
> "Ian" == Ian Lance Taylor writes:
Ian> The problem with warnings for this kind of code in C/C++ is that it
Ian> often arises in macro expansions. I think it would be necessary to
Ian> first develop a scheme which lets us determine whether code resulted
Ian> from a macro expansion or not, w
> "Laurent" == Laurent GUERBY writes:
Laurent> Let's imagine we have a reliable tool on a distributed build
Laurent> farm that accepts set of patches (via mail and web with some
Laurent> authentification) and does automatic regression testing and
Laurent> report on selected platform.
Can we
> "Jeff" == Jeff Law writes:
Jeff> Building libjava (at least for me) is primarily painful due to 2 files
Jeff> (the names escape me) and the rather poor coarse level parallelism
Jeff> (can't build the 32bit and 64bit multilibs in parallel for example).
Jeff> Has anyone looked at fixing the
> "Steven" == Steven Bosscher writes:
Steven> The argument against disabling java as a default language always was
Steven> that there should be at least one default language that requires
Steven> non-call exceptions. I recall testing many patches without trouble if
Steven> I did experimental
> "Ian" == Ian Lance Taylor writes:
Ian> This patch puts the code in libiberty, but it could equally well go in
Ian> gcc. Anybody want to make an argument one way or another?
Ian> +extern const char *
Ian> +objfile_attributes_compare (objfile_attributes *attrs1,
GDB already uses the name "
>>>>> "Steven" == Steven Bosscher writes:
Steven> Assertions in libcpp have been deprecated since r135264:
Steven> 2008-05-13 Tom Tromey
Steven> PR preprocessor/22168:
Steven> * expr.c (eval_token): Warn for use of assertions.
Steven>
> "Bruce" == Bruce Korb writes:
Bruce> That seems to work. There are one or two or three bugs then.
Bruce> Either gdb needs to recognize an out of sync object code, or else
Bruce> gcc needs to produce object code that forces gdb to object in a way
Bruce> more obvious than just deciding upon
> "Kien" == Kien Nguyen Trung writes:
Kien> obj_type_ref
Kien> indirect_ref (test.cpp:21-17)
Kien> The problem is method read() of class B is get from a virtual method
Kien> of based class A. And i cannot get the real name of this method.
Kien> Do you have any idea
> "Dave" == Dave Korn writes:
Dave> I think you're probably assuming too much. Tom T. is working on an
Dave> incremental compiler, isn't he?
I was, but I was asked to work on gdb a couple of years ago, so that
work is suspended.
Dave> But yes, OP, it's a long-term project.
Apple impleme
> "Basile" == Basile Starynkevitch writes:
Basile> My understanding of the description of the tag GTY option in
Basile> http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html#GTY-Options
Basile> is that a given discriminated union case can have several
Basile> tags.
It seems like a reasonable
> "Brett" == Brett Neumeier writes:
Brett> What is still not clear is: what version of the ecj CVS project
Brett> corresponds to "ecj 4.5"? It doesn't look like there are branches or
Brett> tags in the CVS repository.
Yeah, oops. We've been remiss in doing that.
I believe 4.5 was made from
> "Brett" == Brett Neumeier writes:
Brett> Are there any plans to publish the source code along with the binary
Brett> jar file? In the meantime, where can I find the source code for the
Brett> current ecj, as needed by gcc? Is there a source repository I can get
Brett> to?
Yes, check out th
Ian> In Tom's interesting idea, we would write the mark function by hand for
Ian> each C++ type that we use GTY with.
I think we should be clear that the need to write a mark function for a
new type is a drawback of this approach. Perhaps gengtype could still
write the functions for ordinary type
> "Basile" == Basile Starynkevitch writes:
Basile> Still, my concerns on C++ is mostly gengtype related. I believe we need
Basile> to keep a garbage collector even with C++, and I believe that changing
Basile> gengtype to follow C++ could be quite painful if we follow the usual
Basile> route
1 - 100 of 382 matches
Mail list logo
