Re: Debugging the tree object constructed by cp_parser

[Stan Srednyak via Gcc]

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 ASTs ( or parts that
correspond to translation units, or something smaller) stored as they are
constructed by the parser.

thanks,
sincerely yours,
Stan

On Mon, Dec 4, 2023 at 10:46 AM David Malcolm  wrote:

> 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?
>
> You could try putting a breakpoint on "make_node", and then
> conditionalizing it so it only fires when code ==
> TRANSLATION_UNIT_DECL:
>
> (gdb) break make_node
> Breakpoint 5 at 0x1675250: file ../../src/gcc/tree.cc, line 1188.
>
> (gdb) cond 5 code==TRANSLATION_UNIT_DECL
>
> (gdb) run
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
>
> [...snip...]
>
> Breakpoint 5, make_node (code=TRANSLATION_UNIT_DECL) at
> ../../src/gcc/tree.cc:1188
> 1188{
>
> (gdb) bt
> #0  make_node (code=TRANSLATION_UNIT_DECL) at
> ../../src/gcc/tree.cc:1188
> #1  0x01675aae in build_decl (loc=0,
> code=TRANSLATION_UNIT_DECL, name= /tmp/t.c>, type=)
> at ../../src/gcc/tree.cc:5379
> #2  0x0169644c in build_translation_unit_decl (name= out>) at ../../src/gcc/tree.cc:5432
> #3  0x00b1e181 in cxx_init_decl_processing () at
> ../../src/gcc/tree.h:3749
> #4  0x00b6b904 in cxx_init () at ../../src/gcc/cp/lex.cc:336
> #5  0x00a4e23a in lang_dependent_init (name=0x34bd820
> "/tmp/t.c") at ../../src/gcc/toplev.cc:1838
> #6  do_compile () at ../../src/gcc/toplev.cc:2136
> #7  toplev::main (this=this@entry=0x7fffdd6e, argc=,
> argc@entry=22, argv=, argv@entry=0x7fffde78)
> at ../../src/gcc/toplev.cc:2307
> #8  0x00a502f5 in main (argc=22, argv=0x7fffde78) at
> ../../src/gcc/main.cc:39
>
>
> Dave
>
> >
> > I looked into GCC internals docs. The section on the front  end (sec
> > 5) is
> > wonderfully concise, of course, but it does not answer this question.
> > Do
> > you know any sources where this is documented?
> >
> > best regards,
> > Stan
> >
> > On Sun, Dec 3, 2023 at 1:00 PM David Malcolm 
> > wrote:
> >
> > > 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 object
> > > > that
> > > > corresponds to the translation unit being parsed. There is no
> > > > such
> > > > field in
> > > > cp_parser, and in the few tiers of functions calls starting from
> > > > parse_file() function that I followed so far, 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 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
> > > > 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
> > >
> > >
>
>

Re: Debugging the tree object constructed by cp_parser

[David Malcolm via Gcc]

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?

You could try putting a breakpoint on "make_node", and then
conditionalizing it so it only fires when code ==
TRANSLATION_UNIT_DECL:

(gdb) break make_node
Breakpoint 5 at 0x1675250: file ../../src/gcc/tree.cc, line 1188.

(gdb) cond 5 code==TRANSLATION_UNIT_DECL

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

[...snip...]

Breakpoint 5, make_node (code=TRANSLATION_UNIT_DECL) at
../../src/gcc/tree.cc:1188
1188{

(gdb) bt
#0  make_node (code=TRANSLATION_UNIT_DECL) at
../../src/gcc/tree.cc:1188
#1  0x01675aae in build_decl (loc=0,
code=TRANSLATION_UNIT_DECL, name=, type=)
at ../../src/gcc/tree.cc:5379
#2  0x0169644c in build_translation_unit_decl (name=) at ../../src/gcc/tree.cc:5432
#3  0x00b1e181 in cxx_init_decl_processing () at
../../src/gcc/tree.h:3749
#4  0x00b6b904 in cxx_init () at ../../src/gcc/cp/lex.cc:336
#5  0x00a4e23a in lang_dependent_init (name=0x34bd820
"/tmp/t.c") at ../../src/gcc/toplev.cc:1838
#6  do_compile () at ../../src/gcc/toplev.cc:2136
#7  toplev::main (this=this@entry=0x7fffdd6e, argc=,
argc@entry=22, argv=, argv@entry=0x7fffde78)
at ../../src/gcc/toplev.cc:2307
#8  0x00a502f5 in main (argc=22, argv=0x7fffde78) at
../../src/gcc/main.cc:39


Dave

> 
> I looked into GCC internals docs. The section on the front  end (sec
> 5) is
> wonderfully concise, of course, but it does not answer this question.
> Do
> you know any sources where this is documented?
> 
> best regards,
> Stan
> 
> On Sun, Dec 3, 2023 at 1:00 PM David Malcolm 
> wrote:
> 
> > 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 object
> > > that
> > > corresponds to the translation unit being parsed. There is no
> > > such
> > > field in
> > > cp_parser, and in the few tiers of functions calls starting from
> > > parse_file() function that I followed so far, 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 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
> > > 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
> > 
> > 

Re: Debugging the tree object constructed by cp_parser

[Stan Srednyak via Gcc]

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 (sec 5) is
wonderfully concise, of course, but it does not answer this question. Do
you know any sources where this is documented?

best regards,
Stan

On Sun, Dec 3, 2023 at 1:00 PM David Malcolm  wrote:

> 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 object that
> > corresponds to the translation unit being parsed. There is no such
> > field in
> > cp_parser, and in the few tiers of functions calls starting from
> > parse_file() function that I followed so far, 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 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
> > 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
>
>

Re: Debugging the tree object constructed by cp_parser

[David Malcolm via Gcc]

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 object that
> corresponds to the translation unit being parsed. There is no such
> field in
> cp_parser, and in the few tiers of functions calls starting from
> parse_file() function that I followed so far, 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 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
> 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

[Stan Srednyak via Gcc]

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 field in
cp_parser, and in the few tiers of functions calls starting from
parse_file() function that I followed so far, 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 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
to be addressed there.

Thanks in advance,
sincerely yours,

Stan Srednyak

Re: Debugging C++ frontend using CLion IDE

[Tim Lange]

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/Editors that support displaying this identation 
style are GNOME Builder (but that doesn't support the way gcc is 
built), Eclipse, VS Code (since Dec 22) and vim/emacs of course.
For VS Code, you need to apply 'unexpand' to the source files as it 
does not support converting 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, i.e. replacing "-wrapper gdb" with "-wrapper 
gdbserver,localhost:2345". Then you can connect your IDE to that 
gdbserver and fully use the IDE interface to debug. You can configure 
running gcc with a gdbserver as a pre-task to automate this.


- Tim

PS: When I tried CLion last year, I neither could get the build system 
working nor the indentation. So you might want to look at one of the 
other IDEs but I don't if something changed in the time.


On Mi, Mär 1 2023 at 20:59:17 +0300, Berke Yavas via Gcc 
 wrote:

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 regards,
Berke

Re: Debugging C++ frontend using CLion IDE

[Paul Smith]

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) not free (by either definition), and (b) requires
projects to use CMake (at least it did last time I checked), it's
highly unlikely you'll find too many GNU projects that have any
information about how to configure it.

I'm not sure what IDEs other devs use: probably vim or Emacs mostly.

Re: Debugging C++ frontend using CLion IDE

[Charalampos Mitrodimas via Gcc]

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 me?

It might be best to proceed with something that is already documented by
the GCC GNU team. The best way for you to learn how to step through the
code is in the documentation.

See: https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html


Thanks,

Charalampos

>
> Best regards,
> Berke

Re: Debugging C++ frontend using CLion IDE

[Charalampos Mitrodimas via Gcc]

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 me?


It might be best to proceed with something that is already documented by 
the GCC GNU team. The best way for you to learn how to step through the 
code is in the documentation.


See: https://gcc-newbies-guide.readthedocs.io/en/latest/debugging.html


Thanks,

Charalampos



Best regards,
Berke

Debugging C++ frontend using CLion IDE

[Berke Yavas via Gcc]

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 regards,
Berke

Re: fanalyzer: debugging zero state machine

[David Malcolm via Gcc]

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:42 +0200, Tim Lange wrote:
> > >   > >
> > >   > > Hi Dave,
> > 
> > Hi Tim; various responses inline below...
> > 
> > >   > >
> > >   > > I did spent some time to think about the zero state machine.
> > > I
> > >  first
> > >   > > thought about distinguishing between "assigned zero" and "EQ
> > > 0
> > >   > > condition on the path" for cases where e.g. unreachable() is
> > >  used
> > >  to
> > >   > > say that some variable will never be zero according to the
> > >  programmer.
> > >   > > In that case the dev might not want zero warnings from
> > >  conditions
> > >   > > outside the if body itself for dev build where unreachable
> > >  expands
> > >  to
> > >   > > some panic exit. But as the condition constraint is not
> > > pruned
> > >  when the
> > >   > > state machine is distinguishing the states, I'm not sure how
> > > to
> > >  know
> > >   > > whether the analysis already left the if body?
> > >   >
> > >   > The analyzer works on the gimple-ssa representation, which uses
> > >  basic
> > >   > blocks in a CFG, rather than an AST, so the only remants we
> > > have
> > >  of
> > >   > scope is in "clobber" statements (a special kind of assignment
> > >  stmt),
> > >   > which the gimplify adds as variables go out of scope.
> > >  If the constraints only lived until the immediate dominator of `if
> > >  (cond)`, I could easily distinguish:
> > >  1. if (x == 0) && still inside the if => zero
> > >  2. if (x == 0) && outside if => maybe zero
> > >  but as this seems to be not the case, if I want to distinguish 1.
> > > &
> > >  2.,
> > >  I'd have to find another way.
> > >   >
> > >   > For pruning, the analyzer's state_machine class has a
> > >  "can_purge_p"
> > >   > virtual function:
> > >   >
> > >   > /* Return true if it safe to discard the given state (to help
> > >   > when simplifying state objects).
> > >   > States that need leak detection should return false. */
> > >   > virtual bool can_purge_p (state_t s) const = 0;
> > >   >
> > >   > which should return true for a "zeroness" state machine, in
> > > that
> > >  we
> > >   > always consider pruning states for svalues that aren't needed
> > >  anymore
> > >   > along a path.
> > >  Is implemented and returns true.
> > >   >
> > >   > Is there some other kind of state explosion you're running
> > > into?
> > >  It's
> > >   > hard to figure this out further without seeing code.
> > >  No, my code is by far not that mature to be tested. I just had in
> > > my
> > >  head that I wanted to find out if I can distinguish the two cases.
> > >   >
> > >   >
> > >   > > Also, while trying out different things, it seems simple
> > >  assignments on
> > >   > > phi like here
> > >   > > int x;
> > >   > > if (argc == 1) {
> > >   > > x = 1; // x_5
> > >   > > } else {
> > >   > > x = 0; // x_4
> > >   > > }
> > >   > > printf("%i", 5 / x); // x_2
> > >   > > automatically work such that x_2 already inherits the state
> > > from
> > >   > > x_4/x_5 without me doing anything inside my sm's on_phi
> > >  function.
> > >  Same
> > >   > > for the simple y = 0; x = y; case. Where does this happen 
> > > inside
> > >  the
> > >   > > code?
> > >   >
> > >   > With the caveat that I'm seeing your code, what's probably
> > >  happening
> > >  is
> > >   > that we have either:
> > >   >
> > >   > BB (a):
> > >   > x_5 = 1;
> > >   > goto BB (c);
> > >   >
> > >   > BB (b):
> > >   > x_4 = 0;
> > >   > goto BB (c);
> > >   >
> > >   > BB (c):
> > >   > x_2 = PHI (x_5 from (a), x_4 from (b));
> > >  I compiled it with -g, so this one is like the dumped gimple.
> > >   >
> > >   > or (at higher optimization levels):
> > >   >
> > >   > BB (a):
> > >   > goto BB (c);
> > >   >
> > >   > BB (b):
> > >   > goto BB (c);
> > >   >
> > >   > BB (c):
> > >   > x_2 = PHI (1 from (a), 0 from (b));
> > >   >
> > >   > and I think that at the phi node we have 
> > > region_model::handle_phi,
> > >   > which is setting x_2 to either the constant 1 or the constant 0
> > > in
> > >  the
> > >   > store, and is calling the on_phi vfunc, leading to on_phi being
> > >  called
> > >   > for all state machines.
> > >  Thanks, that is the case. The set_value inside handle_phi seems to
> > >  this
> > >  for me.
> > >   >
> > >   > BTW, are you implementing an override for this vfunc:
> > >   > virtual state_machine::state_t get_default_state (const svalue
> > > *)
> > >   > const;
> > >   >
> > >   > to capture the inherently known zeroness/nonzeroness of
> > >  constant_svalue
> > >   > instances? That would make those constants have that state.
> > >  Yeah, I saw that on your nullness check. I tried it on a small
> > >  example
> > >  with and without, but didn't noticed a di

Re: fanalyzer: debugging zero state machine

[Tim Lange]

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 below...


  > >
  > > I did spent some time to think about the zero state machine. I
 first
  > > thought about distinguishing between "assigned zero" and "EQ 0
  > > condition on the path" for cases where e.g. unreachable() is
 used
 to
  > > say that some variable will never be zero according to the
 programmer.
  > > In that case the dev might not want zero warnings from
 conditions
  > > outside the if body itself for dev build where unreachable
 expands
 to
  > > some panic exit. But as the condition constraint is not pruned
 when the
  > > state machine is distinguishing the states, I'm not sure how to
 know
  > > whether the analysis already left the if body?
  >
  > The analyzer works on the gimple-ssa representation, which uses
 basic
  > blocks in a CFG, rather than an AST, so the only remants we have
 of
  > scope is in "clobber" statements (a special kind of assignment
 stmt),
  > which the gimplify adds as variables go out of scope.
 If the constraints only lived until the immediate dominator of `if
 (cond)`, I could easily distinguish:
 1. if (x == 0) && still inside the if => zero
 2. if (x == 0) && outside if => maybe zero
 but as this seems to be not the case, if I want to distinguish 1. &
 2.,
 I'd have to find another way.
  >
  > For pruning, the analyzer's state_machine class has a
 "can_purge_p"
  > virtual function:
  >
  > /* Return true if it safe to discard the given state (to help
  > when simplifying state objects).
  > States that need leak detection should return false. */
  > virtual bool can_purge_p (state_t s) const = 0;
  >
  > which should return true for a "zeroness" state machine, in that
 we
  > always consider pruning states for svalues that aren't needed
 anymore
  > along a path.
 Is implemented and returns true.
  >
  > Is there some other kind of state explosion you're running into?
 It's
  > hard to figure this out further without seeing code.
 No, my code is by far not that mature to be tested. I just had in my
 head that I wanted to find out if I can distinguish the two cases.
  >
  >
  > > Also, while trying out different things, it seems simple
 assignments on
  > > phi like here
  > > int x;
  > > if (argc == 1) {
  > > x = 1; // x_5
  > > } else {
  > > x = 0; // x_4
  > > }
  > > printf("%i", 5 / x); // x_2
  > > automatically work such that x_2 already inherits the state 
from

  > > x_4/x_5 without me doing anything inside my sm's on_phi
 function.
 Same
  > > for the simple y = 0; x = y; case. Where does this happen 
inside

 the
  > > code?
  >
  > With the caveat that I'm seeing your code, what's probably
 happening
 is
  > that we have either:
  >
  > BB (a):
  > x_5 = 1;
  > goto BB (c);
  >
  > BB (b):
  > x_4 = 0;
  > goto BB (c);
  >
  > BB (c):
  > x_2 = PHI (x_5 from (a), x_4 from (b));
 I compiled it with -g, so this one is like the dumped gimple.
  >
  > or (at higher optimization levels):
  >
  > BB (a):
  > goto BB (c);
  >
  > BB (b):
  > goto BB (c);
  >
  > BB (c):
  > x_2 = PHI (1 from (a), 0 from (b));
  >
  > and I think that at the phi node we have 
region_model::handle_phi,
  > which is setting x_2 to either the constant 1 or the constant 0 
in

 the
  > store, and is calling the on_phi vfunc, leading to on_phi being
 called
  > for all state machines.
 Thanks, that is the case. The set_value inside handle_phi seems to
 this
 for me.
  >
  > BTW, are you implementing an override for this vfunc:
  > virtual state_machine::state_t get_default_state (const svalue *)
  > const;
  >
  > to capture the inherently known zeroness/nonzeroness of
 constant_svalue
  > instances? That would make those constants have that state.
 Yeah, I saw that on your nullness check. I tried it on a small
 example
 with and without, but didn't noticed a difference in warnings 
(except

 for not having zero(x_4) inside the supergraph.dot). So if I
 understood
 this right, this is just to have one state less for that
 variable/value[0]?


The states are stored in sm_state_map using a mapping from svalue to
state.

Given e.g. a parameter, this will be "initial_svalue (parm)", but in
the above case where x_4 either has value 1 or has value 0, it's not
storing a state for x_4; it's storing a state for 0 or a state for 1.
So without implementing the get_default_state vfunc, the sm_state_maps
will gradually aquire explicit "this is zero" or "this is nonzero" for
all of the constants that get used, leading to an explosion of states
for all the different combinations of constants that have been
encountered along an execution path, which is probably not going to be
useful.  If you do implement the get_default_state vfunc for 
constants,
then the constants will implicitly have 

Re: fanalyzer: debugging zero state machine

