Re: GDB debugging showing wrong code

Thanks Richard! I have requested an account with the gcc bugzilla system. Trampas On Fri, Dec 27, 2024 at 5:05 AM Richard Biener wrote: > > > > Am 27.12.2024 um 02:50 schrieb Trampas Stern via Gcc : > > > > I am doing embedded development on an arm cortex-m processor using > > arm-none-eabi-

Re: GDB debugging showing wrong code

> Am 27.12.2024 um 02:50 schrieb Trampas Stern via Gcc : > > I am doing embedded development on an arm cortex-m processor using > arm-none-eabi-gcc. I have run into a bug where GDB is showing that the > code executing is code from a function that is not used. The code is > removed as it is n

GDB debugging showing wrong code

I am doing embedded development on an arm cortex-m processor using arm-none-eabi-gcc. I have run into a bug where GDB is showing that the code executing is code from a function that is not used. The code is removed as it is not called, and hence -ffunction-sections -fdata-sections -Wl,--gc-sectio

Re: Debugging the tree object constructed by cp_parser

t able to > > > > find > > > > any > > > > variable remotely similar to the AST of functions/structs etc. > > > > that > > > > must be > > > > constructed by this great piece of software. I would very much > > > > apprecia

Re: Debugging the tree object constructed by cp_parser

, I was not able to > > > find > > > any > > > variable remotely similar to the AST of functions/structs etc. > > > that > > > must be > > > constructed by this great piece of software. I would very much > > > appreciate > > > any explanat

Re: Debugging the tree object constructed by cp_parser

. that > > must be > > constructed by this great piece of software. I would very much > > appreciate > > any explanation from the great experts in gcc on this mailing list. I > > posted a thread at gcc-help, but apparently it is too obvious of a > > question

Re: Debugging the tree object constructed by cp_parser

; to be addressed there. Hi Stan FWIW I've written some notes on debugging GCC: https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html and in particular you might find the following useful: https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html#how-do-i-find-where-a-particular-tree-was-created Hope this is helpful Dave

Debugging the tree object constructed by cp_parser

Dear GCC community, I am assigned the task to debug the trees as being produced by the cp_parser. I was able to print some of the trees using the debug_tree() function. But I am still confused as to where is the tree object that corresponds to the translation unit being parsed. There is no such fi

Re: Debugging C++ frontend using CLion IDE

ng 8 spaces to 1 tab automatically. There are plugins for Code to run customs commands on save. To keep your IDE snappy, you should exclude everything that you won't need from the indexing, especially the test directory. At last, for debugging, I had good experiences with launching a gdbserver,

Re: Debugging C++ frontend using CLion IDE

On Wed, 2023-03-01 at 20:59 +0300, Berke Yavas via Gcc wrote: > One thing I haven't figured out yet, how can I debug C++ frontend(or > any other language frontend) with CLion. If anybody managed to do > this (or using another IDE), could you please share your settings > with me? Since CLion is (a)

Re: Debugging C++ frontend using CLion IDE

Hi Berke, > Hi, > > I am trying to set up my environment for the upcoming google summer of > code. One thing I haven't figured out yet, how can I debug C++ frontend(or > any other language frontend) with CLion. If anybody managed to do this(or > using another IDE), could you please share your sett

Re: Debugging C++ frontend using CLion IDE

Hi Berke, Hi, I am trying to set up my environment for the upcoming google summer of code. One thing I haven't figured out yet, how can I debug C++ frontend(or any other language frontend) with CLion. If anybody managed to do this(or using another IDE), could you please share your settings with

Debugging C++ frontend using CLion IDE

Hi, I am trying to set up my environment for the upcoming google summer of code. One thing I haven't figured out yet, how can I debug C++ frontend(or any other language frontend) with CLion. If anybody managed to do this(or using another IDE), could you please share your settings with me? Best re

Re: fanalyzer: debugging zero state machine

