Re: Debugging the tree object constructed by cp_parser

Hi David, Thanks for your suggestion. I really appreciate it. But I would like to modify the trees as they are constructed. So the first step is to understand how to print them out ( using debug_tree() or even printf()) from inside cp_parser.cc. I think it is a reasonable question: where are the

Re: Debugging the tree object constructed by cp_parser

On Mon, 2023-12-04 at 10:09 -0500, Stan Srednyak wrote: > Hi David, thanks for your email. I really appreciate it. > > Your notes are certainly of help, but I also had a specific question: > how > to access the trees as they are being constructed by the front end. > Do you > have an answer to this

Re: Debugging the tree object constructed by cp_parser

Hi David, thanks for your email. I really appreciate it. Your notes are certainly of help, but I also had a specific question: how to access the trees as they are being constructed by the front end. Do you have an answer to this? I looked into GCC internals docs. The section on the front end (se

Re: Debugging the tree object constructed by cp_parser

On Sat, 2023-12-02 at 17:41 -0500, Stan Srednyak via Gcc wrote: > 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 objec

Re: Debugging C++ frontend using CLion IDE

Hi Berke, I had the same problem last year. Many IDEs don't really work for developing gcc. Most here probably use either emacs or vim. If you want to use an IDE, you might have to do some hacks. The oldschool indentation style of gcc (mix of tab and spaces) is not widely supported. IDEs/Edi

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

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

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

On 02/02/18 23:03, jacob navia wrote: > 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

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:

Re: Debugging offload compiler ICEs

On Tue, May 3, 2016 at 1:19 PM, Thomas Schwinge wrote: > 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 e

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

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

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

On Mon, Mar 25, 2013 at 7:20 PM, Tom Tromey wrote: >> "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 gd

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

On 3/25/13, Tom Tromey wrote: >> "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 instantiat

Re: Debugging C++ Function Calls

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

Re: Debugging incorrect generation of RTL

I suspect the assertion in set_last_insn in emit-rtl.h is giving me false positives.

Re: Debugging incorrect generation of RTL

On 11/01/2012 10:28 AM, Peter Garbett wrote: > I am maintaining a private port that I am attempting to port to GCC 4.7.2 > > With RTL checking enabled, it fails with a message > > > "RTL check: expected code 'reg' have 'const_int' in rhs_regno, at rtl.h:1090" > > > I assume this is because the

Re: 'Debugging Support' translation

Am Samstag, 28. Mai 2011, 22:47:06 schrieb Patric Conrad: > Hi! > > I'm willing to translate publication located at > http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html to the > Belorussian language (my mother tongue). What I'm asking for is your > written permission, so you don't mind afte

Re: Debugging information in C macros

On Tue, 2011-05-10 at 17:33 +0200, Michael T wrote: > Hello all, > > I was wondering if it is possible to improve the debugging information > generated by gcc when resolving C macros? Just as an example, when I > preprocessed the following C file: > Have you tried '-g3'? R.

Re: Debugging information in C macros

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

RE: Debugging information in C macros

> From: rasel...@hotmail.com > > From: bas...@starynkevitch.net > > On Tue, 10 May 2011 17:33:57 +0200 > > Michael T wrote: > > > I was wondering if it is possible to improve the debugging information > > > generated by gcc when resolving C macros? Just as an example, when I > > > preprocessed the

RE: Debugging information in C macros

> From: bas...@starynkevitch.net > On Tue, 10 May 2011 17:33:57 +0200 > Michael T wrote: > > I was wondering if it is possible to improve the debugging information > > generated by gcc when resolving C macros? Just as an example, when I > > preprocessed the following C file: [...] > I am not a st

Re: Debugging information in C macros

On Tue, 10 May 2011 17:33:57 +0200 Michael T wrote: > I was wondering if it is possible to improve the debugging information > generated by gcc when resolving C macros? Just as an example, when I > preprocessed the following C file: > > extern int printf (__const char *__restrict __format, ...);

Re: debugging

On Wed, 23 Mar 2011 08:51:25 +0100, Jakub Jelinek wrote: > http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval > is the git branch with gdb support for this, though as I was told > it is a GDB 7.4 material rather than 7.3 (the msg00268.html > commit is hope

Re: debugging

On Tue, Mar 22, 2011 at 03:29:26PM -0700, Ian Lance Taylor wrote: > Mike Stump writes: > > > So, I was trying to debug some stuff with the top of the tree on a suse > > linux x86_64 box and got: > > > > (gdb) p mode > > Unhandled dwarf expression opcode 0xf3 > > > > which I don't find entertaini

Re: debugging

Mike Stump writes: > So, I was trying to debug some stuff with the top of the tree on a suse linux > x86_64 box and got: > > (gdb) p mode > Unhandled dwarf expression opcode 0xf3 > > which I don't find entertaining. I know I _could_ install a new gdb, and > most likely this would fix the probl

Re: debugging

On Tue, Mar 22, 2011 at 3:15 PM, Mike Stump wrote: > So, I was trying to debug some stuff with the top of the tree on a suse linux > x86_64 box and got: > > (gdb) p mode > Unhandled dwarf expression opcode 0xf3 > > which I don't find entertaining.  I know I _could_ install a new gdb, and > most

Re: Debugging lto1, how?

> Hope this helps... Looks like something is getting really messed up in the argument parsing :-( The error for the hexadecimal number pursing is from the code that should handle things like fil...@offset This is probably from some @file not being expanded. What I would recommend is first debu

Re: Debugging lto1, how?

On Tue, Dec 29, 2009 at 6:50 PM, Rafael Espindola wrote: >> I have the lto1 command line, yes. But that gives a different failure. >> When run from gcc, lto1 crashes with an ICE, and when I run lto1 >> standalone, it crashes with an error reading a hex number. > > Do you have a backtrace of that?

Re: Debugging lto1, how?

> I have the lto1 command line, yes. But that gives a different failure. > When run from gcc, lto1 crashes with an ICE, and when I run lto1 > standalone, it crashes with an error reading a hex number. Do you have a backtrace of that? You can also copy the gcc line and pass -wrapper to it. > > >>

Re: Debugging lto1, how?

On Tue, Dec 29, 2009 at 5:41 PM, Rafael Espindola wrote: > 2009/12/29 Steven Bosscher : >> Hi, >> >> I am trying to see what is going on in lto1 for PR lto/42534. I can >> reproduce the reported ICE but I can't reproduce it inside gdb to see >> what is happening. Debugging lto1 is not trivial - ju

Re: Debugging lto1, how?

2009/12/29 Steven Bosscher : > Hi, > > I am trying to see what is going on in lto1 for PR lto/42534. I can > reproduce the reported ICE but I can't reproduce it inside gdb to see > what is happening. Debugging lto1 is not trivial - just getting the > arguments and input files right is hard. > > App

Re: Debugging gcc front end

HI, I wanna say thanks to everyone that help me. My problem was find the correct path and the command line I will expose what I did to help someone that can have the same problem. I copied the files in my local path $ cp debug /usr/local/bin/ $ cp debugx /usr/local/bin/ after I just run the de

Re: Debugging gcc front end

Guilherme Puglia wrote: > Hi! > > or better, hello again! I have posted a question (with my class friend > Eduardo) about 2 or 3 weeks ago. My question was about the grammar > wich gcc C front end use. Yeh! Hi again you guys :) > To solve my problem I wanna debug the C front end. I was trying

Re: Debugging gcc front end

Guilherme Puglia <1c3br...@gmail.com> writes: > To solve my problem I wanna debug the C front end. I was trying to > debug the gcc main function, toplev_main. Unfortunately, I can't > insert a break point in this line. > > I saw the site http://gcc.gnu.org/wiki/DebuggingGCC and > http://gcc.gnu.or

RE: Debugging a custom GCC Back End

Balthasar Biedermann wrote on 03 August 2008 14:59: > The compilation of my custom GCC works, but the binary I get is not > working. I always get the "internal compiler error: Segmentation fault" > message if I try to Compile a c-file. > But the GCC don't tell me, where or why the error occurred.

Re: debugging info considered harmful to lto.

> Jan Hubicka wrote: > >Thanks for explanation - the space optimization seems relatively > >chalenging to implement, in particular because the variables in scope > >might change in between the time abstract copy is output and the time > >the block referencing to the block via abstract pointer is ou

Re: debugging info considered harmful to lto.

Jason Merrill wrote: > Jan Hubicka wrote: >> Thanks for explanation - the space optimization seems relatively >> chalenging to implement, in particular because the variables in scope >> might change in between the time abstract copy is output and the time >> the block referencing to the block via a

Re: debugging info considered harmful to lto.

Jan Hubicka wrote: Thanks for explanation - the space optimization seems relatively chalenging to implement, in particular because the variables in scope might change in between the time abstract copy is output and the time the block referencing to the block via abstract pointer is output. The

Re: debugging info considered harmful to lto.

On Mon, Jul 23, 2007 at 08:56:11PM +0200, Jan Hubicka wrote: > > On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote: > > It's mostly supposed to be a space optimization. We get e.g. the > > names and (sometimes) types of local variables from the origin copy, > > and only need a location a

Re: debugging info considered harmful to lto.

> On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote: > > The particular problem here is that the abstract origin pointers points > > to the blocks within functions they was constructed from. These are used > > by dwarf2out to output abstract copy of the function and then use it > > as a d

Re: debugging info considered harmful to lto.

On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote: > The particular problem here is that the abstract origin pointers points > to the blocks within functions they was constructed from. These are used > by dwarf2out to output abstract copy of the function and then use it > as a destination

Re: debugging info considered harmful to lto.

Hi, to add some extra data > At the summit, I discovered two things about the internal representation > of debugging information: > > 1) According to Honza, the instances of the BLOCK tree type take 30% of > the space in a compilation. this large portion appears on C++ testcases doing a lot of in

Re: debugging info considered harmful to lto.

On Sun, Jul 22, 2007 at 07:37:43PM -0400, Kenneth Zadeck wrote: > I find it somewhat surprising that we need so many blocks. My > experience is that in real programs few blocks actually have any local > declarations and it appears that we do not bother to get rid of the > blocks that have no local

Re: debugging capabilities on AIX ?

I wrote: << I'd appreciate feedback on general questions from these observations: Is it generally known/expected that xcoff/stabs debugging capabilities degrade when moving from 3.4 to 4.x ? If yes, how is that considered by AIX GCC developers ? (how serious the issue, is it fixable

Re: debugging capabilities on AIX ?

> The reaction varies with developer. AIX continues to use > xcoff/stabs. The feedback of AIX users to IBM sales representatives and > executives will determine the response. FYI Sun has switched to DWARF-2 by default in Studio 11. Just to put a bit of pressure on you. :-) -- Eric Botca