[David Malcolm via Gcc]

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 the zero state machine. I 
> first
>  > > thought about distinguishing between "assigned zero" and "EQ 0
>  > > condition on the path" for cases where e.g. unreachable() is
> used 
> to
>  > > say that some variable will never be zero according to the 
> programmer.
>  > > In that case the dev might not want zero warnings from
> conditions
>  > > outside the if body itself for dev build where unreachable
> expands 
> to
>  > > some panic exit. But as the condition constraint is not pruned 
> when the
>  > > state machine is distinguishing the states, I'm not sure how to 
> know
>  > > whether the analysis already left the if body?
>  >
>  > The analyzer works on the gimple-ssa representation, which uses
> basic
>  > blocks in a CFG, rather than an AST, so the only remants we have
> of
>  > scope is in "clobber" statements (a special kind of assignment
> stmt),
>  > which the gimplify adds as variables go out of scope.
> If the constraints only lived until the immediate dominator of `if 
> (cond)`, I could easily distinguish:
> 1. if (x == 0) && still inside the if => zero
> 2. if (x == 0) && outside if => maybe zero
> but as this seems to be not the case, if I want to distinguish 1. &
> 2., 
> I'd have to find another way.
>  >
>  > For pruning, the analyzer's state_machine class has a
> "can_purge_p"
>  > virtual function:
>  >
>  > /* Return true if it safe to discard the given state (to help
>  > when simplifying state objects).
>  > States that need leak detection should return false. */
>  > virtual bool can_purge_p (state_t s) const = 0;
>  >
>  > which should return true for a "zeroness" state machine, in that
> we
>  > always consider pruning states for svalues that aren't needed
> anymore
>  > along a path.
> Is implemented and returns true.
>  >
>  > Is there some other kind of state explosion you're running into?
> It's
>  > hard to figure this out further without seeing code.
> No, my code is by far not that mature to be tested. I just had in my 
> head that I wanted to find out if I can distinguish the two cases.
>  >
>  >
>  > > Also, while trying out different things, it seems simple 
> assignments on
>  > > phi like here
>  > > int x;
>  > > if (argc == 1) {
>  > > x = 1; // x_5
>  > > } else {
>  > > x = 0; // x_4
>  > > }
>  > > printf("%i", 5 / x); // x_2
>  > > automatically work such that x_2 already inherits the state from
>  > > x_4/x_5 without me doing anything inside my sm's on_phi
> function. 
> Same
>  > > for the simple y = 0; x = y; case. Where does this happen inside
> the
>  > > code?
>  >
>  > With the caveat that I'm seeing your code, what's probably
> happening 
> is
>  > that we have either:
>  >
>  > BB (a):
>  > x_5 = 1;
>  > goto BB (c);
>  >
>  > BB (b):
>  > x_4 = 0;
>  > goto BB (c);
>  >
>  > BB (c):
>  > x_2 = PHI (x_5 from (a), x_4 from (b));
> I compiled it with -g, so this one is like the dumped gimple.
>  >
>  > or (at higher optimization levels):
>  >
>  > BB (a):
>  > goto BB (c);
>  >
>  > BB (b):
>  > goto BB (c);
>  >
>  > BB (c):
>  > x_2 = PHI (1 from (a), 0 from (b));
>  >
>  > and I think that at the phi node we have region_model::handle_phi,
>  > which is setting x_2 to either the constant 1 or the constant 0 in
> the
>  > store, and is calling the on_phi vfunc, leading to on_phi being 
> called
>  > for all state machines.
> Thanks, that is the case. The set_value inside handle_phi seems to
> this 
> for me.
>  >
>  > BTW, are you implementing an override for this vfunc:
>  > virtual state_machine::state_t get_default_state (const svalue *)
>  > const;
>  >
>  > to capture the inherently known zeroness/nonzeroness of 
> constant_svalue
>  > instances? That would make those constants have that state.
> Yeah, I saw that on your nullness check. I tried it on a small
> example 
> with and without, but didn't noticed a difference in warnings (except
> for not having zero(x_4) inside the supergraph.dot). So if I
> understood 
> this right, this is just to have one state less for that 
> variable/value[0]?

The states are stored in sm_state_map using a mapping from svalue to
state.

Given e.g. a parameter, this will be "initial_svalue (parm)", but in
the above case where x_4 either has value 1 or has value 0, it's not
storing a state for x_4; it's storing a state for 0 or a state for 1. 
So without implementing the get_default_state vfunc, the sm_state_maps
will gradually aquire explicit "this is zero" or "this is nonzero" for
all of the constants that get used, leading to an explosion of states
for all the different combinations of constants that have been
encountered along an execution path, which is probably not going to be
useful.  If you do implement the get

fanalyzer: debugging zero state machine

[Tim Lange]

> 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 on the path" for cases where e.g. unreachable() is used 
to
> > say that some variable will never be zero according to the 
programmer.

> > In that case the dev might not want zero warnings from conditions
> > outside the if body itself for dev build where unreachable expands 
to
> > some panic exit. But as the condition constraint is not pruned 
when the
> > state machine is distinguishing the states, I'm not sure how to 
know

> > whether the analysis already left the if body?
>
> The analyzer works on the gimple-ssa representation, which uses basic
> blocks in a CFG, rather than an AST, so the only remants we have of
> scope is in "clobber" statements (a special kind of assignment stmt),
> which the gimplify adds as variables go out of scope.
If the constraints only lived until the immediate dominator of `if 
(cond)`, I could easily distinguish:

1. if (x == 0) && still inside the if => zero
2. if (x == 0) && outside if => maybe zero
but as this seems to be not the case, if I want to distinguish 1. & 2., 
I'd have to find another way.

>
> For pruning, the analyzer's state_machine class has a "can_purge_p"
> virtual function:
>
> /* Return true if it safe to discard the given state (to help
> when simplifying state objects).
> States that need leak detection should return false. */
> virtual bool can_purge_p (state_t s) const = 0;
>
> which should return true for a "zeroness" state machine, in that we
> always consider pruning states for svalues that aren't needed anymore
> along a path.
Is implemented and returns true.
>
> Is there some other kind of state explosion you're running into? It's
> hard to figure this out further without seeing code.
No, my code is by far not that mature to be tested. I just had in my 
head that I wanted to find out if I can distinguish the two cases.

>
>
> > Also, while trying out different things, it seems simple 
assignments on

> > phi like here
> > int x;
> > if (argc == 1) {
> > x = 1; // x_5
> > } else {
> > x = 0; // x_4
> > }
> > printf("%i", 5 / x); // x_2
> > automatically work such that x_2 already inherits the state from
> > x_4/x_5 without me doing anything inside my sm's on_phi function. 
Same
> > for the simple y = 0; x = y; case. Where does this happen inside 
the

> > code?
>
> With the caveat that I'm seeing your code, what's probably happening 
is

> that we have either:
>
> BB (a):
> x_5 = 1;
> goto BB (c);
>
> BB (b):
> x_4 = 0;
> goto BB (c);
>
> BB (c):
> x_2 = PHI (x_5 from (a), x_4 from (b));
I compiled it with -g, so this one is like the dumped gimple.
>
> or (at higher optimization levels):
>
> BB (a):
> goto BB (c);
>
> BB (b):
> goto BB (c);
>
> BB (c):
> x_2 = PHI (1 from (a), 0 from (b));
>
> and I think that at the phi node we have region_model::handle_phi,
> which is setting x_2 to either the constant 1 or the constant 0 in 
the
> store, and is calling the on_phi vfunc, leading to on_phi being 
called

> for all state machines.
Thanks, that is the case. The set_value inside handle_phi seems to this 
for me.

>
> BTW, are you implementing an override for this vfunc:
> virtual state_machine::state_t get_default_state (const svalue *)
> const;
>
> to capture the inherently known zeroness/nonzeroness of 
constant_svalue

> instances? That would make those constants have that state.
Yeah, I saw that on your nullness check. I tried it on a small example 
with and without, but didn't noticed a difference in warnings (except 
for not having zero(x_4) inside the supergraph.dot). So if I understood 
this right, this is just to have one state less for that 
variable/value[0]?


If that is right, is it also favorable to "merge" the stop state and 
non_zero state inside the zero state machine because - for now - there 
is no warning planned on non-zero values?


[0] less states are favorable because then the analyzer maybe has less 
different enodes to visit and thus less runtime(?)

>
> Thanks
> Dave
>
> > - Tim

Also another question unrelated to the ones before. I do have a weird 
bug in my zero sm[1] but I'm unsure where my sm is flawed. Take for 
example, the probably simplest case:

 int x = 0;h
 printf("%d", 42 / x);
If I use inform to emit a notice for my state machine result, it seems 
to be correct and I do get following traversal order (by printing the 
gimple stmt inside on_stmt):

 x_2 = 0;
 _1 = 42 % x_2;
 # .MEM_4 = VDEF <.MEM_3(D)>
 printf ("%d", _1);
 _5 = 0;
 :
 # VUSE <.MEM_4>
 return _5;
But if i use my zero_diagnostics and sm_ctxt->warn to emit the warning, 
I get an unexpected traversal order of:

 x_2 = 0;
 _1 = 42 / x_2;
 # .MEM_4 = VDEF <.MEM_3(D)>
 printf ("%d", _1);
 _5 = 0;
 :
 # VUSE <.MEM_4>
 return _5;
 x_2 = 0; 		<-- why do I 

Re: A simple debugging question

[Gary Oblock via Gcc]

Richard,

Opps! I see my problem. I changed directory into
x264 and not mcf!

I need to stop working so late

Thank you for your input because led me to question
my assumptions about what was going on.

Gary


From: Richard Biener 
Sent: Wednesday, July 14, 2021 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 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/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto1
>  -quiet -dumpdir ./mcf_r.lto.o- -dumpbase mcf_r.lto.o -dumpbase-ext .o -m64 
> -mtune=generic -march=x86-64 -O3 -O3 -Wdfa -version -fno-openmp -fno-openacc 
> -fno-pie -fcf-protection=none -fcommon -fdump-ipa-type-escape-analysis 
> -fdump-ipa-field-reorder -funroll-loops -flto-partition=none 
> -fipa-instance-interleave -fdump-ipa-all-details -fno-ipa-icf 
> -fipa-type-escape-analysis -fipa-field-reorder -fresolution=mcf_r.res 
> -flinker-output=exec --param=early-inlining-insns=96 
> --param=max-inline-insns-auto=64 --param=inline-unit-growth=96 
> @./mcf_r.lto.o-args.0 -o ./mcf_r.lto.o-mcf_r.lto.s
>
> I bring up emacs and go into gdb.
>
> I set it to debug the lto1 path above.
>
> I cd to the build area:
> cd 
> gary@SCC-PC0TYGP5:~/spec/cpu2017/benchspec/CPU/525.x264_r/build/build_base_gcc11_rate_ampere-64.
>
> I set my beakpoint:
> break tree-ssa-sccvn.c:5975
>
> I give the breakpoint a condition (yes I instrumented the code just to do 
> this):
> cond 1 (count == 5326)
>
> Finally, I run lto1 with the long list of arguments above.
>
> It runs a tiny bit and gives me:
> lto1: fatal error: could not open symbol resolution file: No such file or 
> directory
>
> This is a new one for me guys and I've used this approach above
> many times (but not on a SPEC build.) Any hints at what I did
> wrong?

You have to preserve temporary files (the symbol resolution file) with
-save-temps and if you did
the lto1 invocation will have to happen from the directory that file resides in
(-fresolution=mcf_r.res), otherwise lto1 won't find it.

> Note, during development I always build gcc with "-O0 -g".
>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: A simple debugging question

[Richard Biener via Gcc]

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/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto1
>  -quiet -dumpdir ./mcf_r.lto.o- -dumpbase mcf_r.lto.o -dumpbase-ext .o -m64 
> -mtune=generic -march=x86-64 -O3 -O3 -Wdfa -version -fno-openmp -fno-openacc 
> -fno-pie -fcf-protection=none -fcommon -fdump-ipa-type-escape-analysis 
> -fdump-ipa-field-reorder -funroll-loops -flto-partition=none 
> -fipa-instance-interleave -fdump-ipa-all-details -fno-ipa-icf 
> -fipa-type-escape-analysis -fipa-field-reorder -fresolution=mcf_r.res 
> -flinker-output=exec --param=early-inlining-insns=96 
> --param=max-inline-insns-auto=64 --param=inline-unit-growth=96 
> @./mcf_r.lto.o-args.0 -o ./mcf_r.lto.o-mcf_r.lto.s
>
> I bring up emacs and go into gdb.
>
> I set it to debug the lto1 path above.
>
> I cd to the build area:
> cd 
> gary@SCC-PC0TYGP5:~/spec/cpu2017/benchspec/CPU/525.x264_r/build/build_base_gcc11_rate_ampere-64.
>
> I set my beakpoint:
> break tree-ssa-sccvn.c:5975
>
> I give the breakpoint a condition (yes I instrumented the code just to do 
> this):
> cond 1 (count == 5326)
>
> Finally, I run lto1 with the long list of arguments above.
>
> It runs a tiny bit and gives me:
> lto1: fatal error: could not open symbol resolution file: No such file or 
> directory
>
> This is a new one for me guys and I've used this approach above
> many times (but not on a SPEC build.) Any hints at what I did
> wrong?

You have to preserve temporary files (the symbol resolution file) with
-save-temps and if you did
the lto1 invocation will have to happen from the directory that file resides in
(-fresolution=mcf_r.res), otherwise lto1 won't find it.

> Note, during development I always build gcc with "-O0 -g".
>
> Thanks,
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

A simple debugging question

[Gary Oblock via Gcc]

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- -dumpbase mcf_r.lto.o -dumpbase-ext .o -m64 
-mtune=generic -march=x86-64 -O3 -O3 -Wdfa -version -fno-openmp -fno-openacc 
-fno-pie -fcf-protection=none -fcommon -fdump-ipa-type-escape-analysis 
-fdump-ipa-field-reorder -funroll-loops -flto-partition=none 
-fipa-instance-interleave -fdump-ipa-all-details -fno-ipa-icf 
-fipa-type-escape-analysis -fipa-field-reorder -fresolution=mcf_r.res 
-flinker-output=exec --param=early-inlining-insns=96 
--param=max-inline-insns-auto=64 --param=inline-unit-growth=96 
@./mcf_r.lto.o-args.0 -o ./mcf_r.lto.o-mcf_r.lto.s

I bring up emacs and go into gdb.

I set it to debug the lto1 path above.

I cd to the build area:
cd 
gary@SCC-PC0TYGP5:~/spec/cpu2017/benchspec/CPU/525.x264_r/build/build_base_gcc11_rate_ampere-64.

I set my beakpoint:
break tree-ssa-sccvn.c:5975

I give the breakpoint a condition (yes I instrumented the code just to do this):
cond 1 (count == 5326)

Finally, I run lto1 with the long list of arguments above.

It runs a tiny bit and gives me:
lto1: fatal error: could not open symbol resolution file: No such file or 
directory

This is a new one for me guys and I've used this approach above
many times (but not on a SPEC build.) Any hints at what I did
wrong?

Note, during development I always build gcc with "-O0 -g".

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.

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]

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)
   0x103d60005 <+1509>: shlb   %cl, 0x2e(%rsi)

Does GCC ever generate this last instruction (a variable shift of a
byte in memory!)? Even the next to last (register to memory) is only
generated infrequently.

I submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152

You may be correct, but it appears that the “offending" instruction is

->  0x103d60010 <+1520>: movl   (%rbp,%r10,4), %esi

Brad

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

[Gabriel Paubert]

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 specs.
> COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper
> Target: x86_64-apple-darwin19.6.0
> Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 
> --enable-languages=c --disable-multilib --enable-checking=release 
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.3.0 (GCC) 
> 
> This is the crash report from the console:
> 
> Exception Type:EXC_BAD_INSTRUCTION (SIGILL)
> Exception Codes:   0x000c, 0x
> Exception Note:EXC_CORPSE_NOTIFY
> 
> Termination Signal:Illegal instruction: 4
> Termination Reason:Namespace SIGNAL, Code 0x4
> Terminating Process:   exc handler [98080]
> 
> Application Specific Information:
> dyld2 mode
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libgambit.dylib   0x00010dfaf010 
> ___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280)
> 
> This is the disassembled code (arrow points to crash point):
> 
> (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)
> 0x103d60005 <+1509>: shlb   %cl, 0x2e(%rsi)

Does GCC ever generate this last instruction (a variable shift of a
byte in memory!)? Even the next to last (register to memory) is only
generated infrequently.

First thing to do would be to start the disassembly earlier, or even at
the beginning of the function, because I believe that the address you
gave is not an instruction boundary, and in this case the output of the
disassembler is nonsense until it resynchronizes on a real boundary.

Regards,
Gabriel


> 0x103d60008 <+1512>: nopl   (%rax,%rax)
> ->  0x103d60010 <+1520>: movl   (%rbp,%r10,4), %esi
> 0x103d60015 <+1525>: callq  0x103fba9a0   ; symbol stub for: 
> ___UTF_8_put
> 0x103d6001a <+1530>: movq   %r10, %rax
> 0x103d6001d <+1533>: addq   $0x1, %r10
> 0x103d60021 <+1537>: cmpq   %r12, %rax
> 0x103d60024 <+1540>: jne0x103d60010   ; <+1520> at 
> c_intf.c:3280:173
> 
> I don’t know why that particular instruction is “Illegal”.
> 
> Can someone suggest a way forward?
> 
> Thanks.
> 
> Brad

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

[Iain Sandoe via Gcc]

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
COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper
Target: x86_64-apple-darwin19.6.0
Configured with: ../../gcc-10.3.0/configure  
--prefix=/usr/local/gcc-10.3.0 --enable-languages=c --disable-multilib  
--enable-checking=release  
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC)




Can someone suggest a way forward?


Please could you raise a PR (Bugzilla) -  
(https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc)

..  the information here is enough to start
  - but it would help to know what you were compiling when this occurred ..
 adding ‘-save-temps’ to the compile line and adding the .i file to the BZ can 
be helfpul.

.. I think this will take a little analysis (and isn’t something I've seen  
in testing on either i7 or xeon w hardware).


thanks
Iain

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]

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/libexec/gcc/x86_64-apple-darwin19.6.0/10.3.0/lto-wrapper
Target: x86_64-apple-darwin19.6.0
Configured with: ../../gcc-10.3.0/configure --prefix=/usr/local/gcc-10.3.0 
--enable-languages=c --disable-multilib --enable-checking=release 
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC) 

This is the crash report from the console:

