>>>>> "Tom" == Tom Tromey writes:
Tom> This patch introduces a new "class toplev" and changes toplev_main and
Tom> toplev_finalize to be methods of this class. Additionally, now the
Tom> timevars are automatically stopped when the object is destroy
David> OK. Are you able to push this to my branch, or do you need me to do
David> this?
Thanks, I was able to push them.
Tom
gcc/toplev.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/gcc/ChangeLog.jit b/gcc/ChangeLog.jit
index ee1df88..a9b0817 100644
--- a/gcc/ChangeLog.jit
+++ b/gcc/ChangeLog.jit
@@ -1,5 +1,9 @@
2014-03-19 Tom Tromey
+ * toplev.c (general_init): Initialize input_location.
+
+20
e code, since it's 0 either way,
Dave> but perhaps it's more readable?)
Sounds reasonable to me.
How about the appended?
Tom
commit 79ce51eaf41ce7b0e90407245b7cad33ada6887b
Author: Tom Tromey
Date: Thu Mar 20 08:51:25 2014 -0600
initialize input_location
This patch initia
> "Julian" == Julian Brown writes:
Julian> include/
Julian> * dwarf2.h (enum dwarf_calling_convention): Add
Julian> DW_CC_GNU_thiscall_i386.
We've been trying to ensure that all GNU DWARF extensions are
documented. In the past we had problems where an extension was added
and the
+1,9 @@
2014-03-24 Tom Tromey
+ * timevar.c (timevar_print): Clear timevar_enable.
+
+2014-03-24 Tom Tromey
+
* toplev.c (general_init): Initialize input_location.
* input.c (input_location): Initialize to UNKNOWN_LOCATION.
diff --git a/gcc/timevar.c b/gcc/timevar.c
> "Mark" == Mark Wielaard writes:
Mark> Add a new lang-hook that provides the underlying base type of an
Mark> ENUMERAL_TYPE. Including implementations for C and C++. Use this
Mark> enum_underlying_base_type lang-hook in dwarf2out.c to add a DW_AT_type
Mark> base type reference to a DW_TAG_en
> "Marc" == Marc Glisse writes:
Marc> libcpp/
Marc> * line-map.c (get_combined_adhoc_loc): Cast to extern "C" type.
Yucky.
Marc> line_map_realloc reallocator
Marc> - = set->reallocator ? set->reallocator : xrealloc;
Marc> + = set->reallocator ? set->reallocator
Marc> +
> "Marc" == Marc Glisse writes:
Marc> Do you prefer an other approach?
No, this is fine, just yucky.
Marc> Like this? (I'll test if approved, but I am not sure what was wrong
Marc> with the indentation and parentheses so it may be wrong again)
>From the node 'Formatting' in the GCS:
> "Richard" == Richard Sandiford writes:
Richard> Here's the result of running the copyright script on libcpp/.
Richard> It's nice and short, but for consistency with the other patches,
Richard> I've not listed out every file in the changelog.
Richard> Tested on x86_64-linux-gnu. OK to inst
> "Dave" == John David Anglin writes:
Dave> I had looked at this a bit in the past. I don't think it's that
Dave> difficult to add DWARF2 support
Dave> to GCC on hppa. Although we don't support named sections, we can
Dave> create named subspaces
Dave> for the dwarf info. More of an issue i
> "Tristan" == Tristan Gingold writes:
Tom> Another way to look at it is that there have been many changes to GCC's
Tom> DWARF output in the last few years. Surely these have broken these
Tom> DWARF consumers more than this change possibly could.
Tristan> Yes, but there is -gstrict-dwarf to
I'm checking this in as obvious.
Sergio pointed out, via this patch, that gcc/configure didn't properly
emit whether sys/std.h was discovered.
Tested by re-running configure and examining the output.
Tom
2011-10-17 Sergio Durigan Junior
* configure.ac: Display `yes' if the SystemTap
> "Ed" == Ed Smith-Rowland <3dw...@verizon.net> writes:
Ed> + /* Nonzero for the 2011 C++ Standard. */
Ed> + unsigned char cxx11;
I think it would be better if the new field name reflected its purpose,
so something like "user_literals".
Ed> + if (ISIDST(*cur))
Ed> + {
Ed> + typ
> "Paolo" == Paolo Carlini writes:
Paolo> By the way, I have no idea why I didn't see it, only Fortran includes
Paolo> that header in the *libcpp* directory? Anyway, I'm proceeding to
Paolo> bootstrap the attached.
It really isn't ok to do this. That header is supposedly private to
libcpp.
> "Jeff" == Jeff Law writes:
Jeff> First, it's perfectly fine to have a NULL pointer dereference in a
Jeff> program as long as that code is never executed. Once the code is
Jeff> executed, we've entered the realm of undefined behavior.
Jeff> Thus in a conforming program we can safely assume
> "Jeff" == Jeff Law writes:
Jeff> So, presumably there's no way to know we're throwing to
Jeff> NullPointerException from the exception information attached to the
Jeff> statement or BB? If not I could disable if the statement with the
Jeff> memory op throws anywhere. It's not ideal, but c
The new output looks like this:
$11 = std::unique_ptr containing (datum *) 0x6067d0
Let me know what you think.
Tom
b/libstdc++-v3/ChangeLog:
2012-08-10 Tom Tromey
* testsuite/libstdc++-prettyprinters/cxx11.cc (struct datum):
New.
(global): New global.
(m
> "Jonathan" == Jonathan Wakely writes:
>> $11 = std::unique_ptr containing (datum *) 0x6067d0
Jonathan> It's inconsistent with the other printers in that it prints
Jonathan> the stored type, unlike e.g. std::vector which just says
Jonathan> "std::vector of length ..." but I think that's an
ted patch. Let me know what you think.
Tom
2012-08-14 Tom Tromey
* testsuite/libstdc++-prettyprinters/cxx11.cc (struct datum):
New.
(global): New global.
(main): Add test for unique_ptr.
* python/libstdcxx/v6/printers.py
(UniquePointerPrin
> "Diego" == Diego Novillo writes:
Diego> GDB folks, would it be hard to figure out that there is a single
Diego> variant of the called function and trust the user that they are
Diego> passing the right pointer value?
I asked Keith to resurrect his patch for this.
Tom
> "Gaby" == Gabriel Dos Reis writes:
Tom> I asked Keith to resurrect his patch for this.
Gaby> Since people are concerned about typing rules, would it
Gaby> be an option for GDB to allow people to input pointer
Gaby> literals with the "p" suffix (or "0p" prefix instead of "0x")?
I think on
> "Jonathan" == Jonathan Wakely writes:
Jonathan> I like it, please go ahead and check that in it you're happy
Jonathan> with it.
I did. Thanks.
Tom
> "Dodji" == Dodji Seketeli writes:
Dodji> With these changes, the libcpp parts look OK to me if they still
Dodji> boostrap post c++ conversion. I am not a maintainer so I a deferring to
Dodji> Tom and the other maintainers.
I agree. Dodji, thanks for looking at this.
Dmitris, thanks for w
> "Dimitris" == Dimitrios Apostolou writes:
Dimitris> [...] since I broke things like the static assert in
Dimitris> libcpp/identifiers.c, that I don't even understand:
Dimitris> /* We don't need a proxy since the hash table's identifier comes
first
Dimitris> in cpp_hashnode. However,
> "Robert" == Robert Dewar writes:
Robert> Sometimes I wonder whether the insistence on -g not changing code
Robert> generation is warranted. In practice, gdb for me is so weak in handling
Robert> -O1 or -O2, that if I want to debug something I have to recompile
Robert> with -O0 -g, which cau
> "Dehao" == Dehao Chen writes:
Dehao> + static htab_t location_adhoc_data_htab;
Dehao> + static source_location curr_adhoc_loc;
Dehao> + static struct location_adhoc_data *location_adhoc_data;
Dehao> + static unsigned int allocated_location_adhoc_data;
libcpp was written to allow multiple p
ype's name. This lets a library pretend that
some typedefs are canonical.
This includes a fairly comprehensive test case for the new type
printers.
Tom
b/libstdc++-v3/ChangeLog:
2012-09-21 Tom Tromey
* testsuite/libstdc++-prettyprinters/whatis.cc: New file.
* testsuite/l
:basic_string, but I thought a test
Magnus> case here couldn't hurt?
Here's an updated patch with the new tests.
Tom
2012-09-25 Tom Tromey
* testsuite/libstdc++-prettyprinters/whatis.cc: New file.
* testsuite/lib/gdb-test.exp (whatis-test): New proc.
(gdb
> "Florian" == Florian Weimer writes:
Florian> This patch adds support for #pragma GCC warning and #pragma GCC
Florian> error. These pragmas can be used from preprocessor macros,
Florian> unlike the existing #warning and #error directives. Library
Florian> authors can use these pragmas to ad
Jonathan> Please go ahead and commit, thanks, Tom!
Thanks. The needed gdb patches are still pending, so I plan to wait
until those go in before committing to libstdc++. I hope it will be
next week sometime.
Tom
> "Eric" == Eric Botcazou writes:
Pedro> It's not about example, but the fact that host compilers have been
Pedro> compiling that code as part of building gcc for years, without anyone
Pedro> complaining, afaik. It doesn't matter whether the code pointed at
Pedro> is the ugliest or most beau
> "Eric" == Eric Botcazou writes:
>> It's true that this is a pedantic violation; but the point here is that
>> there is no practical barrier to using 'long long'. This code has been
>> in the tree since 2007; so if there is some issue with it, it ought to
>> have surfaced by now.
Eric> The
> "Eric" == Eric Botcazou writes:
Tom> I don't understand what the code being external, or the review, has to
Tom> do with anything. This code is compiled with the same host compiler as
Tom> everything else.
Eric> But, precisely, this line of reasoning is barely defensible in my
Eric> opini
> "Thomas" == Thomas Schwinge writes:
Thomas> This is a backport of upstream boehm-gc configuration support for
Thomas> GNU/Hurd. The equivalent thing has been used in Debian's GCC packages
Thomas> since GCC 4.2 already, and I decided that *NOW* ought to be the time to
Thomas> put it into th
> "Eli" == Eli Zaretskii writes:
Eli> I understand all that, but why would the eq_f function need to be an
Eli> external function on its own?
It is just to avoid other users having to write their own.
Eli> E.g., if we were to write a qsort replacement, would we have a
Eli> suitable string c
> "Steven" == Steven Bosscher writes:
Steven> Makefile.in is a mess. One of these days, someone (hi, Tromey) will
Steven> hopefully get annoyed enough with this again to finish some tool to
Steven> auto-generate the dependences list. Until that time, let's try to
Steven> avoid proliferating t
> "Laurynas" == Laurynas Biveinis writes:
Laurynas> 2012-06-24 Laurynas Bivienis
Laurynas> * include/line-map.h (line_map_macro): Use the "atomic" GTY
option
Laurynas> for the macro_locations field.
Laurynas> gcc/java:
Laurynas> 2012-07-24 Laurynas Biveinis
Laurynas>
really been all that good at language lawyering.
Comments?
2012-07-27 Tom Tromey
* c-common.h (enum rid) : New constant.
* c-common.c (c_common_reswords): Add _Generic.
2012-07-27 Tom Tromey
* c-parser.c (struct c_generic_association): New.
(c_generic_associa
> "Joseph" == Joseph S Myers writes:
Joseph> Could you explain the choices you have made for the issues
Joseph> raised on comp.std.c last month (regarding the handling of
Joseph> qualifiers on controlling expressions) and the rationale for
Joseph> those choices (and make sure there are approp
> "Joseph" == Joseph S Myers writes:
Tom> I wasn't really aware of 6.3.2.1, but after reading it and re-reading
Tom> 6.5.1.1, I think I agree with his "model 0" interpretation: no promotion
Tom> or conversion.
Tom> I don't have a standards-based reason for this, though; just my belief
Tom> t
>>>>> "Joseph" == Joseph S Myers writes:
Joseph> On Mon, 30 Jul 2012, Tom Tromey wrote:
>> 6.3 is about conversions, and the first paragraph starts "several
>> operators convert ...". Based on this, and other such phrases in the
>> text,
> "Ollie" == Ollie Wild writes:
Ollie> 2012-04-22 Ollie Wild
Ollie> * gcc/c-family/c-common.c:
Ollie> * gcc/c-family/c-opts.c (c_common_handle_option):
Ollie> * gcc/c-family/c.opt:
Ollie> * gcc/doc/invoke.texi (struct A):
Ollie> * gcc/testsuite/g++.dg/cpp0x/Wreserved-user-defined-lit
> "Jakub" == Jakub Jelinek writes:
Jakub> On Thu, Apr 26, 2012 at 01:52:31PM -0400, DJ Delorie wrote:
>>
>> I will not oppose adding more unrelated stuff to libiberty, but
>> neither will I approve it. I will let one of the other maintainers or
>> a global maintainer approve it.
Jakub> The
HJ> You should add extern "C" for C++ on those functions moved to
HJ> libiberty.
Yeah, sorry about that.
I'm testing the fix.
Tom
>>>>> "Tom" == Tom Tromey writes:
HJ> You should add extern "C" for C++ on those functions moved to
HJ> libiberty.
Tom> Yeah, sorry about that.
Tom> I'm testing the fix.
Here is what I am checking in.
Tom
ChangeLog:
2012-04-27 Tom Tromey
> "Tristan" == Tristan Gingold writes:
Tristan> 2012-05-04 Tristan Gingold
Tristan>* expr.c (interpret_float_suffix): Add a guard.
Ok.
Tom
> "Dodji" == Dodji Seketeli writes:
Dodji> To properly fix this, I think libcpp should keep the token of the
Dodji> pasting operator '##', instead of representing it with flag on the LHS
Dodji> operand's token. That way, it could use its location.
Originally I had thought that a pasted toke
> "Lawrence" == Lawrence Crowl writes:
Lawrence> The effect is that it now possible to get useful responses to gdb
Lawrence> command like
Lawrence> (gdb) print DECL_FUNCTION_CODE (decl)
Doesn't this mean that if you have checking enabled, and you use the
wrong macro on some tree, cc1 wil
> "Manuel" == Manuel López-Ibáñez writes:
Manuel> Actually, I wonder how you (Richard) and other GCC hackers work with
Manuel> and debug GCC, because it is a real pain in the ass.
Manuel> * All the TREE_ macros don't work.
Manuel> * __extension__ prevents GDB from evaluating many things.
S
> "Manuel" == Manuel López-Ibáñez writes:
Manuel> It seems it will never work for statement expressions:
Manuel> http://article.gmane.org/gmane.comp.gcc.devel/107339
It could be done, but it is non-trivial for sure.
Manuel> I see how these small functions can quickly become annoying. Is it
> "Lawrence" == Lawrence Crowl writes:
Tom> Doesn't this mean that if you have checking enabled, and you use the
Tom> wrong macro on some tree, cc1 will crash? That seems like a distinct
Tom> minus to me.
Lawrence> Yes, it does mean that, but it is a net overall improvement.
It is a net de
ct, and it does
avoid the crash.
Ok?
Tom
2012-05-21 Tom Tromey
http://sourceware.org/bugzilla/show_bug.cgi?id=14065
* testsuite/demangle-expected: Add regression test.
* cp-demangle.c (d_find_pack): Return NULL for
DEMANGLE_COMPONENT_UNNAMED_TYPE.
diff --git a
> "Alexander" == Alexander Monakov writes:
Alexander> Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
Alexander> It's useful to have that in your .gdbinit anyway, because the
Alexander> same issue arises when calling debug_* functions in cc1 from
Alexander> the debugger.
Yeah, why
> "Lawrence" == Lawrence Crowl writes:
Lawrence> Should I add that to my patch to gdbinit.in?
I think it would be helpful.
Tom
> "Mike" == Mike Stump writes:
Mike> Yeah, I kinda think the gdb people are wimping out by not just
Mike> implementing __extension__ and ({}), which, I think get us most of the
Mike> way there. Shh, don't tell them I said that.
We eagerly await your patch.
Tom
> "Diego" == Diego Novillo writes:
Diego> +struct GTY(()) vec_prefix
Diego> +{
Diego> + unsigned num;
Diego> + unsigned alloc;
Diego> +};
Diego> +
Diego> +/* Vector type, user visible. */
Diego> +template
Diego> +struct GTY(()) vec_t
Diego> +{
Diego> + vec_prefix prefix;
Diego> + T GTY((
> "Lawrence" == Lawrence Crowl writes:
Lawrence> On 5/24/12, Gabriel Dos Reis wrote:
>> On May 24, 2012 Lawrence Crowl wrote:
>> > Add a type-safe hash table, typed_htab. Uses of this table
>> > replace uses of libiberty's htab_t. The benefits include less
>> > boiler-plate code, full typ
> "Lawrence" == Lawrence Crowl writes:
Lawrence> Because libcpp was using a typedef hash_table, that typedef has been
Lawrence> renamed cpp_hash_table and uses of it have changed.
The libcpp changes are ok.
Tom
the tests.
I tested this against gdb 7.2 (=> unsupported) and 7.3 (=> all tests
pass).
Let me know what you think.
Tom
2011-08-03 Tom Tromey
* testsuite/libstdc++-prettyprinters/simple.cc: New file.
* testsuite/lib/gdb-test.exp: New file.
* testsuite/libstdc+
> "Peter" == Peter Collingbourne writes:
Peter> 2011-08-02 Peter Collingbourne
Peter> * expr.c (expand_invoke) Use the type of the method rewrite
target.
Ok.
Tom
> "Gabriel" == Gabriel Charette writes:
Gabriel> This hack, has described in more details in the email labeled
Gabriel> "Line 0 Hack??", was now causing problem when serializing the
Gabriel> line_table in pph.
I think you do have to handle location 0 somehow.
This is UNKNOWN_LOCATION, referr
> "Jie" == Jie Liu writes:
Jie> + if(str == NULL)
Jie> + throw new NullPointerException();
Jie> +
Jie>int length = str->length();
Why doesn't 'str->length()' throw the NPE?
Tom
> "Dimitrios" == Dimitrios Apostolou writes:
Dimitrios> 2011-08-09 Dimitrios Apostolou
[...]
Dimitrios> * symtab.c (ht_dump_statistics): Beautified stats output.
Make sure the ChangeLog entries go in the correct directories.
Dimitrios> + obmem= obstack_memory_used (&table->stack);
> "Richard" == Richard Guenther writes:
>> The libcpp part is ok with this change.
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or hash computation.
I was only approv
> "Rainer" == Rainer Orth writes:
Rainer> 2011-08-07 Rainer Orth
Rainer> gcc/java:
Rainer> * jcf-dump.c (print_constant): Cast first frexp arg.
Rainer> libjava:
Rainer> * exception.cc (std::abort): Remove static.
Ok.
Tom
> "Jie" == Jie Liu writes:
Jie> RTEMS does not have virtual memory management, so there is no error
Jie> when access the 0 address on rtems.
Jie> So 'str->length()' donot throw NPE and just return an meaningless value.
If you compile the Java parts of the library with -fcheck-references, it
> "Jie" == Jie Liu writes:
Jie> + *-*-rtems*)
Jie> + can_unwind_signal=no
Jie> + CHECKREFSPEC=-fcheck-references
Jie> + DIVIDESPEC=-fuse-divide-subroutine
Jie> + ;;
This part is OK with a ChangeLog entry.
Jie> +
Spurious newline addition.
Jie> But it does not work as we want, is ther
> "Jie" == Jie Liu writes:
Jie> In my debug, there appears no check for 'this' at start of String.length():
Yeah, I looked for uses of flag_check_references and didn't see one when
building a method's body. So I guess I mis-remembered this.
In any case, the spot you found is just the tip o
> "Gabriel" == Gabriel Charette writes:
Gabriel> Removed LINEMAP_POSITION_FOR_COLUMN, it did the EXACT same
Gabriel> thing as linemap_position_for_column, so maintaining both in
Gabriel> parallel seems like overkill to me. The only thing I can think
Gabriel> of is that it's more optimal as it
> "Rainer" == Rainer Orth writes:
Jason> I'm of two minds about this, but I see that clang and edg still
Jason> use 199711L in C++0x mode, so let's stick with that for now.
Rainer> with the prerequisite patches now installed, here's the reworked version
Rainer> of the final patch.
Rainer> T
>>>>> "Tom" == Tom Tromey writes:
Tom> I'm finally getting back to this.
Tom> This patch adds test suite support for the libstdc++ pretty-printers.
Any comments on this?
I'd like to get it in; Phil found a bug in the std::tuple printer, and
it would be
> "Jason" == Jason Merrill writes:
>> + LC_ENTER_MACRO
>> + /* stringize */
>> + /* paste */
Jason> What is the purpose of these comments?
That is left over from my initial hack. The new scheme doesn't (yet?)
properly handle locations arising from stringizing or token pasting.
Tom
> "Gabriel" == Gabriel Charette writes:
Gabriel> It nows exposes two libcpp functions to force the
Gabriel> source_location for tokens when desired.
I am not really a fan of this approach, but I see why you did it this
way -- anything else would be very invasive.
I can only approve the libc
> "Dimitrios" == Dimitrios Apostolou writes:
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or hash computation.
Tom> I was only approving the change to the dumping.
Tom
> "Jakub" == Jakub Jelinek writes:
Jakub> For ccache and friends I think it would be better to have a
Jakub> preprocessing mode that would output all lines as is (i.e. no
Jakub> macro replacement), except for processing #include/#include_next
Jakub> directives.
That exists -- -fdirectives-on
Tom> That exists -- -fdirectives-only.
Jakub> It isn't exactly what would be needed, as e.g. \\\n are removed from
Jakub> from #defines and thus they get different location of the tokens.
Dodji> Would it be acceptable to just change the output of -fdirective to fit?
Dodji> Or are we bound to not
> "Dodji" == Dodji Seketeli writes:
Dodji> * line-map.c (linemap_add): Assert that reason must not be
Dodji> LC_RENAME when called for the first time on a "main input file".
This is ok. I can't approve the rest but it seems reasonable.
Tom
Tom> Any comments on this?
Tom> I'd like to get it in; Phil found a bug in the std::tuple printer, and
Tom> it would be nice to put in a test case along with the fix.
Benjamin> Hey Tom (and Phil!).
Benjamin> Sorry for the delay: this looks fine. Please put it in on trunk and
Benjamin> enjoy your
> "Diego" == Diego Novillo writes:
Diego> Tom, Cary, Ian, any suggestions? We are trying to figure out a
Diego> compromise for tiny inline functions that are generally a nuisance
Diego> when debugging. The scenario is a call like this: big_function_foo
Diego> (inlined_f (x), inlined_g (y));
> "Diego" == Diego Novillo writes:
Tom> http://sourceware.org/bugzilla/show_bug.cgi?id=8287
Diego> I think this could work. I'm not sure I like the idea of having to
Diego> specify all these blacklist commands, but I appreciate how it can make
Diego> debugging more flexible.
Yeah, that'
> "Jakub" == Jakub Jelinek writes:
Jakub> I don't mind if it goes into gdb, but IMHO the blacklisting should
Jakub> definitely default to blacklisting DW_AT_artificial inline functions
Jakub> (and allowing to unblacklist them), because the artificial attribute
Jakub> has been designed for tha
> "Jeff" == Jeff Law writes:
Jeff> Presumably it hasn't been included because not all gdb's understand
Jeff> those bits and we typically don't build with -g3.
GCC is pretty much the perfect candidate for a -g3 build. All those
macros...
The needed gdb changes have been in since right aroun
> "Sandeep" == Sandeep Soni writes:
Sandeep> The following patch is a basic attempt to build a symbol table that
Sandeep> stores the names of all the declarations made in the input file.
I don't know anything about gimplefe, but unless you have complicated
needs, it is more usual to just put
> "Tristan" == Tristan Gingold writes:
Tristan> I am not against this patch, my only concern is that there are many
Tristan> many dwarf consumers and I have no idea how they will react to this
Tristan> change.
I tend to think that this is the wrong standard to apply. In this case
we would b
> "Rainer" == Rainer Orth writes:
Rainer> libjava:
Rainer> * configure.ac (THREADLIBS): Remove *-*-solaris2.8 handling.
Rainer> * configure: Regenerate.
This part is ok. Thanks.
Tom
> "Rainer" == Rainer Orth writes:
Rainer> libcpp:
Rainer> * lex.c: Remove Solaris 8 reference.
Also ok.
Tom
> "DJ" == DJ Delorie writes:
DJ> Sigh, libiberty is supposed to be a portability library, not a
DJ> kitchen-sink for common stuff. Should I give up that premise? Or
DJ> should we consider a common dwarf2 helper library, and move even more
DJ> of the dwarf2 code into it?
My reasoning was:
> "DJ" == DJ Delorie writes:
Tom> Finally, there is already stuff in libiberty not related to
Tom> portability. E.g., hashtab or the demangler.
DJ> Yeah, I know, hence my "Should I give up that premise?"
Yeah.
I am not sure there will ever be enough shared code to warrant a new
library, p
>>>>> "Jakub" == Jakub Jelinek writes:
Jakub> On Thu, Mar 15, 2012 at 12:41:54PM -0600, Tom Tromey wrote:
>> I guess I can just put the whole DW_TAG_ prefix in there.
>> That isn't a big deal. Or if you have some other suggestion, I can
>>
> "Rainer" == Rainer Orth writes:
Rainer> Continuing with the patches to remove obsolete ports, here's the
Rainer> IRIX 6.5 removal patch.
Rainer> * libjava/gnu/classpath/natSystemProperties.cc (getpwuid_adaptor) claims
Rainer> to be for IRIX, too, but I cannot tell for certain.
It doesn'
> "DJ" == DJ Delorie writes:
DJ> The only drawback to adding toplevel libraries is coordinating changes
DJ> among the toplevel configury.
And adding crud to Makefiles all over.
Pick a name for the new library and I will implement this.
Tom
> "Rainer" == Rainer Orth writes:
Rainer> 2012-03-21 Rainer Orth
Rainer> PR libgcj/52645
Rainer> * gnu/java/net/natPlainDatagramSocketImplPosix.cc (setOption):
Rainer> Restore HAVE_INET6 check.
Rainer> * gnu/java/net/natPlainDatagramSocketImplWin32.cc (setOp
>>>>> "Tom" == Tom Tromey writes:
Tom> Here is a new patch for gcc.
Tom> I still haven't updated the src side, but there's little to do there
Tom> that isn't already done in this patch.
Tom> Ok?
Ping.
Tom
> "Doug" == Doug Evans writes:
Doug> On Thu, Mar 15, 2012 at 11:54 AM, Mike Stump
wroteDoug> btw, is there any interest in mirroring gcc/contrib -> src/contrib?
Doug> [instead of gdb having its own copy in gdb/testsuite, it *could* use
Doug> the one in, e.g., src/contrib. I don't have a str
> "Gaby" == Gabriel Dos Reis writes:
Manuel> So, in fact, libcpp is buggy for not implementing this (as can be seen
Manuel> in emacs). If/When libcpp is fixed, the column info will be correct
Manuel> for tabs. And then, one may care about printing tabs as anything
Manuel> different from a sin
Tom> Here is a new patch for gcc.
Tom> I still haven't updated the src side, but there's little to do there
Tom> that isn't already done in this patch.
Tom> Ok?
Tom> Ping.
Ping.
Tom
> "Steven" == Steven Bosscher writes:
Steven> Subject says all. Will commit as obvious.
Steven> * tree.def (CASE_LABEL_EXPR): Fix documentation, mention all
operands.
Thank you.
Tom
Tom> Here is a new patch for gcc.
Tom> I still haven't updated the src side, but there's little to do there
Tom> that isn't already done in this patch.
Tom> Ok?
Tom> Ping.
Tom> Ping.
This is the third ping.
Please review the patch.
There are two choices:
1. Approve the original patch, adding
> "Gaby" == Gabriel Dos Reis writes:
Gaby> On Wed, Apr 25, 2012 at 9:33 AM, Dodji Seketeli wrote:
>> Hopefully closing the series, this patch switches the compiler to
>> -ftrack-macro-expansion=2 by default.
>>
>> Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
Gaby> Mak
401 - 500 of 579 matches
Mail list logo