On Sun, 2022-06-12 at 20:27 +0200, Tim Lange wrote: > > > On Do, Jun 9 2022 at 13:40:06 -0400, David Malcolm > wrote: > > On Thu, 2022-06-09 at 16:49 +0200, Tim Lange wrote: > > > > > >   > On Mi, Jun 8 2022 at 11:12:52 -0400, David Malcolm > > >   wrote: > > >   > > On Wed, 2022-06-08 at 01:4

Re: fanalyzer: debugging zero state machine

On Do, Jun 9 2022 at 13:40:06 -0400, David Malcolm wrote: On Thu, 2022-06-09 at 16:49 +0200, Tim Lange wrote: > On Mi, Jun 8 2022 at 11:12:52 -0400, David Malcolm wrote: > > On Wed, 2022-06-08 at 01:42 +0200, Tim Lange wrote: > > > > Hi Dave, Hi Tim; various responses inline be

Re: fanalyzer: debugging zero state machine

On Thu, 2022-06-09 at 16:49 +0200, Tim Lange wrote: > >  > On Mi, Jun 8 2022 at 11:12:52 -0400, David Malcolm > wrote: >  > > On Wed, 2022-06-08 at 01:42 +0200, Tim Lange wrote: >  > > >  > > Hi Dave, Hi Tim; various responses inline below... >  > > >  > > I did spent some time to think about

fanalyzer: debugging zero state machine

> On Mi, Jun 8 2022 at 11:12:52 -0400, David Malcolm wrote: > > On Wed, 2022-06-08 at 01:42 +0200, Tim Lange wrote: > > > > Hi Dave, > > > > I did spent some time to think about the zero state machine. I first > > thought about distinguishing between "assigned zero" and "EQ 0 > > condition

Re: A simple debugging question

12:23 AM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: A simple debugging question [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] On Wed, Jul 14, 2021 at 6:42 AM Gary Oblock

Re: A simple debugging question