Exception Type:EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:   0x000c, 0x
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Illegal instruction: 4
Termination Reason:Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [98080]

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libgambit.dylib 0x00010dfaf010 
___SCMOBJ_to_NONNULLSTRING + 1520 (c_intf.c:3280)

This is the disassembled code (arrow points to crash point):

(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)
0x103d60005 <+1509>: shlb   %cl, 0x2e(%rsi)
0x103d60008 <+1512>: nopl   (%rax,%rax)
->  0x103d60010 <+1520>: movl   (%rbp,%r10,4), %esi
0x103d60015 <+1525>: callq  0x103fba9a0   ; symbol stub for: 
___UTF_8_put
0x103d6001a <+1530>: movq   %r10, %rax
0x103d6001d <+1533>: addq   $0x1, %r10
0x103d60021 <+1537>: cmpq   %r12, %rax
0x103d60024 <+1540>: jne0x103d60010   ; <+1520> at 
c_intf.c:3280:173

I don’t know why that particular instruction is “Illegal”.

Can someone suggest a way forward?

Thanks.

Brad

[FOSDEM] [CfP] Debugging Tools devroom 2020

[Mark Wielaard]

* 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: Sunday2 Feb 2020

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate.  It is renown for being
highly developer-oriented and brings together 8000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
https://fosdem.org/

FOSDEM 2020 will take place during the weekend of Saturday, February 1
and Sunday February 2 2020.  On Sunday we will have a devroom for
Debugging Tools, jointly organized by the Valgrind, GDB and strace
projects. Devrooms are a place for development teams to meet, discuss,
hack and publicly present the project's latest improvements and future
directions.

We will have a whole day to hang out together as community embracing
debugging tools (valgrind, gdb, strace, etc.), executable and debugging
formats (ELF and DWARF) and debugging interfaces (ptrace, proc, bpf,
seccomp, etc.)

Please join us, regardless of whether you are a core hacker,
a plugin hacker, a user, a packager or a hacker on a project that
integrates, extends or complements debugging tools.

** Call for Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality.  Please do submit a talk proposal by
Sunday December 1st 2020, so we can make a list of activities during
the day.

Some possible topics for talks/discussions are:

- Recently added functional changes.
- Prototypes of new functionality in existing tools.
- Discuss release/bugfixing strategy/policy.
- Connecting debugging tools together.
- Latest DWARF extensions, going from binary back to source.
- Alternative symbol tables and unwinding data structures
  (ctf, btf, orc)
- Multi, multi, multi... threads, processes and targets.
- Debugging anything, everywhere. Dealing with complex systems.
- Dealing with the dynamic loader and the kernel.
- Intercepting and interposing functions and events.
- Adding GDB features, such as designing GDB python scripts for your
  data structures.
- Advances in gdbserver and the GDB remote serial protocol.
- Adding Valgrind features (adding syscalls for a platform or VEX
  instructions for an architecture port).
- Infrastructure changes to the Valgrind JIT framework.
- Use of new linux kernel interfaces (ptrace, proc, BPF).
- Your interesting use case with a debugging tool.

** How to Submit