Re: debugging capabilities on AIX ?

> On Jan 12, 2007, at 12:56 AM, Olivier Hainque wrote: > >Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to > >evaluate GDB (6.4) debugging capabilities currently yields very > >unpleasant results compared to what we obtain with a GCC 3.4 based > >compiler (80+ extra failures out of

Re: debugging capabilities on AIX ?

On Jan 12, 2007, at 12:56 AM, Olivier Hainque wrote: Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to evaluate GDB (6.4) debugging capabilities currently yields very unpleasant results compared to what we obtain with a GCC 3.4 based compiler (80+ extra failures out of 1800+ tests

Re: debugging capabilities on AIX ?

> Olivier Hainque writes: Olivier> Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to Olivier> evaluate GDB (6.4) debugging capabilities currently yields very Olivier> unpleasant results compared to what we obtain with a GCC 3.4 based Olivier> compiler (80+ extra failures out of

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

I filed a PR29090 for the gcc.dg-struct-layout-1 failure of T(94,struct atal16{}a;,) OK. .comm _a94,1 .stabs "a94:G(0,1)=ar(0,2)[EMAIL PROTECTED];r(0,2);0;017;;0;04;(1,1)",32,0,1,0 .stabs "long unsigned int:t(0,3)[EMAIL PROTECTED];r(0,3);0;01

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Eric, I filed a PR29090 for the gcc.dg-struct-layout-1 failure of T(94,struct atal16{}a;,) ...out of the set of failures I see. I noticed that in the assembly from struct-layout-1_y.s, the follow occurs... .comm _a94,1 .stabs "a94:G(0,1)=ar(0,2)[EMAIL PROTECTED];r(0,2);0;01777

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

On Thu, Sep 14, 2006 at 09:19:12AM -0400, Jack Howarth wrote: > T(94,struct atal16{}a;,) > > into struct-layout-1_test.h would I append it to the > original... > > T(0,enum E2 a:31;,B(0,a,e2_m1,e2_0)) > > ...or replace it? Also I assume I should be editing Doesn't matter, in one case you'll run

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jakub, I would like to create a test case for a couple of the failures I see in gcc.dg-struct-layout-1 on Darwin PPC -m64 so I can submit a PR for this one. I have been able to find all of the lines in the generated testcase for the failed tests... http://gcc.gnu.org/ml/gcc/2006-09/msg00211.html

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Eric, Yesterday's gcc trunk (with the residual TImode patch) shows the following gcc testsuite failures at -m64... FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmp

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jack Howarth wrote: Eric, Do you see the same set of failures... FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Eric, Do you see the same set of failures... > FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_t

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Does anyone recognize any sort of pattern to these failures which might suggest why they fail on Darwin PPC at -m64 and not on ppc64? We do have a radar about the lack of aligned uninitialized variable support, i.e. .comm x,size,align that references t001 and t025. -eric

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

One other note about the tmpdir-gcc.dg-struct-layout-1 failures. I wonder if they could be another manifestation of the latent bug in float to integer conversion which I described in http://gcc.gnu.org/ml/gcc/2006-08/msg00500.html? Jack

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jakub, Okay. I managed to get the testcase built but -DDBG at -m64 by just changing the ifdef for DBDG to an ifndef in the header. The results on Darwin PPC are as follows... fail 94.72 FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute ...which in testsuite/

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jakub, I don't believe I'm using ALT_CC_UNDER_TEST or ALT_CC_UNDER_TEST. However I do have to explicitly pass -m64 so that I test that compile flag at the same time I pass -DDBG. I haven't been able to puzzle out an invocation of make check that does that. If I use... make -k check-gcc RUNTESTF

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

On Tue, Sep 12, 2006 at 12:32:35AM -0400, Jack Howarth wrote: > On Darwin PPC at -m64, we are seeing a slew of failures > in the tmpdir-gcc.dg-struct-layout-1 tests... > > FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layou