On Wed, Jul 14, 2021 at 6:42 AM Gary Oblock via Gcc wrote: > > OK, I haven't asked a dumb question for a while so here goes! > > I'm trying to debug my optimization in lto running 505mcf_r > (yes it's SPEC17.) > > Here's the bit that fails from the make.out: > > /home/gary/gcc_build_gcc11/install/

A simple debugging question

OK, I haven't asked a dumb question for a while so here goes! I'm trying to debug my optimization in lto running 505mcf_r (yes it's SPEC17.) Here's the bit that fails from the make.out: /home/gary/gcc_build_gcc11/install/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto1 -quiet -dumpdir ./mcf_r.lto.o-

Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

On Apr 20, 2021, at 9:11 AM, Gabriel Paubert mailto:paub...@iram.es>> wrote: (lldb) di -s 0x000103d6 -c 10 libgambit.dylib`___SCMOBJ_to_NONNULLSTRING: 0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at c_intf.c:3282:9 0x103d60002 <+1506>: orb%al, 0x31(%rbp) 0

Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

On Tue, Apr 20, 2021 at 12:20:06PM +, Lucier, Bradley J via Gcc wrote: > I’m seeing an “Illegal Instruction” fault and don’t quite know how to > generate a proper bug report yet. > > This is the compiler: > > [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v > Using built-in spe

Re: Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

Lucier, Bradley J via Gcc wrote: I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate a proper bug report yet. This is the compiler: [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc COLLE

Need help debugging possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate a proper bug report yet. This is the compiler: [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/l

[FOSDEM] [CfP] Debugging Tools devroom 2020

* Last Reminder! Talk proposal deadline is this weekend! * Debugging Tools developer room at FOSDEM 2020 (Brussels, Belgium, February 2). Talk/Discussion Submission deadline: Sunday1 Dec 2019 Devroom Schedule announcement: Sunday 15 Dec 2019 Devroom day

[FOSDEM] [CfP] Debugging Tools devroom 2020

Debugging Tools developer room at FOSDEM 2020 (Brussels, Belgium, February 2). Talk/Discussion Submission deadline: Sunday1 Dec 2019 Devroom Schedule announcement: Sunday 15 Dec 2019 Devroom day: Sunday2 Feb 2020 FOSDEM is a free software

[FOSDEM] [CfP] Debugging Tools devroom 2020

Debugging Tools developer room at FOSDEM 2020 (Brussels, Belgium, February 2). Talk/Discussion Submission deadline: Sunday1 Dec 2019 Devroom Schedule announcement: Sunday 15 Dec 2019 Devroom day: Sunday3 Feb 2020 FOSDEM is a free software

Re: debugging libgo failures

On 3/12/19 3:28 PM, Ian Lance Taylor wrote: On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez wrote: I have some libgo failures which I'm pretty sure I caused (see below for details), but I can't seem to figure out how to reproduce. Before I go down the rabbit hole, is there an easy way of r

Re: debugging libgo failures

On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez wrote: > > I have some libgo failures which I'm pretty sure I caused (see below for > details), but I can't seem to figure out how to reproduce. Before I go > down the rabbit hole, is there an easy way of reproducing say: > > FAIL: database/sql > FA

debugging libgo failures

Hi Ian. Hi folks. I have some libgo failures which I'm pretty sure I caused (see below for details), but I can't seem to figure out how to reproduce. Before I go down the rabbit hole, is there an easy way of reproducing say: FAIL: database/sql FAIL: net/http I'm used to scouring x86_64-pc

Re: Debugging optimizer problems

On 02/02/2018 12:29 PM, jacob navia wrote: Hi I am confronted with a classical problem: a program gives correct results when compiled with optimizations off, and gives the wrong ones with optimization (-O2) on. I have isolated the probem in a single file but now there is no way that I can furth

Re: Debugging optimizer problems

se and thank you for pointing me to that doc. > > jacob > > You will find gcc manuals for many versions of the tools at <https://gcc.gnu.org/onlinedocs/>. In your debugging, I find the most common causes of "it works when optimisation is disabled" to be aliasing pr

Re: Debugging optimizer problems

Le 02/02/2018 à 22:11, Florian Weimer a écrit : * jacob navia: I have in my small C compiler introduced the following construct: #pragma optimize(on/off,push/pop) Not sure what you are after. GCC has something quite similar:

Re: Debugging optimizer problems

* jacob navia: > I have in my small C compiler introduced the following construct: > > #pragma optimize(on/off,push/pop) Not sure what you are after. GCC has something quite similar:

Debugging optimizer problems

Hi I am confronted with a classical problem: a program gives correct results when compiled with optimizations off, and gives the wrong ones with optimization (-O2) on. I have isolated the probem in a single file but now there is no way that I can further track down the problem to one of the

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Mon, 19 Sep 2016, Thomas Schwinge wrote: > > The question is whether such a complex type could be a global tree which I > > don't think it could. > > Specifically, my question was whether for every complex type that is part > of the global trees, it holds that the complex type's component type

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge wrote: > Hi! > > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener > wrote: >> On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge >> wrote: >> > --- gcc/tree-core.h >> > +++ gcc/tree-core.h >> > @@ -553,20 +553,6 @@ enum tree_index { >> >TI_BO

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

Hi! On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener wrote: > On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge > wrote: > > --- gcc/tree-core.h > > +++ gcc/tree-core.h > > @@ -553,20 +553,6 @@ enum tree_index { > >TI_BOOLEAN_FALSE, > >TI_BOOLEAN_TRUE, > > > > - TI_COMPLEX_INTEGER_TYP

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

Hi! On Mon, 19 Sep 2016 10:12:48 +0200, Richard Biener wrote: > On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers wrote: > > On Fri, 16 Sep 2016, Thomas Schwinge wrote: > > > >> That's what I was afraid of: for example, I can't tell if it holds for > >> all GCC configurations (back ends), that comp

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Fri, Sep 16, 2016 at 3:32 PM, Thomas Schwinge wrote: > Hi! > > On Fri, 16 Sep 2016 10:59:16 +0200, Richard Biener > wrote: >> On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge >> wrote: >> > On Thu, 08 Sep 2016 13:43:30 +0200, I wrote: >> >> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Fri, Sep 16, 2016 at 7:07 PM, Joseph Myers wrote: > On Fri, 16 Sep 2016, Thomas Schwinge wrote: > >> That's what I was afraid of: for example, I can't tell if it holds for >> all GCC configurations (back ends), that complex types' component types >> will always match one of the already existing

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Fri, 16 Sep 2016, Richard Biener wrote: > Humm ... do we anywhere compare to those global trees by pointer equivalence? > If so then it breaks LTO support for those types. The C front end compares main variants to those types for handling usual arithmetic conversions (and more generally for t

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Fri, 16 Sep 2016, Thomas Schwinge wrote: > That's what I was afraid of: for example, I can't tell if it holds for > all GCC configurations (back ends), that complex types' component types > will always match one of the already existing global trees? (I can Well, a component type could certain

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

Hi! On Fri, 16 Sep 2016 10:59:16 +0200, Richard Biener wrote: > On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge > wrote: > > On Thu, 08 Sep 2016 13:43:30 +0200, I wrote: > >> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener > >> wrote: > >> > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge

Re: [PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

On Fri, Sep 16, 2016 at 9:05 AM, Thomas Schwinge wrote: > Hi! > > (CCing Bernd and Jakub -- for your information, or: "amusement" -- as > you've discussed offloading preload_common_nodes issues before...) > > Got to look into this some more, yesterday: > > On Thu, 08 Sep 2016 13:43:30 +0200, I wro

[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx types (was: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6]))

Hi! (CCing Bernd and Jakub -- for your information, or: "amusement" -- as you've discussed offloading preload_common_nodes issues before...) Got to look into this some more, yesterday: On Thu, 08 Sep 2016 13:43:30 +0200, I wrote: > On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener > wrote: > >

Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

On Thu, Sep 8, 2016 at 1:43 PM, Thomas Schwinge wrote: > Hi! > > On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener > wrote: >> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge >> wrote: >> > I trimmed the CC list -- I'm looking for advice about debugging

Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

Hi! On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener wrote: > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge > wrote: > > I trimmed the CC list -- I'm looking for advice about debugging a lto1 > > ICE. > > > > On Fri, 19 Aug 2016 11:05:59 +, Joseph Mye

Re: Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge wrote: > Hi! > > I trimmed the CC list -- I'm looking for advice about debugging a lto1 > ICE. > > On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers > wrote: >> On Fri, 19 Aug 2016, Richard Biener wrote: >>

Advice sought for debugging a lto1 ICE (was: Implement C _FloatN, _FloatNx types [version 6])

Hi! I trimmed the CC list -- I'm looking for advice about debugging a lto1 ICE. On Fri, 19 Aug 2016 11:05:59 +, Joseph Myers wrote: > On Fri, 19 Aug 2016, Richard Biener wrote: > > Can you quickly verify if LTO works with the new types? I don't see > > anything

Re: Debugging offload compiler ICEs

t's where I got the idea from for this "pause" hack.) To > re-run the mkoffload invoked before, you'll need to set (several?) > environment variables. Yeah, for example debugging things like lto-wrapper itself that is also required. But cut&pasting the lto1 command should work (if not we should fix that). Richard. > > Grüße > Thomas

Re: Debugging offload compiler ICEs

Hi! On Tue, 3 May 2016 12:54:23 +0200, Richard Biener wrote: > On Tue, May 3, 2016 at 12:47 PM, Thomas Schwinge > wrote: > > It is currently difficult to debug offloading compiler invocations. > > These are actually lto1 front ends invoked from the target compilation's > > collect2 process, via

Re: Debugging offload compiler ICEs

On Tue, May 3, 2016 at 12:47 PM, Thomas Schwinge wrote: > Hi! > > It is currently difficult to debug offloading compiler invocations. > These are actually lto1 front ends invoked from the target compilation's > collect2 process, via the respective offloading toolchain's mkoffload. > To the best of

Debugging offload compiler ICEs

Hi! It is currently difficult to debug offloading compiler invocations. These are actually lto1 front ends invoked from the target compilation's collect2 process, via the respective offloading toolchain's mkoffload. To the best of my knowledge, it's not possible to use the target compiler's "-wrap

Re: add support for debugging output

On Fri, Oct 31, 2014 at 3:30 PM, Prathamesh Kulkarni wrote: > On Fri, Oct 31, 2014 at 7:33 PM, Prathamesh Kulkarni > wrote: >> Hi, >>I was wondering if it would be a good idea to add "debugging" >> output to the patterns. >> sth like: >

Debugging var-tracking problem

Folks, I am working on a bug in variable tracking: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 GCC is looping infinitely in attempting to solve a data flow problem in vt_find_locations. My working theory is that compute_bb_dataflow is incorrectly asserting some value has changed when i

Re: Debugging LTO.

Tejas Belagod wrote: Are there any tricks I can use to debug an LTO ICE? See LTO section on https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction Tobias

Debugging LTO.

Hi, Are there any tricks I can use to debug an LTO ICE? Lto1 --help does not seem to give me an option to output trace dumps etc. What I suspect is happening is that cc1 builds erroneous LTO IR info in the objects that causes the ICEs. Is there a reader that will dump the IR from these LTO obj

Re: Debugging C++ Function Calls

> "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

Re: Debugging C++ Function Calls

On 3/25/13, Tom Tromey wrote: > I think the intro text of this message provides the best summary > of the approach: > > http://sourceware.org/ml/gdb-patches/2010-07/msg00284.html Are the symbol searches specific to the scope context, or does it search all globally defined symbols? If you recreat

Re: Debugging C++ Function Calls

On Tue, Mar 26, 2013 at 3:02 PM, Tom Tromey wrote: > 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. Yes, obviously :-) -- Gaby

Re: Debugging C++ Function Calls

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

Re: Debugging C++ Function Calls

C. > Keith Seitz wrote a GCC plugin to try to let us farm out > expression-parsing to the compiler. This has various issues, some > because gdb allows various C++ extensions that are useful when > debugging; and also g++ was too slow. Did you consider using clang?

Re: Debugging C++ Function Calls

> "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

Re: Debugging C++ Function Calls

gt; Keith Seitz wrote a GCC plugin to try to let us farm out > expression-parsing to the compiler. This has various issues, some > because gdb allows various C++ extensions that are useful when > debugging; and also g++ was too slow. > Even if g++ can't be used we at least hope this ti

Re: Debugging C++ Function Calls

erm solution is an integrated compiler, Lawrence> interpreter, and debugger. That's not likely to happen soon. :-) Sergio is re-opening our look into reusing GCC. Keith Seitz wrote a GCC plugin to try to let us farm out expression-parsing to the compiler. This has various issues, some bec

Debugging C++ Function Calls

On 3/25/13, Tom Tromey wrote: >> "Lawrence" == Lawrence Crowl writes: > > Lawrence> My model is that I should be able to cut and paste an expression > Lawrence> from the source to the debugger and have it work. I concede that > Lawrence> C++ function overload resolution is a hard problem. H

Better debugging with!

I've been thinking about this for a while and it can't hurt to share it (it'd become shared eventually anyway) and someone might thing "good idea": Obviously -g makes gcc embed a lot of information in the result that is clear already why not that bit more? Arrays will always be integer sized (

Re: Unifying the GCC Debugging Interface

&paste > Richard> addresses literally. For overloading to work I'd need to write casts > Richard> in front of the inferior call argument. That sounds ugly - so at > least > Richard> keep the old interfaces as well. Or rather for debugging purposes > Richard> provide

Re: Unifying the GCC Debugging Interface

On Tue, Nov 27, 2012 at 10:23 AM, Richard Biener wrote: > me too, just when you do debug_tree ($1) you then don't have $nn for > all of the trees referenced from the output ;) True that :)

Re: Unifying the GCC Debugging Interface

ses literally. For overloading to work I'd need to write casts >> in front of the inferior call argument. That sounds ugly - so at least >> keep the old interfaces as well. Or rather for debugging purposes >> provide python helpers rather than new inferior overloads. > &

Re: Unifying the GCC Debugging Interface

front of the inferior call argument. That sounds ugly - so at least > keep the old interfaces as well. Or rather for debugging purposes > provide python helpers rather than new inferior overloads. Thanks. I think python helpers would probably be a good idea. I tend to use $nn instead of t

Re: Unifying the GCC Debugging Interface

;d need to write casts Richard> in front of the inferior call argument. That sounds ugly - so at least Richard> keep the old interfaces as well. Or rather for debugging purposes Richard> provide python helpers rather than new inferior overloads. Gaby> this means that we need an impr

Re: Unifying the GCC Debugging Interface

front of the inferior call argument. That sounds ugly - so at least > keep the old interfaces as well. Or rather for debugging purposes > provide python helpers rather than new inferior overloads. this means that we need an improvement from GDB. This is not useful only to the small GCC commu

Re: Unifying the GCC Debugging Interface

On Thu, Nov 15, 2012 at 2:12 AM, Lawrence Crowl wrote: > Diego and I seek your comments on the following (loose) proposal. > > > It is sometimes hard to remember which printing function is used > for debugging a type, or even which type you have. > > We propose to rely on ove

Re: Unifying the GCC Debugging Interface

Thanks for all the comments. I have incorporated all the feedback (I hope). We will start implementing this in the cxx-conversion branch. I've created a new wiki page with the debugging proposal: http://gcc.gnu.org/wiki/cxx-conversion/debugging-dumps It is also indexed from the ge

Re: Unifying the GCC Debugging Interface

tter than printf. For any text that needs to be localized, >>> I recommend that we stick with what we have. >> >> I agree with Lawrence that for texts that need localization, what >> we currently have is probably much better deployed. On the other hand, for >> deb

Re: Unifying the GCC Debugging Interface

at we stick with what we have. > > I agree with Lawrence that for texts that need localization, what > we currently have is probably much better deployed. On the other hand, for > debugging routines and in-memory formatting, IOStreams are > very handy. I'm not deeply against iostr

Re: Unifying the GCC Debugging Interface

mp;view=markup > >> Will the number of static >> constructors increase linearly with the number of translation units? Is it >> necessary to include iostream in a core header, in case we want to use >> iostream for the debugging functionality? > > I think this is the cas

Re: Unifying the GCC Debugging Interface

revision=184997&view=markup Will the number of static constructors increase linearly with the number of translation units? Is it necessary to include iostream in a core header, in case we want to use iostream for the debugging functionality? I think this is the case or premature optimization a

Re: Unifying the GCC Debugging Interface

t; Will the number of static > constructors increase linearly with the number of translation units? Is it > necessary to include iostream in a core header, in case we want to use > iostream for the debugging functionality? I think this is the case or premature optimization and you are worrying about the

Re: Unifying the GCC Debugging Interface

translation unit that includes iostream will include the iostream static constructors? Will the number of static constructors increase linearly with the number of translation units? Is it necessary to include iostream in a core header, in case we want to use iostream for the debugging functionality

Re: Unifying the GCC Debugging Interface

On Wed, Nov 21, 2012 at 7:07 AM, Tobias Grosser wrote: > On 11/20/2012 08:32 PM, Basile Starynkevitch wrote: >> >> On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote: >> [] > > All of these functions come in two forms. > > function (FILE *, item_to_dump, forma

Re: Unifying the GCC Debugging Interface

On 11/20/2012 08:32 PM, Basile Starynkevitch wrote: On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote: [] All of these functions come in two forms. function (FILE *, item_to_dump, formatting) function (item_to_dump, formatting) Since we have switched to C++, it wo

Re: Unifying the GCC Debugging Interface

Hi, On Tue, 20 Nov 2012, Lawrence Crowl wrote: > On 11/19/12, Diego Novillo wrote: > > On Nov 19, 2012 Michael Matz wrote: > > > So, yes, the larger layouting should be determined by name of the > > > dump function. A flag argument might look nice from an interface > > > design perspective, bu

Re: Unifying the GCC Debugging Interface

debugger -- see what you will get: > > > But that also suggest that the debugging experience needs for some > improvement Everyone will win if this works better Fully agreed. -- Gaby

Re: Unifying the GCC Debugging Interface

On 11/21/2012 02:01 AM, Xinliang David Li wrote: Right -- gdb does not know the complete type of std::cout and std::cerr -- try the following program with -g and invoke print, or << in the debugger -- see what you will get: But that also suggest that the debugging experience needs fo

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 7:01 PM, Xinliang David Li wrote: > Right -- gdb does not know the complete type of std::cout and > std::cerr -- try the following program with -g and invoke print, or << > in the debugger -- see what you will get: Is this because the hack we (libstdc++ folks) used to defi

Re: Unifying the GCC Debugging Interface

alization, what we currently have is probably much better deployed. On the other hand, for debugging routines and in-memory formatting, IOStreams are very handy. -- Gaby

Re: Unifying the GCC Debugging Interface

are two big advantages. First, you can concisely output a >>> bunch of stuff without having to worry about types. Very good for >>> quick coding. >>> >>>std::cout << "My variable is " << varnode >>> <<

Re: Unifying the GCC Debugging Interface

having to worry about types. Very good for >> quick coding. >> >>std::cout << "My variable is " << varnode >> << " and its type is " << typnode >> << std::endl; >> >> Second, the streams

Re: Unifying the GCC Debugging Interface

<< std::endl; > > Second, the streams write to an output stream, which can be a > file or it can be a string buffer. So, output isn't essentially > different from writing chars to a string. > > The primary disadvantage is that to exploit that those advantage

Re: Unifying the GCC Debugging Interface

lt; "My variable is " << varnode << " and its type is " << typnode << std::endl; Second, the streams write to an output stream, which can be a file or it can be a string buffer. So, output isn't essentially different from writing

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 2:32 PM, Basile Starynkevitch wrote: > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote: > [] >> >> All of these functions come in two forms. >> >> >> >> function (FILE *, item_to_dump, formatting) >> >> function (item_to_dump, formatting) > > Si

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 2:34 PM, Xinliang David Li wrote: > class bitmap { >public: > void print_me (print_flags flags = print_pretty, FILE *stream = stderr); > ... > }; This is fine and all, but most of our objects are pointers and many times we are dealing with NULL pointers. W

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 12:03 PM, Andrew MacLeod wrote: > On 11/14/2012 08:12 PM, Lawrence Crowl wrote: >> >> Diego and I seek your comments on the following (loose) proposal. >> >> >> We propose to provide several function overload sets, as below. >> >> >> dump_pretty >> >> This function ove

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 11:19:41AM -0800, Lawrence Crowl wrote: > On 11/19/12, Diego Novillo wrote: > > On Nov 19, 2012 Michael Matz wrote: > > > So, yes, the larger layouting should be determined by name of the > > > dump function. A flag argument might look nice from an interface > > > design

Re: Unifying the GCC Debugging Interface

int_me (print_pretty | print_decl_only); ... David On Wed, Nov 14, 2012 at 5:12 PM, Lawrence Crowl wrote: > Diego and I seek your comments on the following (loose) proposal. > > > It is sometimes hard to remember which printing function is used > for debugging a type, or even which

Re: Unifying the GCC Debugging Interface

On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote: [] > >> All of these functions come in two forms. > >> > >> function (FILE *, item_to_dump, formatting) > >> function (item_to_dump, formatting) Since we have switched to C++, it would be really nice to have dump functio

Re: Unifying the GCC Debugging Interface

On 11/20/12, Andrew MacLeod wrote: > On 11/14/2012 08:12 PM, Lawrence Crowl wrote: >> Diego and I seek your comments on the following (loose) proposal. >> >> >> We propose to provide several function overload sets, as below. >> >> >> dump_pretty >> >> This function overload set provides the b

  1   2   3   4   >