Please use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have
  already created it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab)
  and Bio ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Debugging Tools devroom" track
  (on the "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the
  intended audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

** Recording of Talks

As usually the FOSDEM organisers plan to have live streaming and
recording fully working, both for remote/later viewing of talks, and
so that people can watch streams in the hallways when rooms are full.
This obviously requires speakers to consent to being recorded and
streamed.  If you plan to be a speaker, please understand that by
doing so you implicitly give consent for your talk to be recorded and
streamed.  The recordings will be published under the same licence as
all FOSDEM content (CC-BY).

** Code of Conduct

In order to keep FOSDEM a fun, interesting and positive experience
for everybody, we expect participants to follow our guidelines:
https://fosdem.org/2020/practical/conduct/

** Important dates

  Talk/Discussion Submission deadline: Sunday1 Dec 2019
  Devroom Schedule announcement:   Sunday   15 Dec 2019
  Devroom day: Sunday2 Feb 2020

Hope to see you all at FOSDEM 2020 in the joint Debugging Tools
devroom. Brussels (Belgium), Sunday February 2 2020.

[FOSDEM] [CfP] Debugging Tools devroom 2020

[Mark Wielaard]

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 event that offers open source communities a
place to meet, share ideas and collaborate.  It is renown for being
highly developer-oriented and brings together 8000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
https://fosdem.org/

FOSDEM 2020 will take place during the weekend of Saturday, February 1
and Sunday February 2 2020.  On Sunday we will have a devroom for
Debugging Tools, jointly organized by the Valgrind, GDB and strace
projects. Devrooms are a place for development teams to meet, discuss,
hack and publicly present the project's latest improvements and future
directions.

We will have a whole day to hang out together as community embracing
debugging tools (valgrind, gdb, strace, etc.), executable and debugging
formats (ELF and DWARF) and debugging interfaces (ptrace, proc, bpf,
seccomp, etc.)

Please join us, regardless of whether you are a core hacker,
a plugin hacker, a user, a packager or a hacker on a project that
integrates, extends or complements debugging tools.

** Call for Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality.  Please do submit a talk proposal by
Sunday December 1st 2020, so we can make a list of activities during
the day.

Some possible topics for talks/discussions are:

- Recently added functional changes.
- Prototypes of new functionality in existing tools.
- Discuss release/bugfixing strategy/policy.
- Connecting debugging tools together.
- Latest DWARF extensions, going from binary back to source.
- Alternative symbol tables and unwinding data structures
  (ctf, btf, orc)
- Multi, multi, multi... threads, processes and targets.
- Debugging anything, everywhere. Dealing with complex systems.
- Dealing with the dynamic loader and the kernel.
- Intercepting and interposing functions and events.
- Adding GDB features, such as designing GDB python scripts for your
  data structures.
- Advances in gdbserver and the GDB remote serial protocol.
- Adding Valgrind features (adding syscalls for a platform or VEX
  instructions for an architecture port).
- Infrastructure changes to the Valgrind JIT framework.
- Use of new linux kernel interfaces (ptrace, proc, BPF).
- Your interesting use case with a debugging tool.

** How to Submit

Please use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have
  already created it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab)
  and Bio ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Debugging Tools devroom" track
  (on the "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the
  intended audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

** Recording of Talks

As usually the FOSDEM organisers plan to have live streaming and
recording fully working, both for remote/later viewing of talks, and
so that people can watch streams in the hallways when rooms are full.
This obviously requires speakers to consent to being recorded and
streamed.  If you plan to be a speaker, please understand that by
doing so you implicitly give consent for your talk to be recorded and
streamed.  The recordings will be published under the same licence as
all FOSDEM content (CC-BY).

** Code of Conduct

In order to keep FOSDEM a fun, interesting and positive experience
for everybody, we expect participants to follow our guidelines:
https://fosdem.org/2020/practical/conduct/

** Important dates

  Talk/Discussion Submission deadline: Sunday1 Dec 2019
  Devroom Schedule announcement:   Sunday   15 Dec 2019
  Devroom day: Sunday2 Feb 2020

Hope to see you all at FOSDEM 2020 in the joint Debugging Tools
devroom. Brussels (Belgium), Sunday February 2 2020.

[FOSDEM] [CfP] Debugging Tools devroom 2020

[Mark Wielaard]

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 event that offers open source communities a
place to meet, share ideas and collaborate.  It is renown for being
highly developer-oriented and brings together 8000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
https://fosdem.org/

FOSDEM 2020 will take place during the weekend of Saturday, February 1
and Sunday February 2 2020.  On Sunday we will have a devroom for
Debugging Tools, jointly organized by the Valgrind, GDB and strace
projects. Devrooms are a place for development teams to meet, discuss,
hack and publicly present the project's latest improvements and future
directions.

We will have a whole day to hang out together as community embracing
debugging tools (valgrind, gdb, strace, etc.), executable and debugging
formats (ELF and DWARF) and debugging interfaces (ptrace, proc, bpf,
seccomp, etc.)

Please join us, regardless of whether you are a core hacker,
a plugin hacker, a user, a packager or a hacker on a project that
integrates, extends or complements debugging tools.

** Call for Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality.  Please do submit a talk proposal by
Sunday December 1st 2020, so we can make a list of activities during
the day.

Some possible topics for talks/discussions are:

- Recently added functional changes.
- Prototypes of new functionality in existing tools.
- Discuss release/bugfixing strategy/policy.
- Connecting debugging tools together.
- Latest DWARF extensions, going from binary back to source.
- Alternative symbol tables and unwinding data structures
  (ctf, btf, orc)
- Multi, multi, multi... threads, processes and targets.
- Debugging anything, everywhere. Dealing with complex systems.
- Dealing with the dynamic loader and the kernel.
- Intercepting and interposing functions and events.
- Adding GDB features, such as designing GDB python scripts for your
  data structures.
- Advances in gdbserver and the GDB remote serial protocol.
- Adding Valgrind features (adding syscalls for a platform or VEX
  instructions for an architecture port).
- Infrastructure changes to the Valgrind JIT framework.
- Use of new linux kernel interfaces (ptrace, proc, BPF).
- Your interesting use case with a debugging tool.

** How to Submit

Please use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have
  already created it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab)
  and Bio ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Debugging Tools devroom" track
  (on the "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the
  intended audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

** Recording of Talks

As usually the FOSDEM organisers plan to have live streaming and
recording fully working, both for remote/later viewing of talks, and
so that people can watch streams in the hallways when rooms are full.
This obviously requires speakers to consent to being recorded and
streamed.  If you plan to be a speaker, please understand that by
doing so you implicitly give consent for your talk to be recorded and
streamed.  The recordings will be published under the same licence as
all FOSDEM content (CC-BY).

** Code of Conduct

In order to keep FOSDEM a fun, interesting and positive experience
for everybody, we expect participants to follow our guidelines:
https://fosdem.org/2020/practical/conduct/

** Important dates

  Talk/Discussion Submission deadline: Sunday1 Dec 2019
  Devroom Schedule announcement:   Sunday   15 Dec 2019
  Devroom day: Sunday3 Feb 2020

Hope to see you all at FOSDEM 2020 in the joint Debugging Tools
devroom. Brussels (Belgium), Sunday February 2 2020.
___
FOSDEM mailing list
fos...@lists.fosdem.org
https://lists.fosdem.org/listinfo/fosdem

Re: debugging libgo failures

[Aldy Hernandez]

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 reproducing say:

FAIL: database/sql
FAIL: net/http

I'm used to scouring
x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining
insight on how to manually run tests.  However, there's nothing in
libgo/testsuite, and libgo/libgo.log just has a summary of tests.

Ideally I'd like a way of building a test (with say -fdump-tree-all),
and/or sticking gdb on the resulting executable.


To run a test, cd to the libgo build directly (TARGET/libgo) and run
`make database/sql/check`.  To see the exact commands that it runs,
including how the compiler is invoked, run `make GOTESTFLAGS=--trace
database/sql/check`.  To leave the directory behind with the test
program, run `make GOTESTFLAGS=--keep database/sql/check`.  That will
leave a gotest/test directory.  In that directory you can run
`LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests.
You can run specific failing tests using a -test.run option.  You can
of course run gdb on the program.

Hope that helps.


Thank you very very much.  This was exactly what I needed.  Bug fixed, 
btw :).


Is this information available somewhere in our docs or wiki?  It'd be 
incredibly useful for others I bet.


Thanks.
Aldy

Re: debugging libgo failures

[Ian Lance Taylor]

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
> FAIL: net/http
>
> I'm used to scouring
> x86_64-pc-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining
> insight on how to manually run tests.  However, there's nothing in
> libgo/testsuite, and libgo/libgo.log just has a summary of tests.
>
> Ideally I'd like a way of building a test (with say -fdump-tree-all),
> and/or sticking gdb on the resulting executable.

To run a test, cd to the libgo build directly (TARGET/libgo) and run
`make database/sql/check`.  To see the exact commands that it runs,
including how the compiler is invoked, run `make GOTESTFLAGS=--trace
database/sql/check`.  To leave the directory behind with the test
program, run `make GOTESTFLAGS=--keep database/sql/check`.  That will
leave a gotest/test directory.  In that directory you can run
`LD_LIBRARY_PATH=../../.libs ./a.out -test.short` to run the tests.
You can run specific failing tests using a -test.run option.  You can
of course run gdb on the program.

Hope that helps.

Ian


> --- FAIL: TestMaxIdleConns (0.00s)
>  sql_test.go:1789: freeConns after set to zero = -1; want 0
>  sql_test.go:1798: freeConns = -1; want 0
> panic: runtime error: makeslice: cap out of range [recovered]
>  panic: runtime error: makeslice: cap out of range
>
> goroutine 202 [running]:
> panic
>  /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:588
> testing.tRunner..func1
>  /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:765
> panic
>  /home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:535
> database..z2fsql.DB.Close
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql.go:768
> sql.closeDB
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:140
> database..z2fsql.TestMaxIdleConns
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:1800
> testing.tRunner
>  /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:827
> created by testing.T.Run
>  /home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:878 +1163
> FAIL: database/sql
>
>
> [snip]
> [snip]
>
> net..z2fhttp.persistConn.writeLoop
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1888
> created by net..z2fhttp.Transport.dialConn
>
> /home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1339
> +2693
>
> eax0x0
> ebx0x2
> ecx0xcbbdd84c
> edx0x0
> edi0x0
> esi0x8
> ebp0xcbbdd84c
> esp0xcbbdd830
> eip0xf7f93049
> eflags 0x286
> cs 0x23
> fs 0x0
> gs 0x63
> FAIL: net/http

debugging libgo failures

[Aldy Hernandez]

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-linux-gnu/libWHATEVER/testsuite/libWHATEVER.log and gaining 
insight on how to manually run tests.  However, there's nothing in 
libgo/testsuite, and libgo/libgo.log just has a summary of tests.


Ideally I'd like a way of building a test (with say -fdump-tree-all), 
and/or sticking gdb on the resulting executable.


Thanks.
Aldy

--- FAIL: TestMaxIdleConns (0.00s)
sql_test.go:1789: freeConns after set to zero = -1; want 0
sql_test.go:1798: freeConns = -1; want 0
panic: runtime error: makeslice: cap out of range [recovered]
panic: runtime error: makeslice: cap out of range

goroutine 202 [running]:
panic
/home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:588
testing.tRunner..func1
/home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:765
panic
/home/cygnus/aldyh/src/gcc/libgo/go/runtime/panic.go:535
database..z2fsql.DB.Close

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql.go:768
sql.closeDB

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:140
database..z2fsql.TestMaxIdleConns

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/libgo/gotest51314/test/sql_test.go:1800
testing.tRunner
/home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:827
created by testing.T.Run
/home/cygnus/aldyh/src/gcc/libgo/go/testing/testing.go:878 +1163
FAIL: database/sql


[snip]
[snip]

net..z2fhttp.persistConn.writeLoop

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1888
created by net..z2fhttp.Transport.dialConn

/home/cygnus/aldyh/bld/ranger/x86_64-pc-linux-gnu/32/libgo/gotest2965/test/transport.go:1339 
+2693


eax0x0
ebx0x2
ecx0xcbbdd84c
edx0x0
edi0x0
esi0x8
ebp0xcbbdd84c
esp0xcbbdd830
eip0xf7f93049
eflags 0x286
cs 0x23
fs 0x0
gs 0x63
FAIL: net/http

Re: Debugging optimizer problems

[Martin Sebor]

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 further track down the problem to one of the many functions in
that file.


The approach that usually works reasonably well is to use a tool
like delta or creduce to shrink the size of the problem to a small
test case.  https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction.

FWIW, the trick I've successfully used in the past is to add
an assert or some such conditional close to the point where
you see the wrong results being computed in the debugger.  Then
take the entry point into the file (whatever function eventually
leads to the bad behavior) and create a main that calls it with
the right values of all the arguments to trigger the bug.
Linking that into an executable typically causes many unresolved
references to symbols defined elsewhere in the file.  Provide
dummy definitions for those symbols in the same file so that
the program eventually links while still exhibiting the problem.
(Doing the same for other functions in the same file helps speed
up the whole process).  Then create a shell script that compiles
and links the file (treating all warnings as errors to avoid bad
changes from masking the problem) and runs the program looking
for the same failed assertion.  Let it run under delta for a few
hours or a day until the size is small enough so you understand
exactly what triggers the problem.

Martin



I have in my small C compiler introduced the following construct:

#pragma optimize(on/off,push/pop)

to deal with optimizer bugs.

#pragma optimize(off)

turns OFF all optimizations until a #pragma optimize(on) is seen or
until the end of the compiulation unit. If

#pragma optimize(off,push)

is given, the optimization state can be retrieved with a

#pragma optimize(pop), or

#pragma optimize(on)

This has three advantages:

1) Allows the user to reduce the code area where the problem is hiding.

2) Provides a work around to the user for any optimizer bug.

3) Allows gcc developers to find bugs in a more direct fashion.

These pragmas can only be given at a global scope, not within a function.

I do not know gcc internals, and this improvement could be difficult to
implement, and I do not know either your priorities in gcc development
but it surely would help users. Obviously I think that the problem is in
the code I am compiling, not in gcc, but it *could* be in gcc. That
construct would help enormously.

Thanks in advance for your time.

jacob

Re: Debugging optimizer problems

[David Brown]

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:
>>
>> <https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html>
>>
> 
> Great!
> 
> I had never seen it, and the docs in my machine weren't very explicit
> about that.
> 
> I apologize for the noise 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 problems, integer overflow
issues, or missing volatiles (that is more common in my world of
embedded programming, rather than PC software).  So rather than just:

#pragma GCC optimize("-O2")

and

#pragma GCC optimize("-O0")

I'd recommend testing with

#pragma GCC optimize("-fno-strict-aliasing")

and

#pragma GCC optimize("-fwrapv")

to see if that helps you isolate your problems quickly.

And if you have a reasonably modern gcc, try out the -fsanitize options
- they can be a great help in spotting bugs at run-time.

Re: Debugging optimizer problems

[jacob navia]

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:




Great!

I had never seen it, and the docs in my machine weren't very explicit 
about that.


I apologize for the noise and thank you for pointing me to that doc.

jacob

Re: Debugging optimizer problems

[Florian Weimer]

* 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

[jacob navia]

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 many functions in 
that file.


I have in my small C compiler introduced the following construct:

#pragma optimize(on/off,push/pop)

to deal with optimizer bugs.

#pragma optimize(off)

turns OFF all optimizations until a #pragma optimize(on) is seen or 
until the end of the compiulation unit. If


#pragma optimize(off,push)

is given, the optimization state can be retrieved with a

#pragma optimize(pop), or

#pragma optimize(on)

This has three advantages:

1) Allows the user to reduce the code area where the problem is hiding.

2) Provides a work around to the user for any optimizer bug.

3) Allows gcc developers to find bugs in a more direct fashion.

These pragmas can only be given at a global scope, not within a function.

I do not know gcc internals, and this improvement could be difficult to 
implement, and I do not know either your priorities in gcc development 
but it surely would help users. Obviously I think that the problem is in 
the code I am compiling, not in gcc, but it *could* be in gcc. That 
construct would help enormously.


Thanks in advance for your time.

jacob

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]))

[Joseph Myers]

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 also
> is part of the global trees?

That should definitely be the case (but there might be (a) complex types 
that aren't part of those trees, whose components aren't part either, and 
(b) non-complex types that are part of the global trees, whose 
corresponding complex types exist but aren't part of the global trees).

-- 
Joseph S. Myers
jos...@codesourcery.com

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]))

[Richard Biener]

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_BOOLEAN_FALSE,
>> >TI_BOOLEAN_TRUE,
>> >
>> > -  TI_COMPLEX_INTEGER_TYPE,
>> > -[...]
>> > -  TI_COMPLEX_FLOAT128X_TYPE,
>> > -
>> >TI_FLOAT_TYPE,
>> >TI_DOUBLE_TYPE,
>> >TI_LONG_DOUBLE_TYPE,
>> > @@ -596,6 +582,23 @@ enum tree_index {
>> >  - TI_FLOATN_NX_TYPE_FIRST  \
>> >  + 1)
>> >
>> > +  /* Put the complex types after their component types, so that in 
>> > (sequential)
>> > + tree streaming we can assert that their component types have already 
>> > been
>> > + handled (see tree-streamer.c:record_common_node).  */
>> > +  TI_COMPLEX_INTEGER_TYPE,
>> > +  TI_COMPLEX_FLOAT_TYPE,
>> > +  TI_COMPLEX_DOUBLE_TYPE,
>> > +  TI_COMPLEX_LONG_DOUBLE_TYPE,
>> > +
>> > +  TI_COMPLEX_FLOAT16_TYPE,
>> > +  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
>> > +  TI_COMPLEX_FLOAT32_TYPE,
>> > +  TI_COMPLEX_FLOAT64_TYPE,
>> > +  TI_COMPLEX_FLOAT128_TYPE,
>> > +  TI_COMPLEX_FLOAT32X_TYPE,
>> > +  TI_COMPLEX_FLOAT64X_TYPE,
>> > +  TI_COMPLEX_FLOAT128X_TYPE,
>> > +
>> >TI_FLOAT_PTR_TYPE,
>> >TI_DOUBLE_PTR_TYPE,
>> >TI_LONG_DOUBLE_PTR_TYPE,
>>
>> If the above change alone fixes your issues then it is fine to commit.
>
> That alone won't fix the problem, because we'd still have the recursion
> in gcc/tree-streamer.c:record_common_node done differently for x86_64
> target and nvptx offload target.

Doh - obviously.

>> > --- gcc/tree-streamer.c
>> > +++ gcc/tree-streamer.c
>> > @@ -278,9 +278,23 @@ record_common_node (struct streamer_tree_cache_d 
>> > *cache, tree node)
>> >streamer_tree_cache_append (cache, node, cache->nodes.length ());
>> >
>> >if (POINTER_TYPE_P (node)
>> > -  || TREE_CODE (node) == COMPLEX_TYPE
>> >|| TREE_CODE (node) == ARRAY_TYPE)
>> >  record_common_node (cache, TREE_TYPE (node));
>> > +  else if (TREE_CODE (node) == COMPLEX_TYPE)
>> > +{
>> > +  /* Assert that complex types' component types have already been 
>> > handled
>> > +(and we thus don't need to recurse here).  See PR lto/77458.  */
>> > +  if (cache->node_map)
>> > +   gcc_assert (streamer_tree_cache_lookup (cache, TREE_TYPE (node), 
>> > NULL));
>> > +  else
>> > +   {
>> > + gcc_assert (cache->nodes.exists ());
>> > + bool found = false;
>> > + for (unsigned i = 0; !found && i < cache->nodes.length (); ++i)
>> > +   found = true;
>>
>> hmm, this doesn't actually test anything? ;)
>
> ;-) Haha, hooray for patch review!
>
>> > + gcc_assert (found);
>> > +   }
>> > +}
>> >else if (TREE_CODE (node) == RECORD_TYPE)
>> >  {
>> >/* The FIELD_DECLs of structures should be shared, so that every
>
>> So I very much like to go forward with this kind of change as well
>
> OK, good.  So, in plain text, we'll make it a requirement that:
> integer_types trees must only refer to earlier integer_types trees;
> sizetype_tab trees must only refer to integer_types trees, and earlier
> sizetype_tab trees; and global_trees must only refer to integer_types
> trees, sizetype_tab trees, and earlier global_trees.

Yeah, though I'd put sizetypes first.

>> (the assert code
>> should go to a separate helper function).
>
> Should this checking be done only in
> gcc/tree-streamer.c:record_common_node, or should generally

Yes.

> gcc/tree-streamer.c:streamer_tree_cache_append check/assert that such
> recursive trees are already present in the cache?  And generally do that,
> or "if (flag_checking)" only?

I think we should restrict it to flag_checking only because in general violating
it is harmless plus we never know what happens on all targets/frontend/flag(!)
combinations.

>
>> Did you try it on more than just
>> the complex type case?
>
> Not yet, but now that you have approved the general concept, I'll look
> into that.
>
> Here's the current patch with the assertion condition fixed, but still
> for complex types only.  OK for trunk already?

Ok with the checking blob moved to a helper function,

  bool common_node_recorded_p (cache, node)

and its body guarded with if (flag_checking).

[looks to me we miss handling of vector type components alltogether,
maybe there are no global vector type trees ...]

Thanks,
Richard.

> --- gcc/tree-core.h
> +++ gcc/tree-core.h
> @@ -553,20 +553,6 @@ enum tree_index {
>TI_BOOLEAN_FALSE,
>TI_BOOLEAN_TRUE,
>
> -  TI_COMPLEX_INTEGER_TYPE,
> -  TI_COMPLEX_FLOAT_TYPE,
> -  TI_COMPLEX_DOUBLE_TYPE,
> -  TI_COMPLEX_LONG_DOUBLE_TYPE,
> -
> -  TI_COMPLEX_FLOAT16_TYPE,
> -  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
> -  TI_COMPLEX_FLOAT32_TYPE,
> -  TI_COMPLEX_FLOAT64_TYPE,
> -  TI_COMPLEX_

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]))

[Thomas Schwinge]

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_TYPE,
> > -[...]
> > -  TI_COMPLEX_FLOAT128X_TYPE,
> > -
> >TI_FLOAT_TYPE,
> >TI_DOUBLE_TYPE,
> >TI_LONG_DOUBLE_TYPE,
> > @@ -596,6 +582,23 @@ enum tree_index {
> >  - TI_FLOATN_NX_TYPE_FIRST  \
> >  + 1)
> >
> > +  /* Put the complex types after their component types, so that in 
> > (sequential)
> > + tree streaming we can assert that their component types have already 
> > been
> > + handled (see tree-streamer.c:record_common_node).  */
> > +  TI_COMPLEX_INTEGER_TYPE,
> > +  TI_COMPLEX_FLOAT_TYPE,
> > +  TI_COMPLEX_DOUBLE_TYPE,
> > +  TI_COMPLEX_LONG_DOUBLE_TYPE,
> > +
> > +  TI_COMPLEX_FLOAT16_TYPE,
> > +  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
> > +  TI_COMPLEX_FLOAT32_TYPE,
> > +  TI_COMPLEX_FLOAT64_TYPE,
> > +  TI_COMPLEX_FLOAT128_TYPE,
> > +  TI_COMPLEX_FLOAT32X_TYPE,
> > +  TI_COMPLEX_FLOAT64X_TYPE,
> > +  TI_COMPLEX_FLOAT128X_TYPE,
> > +
> >TI_FLOAT_PTR_TYPE,
> >TI_DOUBLE_PTR_TYPE,
> >TI_LONG_DOUBLE_PTR_TYPE,
> 
> If the above change alone fixes your issues then it is fine to commit.

That alone won't fix the problem, because we'd still have the recursion
in gcc/tree-streamer.c:record_common_node done differently for x86_64
target and nvptx offload target.

> > --- gcc/tree-streamer.c
> > +++ gcc/tree-streamer.c
> > @@ -278,9 +278,23 @@ record_common_node (struct streamer_tree_cache_d 
> > *cache, tree node)
> >streamer_tree_cache_append (cache, node, cache->nodes.length ());
> >
> >if (POINTER_TYPE_P (node)
> > -  || TREE_CODE (node) == COMPLEX_TYPE
> >|| TREE_CODE (node) == ARRAY_TYPE)
> >  record_common_node (cache, TREE_TYPE (node));
> > +  else if (TREE_CODE (node) == COMPLEX_TYPE)
> > +{
> > +  /* Assert that complex types' component types have already been 
> > handled
> > +(and we thus don't need to recurse here).  See PR lto/77458.  */
> > +  if (cache->node_map)
> > +   gcc_assert (streamer_tree_cache_lookup (cache, TREE_TYPE (node), 
> > NULL));
> > +  else
> > +   {
> > + gcc_assert (cache->nodes.exists ());
> > + bool found = false;
> > + for (unsigned i = 0; !found && i < cache->nodes.length (); ++i)
> > +   found = true;
> 
> hmm, this doesn't actually test anything? ;)

;-) Haha, hooray for patch review!

> > + gcc_assert (found);
> > +   }
> > +}
> >else if (TREE_CODE (node) == RECORD_TYPE)
> >  {
> >/* The FIELD_DECLs of structures should be shared, so that every

> So I very much like to go forward with this kind of change as well

OK, good.  So, in plain text, we'll make it a requirement that:
integer_types trees must only refer to earlier integer_types trees;
sizetype_tab trees must only refer to integer_types trees, and earlier
sizetype_tab trees; and global_trees must only refer to integer_types
trees, sizetype_tab trees, and earlier global_trees.

> (the assert code
> should go to a separate helper function).

Should this checking be done only in
gcc/tree-streamer.c:record_common_node, or should generally
gcc/tree-streamer.c:streamer_tree_cache_append check/assert that such
recursive trees are already present in the cache?  And generally do that,
or "if (flag_checking)" only?

> Did you try it on more than just
> the complex type case?

Not yet, but now that you have approved the general concept, I'll look
into that.

Here's the current patch with the assertion condition fixed, but still
for complex types only.  OK for trunk already?

--- gcc/tree-core.h
+++ gcc/tree-core.h
@@ -553,20 +553,6 @@ enum tree_index {
   TI_BOOLEAN_FALSE,
   TI_BOOLEAN_TRUE,
 
-  TI_COMPLEX_INTEGER_TYPE,
-  TI_COMPLEX_FLOAT_TYPE,
-  TI_COMPLEX_DOUBLE_TYPE,
-  TI_COMPLEX_LONG_DOUBLE_TYPE,
-
-  TI_COMPLEX_FLOAT16_TYPE,
-  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
-  TI_COMPLEX_FLOAT32_TYPE,
-  TI_COMPLEX_FLOAT64_TYPE,
-  TI_COMPLEX_FLOAT128_TYPE,
-  TI_COMPLEX_FLOAT32X_TYPE,
-  TI_COMPLEX_FLOAT64X_TYPE,
-  TI_COMPLEX_FLOAT128X_TYPE,
-
   TI_FLOAT_TYPE,
   TI_DOUBLE_TYPE,
   TI_LONG_DOUBLE_TYPE,
@@ -596,6 +582,23 @@ enum tree_index {
 - TI_FLOATN_NX_TYPE_FIRST  \
 + 1)
 
+  /* Put the complex types after their component types, so that in (sequential)
+ tree streaming we can assert that their component types have already been
+ handled (see tree-streamer.c:record_common_node).  */
+  TI_COMPLEX_INTEGER_TYPE,
+  TI_COMPLEX_FLOAT_TYPE,
+  TI_COMPLEX_DOUBLE_TYPE,
+  TI_COMPLEX_LONG_DOUBLE_TYPE,
+
+  TI_COMPLEX_FLOAT16_TYPE,
+  TI_COMPLEX_FLOATN_NX_TYPE_FIRST = TI_COMPLEX_FLOAT16_TYPE,
+  TI_CO

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]))

[Thomas Schwinge]

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 complex types' component types
> >> will always match one of the already existing global trees?  (I can
> >
> > Well, a component type could certainly match a target-specific type
> > instead (e.g. __ibm128 on powerpc, which if it's not long double won't be
> > any of the other types either).  That's a type registered with
> > lang_hooks.types.register_builtin_type, not one of the global trees.
> > (You can't write _Complex __ibm128, but can get such a type with _Complex
> > float __attribute__ ((__mode__ (__IC__))).  Or similarly, with ARM __fp16,
> > the complex type _Complex float __attribute__ ((__mode__ (__HC__))).)
> 
> 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 also
is part of the global trees?


Grüße
 Thomas

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]))

[Richard Biener]

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 
>> >>  wrote:
>> >> > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge 
>> >> >  wrote:
>> >> > > As I noted in :
>> >> > >
>> >> > > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx 
>> >> > > types", nvptx
>> >> > > offloading is broken, ICEs in LTO stream-in.  Probably some kind 
>> >> > > of data-type
>> >> > > mismatch that is not visible with Intel MIC offloading (using the 
>> >> > > same data
>> >> > > types) but explodes with nvptx.  I'm having a look.
>> >
>> >> > [...] preload_common_nodes.  This is carefully crafted to _not_ diverge 
>> >> > by
>> >> > frontend (!) it wasn't even designed to cope with global trees being 
>> >> > present
>> >> > or not dependent on target (well, because the target is always the
>> >> > same! mind you!)
>> >>
>> >> Scary.  ;-/
>> >>
>> >> > Now -- in theory it should deal with NULLs just fine (resulting in
>> >> > error_mark_node), but it can diverge when there are additional
>> >> > compount types (like vectors, complex
>> >> > or array or record types) whose element types are not in the set of
>> >> > global trees.
>> >> > The complex _FloatN types would be such a case given they appear before 
>> >> > their
>> >> > components.  That mixes up the ordering at least.
>> >>
>> >> ACK, but that's also an issue for "regular" float/complex float, which
>> >> also is in "reverse" order.  But that's "fixed" by the recursion in
>> >> gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
>> >> COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.
>> >
>> > So, that mechanism does work, but what's going wrong is the following:
>> > with differing target vs. offload target, we potentially (and actually
>> > do, in the case of x86_64 vs. nvptx) have different sets of _FloatN and
>> > _FloatNx types.  That is, for nvptx, a few of these don't exist (so,
>> > NULL_TREE), and so it follows their complex variants also don't exist,
>> > and thus the recursion that I just mentioned for complex types is no
>> > longer done in lockstep in the x86_64 cc1 vs. the nvptx lto1, hence we
>> > get an offset (of two, in this specific case), and consequently streaming
>> > explodes, for example, as soon as it hits a forward-reference (due to
>> > looking for tree 185 (x86_64 cc1 view; as encoded in the stream) when it
>> > should be looking for tree 183 (nvptx lto1 view).
>> >
>> >> (I've
>> >> put "fixed" in quotes -- doesn't that recursion mean that we're thus
>> >> putting "complex float", "float", [...], "float" (again) into the cache?
>> >> Anyway that's for later...)
>> >
>> > Maybe it would make sense to do this tree streaming in two passes: first
>> > build a set of what we actually need, and then stream that, without
>> > duplicates.  (Or, is also for these "pickled" trees their order relevant,
>> > so that one tree may only refer to other earlier but not later ones?
>> > Anyway, we could still remember the set of trees already streamed, and
>> > avoid the double streaming I described?)
>> >
>> > So I now understand that due to the stream format, the integer tree IDs
>> > (cache->next_id) have to match in all cc1/lto1s (etc.), so we'll have to
>> > make that work for x86_64 target vs. nvptx offload target being
>> > different.  (I'm pondering some ideas about how to rework that integer
>> > tree ID generation.)
>> >
>> > (I have not digested completely yet what the implications are for the
>> > skipping we're doing for some trees in preload_common_nodes), but here is
>> > a first patch that at least gets us rid of the immediate problem.  (I'll
>> > fix the TODO by adding a "#define TI_COMPLEX_FLOATN_NX_TYPE_LAST" to
>> > gcc/tree-core.h, OK?)  Will such a patch be OK for trunk, at least for
>> > now?
>>
>> Humm ... do we anywhere compare to those global trees by pointer equivalence?
>
> I have not verified that.  Does GCC permit/forbid that on a case-by-case
> basis -- which seems very fragile to me?
>
>> If so then it breaks LTO support for those types.
>
> OK, I think I understand that -- but I do have a "lto_stream_offload_p"
> conditional in my code changes, so these changes should only affect the
> offloading stream, in my understanding?
>
>> I think forcing proper ordering so that we can assert that at the
>> point we'd like
>> to recurse the nodes we recurse for are already in the cache would be a 
>> better
>> fix.
>
> ACK.  That's what I'd planned to look into as a next step.
>
>> This might need some additional global trees in case components do not
>> explicitely exist
>
> 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

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]))

[Richard Biener]

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 global trees?  (I can
>
> Well, a component type could certainly match a target-specific type
> instead (e.g. __ibm128 on powerpc, which if it's not long double won't be
> any of the other types either).  That's a type registered with
> lang_hooks.types.register_builtin_type, not one of the global trees.
> (You can't write _Complex __ibm128, but can get such a type with _Complex
> float __attribute__ ((__mode__ (__IC__))).  Or similarly, with ARM __fp16,
> the complex type _Complex float __attribute__ ((__mode__ (__HC__))).)

The question is whether such a complex type could be a global tree which I
don't think it could.

Richard.

> --
> Joseph S. Myers
> jos...@codesourcery.com

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]))

[Joseph Myers]

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 type compatibility), but 
that's not relevant to LTO.  I don't think there should be such 
comparisons outside the front ends.

-- 
Joseph S. Myers
jos...@codesourcery.com

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]))

[Joseph Myers]

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 certainly match a target-specific type 
instead (e.g. __ibm128 on powerpc, which if it's not long double won't be 
any of the other types either).  That's a type registered with 
lang_hooks.types.register_builtin_type, not one of the global trees.  
(You can't write _Complex __ibm128, but can get such a type with _Complex 
float __attribute__ ((__mode__ (__IC__))).  Or similarly, with ARM __fp16, 
the complex type _Complex float __attribute__ ((__mode__ (__HC__))).)

-- 
Joseph S. Myers
jos...@codesourcery.com

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]))

[Thomas Schwinge]

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 
> >> >  wrote:
> >> > > As I noted in :
> >> > >
> >> > > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx 
> >> > > types", nvptx
> >> > > offloading is broken, ICEs in LTO stream-in.  Probably some kind 
> >> > > of data-type
> >> > > mismatch that is not visible with Intel MIC offloading (using the 
> >> > > same data
> >> > > types) but explodes with nvptx.  I'm having a look.
> >
> >> > [...] preload_common_nodes.  This is carefully crafted to _not_ diverge 
> >> > by
> >> > frontend (!) it wasn't even designed to cope with global trees being 
> >> > present
> >> > or not dependent on target (well, because the target is always the
> >> > same! mind you!)
> >>
> >> Scary.  ;-/
> >>
> >> > Now -- in theory it should deal with NULLs just fine (resulting in
> >> > error_mark_node), but it can diverge when there are additional
> >> > compount types (like vectors, complex
> >> > or array or record types) whose element types are not in the set of
> >> > global trees.
> >> > The complex _FloatN types would be such a case given they appear before 
> >> > their
> >> > components.  That mixes up the ordering at least.
> >>
> >> ACK, but that's also an issue for "regular" float/complex float, which
> >> also is in "reverse" order.  But that's "fixed" by the recursion in
> >> gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
> >> COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.
> >
> > So, that mechanism does work, but what's going wrong is the following:
> > with differing target vs. offload target, we potentially (and actually
> > do, in the case of x86_64 vs. nvptx) have different sets of _FloatN and
> > _FloatNx types.  That is, for nvptx, a few of these don't exist (so,
> > NULL_TREE), and so it follows their complex variants also don't exist,
> > and thus the recursion that I just mentioned for complex types is no
> > longer done in lockstep in the x86_64 cc1 vs. the nvptx lto1, hence we
> > get an offset (of two, in this specific case), and consequently streaming
> > explodes, for example, as soon as it hits a forward-reference (due to
> > looking for tree 185 (x86_64 cc1 view; as encoded in the stream) when it
> > should be looking for tree 183 (nvptx lto1 view).
> >
> >> (I've
> >> put "fixed" in quotes -- doesn't that recursion mean that we're thus
> >> putting "complex float", "float", [...], "float" (again) into the cache?
> >> Anyway that's for later...)
> >
> > Maybe it would make sense to do this tree streaming in two passes: first
> > build a set of what we actually need, and then stream that, without
> > duplicates.  (Or, is also for these "pickled" trees their order relevant,
> > so that one tree may only refer to other earlier but not later ones?
> > Anyway, we could still remember the set of trees already streamed, and
> > avoid the double streaming I described?)
> >
> > So I now understand that due to the stream format, the integer tree IDs
> > (cache->next_id) have to match in all cc1/lto1s (etc.), so we'll have to
> > make that work for x86_64 target vs. nvptx offload target being
> > different.  (I'm pondering some ideas about how to rework that integer
> > tree ID generation.)
> >
> > (I have not digested completely yet what the implications are for the
> > skipping we're doing for some trees in preload_common_nodes), but here is
> > a first patch that at least gets us rid of the immediate problem.  (I'll
> > fix the TODO by adding a "#define TI_COMPLEX_FLOATN_NX_TYPE_LAST" to
> > gcc/tree-core.h, OK?)  Will such a patch be OK for trunk, at least for
> > now?
> 
> Humm ... do we anywhere compare to those global trees by pointer equivalence?

I have not verified that.  Does GCC permit/forbid that on a case-by-case
basis -- which seems very fragile to me?

> If so then it breaks LTO support for those types.

OK, I think I understand that -- but I do have a "lto_stream_offload_p"
conditional in my code changes, so these changes should only affect the
offloading stream, in my understanding?

> I think forcing proper ordering so that we can assert that at the
> point we'd like
> to recurse the nodes we recurse for are already in the cache would be a better
> fix.

ACK.  That's what I'd planned to look into as a next step.

> This might need some additional global trees in case components do not
> explicitely exist

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
certainly imagine some "strange" ISAs/data types breaking this assertion
-- no idea wheth

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]))

[Richard Biener]

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 wrote:
>> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener 
>>  wrote:
>> > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge  
>> > wrote:
>> > > 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
>> > >> > that would prevent it but having new global trees and backends 
>> > >> > initializing them
>> > >> > might come up with surprises (see 
>> > >> > tree-streamer.c:preload_common_nodes)
>> > >>
>> > >> Well, the execution tests are in gcc.dg/torture, which is run with 
>> > >> various
>> > >> options including -flto (and I've checked the testsuite logs to confirm
>> > >> these tests are indeed run with such options).  Is there something else
>> > >> you think should be tested?
>> > >
>> > > As I noted in :
>> > >
>> > > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx 
>> > > types", nvptx
>> > > offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
>> > > data-type
>> > > mismatch that is not visible with Intel MIC offloading (using the 
>> > > same data
>> > > types) but explodes with nvptx.  I'm having a look.
>
>> > [...] preload_common_nodes.  This is carefully crafted to _not_ diverge by
>> > frontend (!) it wasn't even designed to cope with global trees being 
>> > present
>> > or not dependent on target (well, because the target is always the
>> > same! mind you!)
>>
>> Scary.  ;-/
>>
>> > Now -- in theory it should deal with NULLs just fine (resulting in
>> > error_mark_node), but it can diverge when there are additional
>> > compount types (like vectors, complex
>> > or array or record types) whose element types are not in the set of
>> > global trees.
>> > The complex _FloatN types would be such a case given they appear before 
>> > their
>> > components.  That mixes up the ordering at least.
>>
>> ACK, but that's also an issue for "regular" float/complex float, which
>> also is in "reverse" order.  But that's "fixed" by the recursion in
>> gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
>> COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.
>
> So, that mechanism does work, but what's going wrong is the following:
> with differing target vs. offload target, we potentially (and actually
> do, in the case of x86_64 vs. nvptx) have different sets of _FloatN and
> _FloatNx types.  That is, for nvptx, a few of these don't exist (so,
> NULL_TREE), and so it follows their complex variants also don't exist,
> and thus the recursion that I just mentioned for complex types is no
> longer done in lockstep in the x86_64 cc1 vs. the nvptx lto1, hence we
> get an offset (of two, in this specific case), and consequently streaming
> explodes, for example, as soon as it hits a forward-reference (due to
> looking for tree 185 (x86_64 cc1 view; as encoded in the stream) when it
> should be looking for tree 183 (nvptx lto1 view).
>
>> (I've
>> put "fixed" in quotes -- doesn't that recursion mean that we're thus
>> putting "complex float", "float", [...], "float" (again) into the cache?
>> Anyway that's for later...)
>
> Maybe it would make sense to do this tree streaming in two passes: first
> build a set of what we actually need, and then stream that, without
> duplicates.  (Or, is also for these "pickled" trees their order relevant,
> so that one tree may only refer to other earlier but not later ones?
> Anyway, we could still remember the set of trees already streamed, and
> avoid the double streaming I described?)
>
> So I now understand that due to the stream format, the integer tree IDs
> (cache->next_id) have to match in all cc1/lto1s (etc.), so we'll have to
> make that work for x86_64 target vs. nvptx offload target being
> different.  (I'm pondering some ideas about how to rework that integer
> tree ID generation.)
>
> (I have not digested completely yet what the implications are for the
> skipping we're doing for some trees in preload_common_nodes), but here is
> a first patch that at least gets us rid of the immediate problem.  (I'll
> fix the TODO by adding a "#define TI_COMPLEX_FLOATN_NX_TYPE_LAST" to
> gcc/tree-core.h, OK?)  Will such a patch be OK for trunk, at least for
> now?

Humm ... do we anywhere compare to those global trees by pointer equivalence?
If so then it breaks LTO support for those types.

I think forcing proper ordering so that we can assert that at the
point we'd like
to recurse the nodes we recurse for are already in the cache would be a better
fix.  This might need some additional global trees in case components do not
ex

[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]))

[Thomas Schwinge]

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:
> > On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge  
> > wrote:
> > > 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
> > >> > that would prevent it but having new global trees and backends 
> > >> > initializing them
> > >> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
> > >>
> > >> Well, the execution tests are in gcc.dg/torture, which is run with 
> > >> various
> > >> options including -flto (and I've checked the testsuite logs to confirm
> > >> these tests are indeed run with such options).  Is there something else
> > >> you think should be tested?
> > >
> > > As I noted in :
> > >
> > > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx 
> > > types", nvptx
> > > offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
> > > data-type
> > > mismatch that is not visible with Intel MIC offloading (using the 
> > > same data
> > > types) but explodes with nvptx.  I'm having a look.

> > [...] preload_common_nodes.  This is carefully crafted to _not_ diverge by
> > frontend (!) it wasn't even designed to cope with global trees being present
> > or not dependent on target (well, because the target is always the
> > same! mind you!)
> 
> Scary.  ;-/
> 
> > Now -- in theory it should deal with NULLs just fine (resulting in
> > error_mark_node), but it can diverge when there are additional
> > compount types (like vectors, complex
> > or array or record types) whose element types are not in the set of
> > global trees.
> > The complex _FloatN types would be such a case given they appear before 
> > their
> > components.  That mixes up the ordering at least.
> 
> ACK, but that's also an issue for "regular" float/complex float, which
> also is in "reverse" order.  But that's "fixed" by the recursion in
> gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
> COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.

So, that mechanism does work, but what's going wrong is the following:
with differing target vs. offload target, we potentially (and actually
do, in the case of x86_64 vs. nvptx) have different sets of _FloatN and
_FloatNx types.  That is, for nvptx, a few of these don't exist (so,
NULL_TREE), and so it follows their complex variants also don't exist,
and thus the recursion that I just mentioned for complex types is no
longer done in lockstep in the x86_64 cc1 vs. the nvptx lto1, hence we
get an offset (of two, in this specific case), and consequently streaming
explodes, for example, as soon as it hits a forward-reference (due to
looking for tree 185 (x86_64 cc1 view; as encoded in the stream) when it
should be looking for tree 183 (nvptx lto1 view).

> (I've
> put "fixed" in quotes -- doesn't that recursion mean that we're thus
> putting "complex float", "float", [...], "float" (again) into the cache?
> Anyway that's for later...)

Maybe it would make sense to do this tree streaming in two passes: first
build a set of what we actually need, and then stream that, without
duplicates.  (Or, is also for these "pickled" trees their order relevant,
so that one tree may only refer to other earlier but not later ones?
Anyway, we could still remember the set of trees already streamed, and
avoid the double streaming I described?)

So I now understand that due to the stream format, the integer tree IDs
(cache->next_id) have to match in all cc1/lto1s (etc.), so we'll have to
make that work for x86_64 target vs. nvptx offload target being
different.  (I'm pondering some ideas about how to rework that integer
tree ID generation.)

(I have not digested completely yet what the implications are for the
skipping we're doing for some trees in preload_common_nodes), but here is
a first patch that at least gets us rid of the immediate problem.  (I'll
fix the TODO by adding a "#define TI_COMPLEX_FLOATN_NX_TYPE_LAST" to
gcc/tree-core.h, OK?)  Will such a patch be OK for trunk, at least for
now?

commit d2045bd028104be2ede5ae1d5d7b9395e67a8180
Author: Thomas Schwinge 
Date:   Thu Sep 15 21:56:16 2016 +0200

[PR lto/77458] Avoid ICE in offloading with differing _FloatN, _FloatNx 
types

gcc/
PR lto/77458
* tree-streamer.c (preload_common_nodes): Skip _FloatN and
_FloatNx types if offloading.
---
 gcc/tree-streamer.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git gcc/tree-streamer.c gcc/tree-streamer.c
index 7ea7096..061d831 100644
--- gcc/tree-streamer.c
+++ gcc/tree-streamer.c
@@ -333,7 +3

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

[Richard Biener]

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 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
>> >> > that would prevent it but having new global trees and backends 
>> >> > initializing them
>> >> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
>> >>
>> >> Well, the execution tests are in gcc.dg/torture, which is run with various
>> >> options including -flto (and I've checked the testsuite logs to confirm
>> >> these tests are indeed run with such options).  Is there something else
>> >> you think should be tested?
>> >
>> > As I noted in <https://gcc.gnu.org/PR77458>:
>> >
>> > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx 
>> > types", nvptx
>> > offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
>> > data-type
>> > mismatch that is not visible with Intel MIC offloading (using the same 
>> > data
>> > types) but explodes with nvptx.  I'm having a look.
>> >
>> > I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
>> > backtrace of the ICE looks as follows:
>> >
>> > #0  fancy_abort (file=file@entry=0x10d61d0 
>> > "[...]/source-gcc/gcc/vec.h", line=line@entry=727, 
>> > function=function@entry=0x10d6e3a 
>> > <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") 
>> > at [...]/source-gcc/gcc/diagnostic.c:1414
>> > #1  0x0058c9ef in vec> > vl_embed>::operator[] (this=0x16919c0, ix=ix@entry=185) at 
>> > [...]/source-gcc/gcc/vec.h:727
>> > #2  0x0058ca33 in vec::operator[] 
>> > (this=this@entry=0x1691998, ix=ix@entry=185) at 
>> > [...]/source-gcc/gcc/vec.h:1211
>>
>> so it wants tree 185 which is (given the low number) likely one streamed by
>> preload_common_nodes.  This is carefully crafted to _not_ diverge by
>> frontend (!) it wasn't even designed to cope with global trees being present
>> or not dependent on target (well, because the target is always the
>> same! mind you!)
>
> Scary.  ;-/
>
>> Now -- in theory it should deal with NULLs just fine (resulting in
>> error_mark_node), but it can diverge when there are additional
>> compount types (like vectors, complex
>> or array or record types) whose element types are not in the set of
>> global trees.
>> The complex _FloatN types would be such a case given they appear before their
>> components.  That mixes up the ordering at least.
>
> ACK, but that's also an issue for "regular" float/complex float, which
> also is in "reverse" order.  But that's "fixed" by the recursion in
> gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
> COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.  (I've
> put "fixed" in quotes -- doesn't that recursion mean that we're thus
> putting "complex float", "float", [...], "float" (again) into the cache?
> Anyway that's for later...)
>
>> So I suggest to add a print_tree to where it does the 
>> streamer_tree_cache_append
>> and compare cc1 and lto1 outcome.
>
> Thanks for all your suggestions!
>
> As far as I can tell, tree 185 is in fact among the first trees just
> after the preloaded ones...  (See record_common_node followed by
> streamer_tree_cache_append with "ix == hash" vs., from "ix=180" onwards,
> streamer_tree_cache_append called from elsewhere with "ix != hash".)
> (I'm also noticing that this cache first is built from "ix=0" through
> "ix=179", then apparently discarded, and rebuilt again, which seems
> surprising but which I've not yet looked into; hopefully unrelated
> issue.)  I'll continue to poke at this, but wanted to given an update
> here at least.

Ok - so the only other suggestion is to do lock-step debugging of the
cc1 / lto1 process
starting from the last known "equal" tree we put

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

[Thomas Schwinge]

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 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
> >> > that would prevent it but having new global trees and backends 
> >> > initializing them
> >> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
> >>
> >> Well, the execution tests are in gcc.dg/torture, which is run with various
> >> options including -flto (and I've checked the testsuite logs to confirm
> >> these tests are indeed run with such options).  Is there something else
> >> you think should be tested?
> >
> > As I noted in <https://gcc.gnu.org/PR77458>:
> >
> > As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", 
> > nvptx
> > offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
> > data-type
> > mismatch that is not visible with Intel MIC offloading (using the same 
> > data
> > types) but explodes with nvptx.  I'm having a look.
> >
> > I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
> > backtrace of the ICE looks as follows:
> >
> > #0  fancy_abort (file=file@entry=0x10d61d0 
> > "[...]/source-gcc/gcc/vec.h", line=line@entry=727, 
> > function=function@entry=0x10d6e3a 
> > <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") 
> > at [...]/source-gcc/gcc/diagnostic.c:1414
> > #1  0x0058c9ef in vec > vl_embed>::operator[] (this=0x16919c0, ix=ix@entry=185) at 
> > [...]/source-gcc/gcc/vec.h:727
> > #2  0x0058ca33 in vec::operator[] 
> > (this=this@entry=0x1691998, ix=ix@entry=185) at 
> > [...]/source-gcc/gcc/vec.h:1211
> 
> so it wants tree 185 which is (given the low number) likely one streamed by
> preload_common_nodes.  This is carefully crafted to _not_ diverge by
> frontend (!) it wasn't even designed to cope with global trees being present
> or not dependent on target (well, because the target is always the
> same! mind you!)

Scary.  ;-/

> Now -- in theory it should deal with NULLs just fine (resulting in
> error_mark_node), but it can diverge when there are additional
> compount types (like vectors, complex
> or array or record types) whose element types are not in the set of
> global trees.
> The complex _FloatN types would be such a case given they appear before their
> components.  That mixes up the ordering at least.

ACK, but that's also an issue for "regular" float/complex float, which
also is in "reverse" order.  But that's "fixed" by the recursion in
gcc/tree-streamer.c:record_common_node for "TREE_CODE (node) ==
COMPLEX_TYPE".  This likewise seems to work for the _FloatN types.  (I've
put "fixed" in quotes -- doesn't that recursion mean that we're thus
putting "complex float", "float", [...], "float" (again) into the cache?
Anyway that's for later...)

> So I suggest to add a print_tree to where it does the 
> streamer_tree_cache_append
> and compare cc1 and lto1 outcome.

Thanks for all your suggestions!

As far as I can tell, tree 185 is in fact among the first trees just
after the preloaded ones...  (See record_common_node followed by
streamer_tree_cache_append with "ix == hash" vs., from "ix=180" onwards,
streamer_tree_cache_append called from elsewhere with "ix != hash".)
(I'm also noticing that this cache first is built from "ix=0" through
"ix=179", then apparently discarded, and rebuilt again, which seems
surprising but which I've not yet looked into; hopefully unrelated
issue.)  I'll continue to poke at this, but wanted to given an update
here at least.

[...]
PID=12052 [...]/source-gcc/gcc/tree-streamer.c:272:record_common_node
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x768e23f0 precision 
64>
PID=12052 
[...]/source-gcc/gcc/tree-streamer.c:214:streamer_tree_cache_append
  ix=178 hash=178 tree=0x768e23f0
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x768e23f0 precision 
64>
PID=12052 [...]/source-gcc/gcc/tree-streamer.c:272:record_common_node
 

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

[Richard Biener]

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:
>> > Can you quickly verify if LTO works with the new types?  I don't see 
>> > anything
>> > that would prevent it but having new global trees and backends 
>> > initializing them
>> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
>>
>> Well, the execution tests are in gcc.dg/torture, which is run with various
>> options including -flto (and I've checked the testsuite logs to confirm
>> these tests are indeed run with such options).  Is there something else
>> you think should be tested?
>
> As I noted in <https://gcc.gnu.org/PR77458>:
>
> As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", 
> nvptx
> offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
> data-type
> mismatch that is not visible with Intel MIC offloading (using the same 
> data
> types) but explodes with nvptx.  I'm having a look.
>
> I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
> backtrace of the ICE looks as follows:
>
> #0  fancy_abort (file=file@entry=0x10d61d0 "[...]/source-gcc/gcc/vec.h", 
> line=line@entry=727, function=function@entry=0x10d6e3a 
> <_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at 
> [...]/source-gcc/gcc/diagnostic.c:1414
> #1  0x0058c9ef in vec::operator[] 
> (this=0x16919c0, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:727
> #2  0x0058ca33 in vec::operator[] 
> (this=this@entry=0x1691998, ix=ix@entry=185) at 
> [...]/source-gcc/gcc/vec.h:1211

so it wants tree 185 which is (given the low number) likely one streamed by
preload_common_nodes.  This is carefully crafted to _not_ diverge by
frontend (!) it wasn't even designed to cope with global trees being present
or not dependent on target (well, because the target is always the
same! mind you!)

Now -- in theory it should deal with NULLs just fine (resulting in
error_mark_node), but it can diverge when there are additional
compount types (like vectors, complex
or array or record types) whose element types are not in the set of
global trees.
The complex _FloatN types would be such a case given they appear before their
components.  That mixes up the ordering at least.

So I suggest to add a print_tree to where it does the streamer_tree_cache_append
and compare cc1 and lto1 outcome.

The ICE above means the lto1 has fewer preloaded nodes I guess.

Richard.

> #3  0x00c73e54 in streamer_tree_cache_get_tree (cache=0x1691990, 
> ix=ix@entry=185) at [...]/source-gcc/gcc/tree-streamer.h:98
> #4  0x00c73eb9 in streamer_get_pickled_tree 
> (ib=ib@entry=0x7fffceb0, data_in=data_in@entry=0x1691930) at 
> [...]/source-gcc/gcc/tree-streamer-in.c:1112
> #5  0x008f841b in lto_input_tree_1 (ib=ib@entry=0x7fffceb0, 
> data_in=data_in@entry=0x1691930, tag=tag@entry=LTO_tree_pickle_reference, 
> hash=hash@entry=0) at [...]/source-gcc/gcc/lto-streamer-in.c:1404
> #6  0x008f8844 in lto_input_tree (ib=0x7fffceb0, 
> data_in=0x1691930) at [...]/source-gcc/gcc/lto-streamer-in.c:1444
> #7  0x00c720d2 in lto_input_ts_list_tree_pointers 
> (ib=ib@entry=0x7fffceb0, data_in=data_in@entry=0x1691930, 
> expr=expr@entry=0x76993780) at [...]/source-gcc/gcc/tree-streamer-in.c:861
> #8  0x00c7444e in streamer_read_tree_body 
> (ib=ib@entry=0x7fffceb0, data_in=data_in@entry=0x1691930, 
> expr=expr@entry=0x76993780) at 
> [...]/source-gcc/gcc/tree-streamer-in.c:1077
> #9  0x008f6428 in lto_read_tree_1 (ib=ib@entry=0x7fffceb0, 
> data_in=data_in@entry=0x1691930, expr=expr@entry=0x76993780) at 
> [...]/source-gcc/gcc/lto-streamer-in.c:1285
> #10 0x008f651b in lto_read_tree (ib=ib@entry=0x7fffceb0, 
> data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) 
> at [...]/source-gcc/gcc/lto-streamer-in.c:1315
> #11 0x008f85db in lto_input_tree_1 (ib=ib@entry=0x7fffceb0, 
> data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) 
> at [...]/source-gcc/gcc/lto-streamer-in.c:1427
> #12 0x008f8673 in lto_input_scc (ib=ib@entry=0x7fffceb0, 
> data_in=data_in@entry=0x1691930, len=len@entry=0x7fffceac, 
> entry_len=entry_len@entry=0x7fffcea8) at 
> [...]/source-gcc/gcc/lto-streamer-in.c:1339
> #13 0x005890f7 in lto_read_decls 
> (decl_d

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

[Thomas Schwinge]

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
> > that would prevent it but having new global trees and backends initializing 
> > them
> > might come up with surprises (see tree-streamer.c:preload_common_nodes)
> 
> Well, the execution tests are in gcc.dg/torture, which is run with various 
> options including -flto (and I've checked the testsuite logs to confirm 
> these tests are indeed run with such options).  Is there something else 
> you think should be tested?

As I noted in <https://gcc.gnu.org/PR77458>:

As of the PR32187 commit r239625 "Implement C _FloatN, _FloatNx types", 
nvptx
offloading is broken, ICEs in LTO stream-in.  Probably some kind of 
data-type
mismatch that is not visible with Intel MIC offloading (using the same data
types) but explodes with nvptx.  I'm having a look.

I know how to use "-save-temps -v" to re-run the ICEing lto1 in GDB; a
backtrace of the ICE looks as follows:

#0  fancy_abort (file=file@entry=0x10d61d0 "[...]/source-gcc/gcc/vec.h", 
line=line@entry=727, function=function@entry=0x10d6e3a 
<_ZZN3vecIP9tree_node7va_heap8vl_embedEixEjE12__FUNCTION__> "operator[]") at 
[...]/source-gcc/gcc/diagnostic.c:1414
#1  0x0058c9ef in vec::operator[] 
(this=0x16919c0, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:727
#2  0x0058ca33 in vec::operator[] 
(this=this@entry=0x1691998, ix=ix@entry=185) at [...]/source-gcc/gcc/vec.h:1211
#3  0x00c73e54 in streamer_tree_cache_get_tree (cache=0x1691990, 
ix=ix@entry=185) at [...]/source-gcc/gcc/tree-streamer.h:98
#4  0x00c73eb9 in streamer_get_pickled_tree 
(ib=ib@entry=0x7fffceb0, data_in=data_in@entry=0x1691930) at 
[...]/source-gcc/gcc/tree-streamer-in.c:1112
#5  0x008f841b in lto_input_tree_1 (ib=ib@entry=0x7fffceb0, 
data_in=data_in@entry=0x1691930, tag=tag@entry=LTO_tree_pickle_reference, 
hash=hash@entry=0) at [...]/source-gcc/gcc/lto-streamer-in.c:1404
#6  0x008f8844 in lto_input_tree (ib=0x7fffceb0, 
data_in=0x1691930) at [...]/source-gcc/gcc/lto-streamer-in.c:1444
#7  0x00c720d2 in lto_input_ts_list_tree_pointers 
(ib=ib@entry=0x7fffceb0, data_in=data_in@entry=0x1691930, 
expr=expr@entry=0x76993780) at [...]/source-gcc/gcc/tree-streamer-in.c:861
#8  0x00c7444e in streamer_read_tree_body 
(ib=ib@entry=0x7fffceb0, data_in=data_in@entry=0x1691930, 
expr=expr@entry=0x76993780) at [...]/source-gcc/gcc/tree-streamer-in.c:1077
#9  0x008f6428 in lto_read_tree_1 (ib=ib@entry=0x7fffceb0, 
data_in=data_in@entry=0x1691930, expr=expr@entry=0x76993780) at 
[...]/source-gcc/gcc/lto-streamer-in.c:1285
#10 0x008f651b in lto_read_tree (ib=ib@entry=0x7fffceb0, 
data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) 
at [...]/source-gcc/gcc/lto-streamer-in.c:1315
#11 0x008f85db in lto_input_tree_1 (ib=ib@entry=0x7fffceb0, 
data_in=data_in@entry=0x1691930, tag=tag@entry=4, hash=hash@entry=4086308758) 
at [...]/source-gcc/gcc/lto-streamer-in.c:1427
#12 0x008f8673 in lto_input_scc (ib=ib@entry=0x7fffceb0, 
data_in=data_in@entry=0x1691930, len=len@entry=0x7fffceac, 
entry_len=entry_len@entry=0x7fffcea8) at 
[...]/source-gcc/gcc/lto-streamer-in.c:1339
#13 0x005890f7 in lto_read_decls 
(decl_data=decl_data@entry=0x77fc, data=data@entry=0x169d570, 
resolutions=...) at [...]/source-gcc/gcc/lto/lto.c:1693
#14 0x005898c8 in lto_file_finalize 
(file_data=file_data@entry=0x77fc, file=file@entry=0x15eedb0) at 
[...]/source-gcc/gcc/lto/lto.c:2037
#15 0x00589928 in lto_create_files_from_ids 
(file=file@entry=0x15eedb0, file_data=file_data@entry=0x77fc, 
count=count@entry=0x7fffd054) at [...]/source-gcc/gcc/lto/lto.c:2047
#16 0x00589a7a in lto_file_read (file=0x15eedb0, 
resolution_file=resolution_file@entry=0x0, count=count@entry=0x7fffd054) at 
[...]/source-gcc/gcc/lto/lto.c:2088
#17 0x00589e84 in read_cgraph_and_symbols (nfiles=1, 
fnames=0x160e990) at [...]/source-gcc/gcc/lto/lto.c:2798
#18 0x0058a572 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:3299
#19 0x00a48eff in compile_file () at 
[...]/source-gcc/gcc/toplev.c:466
#20 0x00550943 in do_compile () at 
[...]/source-gcc/gcc/toplev.c:2010
#21 toplev::main (this=this@entry=0x7fffd180, argc=argc@entry=20, 
argv=0x15daf20, argv@entry=0x7fffd288) at [...]/source-gcc/gcc/toplev.c:2144
#22 0x00552717 in main (argc=20, argv=0x7fffd288) at 
[...]/source-gcc/gcc/main.c:39

(Com

Re: Debugging offload compiler ICEs

[Richard Biener]

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 ends invoked from the target compilation's
>> > collect2 process, via the respective offloading toolchain's mkoffload.
>
>> Does -v -save-temps not provide enough info to re-launch the lto1 process?
>
> Actually, given very limited testing I have just done, that indeed seems
> to work fine now, for re-running the actual offload compiler invocation
> (driver as well as lto1 directly).  Good!  (As far as I remember, it used
> not to work a few months ago, with relevant files not having been
> preserved; that'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

[Thomas Schwinge]

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 the respective offloading toolchain's mkoffload.

> Does -v -save-temps not provide enough info to re-launch the lto1 process?

Actually, given very limited testing I have just done, that indeed seems
to work fine now, for re-running the actual offload compiler invocation
(driver as well as lto1 directly).  Good!  (As far as I remember, it used
not to work a few months ago, with relevant files not having been
preserved; that'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.


Grüße
 Thomas

Re: Debugging offload compiler ICEs

[Richard Biener]

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 my knowledge, it's not possible to use the target
> compiler's "-wrapper" option to have GDB step into an offloading
> compilation's mkoffload/lto1, or if it is (GDB follow-fork-mode "child"
> maybe?), then it's very cumbersome.
>
> A while ago, I came up with the following hack to make the (offloading)
> compiler pause if an ICE is hit.  This will then result in a message on
> stderr (that is, in the current offloading compilation's /tmp/cc*.le
> file...), about which PID to attach to ("gdb -p [PID]").

Does -v -save-temps not provide enough info to re-launch the lto1 process?

Richard.

> --- gcc/diagnostic.c
> +++ gcc/diagnostic.c
> @@ -40,6 +40,16 @@ along with GCC; see the file COPYING3.  If not see
>  # include 
>  #endif
>
> +#include 
> +void wait_for_debugger()
> +{
> +  // In case that Yama LSM is enabled in mode 1 ("restricted ptrace").
> +  prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0);
> +  fprintf(stderr, "Attach debugger to pid %d\n", getpid());
> +  while (pause() == EINTR)
> +;
> +}
> +
>  #define pedantic_warning_kind(DC)  \
>((DC)->pedantic_errors ? DK_ERROR : DK_WARNING)
>  #define permissive_error_kind(DC) ((DC)->permissive ? DK_WARNING : DK_ERROR)
> @@ -486,6 +496,8 @@ diagnostic_action_after_output (diagnostic_context 
> *context,
> "with any bug report.\n"));
> fnotice (stderr, "See %s for instructions.\n", bug_report_url);
>
> +   wait_for_debugger();
> +
> exit (ICE_EXIT_CODE);
>}
>
>
> Posting this here (and will add a link to the Offloading wiki page) just
> in case this is useful for others, too.
>
>
> Grüße
>  Thomas

Debugging offload compiler ICEs

[Thomas Schwinge]

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 "-wrapper" option to have GDB step into an offloading
compilation's mkoffload/lto1, or if it is (GDB follow-fork-mode "child"
maybe?), then it's very cumbersome.

A while ago, I came up with the following hack to make the (offloading)
compiler pause if an ICE is hit.  This will then result in a message on
stderr (that is, in the current offloading compilation's /tmp/cc*.le
file...), about which PID to attach to ("gdb -p [PID]").

--- gcc/diagnostic.c
+++ gcc/diagnostic.c
@@ -40,6 +40,16 @@ along with GCC; see the file COPYING3.  If not see
 # include 
 #endif
 
+#include 
+void wait_for_debugger()
+{
+  // In case that Yama LSM is enabled in mode 1 ("restricted ptrace").
+  prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0);
+  fprintf(stderr, "Attach debugger to pid %d\n", getpid());
+  while (pause() == EINTR)
+;
+}
+
 #define pedantic_warning_kind(DC)  \
   ((DC)->pedantic_errors ? DK_ERROR : DK_WARNING)
 #define permissive_error_kind(DC) ((DC)->permissive ? DK_WARNING : DK_ERROR)
@@ -486,6 +496,8 @@ diagnostic_action_after_output (diagnostic_context *context,
"with any bug report.\n"));
fnotice (stderr, "See %s for instructions.\n", bug_report_url);
 
+   wait_for_debugger();
+
exit (ICE_EXIT_CODE);
   }
 

Posting this here (and will add a link to the Offloading wiki page) just
in case this is useful for others, too.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: add support for debugging output

[Richard Biener]

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:
>>
>> (simplify
>>   (plus @x integer_zerop)
>>   (non_lvalue @x)
>>   debug_out "Simplified pattern_foo")

Hmm.  Jakub requested to put back the (optional) naming of patterns.
So instead of just printing file:line we could name the pattern that applied.
Of course for

 (simplify "foo"
   (mult @x @y)
   (if (integer_zerop (@y))
  @y)
   (if (integer_onep (@y))
 @x))

it wouldn't distinguish both cases.

But yes, using the file:line in testcases makes them too volatile to
changes.

>> the corresponding change in gimple-match.c/generic-match.c would be:
>> if (dump_file && (dump_flags & TDF_DETAILS))
>> {
>>   fprintf (dump_file, "Applying pattern match.pd:161, %s:%d\n",
>> __FILE__, __LINE__);
>>   fprintf (dump_file, "Simplified pattern_foo\n");
>> }
> Transforms that involve subexpressions may return false, so it woudn't
> be correct to place debug_out there.

Hmm, why?  Ah, because if "seq" is NULL.

> maybe instead place debug_out string just above "return true;" ?

Yeah, we probably should move the existing debug output there.

So besides from putting naming of simplify patterns back we probably
need to add a counter for the transform inside it so we could print
"Applying simplification 2 in pattern foo" if we applied x * 1 -> x.
OTOH it doesn't tell you the full story either if it is

(for op (mult plus)
  (simplify
(op @x integer_zerop)
@x))

because ideally you'd want to know the operator that was used as well...
(so print "with op == mult"?).  What about commutates and conditional
converts?  In the end having both match.pd line and generated file
line gets me enough information for my debugging.

And for dump files all users of gimple_simplify add their own debug
dumping (which doesn't always tell the whole story).

(it's always a good idea to include a gcc mailing list in such discussions)

Richard.

> for the above pattern:
>
> /* #line 3 "plus.pd" */
> tree captures[2] ATTRIBUTE_UNUSED = {};
> captures[0] = op0;
> captures[1] = op1;
> if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file,
> "Applying pattern plus.pd:3, %s:%d\n", __FILE__, __LINE__);
> res_ops[0] = captures[0];
> *res_code = TREE_CODE (res_ops[0]);
> // add here
> if (dump_file && (dump_flags & TDF_DETAILS)) fprintf ("Simplified
> pattern_foo\n");
> return true;
>>
>> and in the test-cases we can simply grep for "Simplified pattern_foo".
>> sth like:
>>
>> int test (int x)
>> {
>>   int t1 = 0;
>>   int t2 = x + t1;
>>   return t2;
>> }
>> /* { dg-final { scan-tree-dump "Simplified pattern_foo" "ccp1" } } */
>>
>> or maybe introduce name to simplifiers ?
>> (simplify "pattern_foo"
>>   (plus @x integer_zerop)
>>   (non_lvalue @x))
>>
>> and corresponding gimple-match.c change:
>> fprintf (dump_file, "pattern_foo\n");
>>
>> (not sure if it's correct grepping for debug_out in test-cases, it
>> worked for the
>> above pattern though).
>>
>> Thanks.
>> Prathamesh

Debugging var-tracking problem

[Michael Collison]

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 it has not. I have 
reduced my case to a candidate set of basic blocks and a (candidate) RTL 
location this is continually removed/added. The rtl location is:


dataflow difference found: removal of:
 name: D#255
   offset 0
 (mem/f/c:SI (value/u:SI 106:3955 @0x22cb2f8/0x23424a0) [3 
result.d+0 S4 A32])


I understand that the argument to 'VALUE" is a cselib_val_struct but I 
don't know how to map this back to a insn that is causing the problem. 
Any thoughts on how I might debug thus further?


Regards,

Michael Collison
michael.colli...@linaro.org

Re: Debugging LTO.

[Tobias Burnus]

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.

[Tejas Belagod]

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 objects? AFAICS, this page


 https://gcc.gnu.org/wiki/LinkTimeOptimization

says such a reader is still a TODO.

Thanks,
Tejas.

Re: Debugging C++ Function Calls

[Tom Tromey]

> "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 not
locally visible.

Lawrence> There is a weakness in the patch, int that the following is legal.
[...]

Thanks.

Tom

Re: Debugging C++ Function Calls

[Lawrence Crowl]

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 recreate the name lookup as the compiler did, I think the
approach will be workable.  Otherwise, there is a potential for
doing overload resoulution and getting a different result.  I don't
think the template names directly make much difference here.

There is a weakness in the patch, int that the following is legal.

template T func(T arg) { return arg + 0; }
template<> int func(int arg) { return arg + 1; }
int func(int arg) { return arg + 2; }
int main() { return func(0); }

The language prefers to call a non-template function over a template
instance with the same paramter types.

So, in your new search, you could have two functions with the same
name and same parameter types.  You will need to keep a bit on the
template-derived version so that you can break the tie.

-- 
Lawrence Crowl

Re: Debugging C++ Function Calls

[Gabriel Dos Reis]

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

[Tom Tromey]

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

[Richard Biener]

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 gdb won't be instantiating.
> Lawrence> The critical distinction is that I'm not trying to call arbitrary
> Lawrence> expressions (which would have a SFINAE problem) but call expressions
> Lawrence> that already appear in the source.
>
> Thanks.
> I will think about it.
>
> Lawrence> I agree that the best long-term 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
> 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

[Tom Tromey]

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

Tom

Re: Debugging C++ Function Calls

[Lawrence Crowl]

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 instantiating.
> Lawrence> The critical distinction is that I'm not trying to call arbitrary
> Lawrence> expressions (which would have a SFINAE problem) but call
> expressions
> Lawrence> that already appear in the source.
>
> Thanks.
> I will think about it.
>
> Lawrence> I agree that the best long-term 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
> 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 time to identify some of
> the things that make it slow and file a few bug reports...
>
> Lawrence> I don't know anything about gdb internals, so it may not be
> helpful
> Lawrence> for me to look at it.
>
> Sure, but maybe for a critique of the approach.  But only if you are
> interested.

Sure, send it.

-- 
Lawrence Crowl

Re: Debugging C++ Function Calls

[Tom Tromey]

>>>>> "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 is that I'm not trying to call arbitrary
Lawrence> expressions (which would have a SFINAE problem) but call expressions
Lawrence> that already appear in the source.

Thanks.
I will think about it.

Lawrence> I agree that the best long-term 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
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 time to identify some of
the things that make it slow and file a few bug reports...

Lawrence> I don't know anything about gdb internals, so it may not be helpful
Lawrence> for me to look at it.

Sure, but maybe for a critique of the approach.  But only if you are
interested.

Tom

Debugging C++ Function Calls

[Lawrence Crowl]

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.  However, gdb
> Lawrence> has a slightly easier task in that it won't be doing instantiation
> Lawrence> (as that expression has already instantiated everything it needs)
> Lawrence> and so it need only pick among what exists.
>
> Yeah, what isn't clear to me is that even this can be done in a
> behavior-preserving way, at least short of having full source available
> and the entire compiler in the debugger.
>
> I'd be very pleased to be wrong, but my current understanding is that
> one can play arbitrary games with SFINAE to come up with code that
> defeats any less complete solution.

Hm.  I haven't thought about this deeply, but I think SFINAE may
not be less of an issue because it serves to remove candidates
from potential instantiation, and gdb won't be instantiating.
The critical distinction is that I'm not trying to call arbitrary
expressions (which would have a SFINAE problem) but call expressions
that already appear in the source.

I agree that the best long-term solution is an integrated compiler,
interpreter, and debugger.  That's not likely to happen soon.  :-)

>
> Sergio is going to look at this area again.  So if you know differently,
> it would be great to have your input.
>
> I can dig up the current ("pending" -- but really unreviewed for a few
> years for the above reasons) gdb patch if you are interested.  I believe
> it worked by applying overload-resolution-like rules to templates
> (though it has been a while).

I don't know anything about gdb internals, so it may not be helpful
for me to look at it.

-- 
Lawrence Crowl

Better debugging with!

[Alec Teal]

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 
(4 bytes) (you could go long...) and it'd be really convenient if you 
didn't have to tell gdb how big of an array to pretend it is, why not 
tell it in code? This'd be great! It already knows about pointers so 
this is just a simple step:



int n = 10;
#GDB_PAY_ATTENTION int n
MyType* arrayOfSorts = (MyType*) malloc(n*sizeof(MyType));

(not a word about calloc)

the int after ATTENTION is just if you had MASSIVE arrays beyond the 
bounds of an unsigned int (could happen, who am I to prevent that, in 
theory) perhaps int could be implicit, followed by the variable name or 
constant size of the array.


This should just tell GDB to pay attention to the NEXT STATEMENT ONLY 
and the first statement on that line (incase you can think of some weird 
way this would mean re-writing something currently valid):


struct Vertex {
float x;
float y;
float z;
};

int n = 100*3;
#GDB_PAY_ATTENTION n
float* points = malloc(n*sizeof(float));
int k = n / 3;
#GDB_PAY_ATTENTION k
Vertex* vertices = (Vertex*) points;

Obviously not GDB_PAY_ATTENTION, that's supposed to be humour because I 
have no ideas for a name yet.


I also see no reason not to allow "n" to be an expression? with the K 
above an optimizer will have it's way with that anyway as k isn't used 
after, you get the idea!


Alec

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

On Tue, Nov 27, 2012 at 8:54 AM, Tom Tromey  wrote:
>>>>>> "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 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 improvement from GDB.  This
> Gaby> is not useful only to the small GCC community.  It is very useful to
> Gaby> the wider GDB/C++ user community.
>
> There is no way for gdb to do anything about this generically.
> Richard is talking about a situation like:
>
> print overload(0xf)
>
> gdb can't know what the user meant here.
>
> Maybe it is possible with some application-specific knowledge, for
> example if you could tell the type of an object from its address.
> In this case it can be done by gcc, via Python scripts for gdb.
>
> Tom

Thanks for the clarification.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

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

[Richard Biener]

On Tue, Nov 27, 2012 at 4:06 PM, Diego Novillo  wrote:
> On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener
>  wrote:
>
>> Just to add another case which seems to be not covered in the thread.
>> When dumping from inside a gdb session in many cases I cut&paste
>> addresses 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.
>
> Thanks.  I think python helpers would probably be a good idea.  I tend
> to use $nn instead of the numeric values.  The $nn variables are
> typed.

me too, just when you do debug_tree ($1) you then don't have $nn for
all of the trees referenced from the output ;)

Richard.

>
> Diego.

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

On Sun, Nov 25, 2012 at 8:45 AM, Richard Biener
 wrote:

> Just to add another case which seems to be not covered in the thread.
> When dumping from inside a gdb session in many cases I cut&paste
> addresses 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.

Thanks.  I think python helpers would probably be a good idea.  I tend
to use $nn instead of the numeric values.  The $nn variables are
typed.


Diego.

Re: Unifying the GCC Debugging Interface

[Tom Tromey]

>>>>> "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 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 improvement from GDB.  This
Gaby> is not useful only to the small GCC community.  It is very useful to
Gaby> the wider GDB/C++ user community.

There is no way for gdb to do anything about this generically.
Richard is talking about a situation like:

print overload(0xf)

gdb can't know what the user meant here.

Maybe it is possible with some application-specific knowledge, for
example if you could tell the type of an object from its address.
In this case it can be done by gcc, via Python scripts for gdb.

Tom

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener
 wrote:

> Just to add another case which seems to be not covered in the thread.
> When dumping from inside a gdb session in many cases I cut&paste
> addresses 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.

this means that we need an improvement from GDB.  This
is not useful only to the small GCC community.  It is very useful to
the wider GDB/C++ user community.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Richard Biener]

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 overloading to unify the interface to a small
> set of function names.  Every major data type should have associated
> debug/dump functionality.  We will unify the current *_dump/*_debug
> functions under the same common overloaded name.

Just to add another case which seems to be not covered in the thread.
When dumping from inside a gdb session in many cases I cut&paste
addresses 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.

Richard.

> We intend to only apply this approach to functions that take the
> type to display as an argument, and that are routinely used in
> debugging.
>
> We propose to provide several function overload sets, as below.
>
>
> dump_pretty
>
> This function overload set provides the bulk of the printing.
> They will use the existing pretty-printer functions in their
> implementation.
>
> dump_raw
>
> This function overload set provides the raw oriented dump,
> e.g. a tuple.
>
> dump_verbose
>
> This function overload set provides the extra details dump.
>
>
> All of these functions come in two forms.
>
> function (FILE *, item_to_dump, formatting)
> function (item_to_dump, formatting)
>
> If the FILE* is not specified, the output is to stderr.  The
> formatting argument is optional, with a default suitable to the kind
> of item to dump.
>
>
> We should remove tree-browser.c.  It is not used at all and it is
> likely broken.
>
> --
> Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

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 general improvement projects wiki:
http://gcc.gnu.org/wiki/ImprovementProjects



Diego.

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

On Wed, Nov 21, 2012 at 9:02 AM, Ian Lance Taylor  wrote:
> On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis
>  wrote:
>> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl  wrote:
>>
>>> And, as a side note, highly formatted output generally is not
>>> much better 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
>> debugging routines and in-memory formatting, IOStreams are
>> very handy.
>
> I'm not deeply against iostreams, but I don't see that they bring us
> any significant advantages over what we already have.  We already have
> typed check formatting, we can already write to a memory buffer.  It
> took a lot of work to get there, but that work has been done.  It's
> quite unlikely that we would ever want to use iostreams for
> user-visible compiler output, because there is no straightforward
> support for localization.

As I said earlier, our homegrown IO with localization is probably much
better than what bare bones C++ IOstreams offer, so we are all
in agreement over this.

> So we are only talking about dump files and
> debug output.

Yes.

>  What parts of the compiler would be clearly better if
> we used iostreams?

Having to hardcode the format specifiers means that we
are either restricted in changes or bound to (silent
truncation) errors when we change representation.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Ian Lance Taylor]

On Wed, Nov 21, 2012 at 3:18 AM, Gabriel Dos Reis
 wrote:
> On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl  wrote:
>
>> And, as a side note, highly formatted output generally is not
>> much better 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
> debugging routines and in-memory formatting, IOStreams are
> very handy.

I'm not deeply against iostreams, but I don't see that they bring us
any significant advantages over what we already have.  We already have
typed check formatting, we can already write to a memory buffer.  It
took a lot of work to get there, but that work has been done.  It's
quite unlikely that we would ever want to use iostreams for
user-visible compiler output, because there is no straightforward
support for localization.  So we are only talking about dump files and
debug output.  What parts of the compiler would be clearly better if
we used iostreams?

Ian

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

I forgot to add this important information: you don't get the nifty
counters if you don't include .  Specifically.
That means including  or  does not
introduce any nifty counter. Including , which
allows you to perform in-memory formatted IO, does not
introduce any nifty counter.  Said, differently, the worry
about IOStreams introducing unnecessary "static
constructor" is either overblown or misplaced, or both.

-- Gaby

On Wed, Nov 21, 2012 at 8:25 AM, Gabriel Dos Reis
 wrote:
> On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser  wrote:
>
>> Is it correct to state that every translation unit that includes iostream
>> will include the iostream static constructors?
>
> C++ requires the definitions of globals such as std::cin, std::cout,
> and std::cerr
> that must be contructed (by any magic) before users attempt to use them.  To 
> aid
> with this, the C++ standard formalizes the programming pattern known as
> `nifty counter' in the form of the class std::ios_base::Init such that
> (quoting C++)
>
>The class Init describes an object whose construction ensures the
>construction of the eight objects declared in  (27.4)
> that associate
>file stream buffers with the standard C streams provided for by the
>functions declared in  (27.9.2).
>
> Whether a compiler decides to implement this with "static constructor" is
> an implementation detail issue.  Of course, since no object is constructed
> more than once, no actual iostream object constructor is run more than
> once.  You can see how we implemented this in libstdc++
>
> 
> http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc?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 and you are worrying
> about the wrong thing.  Every translation unit that includes 
> gets a static global variable of an empty class type (therefore occupying
> 1 byte).   See
>
> 
> http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/std/iostream?revision=184997&view=markup
>
>  That 1 byte triggers a *dynamic* intialization from the corresponding
> translation unit.  However, the actual iostream objects are constructed
> only once.
>
>>
>>
>>> e of it. Only the translation that includes
>>> iostream gets the niftty counters.
>>>
>>> Furthermore, not including iostream does not mean you don't
>>> get static constructors -- GCC has lot of global variables and if
>>> any of them incures dynamic initialization, you get
>>> dynamic initialization.  Note also that if you explicitly delay
>>> initialization to runtime, you are going to pay for it anyway
>>> through brittle manual initialization.
>>
>>
>> I was mainly interested in compering FILE* and iostream. To my knowledge the
>> FILE* interface does not have any significant construction overhead.
>
> You are kidding me, right?
>
> Anyway, I think you are focusing on the wrong thing.
> For GCC's homegrown IO occurs far more overhead than
> you appear to believe - I am saying this from my work on the
> diagnostic machinery; we can do a better job if we had
> a more typed interface.  This is true not only for the
> diagnostic machinery, which is partly used by the various
> debug systems, but also of the debug systems themselves.
> You are worrying about something I suspect you would not be able to
> measure compared to the performance of the existing
> debug systems.
>
> -- Gaby

Re: Unifying the GCC Debugging Interface

[Tobias Grosser]

On 11/21/2012 03:25 PM, Gabriel Dos Reis wrote:

On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser  wrote:


Is it correct to state that every translation unit that includes iostream
will include the iostream static constructors?


C++ requires the definitions of globals such as std::cin, std::cout,
and std::cerr
that must be contructed (by any magic) before users attempt to use them.  To aid
with this, the C++ standard formalizes the programming pattern known as
`nifty counter' in the form of the class std::ios_base::Init such that
(quoting C++)

The class Init describes an object whose construction ensures the
construction of the eight objects declared in  (27.4)
that associate
file stream buffers with the standard C streams provided for by the
functions declared in  (27.9.2).

Whether a compiler decides to implement this with "static constructor" is
an implementation detail issue.  Of course, since no object is constructed
more than once, no actual iostream object constructor is run more than
once.  You can see how we implemented this in libstdc++

 
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc?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 and you are worrying
about the wrong thing.  Every translation unit that includes 
gets a static global variable of an empty class type (therefore occupying
1 byte).   See

 
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/std/iostream?revision=184997&view=markup

  That 1 byte triggers a *dynamic* intialization from the corresponding
translation unit.  However, the actual iostream objects are constructed
only once.





e of it. Only the translation that includes
iostream gets the niftty counters.

Furthermore, not including iostream does not mean you don't
get static constructors -- GCC has lot of global variables and if
any of them incures dynamic initialization, you get
dynamic initialization.  Note also that if you explicitly delay
initialization to runtime, you are going to pay for it anyway
through brittle manual initialization.



I was mainly interested in compering FILE* and iostream. To my knowledge the
FILE* interface does not have any significant construction overhead.


You are kidding me, right?

Anyway, I think you are focusing on the wrong thing.
For GCC's homegrown IO occurs far more overhead than
you appear to believe - I am saying this from my work on the
diagnostic machinery; we can do a better job if we had
a more typed interface.  This is true not only for the
diagnostic machinery, which is partly used by the various
debug systems, but also of the debug systems themselves.
You are worrying about something I suspect you would not be able to
measure compared to the performance of the existing
debug systems.


I was not too much worried. Just very interested in some judgment.

Thanks a lot for the nice explanation

Tobias

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

On Wed, Nov 21, 2012 at 7:48 AM, Tobias Grosser  wrote:

> Is it correct to state that every translation unit that includes iostream
> will include the iostream static constructors?

C++ requires the definitions of globals such as std::cin, std::cout,
and std::cerr
that must be contructed (by any magic) before users attempt to use them.  To aid
with this, the C++ standard formalizes the programming pattern known as
`nifty counter' in the form of the class std::ios_base::Init such that
(quoting C++)

   The class Init describes an object whose construction ensures the
   construction of the eight objects declared in  (27.4)
that associate
   file stream buffers with the standard C streams provided for by the
   functions declared in  (27.9.2).

Whether a compiler decides to implement this with "static constructor" is
an implementation detail issue.  Of course, since no object is constructed
more than once, no actual iostream object constructor is run more than
once.  You can see how we implemented this in libstdc++


http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc?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 and you are worrying
about the wrong thing.  Every translation unit that includes 
gets a static global variable of an empty class type (therefore occupying
1 byte).   See


http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/std/iostream?revision=184997&view=markup

 That 1 byte triggers a *dynamic* intialization from the corresponding
translation unit.  However, the actual iostream objects are constructed
only once.

>
>
>> e of it. Only the translation that includes
>> iostream gets the niftty counters.
>>
>> Furthermore, not including iostream does not mean you don't
>> get static constructors -- GCC has lot of global variables and if
>> any of them incures dynamic initialization, you get
>> dynamic initialization.  Note also that if you explicitly delay
>> initialization to runtime, you are going to pay for it anyway
>> through brittle manual initialization.
>
>
> I was mainly interested in compering FILE* and iostream. To my knowledge the
> FILE* interface does not have any significant construction overhead.

You are kidding me, right?

Anyway, I think you are focusing on the wrong thing.
For GCC's homegrown IO occurs far more overhead than
you appear to believe - I am saying this from my work on the
diagnostic machinery; we can do a better job if we had
a more typed interface.  This is true not only for the
diagnostic machinery, which is partly used by the various
debug systems, but also of the debug systems themselves.
You are worrying about something I suspect you would not be able to
measure compared to the performance of the existing
debug systems.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Tobias Grosser]

On 11/21/2012 02:33 PM, Gabriel Dos Reis wrote:

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, formatting)
   function (item_to_dump, formatting)



Since we have switched to C++, it would be really nice to have dump
functions
writing to a C++ std::ostream



If I understood correctly, including iostream may (depending on your c++
library) introduce static constructors in every translation unit.


This is obviously false on the fac


Sorry. I did not express this carefully.

Also, I probably did not make clear that I am not proposing to not use 
iostream, but rather asking of someone knowledgeable who understands the 
costs.


Is it correct to state that every 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?



e of it. Only the translation that includes
iostream gets the niftty counters.

Furthermore, not including iostream does not mean you don't
get static constructors -- GCC has lot of global variables and if
any of them incures dynamic initialization, you get
dynamic initialization.  Note also that if you explicitly delay
initialization to runtime, you are going to pay for it anyway
through brittle manual initialization.


I was mainly interested in compering FILE* and iostream. To my knowledge 
the FILE* interface does not have any significant construction overhead.



This could
negatively impact the startup time of gcc.


Do you have concrete data point on this specific case?
(I am not asking for artificial benchmark)


No. I just heard about it and wanted to verify that this is a non-issue.


The cost you get with iostream isn't with dynamic
intiialization, it is with something else (notably locales.)


Thanks for the pointer.

Cheers
Tobi

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

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, formatting)
>   function (item_to_dump, formatting)
>>
>>
>> Since we have switched to C++, it would be really nice to have dump
>> functions
>> writing to a C++ std::ostream
>
>
> If I understood correctly, including iostream may (depending on your c++
> library) introduce static constructors in every translation unit.

This is obviously false on the face of it. Only the translation that includes
iostream gets the niftty counters.

Furthermore, not including iostream does not mean you don't
get static constructors -- GCC has lot of global variables and if
any of them incures dynamic initialization, you get
dynamic initialization.  Note also that if you explicitly delay
initialization to runtime, you are going to pay for it anyway
through brittle manual initialization.

> This could
> negatively impact the startup time of gcc.

Do you have concrete data point on this specific case?
(I am not asking for artificial benchmark)

The cost you get with iostream isn't with dynamic
intiialization, it is with something else (notably locales.)

> LLVM explicitly forbids the use. If we allow it, it would be good if a more
> knowledgeable person thought about the possible overhead.

LLVM forbids lot of good things.  If your competition is LLVM, you don't
win by repeated the same mistakes.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Tobias Grosser]

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 would be really nice to have dump functions
writing to a C++ std::ostream


If I understood correctly, including iostream may (depending on your c++ 
library) introduce static constructors in every translation unit. This 
could negatively impact the startup time of gcc.


LLVM explicitly forbids the use. If we allow it, it would be good if a 
more knowledgeable person thought about the possible overhead.


Cheers
Tobi

Re: Unifying the GCC Debugging Interface

[Michael Matz]

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, but it's harder to use in the debugger.
> >
> > As long as all these different objects share the same data
> > structure, we will need to have different named entry points.
> > Ideally they would all respond to 'dump(t)' and overloading will
> > figure it out automatically.  For now, we'll need dump_function,
> > dump_tree, dump_generic, and we may need a few more.
> 
> Diego and I talked about this a bit more, and would like to explore
> a set of dump names that distinguish between dumping the head of
> an item and its body.  In essence, the former asks for the function
> declaration, the latter its definition.
> 
> Comments?

Sounds useful for functions.  But what other items do you have in mind?  
What's the head of a PLUS_EXPR, or generally a tree that isn't DECL_P, or 
of a gimple_seq or an CFG edge?  For the two latter I could conconct some 
artificial definition of head, but it would feel arbitrary.


Ciao,
Michael.

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

On Wed, Nov 21, 2012 at 5:37 AM, Theodore Papadopoulo
 wrote:
> 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 for some
> improvement Everyone will win if this works better

Fully agreed.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Theodore Papadopoulo]

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 for some 
improvement Everyone will win if this works better


Slightly off topic of course, but...

Theo.

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

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 define them?

-- Gaby

Re: Unifying the GCC Debugging Interface

[Gabriel Dos Reis]

On Tue, Nov 20, 2012 at 6:16 PM, Lawrence Crowl  wrote:

> And, as a side note, highly formatted output generally is not
> much better 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
debugging routines and in-memory formatting, IOStreams are
very handy.

-- Gaby

Re: Unifying the GCC Debugging Interface

[Xinliang David Li]

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:

#include 
using namespace std;

class A {
public:
int i;
};

__attribute__((noinline)) void print (ostream& os, const A& a) { os <<
a.i << endl ; }

__attribute__((noinline)) void operator<< (ostream& os,  const A& a)
{
   os << a.i << endl;
}


int main()
{

   A a;

   cout << a;
   print (cout, a);

On Tue, Nov 20, 2012 at 4:37 PM, Lawrence Crowl  wrote:
> On 11/20/12, Xinliang David Li  wrote:
>> one minus -- less gdb friendly.
>
> Do you mean that gdb does not handle the stream expressions
> or something else?
>
>>
>> David
>>
>> On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl  wrote:
>>> On 11/20/12, Diego Novillo  wrote:
>>>> On Nov 20, 2012 Basile Starynkevitch  wrote:
>>>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>>>> > > 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 functions writing to a C++ std::ostream
>>>>
>>>> I'm not sure what to think about using streams.  I have no great
>>>> familiarity with them, so I can't say whether they provide any
>>>> concrete advantages over dumping to FILE objects.  Additionally,
>>>> the rest of the compiler uses FILE objects for I/O.  How do the
>>>> two stay in sync?
>>>
>>> There 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
>>>  << " 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 chars to a string.
>>>
>>> The primary disadvantage is that to exploit that those advantages,
>>> you need to convert all of the debugging/dumping I/O to use streams.
>>>
>>> And, as a side note, highly formatted output generally is not
>>> much better than printf.  For any text that needs to be localized,
>>> I recommend that we stick with what we have.
>>>
>>> --
>>> Lawrence Crowl
>>
>
>
> --
> Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Lawrence Crowl]

On 11/20/12, Xinliang David Li  wrote:
> one minus -- less gdb friendly.

Do you mean that gdb does not handle the stream expressions
or something else?

>
> David
>
> On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl  wrote:
>> On 11/20/12, Diego Novillo  wrote:
>>> On Nov 20, 2012 Basile Starynkevitch  wrote:
>>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>>> > > 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 functions writing to a C++ std::ostream
>>>
>>> I'm not sure what to think about using streams.  I have no great
>>> familiarity with them, so I can't say whether they provide any
>>> concrete advantages over dumping to FILE objects.  Additionally,
>>> the rest of the compiler uses FILE objects for I/O.  How do the
>>> two stay in sync?
>>
>> There 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
>>  << " 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 chars to a string.
>>
>> The primary disadvantage is that to exploit that those advantages,
>> you need to convert all of the debugging/dumping I/O to use streams.
>>
>> And, as a side note, highly formatted output generally is not
>> much better than printf.  For any text that needs to be localized,
>> I recommend that we stick with what we have.
>>
>> --
>> Lawrence Crowl
>


-- 
Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Xinliang David Li]

one minus -- less gdb friendly.

David

On Tue, Nov 20, 2012 at 4:16 PM, Lawrence Crowl  wrote:
> On 11/20/12, Diego Novillo  wrote:
>> On Nov 20, 2012 Basile Starynkevitch  wrote:
>> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
>> > > 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 functions writing to a C++ std::ostream
>>
>> I'm not sure what to think about using streams.  I have no great
>> familiarity with them, so I can't say whether they provide any
>> concrete advantages over dumping to FILE objects.  Additionally,
>> the rest of the compiler uses FILE objects for I/O.  How do the
>> two stay in sync?
>
> There 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
>  << " 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 chars to a string.
>
> The primary disadvantage is that to exploit that those advantages,
> you need to convert all of the debugging/dumping I/O to use streams.
>
> And, as a side note, highly formatted output generally is not
> much better than printf.  For any text that needs to be localized,
> I recommend that we stick with what we have.
>
> --
> Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Lawrence Crowl]

On 11/20/12, Diego Novillo  wrote:
> On Nov 20, 2012 Basile Starynkevitch  wrote:
> > On Tue, Nov 20, 2012 at 11:24:40AM -0800, Lawrence Crowl wrote:
> > > 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 functions writing to a C++ std::ostream
>
> I'm not sure what to think about using streams.  I have no great
> familiarity with them, so I can't say whether they provide any
> concrete advantages over dumping to FILE objects.  Additionally,
> the rest of the compiler uses FILE objects for I/O.  How do the
> two stay in sync?

There 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
 << " 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 chars to a string.

The primary disadvantage is that to exploit that those advantages,
you need to convert all of the debugging/dumping I/O to use streams.

And, as a side note, highly formatted output generally is not
much better than printf.  For any text that needs to be localized,
I recommend that we stick with what we have.

-- 
Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

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)
>
> Since we have switched to C++, it would be really nice to have dump functions
> writing to a C++ std::ostream

I'm not sure what to think about using streams.  I have no great
familiarity with them, so I can't say whether they provide any
concrete advantages over dumping to FILE objects.  Additionally, the
rest of the compiler uses FILE objects for I/O.  How do the two stay
in sync?


Diego.

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

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.  With free functions, we
don't have this issue.

I'm not opposed to having them be member functions.  It's just that
the free functions will still be needed.


Diego.

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

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 overload set provides the bulk of the printing.
>>  They will use the existing pretty-printer functions in their
>>  implementation.
>
> Since this is the one that would be most commonly used, could we just call
> it "dump"?

I think it makes sense, yeah.

> assuming there aren't any varargs, why not simply move the 'FILE *'
> parameter to the end, default it to STDERR, and then only have the one
> function...  I'm certainly not locked into the old style must-have-FILE
> first paradigm.

Yes, good point.


Diego.

Re: Unifying the GCC Debugging Interface

[Martin Jambor]

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 perspective, but it's harder to use in the debugger.
> >
> > As long as all these different objects share the same data
> > structure, we will need to have different named entry points.
> > Ideally they would all respond to 'dump(t)' and overloading will
> > figure it out automatically.  For now, we'll need dump_function,
> > dump_tree, dump_generic, and we may need a few more.
> 
> Diego and I talked about this a bit more, and would like to explore
> a set of dump names that distinguish between dumping the head of
> an item and its body.  In essence, the former asks for the function
> declaration, the latter its definition.
> 
> Comments?

Well, it sounds a bit too artificial to me, but I can live with
remembering that dump_head is actually dump_generic and dump_body is
dump_tree... or would it be dump_function?

I still think that (as a first step) if you can reduce the number of
dump function names only somewhat and make their parameters consistent
in the process, it will help a lot (and will be quite some work).  If
you then want to continue unifying the names more, you'll be able to
do it easily and immediately see what makes sense and what does not.

Martin

Re: Unifying the GCC Debugging Interface

[Xinliang David Li]

This can be simplified further -- there should be one print method for
every class/struct entity as a member method

enum print_flags
{
   print_pretty = 0x1,
   print_decl_only = 0x2,
   print_raw  = 0x4,
   ..
};

class bitmap {
   public:
  void print_me (print_flags flags = print_pretty, FILE *stream = stderr);
 ...
};

class vector {
public:
  void print_me (print_flags flags = print_pretty, FILE *stream = stderr);
...
};

class cgraph_node {
   public:
void print_me (...);
}..


Example:

decl->print_me (); // dump pretty form of the decl to stderr

decl->print_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 type you have.
>
> We propose to rely on overloading to unify the interface to a small
> set of function names.  Every major data type should have associated
> debug/dump functionality.  We will unify the current *_dump/*_debug
> functions under the same common overloaded name.
>
> We intend to only apply this approach to functions that take the
> type to display as an argument, and that are routinely used in
> debugging.
>
> We propose to provide several function overload sets, as below.
>
>
> dump_pretty
>
> This function overload set provides the bulk of the printing.
> They will use the existing pretty-printer functions in their
> implementation.
>
> dump_raw
>
> This function overload set provides the raw oriented dump,
> e.g. a tuple.
>
> dump_verbose
>
> This function overload set provides the extra details dump.
>
>
> All of these functions come in two forms.
>
> function (FILE *, item_to_dump, formatting)
> function (item_to_dump, formatting)
>
> If the FILE* is not specified, the output is to stderr.  The
> formatting argument is optional, with a default suitable to the kind
> of item to dump.
>
>
> We should remove tree-browser.c.  It is not used at all and it is
> likely broken.
>
> --
> Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Basile Starynkevitch]

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 functions 
writing to a C++ std::ostream

Plugins would be very happy if the output stream was a C++ one (at least MELT 
certainly will be happy).
Otherwise, they may spend a lot of boring effort to make that happen 
(and fmemopen is less standard than std::ostream).

So please, let's dump to some std::ostream; it is much easy to use other 
streams 
(e.g. ostringstream-s) for other purposes (I am guessing that every language 
binding 
to plugins -we have MELT, Python, Lua, already) will be really happy to at 
least be able to output to some memory buffer (and with ostream-s, we have much 
more).

Ideally, we could have some default formatting and even get some operator << 


Cheers.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Unifying the GCC Debugging Interface

[Lawrence Crowl]

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 bulk of the printing.
>>  They will use the existing pretty-printer functions in their
>>  implementation.
>
> Since this is the one that would be most commonly used, could we
> just call it "dump"?

We will almost certainly want to name one of them just dump.
We chose to be verbose in this discussion so that we have a clearer
idea of what we intend for each.

>> dump_raw
>>
>>  This function overload set provides the raw oriented dump,
>>  e.g. a tuple.
>>
>> dump_verbose
>>
>>  This function overload set provides the extra details dump.
>>
>>
>> All of these functions come in two forms.
>>
>>  function (FILE *, item_to_dump, formatting)
>>  function (item_to_dump, formatting)
>>
>> If the FILE* is not specified, the output is to stderr.  The
>> formatting argument is optional, with a default suitable to the kind
>> of item to dump.
>
> assuming there aren't any varargs, why not simply move the 'FILE *'
> parameter to the end, default it to STDERR, and then only have the one
> function...  I'm certainly not locked into the old style must-have-FILE
> first paradigm.
>
> Although I guess then you have the issue of default formatting when you
> don't have a default FILE...  Which I guess is probably more important.
>  OK , 2 functions is probably better since one is just a wrapper
> anyway :-)

Yes, when you want to default two different things equally, it makes
sense to do the overload.  (The current proposal assumes that one
does not need to dump a FILE.)

-- 
Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Lawrence Crowl]

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, but it's harder to use in the debugger.
>
> As long as all these different objects share the same data
> structure, we will need to have different named entry points.
> Ideally they would all respond to 'dump(t)' and overloading will
> figure it out automatically.  For now, we'll need dump_function,
> dump_tree, dump_generic, and we may need a few more.

Diego and I talked about this a bit more, and would like to explore
a set of dump names that distinguish between dumping the head of
an item and its body.  In essence, the former asks for the function
declaration, the latter its definition.

Comments?

-- 
Lawrence Crowl

Re: Unifying the GCC Debugging Interface

[Andrew MacLeod]

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 bulk of the printing.
 They will use the existing pretty-printer functions in their
 implementation.
Since this is the one that would be most commonly used, could we just 
call it "dump"?

dump_raw

 This function overload set provides the raw oriented dump,
 e.g. a tuple.

dump_verbose

 This function overload set provides the extra details dump.





All of these functions come in two forms.

 function (FILE *, item_to_dump, formatting)
 function (item_to_dump, formatting)

If the FILE* is not specified, the output is to stderr.  The
formatting argument is optional, with a default suitable to the kind
of item to dump.


assuming there aren't any varargs, why not simply move the 'FILE *' 
parameter to the end, default it to STDERR, and then only have the one 
function...  I'm certainly not locked into the old style must-have-FILE 
first paradigm.


Although I guess then you have the issue of default formatting when you 
don't have a default FILE...  Which I guess is probably more important. 
OK , 2 functions is probably better since one is just a wrapper 
anyway :-)


Overall I like this as well.  Again, with my lousy memory for exact 
function names, I'm always grepping through the different print files to 
find the routine I'm looking for.   Standardizing them in name and 
format would be helpful.


Andrew

Re: Unifying the GCC Debugging Interface

[Diego Novillo]

On Mon, Nov 19, 2012 at 10:11 AM, 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, but it's harder to use in the debugger.

As long as all these different objects share the same data structure,
we will need to have different named entry points.  Ideally they would
all respond to 'dump(t)' and overloading will figure it out
automatically.  For now, we'll need dump_function, dump_tree,
dump_generic, and we may need a few more.


Diego.