Re: A proposal to align GCC stack
H.J. Lu writes: > What value did you use for -mpreferred-stack-boundary? The x86 backend > defaults to 16byte. On Windows the 16-byte default pretty much just wastes space, so I use -mpreferred-stack-boundary=2 where it might make a difference. In the case where I wanted to use SSE vector instructions, I explicitly used -mpreferred-stack-boundary=4 (16-byte alignment). >STACK_BOUNDARY is the minimum stack boundary. MAX(STACK_BOUNDARY, >PREFERRED_STACK_BOUNDARY) == PREFERRED_STACK_BOUNDARY. So the question is >if we should assume INCOMING == PREFERRED_STACK_BOUNDARY in all cases: Doing this would also remove need for ABI_STACK_BOUNDARY in your proposal. >Pros: > 1. Keep the current behaviour of -mpreferred-stack-boundary. > >Cons: > 1. The generated code is incompatible with the other object files. Well, your proposal wouldn't completely solve that problem, either. You can't guarantee compatiblity with object files compiled with different values -mpreferred-stack-boundary, including those compiled with current implementation, unless you assume the incomming stack is aligned to the lowest value the flag can have and align the outgoing stack to the highest value that the flag can have. Ross Ridge
Re: A proposal to align GCC stack
Ross Ridge writes: > As I mentioned later in my message STACK_BOUNDARY shouldn't be defined in > terms of hardware, but in terms of the ABI. While the i386 allows the > stack pointer to bet set to any value, by convention the stack pointer > is always kept 4-byte aligned at all times. GCC should never generate > code that that would violate this requirement, even in leaf-functions > or transitorily during the prologue/epilogue. H.J. Lu writes: > From gcc internal manual I'm suggesting a different defintion of STACK_BOUNDARY which wouldn't, if strictly followed, result STACK_BOUNDARY being defined as 8 on the i386. The i386 hardware doesn't enforce a minimum alignment on the stack pointer. > Since x86 always push/pop stack by decrementing/incrementing address > size, it makes senses to define STACK_BOUNDARY as address size. The i386 PUSH and POP instructions adjust stack pointer the by the operand size of the instruction. The address size of the instruction has no effect. For example, GCC should never generate code like this: pushw $0 pushw %ax because the stack is temporarily misaligned. This could result in a signal, trap, interrupt or other asynchronous handler using a misaligned stack. In context of your proposal, defining STACK_BOUNDARY this way, as a requirement imposed on GCC by an ABI (or at least by convention), not the hardware, is important. Without an ABI requirement, there's nothing that would prohibit an i386 leaf function from adjusting the stack in a way that leaves the stack 1- or 2-byte aligned. Ross Ridge
Re: A proposal to align GCC stack
On 12/18/07, Ross Ridge <[EMAIL PROTECTED]> wrote: > Look at it another way. Lets say you were compiling x86_64 code with > -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignment. Can we stop talking about x86/x86_64 specifics issues here? I have an use case for the PowerPC side of the Cell BE for variables greater than the normal stack boundary alignment of 16bytes. They need to be 128byte aligned for DMA transfering to the SPUs. I already proposed a patch [1] to fix this use case but I have not seen many replies yet. Thanks, Andrew Pinski [1] http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html
Re: A proposal to align GCC stack
Andrew Pinski writes: > Can we stop talking about x86/x86_64 specifics issues here? No. >I have an use case for the PowerPC side of the Cell BE for variables >greater than the normal stack boundary alignment of 16bytes. They need >to be 128byte aligned for DMA transfering to the SPUs. > >I already proposed a patch [1] to fix this use case but I have not >seen many replies yet. Complaining about someone talking about x86/x86_64 specific issues and then bringing up a PowerPC/Cell specific issue is probably not the best way to go about getting your patch approved. Ross Ridge
vliw scheduling - TImode bug?
Hello,
I see quite a few instances when i get the following RTL. A conditional
branch, followed by a BASIC_BLOCK note, followed by a non-TImode
instruction. Theoretically, i should be allowed to package the non-TI
instruction along with the conditional branch, but doing so seems to be
produce incorrect results. Am i supposed to consider the
NOTE_INSN_BASIC_BLOCK as a cycle-breaker? Or, is it a genuine bug in the
way TImodes are set on instructions?
(jump_insn:TI 144 225 17 2
/home/hariharans5/gcc-4.2.2/gcc/testsuite/gcc.c-torture/execute/931004-8.c:15
(parallel [
(set (pc)
(if_then_else (le:HI (reg:CC 17 pseudoCC)
(const_int 0 [0x0]))
(label_ref 109)
(pc)))
(use (const_int 77 [0x4d]))
]) 10 {*branch} (nil)
(expr_list:REG_DEAD (reg:CC 17 pseudoCC)
(expr_list:REG_BR_PROB (const_int 500 [0x1f4])
(nil
(note 17 144 124 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 124 17 21 3
("/home/hariharans5/gcc-4.2.2/gcc/testsuite/gcc.c-torture/execute/931004-8.c")
17)
(insn 21 124 196 3
/home/hariharans5/gcc-4.2.2/gcc/testsuite/gcc.c-torture/execute/931004-8.c:15
(set (reg:HI 3 R3)
(plus:HI (reg/f:HI 13 FP)
(const_int 12 [0xc]))) 31 {*lea_move} (nil)
(nil))
Thanks and regards
Hari
A proposal to align GCC stack - update
Thanks for Ross and HJ's comments. Here is updated proposal: Changes: - value of REQUIRED_STACK_BOUNDARY of leaf function - value of INCOMING_STACK_BOUNDARY -- 0. MOTIVATION -- Some local variables (such as of __m128 type or marked with alignment attribute) require stack aligned at a boundary larger than the default stack boundary. Current GCC partially supports this with limitations. We are proposing a new design to fully solve the problem. -- 1. CURRENT IMPLEMENTATION -- There are two ways current GCC supports bigger than default stack alignment. One is to make sure that stack is aligned at program entry point, and then ensure that for each non-leaf function, its frame size is aligned. This approach doesn't work when linking with libs or objects compiled by other psABI confirming compilers. Some problems are logged as PR 33721. Another is to adjust stack alignment at the entry point of a function if it is marked with __attribute__ ((force_align_arg_pointer)) or -mstackrealign option is provided. This method guarantees the alignment in most of the cases but with following problems and limitations: * Only 16 bytes alignment is supported * Adjusting stack alignment at each function prologue hurts performance unnecessarily, because not all functions need bigger alignment. In fact, commonly only those functions which have SSE variables defined locally (either declared by the user or compiler generated internal temporary variables) need corresponding alignment. * Doesn't support x86_64 for the cases when required stack alignment is > 16 bytes * Emits inefficient and complicated prologue/epilogue code to adjust stack alignment * Doesn't work with nested functions * Has a bug handling register parameters, which resulted in a cpu2006 failure. A patch is available as a workaround. -- 2. NEW PROPOSAL: DESIGN -- Here, we propose a new design to fully support stack alignment while overcoming above problems. The new design will * Support arbitrary alignment value, including 4,8,16,32... * Adjust function stack alignment only when necessary * Initial development will be on i386 and x86_64, but can be extended to other platforms * Emit more efficient prologue/epilogue code * Coexist with special features like dynamic stack allocation (alloca), nested functions, register parameter passing, PIC code and tail call optimization * Be able to debug and unwind stack 2.1 Support arbitrary alignment value Different source code and optimizations requires different stack alignment, as in following table: Feature Alignment (bytes) i386_ABI4 x86_64_ABI 16 char1 short 2 int 4 long4/8* long long 8 __m64 8 __m128 16 float 4 double 8 long double 16 user specified any power of 2 *Note: 4 for i386, 8 for x86_64 The new design will support any alignment value in this table. 2.2 Adjust function stack alignment only when necessary Current GCC defines following macros related to stack alignment: i. STACK_BOUNDARY in bits, which is preferred by hardware, 32 for i386 and 64 for x86_64. It is the minimum stack boundary. It is fixed. ii. PREFERRED_STACK_BOUNDARY. It sets the stack alignment when calling a function. It may be set at command line and has no impact on stack alignment at function entry. This proposal requires PREFERRED >= STACK, and by default set to ABI_STACK_BOUNDARY This design will define a few more macros, or concepts not explicitly defined in code: iii. ABI_STACK_BOUNDARY in bits, which is the stack boundary specified by psABI, 32 for i386 and 128 for x86_64. ABI_STACK_BOUNDARY >= STACK_BOUNDARY. It is fixed for a given psABI. iv. LOCAL_STACK_BOUNDARY in bits. Each function stack has its own stack alignment requirement, which depends the alignment of its stack variables, LOCAL_STACK_BOUNDARY = MAX (alignment of each effective stack variable). v. INCOMING_STACK_BOUNDARY in bits, which is the stack boundary at function entry. If a function is marked with __attribute__ ((force_align_arg_pointer)) or -mstackrealign option is provided, INCOMING = STACK_BOUNDARY. Otherwise, INCOMING == PREFERRED_STACK_BOUNDARY. For those function whose PREFERRED is larger than ABI, it is the caller's responsibility to invoke them with appropriate PREFERRED. vi. REQUIRED_STACK_ALIGNMENT in bits, which is stack alignment required by local variables and calling other function. REQUIRED_STACK_ALIGNMENT == MAX(LOCAL_STACK_BOUNDARY,PREFERRED_STACK_BOUNDARY) in case of a non-leaf function. For a leaf function, REQUIRED_STACK_ALIGNMENT == MAX(LOCAL_STACK_BOUNDARY,STACK_BOUNDARY). This proposal won't adjust stack when INCOMING_STACK_BOUNDARY >= REQUIRED_STACK_ALIGNMENT. Only when INCOMING_STACK_BOUNDARY < REQUIRED_STACK_ALIGNMENT, it will adjust stack to REQUIRED_STACK_ALIGNMENT at prologue. 2.3 Initial development on i386 and x86_64 We initially support i386 and x86_64. In this document we focus more on i386 becau
Re: Regression count, and how to keep bugs around forever
On 19/12/2007, Steven Bosscher <[EMAIL PROTECTED]> wrote: > > The current list of "All regressions" should be a list of bugs that > people are actively trying to resolve, preferably before the release > of GCC 4.3. Instead, it is a mix of high-activity bug reports and bug > reports where even the target maintainer has been unwilling for 3.5 > years to spend some time on resolving the bug report. So to pick a bug > report to work on, I need to go through the but report summaries of a > long list, trying to pick out new regressions between the old > no-one-cares P4 and P5 regressions. > I am sorry but I don't understand how this can be possible. Old no-one-cares have a lower ID than new ones. So if you start with the list backwards you should always get the newer ones. Also, PRs that are regressions for 4.3 only cannot be that old (but perhaps they are no-one-cares). On the other hand, there are around 1003 PRs UNCONFIRMED. Those are annoying. > Maybe it is just me, but I find it very annoying to have to wade > through long bug lists, so I just don't do this. Instead I just don't > look at P4/P5 regressions anymore at all. It's just too much trouble > to find a bug report where the reporter or the target maintainer cares > as much as you do about resolving the bug. Well, perhaps instead of 2 lists: Serious regressions and All regressions. We should have 3 lists: High priority, Medium Priority, Low priority. High priority is the same as Serious regressions, Medium are P4 and P5 and Low priority are those that you just described (P6?). Anyway, I don't typically look at those lists. I create my own customized searches and save them. Cheers, Manuel.
Re: A proposal to align GCC stack
On Wed, Dec 19, 2007 at 04:12:55AM -0500, Ross Ridge wrote: > > I'm suggesting a different defintion of STACK_BOUNDARY which wouldn't, > if strictly followed, result STACK_BOUNDARY being defined as 8 on > the i386. The i386 hardware doesn't enforce a minimum alignment on the > stack pointer. On i386, you can only push/pop 2 or 4 bytes. On x86-64, you can only push/pop 2 or 8 bytes. > stack. In context of your proposal, defining STACK_BOUNDARY this way, > as a requirement imposed on GCC by an ABI (or at least by convention), > not the hardware, is important. Without an ABI requirement, there's > nothing that would prohibit an i386 leaf function from adjusting the > stack in a way that leaves the stack 1- or 2-byte aligned. > I don't mind changing the definition of STACK_BOUNDARY. It won't affect our proposal. However, please don't use ABI when defining STACK_BOUNDARY since a given hardware can have more than one ABIs and only one STACK_BOUNDARY. H.J.
Re: A proposal to align GCC stack
On Wed, Dec 19, 2007 at 04:12:59AM -0500, Ross Ridge wrote: > > >STACK_BOUNDARY is the minimum stack boundary. MAX(STACK_BOUNDARY, > >PREFERRED_STACK_BOUNDARY) == PREFERRED_STACK_BOUNDARY. So the question is > >if we should assume INCOMING == PREFERRED_STACK_BOUNDARY in all cases: > > Doing this would also remove need for ABI_STACK_BOUNDARY in your proposal. In our proposal, ABI_STACK_BOUNDARY provides the default value for PREFERRED_STACK_BOUNDARY. It can be different for different OSes. For a given OS, you can change PREFERRED_STACK_BOUNDARY. But you can't change ABI_STACK_BOUNDARY. You can think it as software STACK_BOUNDARY. > > >Pros: > > 1. Keep the current behaviour of -mpreferred-stack-boundary. > > > >Cons: > > 1. The generated code is incompatible with the other object files. > > Well, your proposal wouldn't completely solve that problem, either. > You can't guarantee compatiblity with object files compiled with different > values -mpreferred-stack-boundary, including those compiled with current > implementation, unless you assume the incomming stack is aligned to > the lowest value the flag can have and align the outgoing stack to the > highest value that the flag can have. We can align the outgoing stack to PREFERRED_STACK_BOUNDARY and assume INCOMING = MIN (ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY), which is our original proposal. H.J.
Re: Regression count, and how to keep bugs around forever
On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote: > The current list of "All regressions" should be a list of bugs that > people are actively trying to resolve, preferably before the release > of GCC 4.3. No, it should be exactly what it says it is. If you want an additional list of bugs that are being actively worked on (and labelled as such), that's fine (although I have no idea how that list would be useful). > Instead, it is a mix of high-activity bug reports and bug > reports where even the target maintainer has been unwilling for 3.5 > years to spend some time on resolving the bug report. That may be an indication that maintainership should be passed on to someone else. I don't see how it can be an indication that the bug should not be fixed. > So to pick a bug > report to work on, I need to go through the but report summaries of a > long list, trying to pick out new regressions between the old > no-one-cares P4 and P5 regressions. PR numbers are assigned in ascending order. The newest regressions have the highest numbers. What exactly is the problem you're facing when starting with the highest-numbered PRs? > To me, the situation is quite clear: If a bug report is open for so > long, and even the reporter and the responsible maintainer show no > sign of motivation to work on resolving the bug, I think this tells us > something about how important this bug is: Not important enough to > fix. IMOH we should close such reports as WONTFIX or SUSPENDED to > make them less visible, so that other bug reports don't fall through > the cracks. > > So I'm asking for a policy here that says when it is OK to resolve old > bug without progress as WONTFIX or SUSPENDED. Start shooting. Having assigned myself to and/or posted patches for some of the bugs you want to close as WONTFIX, including four which have four-digit PR numbers, my response is predictable: No way. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: Designs for better debug info in GCC
On 12/19/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote: > > > > > Consider PRE alone, > > > > > If your debug statement strategy is "move debug statements when we > > > insert code that is equivalent" > > > > Move? Debug statements don't move, in general. I'm not sure what you > > have in mind, but I sense some disconnect here. > > OKay, so if you aren't going to move them, you have to erase them when > you move statements around. > Besides this, how do you plan on handling the following situations (both of which reassoc performs *right now*). These are the relatively easy ones Here is the easy one: z_5 = a_3 + b_3 x_4 = z_5 + c_3 DEBUG(x, x_4) Reassoc may transform this into: z_5 = c_3 + b_3 x_4 = z_5 + a_3 DEBUG(x, x_4) Now x has the wrong value. At least in this case, you can tell which DEBUG statement to eliminate easily (it is an immediate use of x_4) It gets worse, however c_3 = a_1 + b_2 z_5 = c_3 + d_9 x_4 = z_5 + e_10 DEBUG(x, x_4) y_7 = x_4 + f_11 z_8 = y_7 + g_12 -> c_3 = a_1 + b_2 z_5 = c_3 + g_12 x_4 = z_5 + e_10 DEBUG(x, x_4) y_7 = x_4 + f_11 z_8 = y_7 + d_9 x_4 now no longer represents the value of x, but we haven't directly changed x_4, it's immediate users, or the statements that immediately make up it's defining values. How do you propose we figure out which DEBUG statements we may have affected without doing all kinds of walks? (This is of course, a more general problem of how do i find which debug statements are reached by my transformation without doing linear walks)
Re: Designs for better debug info in GCC
On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote: > > >> int c = z; > >> whatever0(c); > >> c = x; > > > Because you have added information you have no way of knowing. > > How exactly did you compute that the call *definitely sets c to the > > value of z_0*, and definitely sets the value of c to x_2. > > Err... I guess you're thinking memory, global variables, alias > analysis and that sort of stuff. > Yes, i mixed your examples up, i apologize. > None of this applies to gimple registers, which is all the annotations > are about. > > > > However, value equivalene does not imply location equivalence, and all > > of our debug formats deal with locations of variables, except for > > constants. > > Dwarf enables arbitrary value expressions too. Well, uh, no. The only way to directly specify the value of a variable is for constants. DW_AT_const_value does not allow location descriptions. "An entry describing a variable or formal parameter whose value is constant and not represented by an object in the address space of the program, or an entry describing a named constant, does not have a location attribute. Such entries have a DW_AT_const_value attribute, whose value may be a string or any of the constant data or data block forms, as appropriate for the representation of the variable's value. The value of this attribute is the actual constant value of the variable, represented as it would be on the target architecture. " There are no other provisions in DWARF for describing the value of a variable, it is expected you describe their locations using DW_AT_location (which gives you the full power of location descriptions, but requires you to return a location, not a value) > There's some > discussion about lvalue vs rvalue in the document, and this is also > something that will take some experimenting. I'm not entirely sure > where to draw the line, and I'm not entirely sure there is a perfect > answer. I'm still curious where you think it describes value expressions for variables other than constants (which again, can't use the location description language) Again, i'd support such an extension, but it does not currently exist. Rest answers in other message.
Re: Designs for better debug info in GCC
Daniel Berlin wrote: Here is the easy one: z_5 = a_3 + b_3 x_4 = z_5 + c_3 DEBUG(x, x_4) Reassoc may transform this into: z_5 = c_3 + b_3 x_4 = z_5 + a_3 DEBUG(x, x_4) Now x has the wrong value. ?? x_4 looks like it has the value 'a_3 + b_3 + c_3' in both examples to me, although computed in different orders... so isn't that still the right value? Andrew
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
On 12/18/07 08:29, Jan Hubicka wrote: Doing call graph changes should not be that hard (I was trying to keep similar deisgn in mind when implementing it, even if we stepped away from the plan in some cases, like reorganizing passes from vertical to horisontal order). Nearest problem I see is merging different declarations of units read back, I have prototype implementation of DECL merging pass done from my trip this week and hope to have it working at least for --combine and C during christmas. Cool. Yeah, that is going to be one of the main things we need to continue. For the next little while I will be working on finishing tuples, most of what remains are mechanical changes to get bootstraps going. I will then work on tuning RTL generation. Since we have these two ongoing branches (LTO and tuples) that will be used by whole program optimizer, I think we need to coordinate a little bit. I wrote up a wiki page to keep all these things linked from one place. http://gcc.gnu.org/wiki/whopr I started a very incomplete implementation plan that I would like folks to help fill in. Ken/Nathan, what are the major issues still missing in LTO? I wrote up a couple, but I'm sure you guys have a much more complete list. Jan, wrt the optimization plan coming out of the analysis phase, and the various pieces of header/summary information, what do you think are the major pieces we need? In terms of branch mechanics, I'm initially tempted to do this implementation on a branch separate from tuples and lto. This will allow us to merge both lto and tuples separately, as the rest of the optimizer is still a long ways away. What do folks think? Thanks. Diego.
Re: Strange error message from gdb
On Wed, Dec 19, 2007 at 05:21:50PM +, Andrew Haley wrote: > Die: DW_TAG_interface_type (abbrev = 23, offset = 4181) > has children: FALSE > attributes: > DW_AT_declaration (DW_FORM_flag) flag: TRUE > Dwarf Error: Cannot find type of die [in module /home/aph/a.out] > > I suppose this means that gcj is generating bad debug info, but I > don't know what it's complaining about exactly, so I don't know how to > fix it. > > Here's the abbrev in question: > > <1><1055>: Abbrev Number: 23 (DW_TAG_interface_type) > <1056> DW_AT_declaration : 1 That DIE doesn't have any content. It says "I am a declartion of an interface". But not which interface or what it's called or what the type is. I'd need a backtrace to be more specific, but in addition to bad debug info this may be a limitation in GDB; it does not know anything about DW_TAG_interface_type. -- Daniel Jacobowitz CodeSourcery
Strange error message from gdb
Die: DW_TAG_interface_type (abbrev = 23, offset = 4181) has children: FALSE attributes: DW_AT_declaration (DW_FORM_flag) flag: TRUE Dwarf Error: Cannot find type of die [in module /home/aph/a.out] I suppose this means that gcj is generating bad debug info, but I don't know what it's complaining about exactly, so I don't know how to fix it. Here's the abbrev in question: <1><1055>: Abbrev Number: 23 (DW_TAG_interface_type) <1056> DW_AT_declaration : 1 Clues welcome... Thanks, Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Strange error message from gdb
Daniel Jacobowitz writes: > On Wed, Dec 19, 2007 at 05:21:50PM +, Andrew Haley wrote: > > Die: DW_TAG_interface_type (abbrev = 23, offset = 4181) > >has children: FALSE > >attributes: > >DW_AT_declaration (DW_FORM_flag) flag: TRUE > > Dwarf Error: Cannot find type of die [in module /home/aph/a.out] > > > > I suppose this means that gcj is generating bad debug info, but I > > don't know what it's complaining about exactly, so I don't know how to > > fix it. > > > > Here's the abbrev in question: > > > > <1><1055>: Abbrev Number: 23 (DW_TAG_interface_type) > > <1056> DW_AT_declaration : 1 > > That DIE doesn't have any content. It says "I am a declartion of an > interface". But not which interface or what it's called or what the > type is. Well, the type is the interface: there's nothing else it might be. > I'd need a backtrace to be more specific, but in addition to bad > debug info this may be a limitation in GDB; it does not know > anything about DW_TAG_interface_type. OK, thanks. Anyway, on inspection it seems like read_type_die() in dwarf2read.c doesn't know how to handle DW_TAG_interface_type. This is rather odd, given that dwarf_tag_name() does know about interface types. Maybe I should just fix gcj not to use DW_TAG_interface_type. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Designs for better debug info in GCC
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> You snipped (skipped?) one aspect of the reasoning on why it is
> appropriate. Of course this doesn't prove it's the best possibility,
> but I haven't seen evidence of why it isn't.
You will find it easier to demonstrate the worth of your proposal if
you act publically as though your interlocutors are people of good
will, even when it doesn't seem that way to you, and omit
interjections like "(skipped?)". Assuming the goal is to get this
into mainline gcc, you have to convince us, not the other way around.
The first step in convincing people in this forum is not to irritate
them.
> Now, if you tell me that information about i_0 and j_2 is
> backward-propagated to the top of the function, where x and y are set
> up, I introduce say zero-initialization for i and j before probe1()
> (an actual function call, mind you), and then this representation is
> provably broken.
To be sure we are on the same page, I think your argument here is that
with this code:
int f(int x, int y) {
int i = 0, j = 0;
probe1();
i = x;
j = y;
probe2();
if (x < y)
i += y;
else
j -= x;
probe3();
return g (i ,j);
}
if I set a breakpoint just before the call to probe2(), and I print
the values of 'i' and 'j', I should get the values of 'x' and 'y'.
That is, you want to emit a DWARF variable note at that point that the
value of 'i' can be found in the location corresponding to 'x'.
Of course there are no actual instructions between the calls to
probe1() and probe2(). If I use gdb's "finish" command out of
probe1(), what values should I see for 'i' and 'j' at that point?
Arguably I am now before the assignment statements, and should see '0'
and '0', the values that 'i' and 'j' have before they are changed. Of
course, this is the same location as the breakpoint before probe2(),
and we can't see both '0'/'0' and 'x'/'y'. So it seems to me that
this situation is actually somewhat ambiguous. I don't see an
obviously correct answer.
Setting that aside, seeing the values 'x' and 'y' would probably be
more useful in practice, even if the other possibility is not wrong.
I think the general issue you are describing is how to handle an
assignment which appears in user code but which has been eliminated
during optimization.
You are certainly correct: the scheme I was outlining does not address
deleted assignments.
It seems to me that such eliminated assignments are inherently
ambiguous. If the assignment is gone, then there is a point in the
generated code where the variable logically has both the old and the
new values. I assume that the debugger can only display one value.
Which one should it be?
Your representation clearly makes a choice. What makes it a
principled choice? Consider a series of assignments to a local
variable, and suppose that all the assignments are deleted becaues
they are unused. Are there dependencies between the DEBUG notes which
keep them in the right order?
One way to make a principled choice is to consider the line notes we
are going to emit with the debugging information. Presumably we do
not have the goal of emitting correct debug information in between
line notes--e.g., when using the "stepi" command in gdb. Our goal is
to emit correct debug information at the points where a debugger would
naturally stop--the notes for where a line starts.
I wonder whether it would be feasible for the debug info generation to
work from the assignments in the source code as generated by the
frontend. For each assignment, we would find the corresponding line
note. Then we would look at the right hand side, and try to identify
where that value could be found at that point in the program. This
would be a variant of our current variable tracking pass. I haven't
thought about this enough to know whether it would really work.
> > It is of course true that optimized code will move around
> > unpredictably, and your proposal doesn't handle that.
>
> It handles that in that a variable will be regarded as being assigned
> to a value when execution crosses the debug stmt/insn originally
> inserted right after the assignment. This is by design, but I realize
> now I forgot to mention this in the design document.
>
> The idea is that, debug insns get high priority in scheduling.
> However, since they mention the assignment just before them, if the
> assignment is just moved earlier, without an intervening scheduling
> barrier, then the debug instruction will follow it. If the assignment
> is removed, then the debug insn can be legitimately be move up to the
> point where the assignment, if remaining, might have been moved up to.
> However, if the assignment is moved to a separate basic block, say out
> of a loop or a conditional, then we don't want the debug insn to move
> with it: such that hoisting and commonizing are regarded as setting
> temporaries, and the value is only "committed" to the variable if we
> get to the point where the assign
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
Diego Novillo wrote > On 12/18/07 08:29, Jan Hubicka wrote: > >> Doing call graph changes should not be that hard (I was trying to keep >> similar deisgn in mind when implementing it, even if we stepped away >> from the plan in some cases, like reorganizing passes from vertical to >> horisontal order). Nearest problem I see is merging different >> declarations of units read back, I have prototype implementation of DECL >> merging pass done from my trip this week and hope to have it working at >> least for --combine and C during christmas. > > Cool. Yeah, that is going to be one of the main things we need to > continue. For the next little while I will be working on finishing > tuples, most of what remains are mechanical changes to get bootstraps > going. I will then work on tuning RTL generation. > > Since we have these two ongoing branches (LTO and tuples) that will be > used by whole program optimizer, I think we need to coordinate a > little bit. I wrote up a wiki page to keep all these things linked > from one place. > > http://gcc.gnu.org/wiki/whopr > > I started a very incomplete implementation plan that I would like > folks to help fill in. > > Ken/Nathan, what are the major issues still missing in LTO? I wrote > up a couple, but I'm sure you guys have a much more complete list. > > Jan, wrt the optimization plan coming out of the analysis phase, and > the various pieces of header/summary information, what do you think > are the major pieces we need? > > In terms of branch mechanics, I'm initially tempted to do this > implementation on a branch separate from tuples and lto. This will > allow us to merge both lto and tuples separately, as the rest of the > optimizer is still a long ways away. What do folks think? > > > Thanks. Diego. I am hoping that in the next couple of days, Nathan and I will be able to say that we have completed to work that Codesourcery/NaturalBridge contracted to do with IBM. Completion means that we are able to compile and run the C language spec 2000 benchmarks in LTO mode, as well as compile all of the gcc compiler itself (this does not include the runtime). There are still many open issues that we are hoping that the community would address (The next four items are considered general cleanups/improvements independent of LTO and would be welcomed as changes to the truck when stage I opens. However a complete LTO implementation depends on them being completed): 1) Removal of the rest of the lang hooks. 2) Removal of support for not file at time mode (I believe that IanT has a patch for this.) 3) Removal of any remaining places where the front ends directly generate rtl. 4) Gimplifying static initializers at the same time as everything else. When these 4 items are done, it will be possible to consider the making lto work with other front ends. There are still LTO items that do not work with the C front ends. Most of these support extensions to C. 1) We do not handle types that reference local variables. Such as arrays that are sized by the parameter to a function. 2) Nested functions. 3) Attributes associated with types, like packed. (1) may be hard. The rest of a simple matter of programming. There is still a matter that it is difficult to separate the LTO type information from the debugging information. There are a large number of things that need to change to make lto/whopr a reality. Many of them are addressed in the google document. I personally was planning to start restructuring the ipa passes and serializing the cgraph. I was waiting for Honza to get back to being regularly available so that we could work on that together. The current code does not need serialize the cgraph since it loads all functions into memory, the call graph is just rebuilt as each function is loaded. This obviously needs to be changed before we can at all talk about distributing the compilation. I personally think that the most pressing problems are 1) making lto/whopr work in the presence of modules that do not fit perfectly together, because of type or function argument mismatches. I think that this will be a challenging problem that will require a lot of thought and code. The easy case of just dying when things do not match up is ok, but it is unlikely that lto/whopr will be a generally useful tool without at least being able to swallow any existing program and at least do try to do something good. 2) making the front end specific aliasing information available in some language independent manner to the back ends. Gcc is basically a C compiler with a bunch of other front ends graphed onto it. While it makes many accommodations to the requirements of other languages, it rarely does things to take advantage of the "higher level" information that is available in non C languages. Toon's paper at last year's summit is a good example of exactly how badly we do, and the problem is likely to only get worse with LTO/whopr as the lang hooks go away. While the last s
Re: Strange error message from gdb
On Wed, Dec 19, 2007 at 05:54:10PM +, Andrew Haley wrote: > > That DIE doesn't have any content. It says "I am a declartion of an > > interface". But not which interface or what it's called or what the > > type is. > > Well, the type is the interface: there's nothing else it might be. >From the DWARF standard: Interface types are represented by debugging information entries with the tag DW_TAG_interface_type. An interface type entry has a DW_AT_name attribute, whose value is a null-terminated string containing the type name as it appears in the source program. The members of an interface are represented by debugging information entries that are owned by the interface type entry and that appear in the same order as the corresponding declarations in the source program. So this is a declaration of an interface, but without a name. GDB is doing the wrong thing with it, but it still seems wrong to me. Or do Java interfaces have no name? > Anyway, on inspection it seems like read_type_die() in dwarf2read.c > doesn't know how to handle DW_TAG_interface_type. This is rather odd, > given that dwarf_tag_name() does know about interface types. That's just a complete transcription of the DWARF tags (at some point in history). -- Daniel Jacobowitz CodeSourcery
Re: Designs for better debug info in GCC
On Wed, Dec 19, 2007 at 10:00:38AM -0800, Ian Lance Taylor wrote:
> int f(int x, int y) {
> int i = 0, j = 0;
>
> probe1();
> i = x;
> j = y;
> probe2();
> Of course there are no actual instructions between the calls to
> probe1() and probe2(). If I use gdb's "finish" command out of
> probe1(), what values should I see for 'i' and 'j' at that point?
> Arguably I am now before the assignment statements, and should see '0'
> and '0', the values that 'i' and 'j' have before they are changed. Of
> course, this is the same location as the breakpoint before probe2(),
> and we can't see both '0'/'0' and 'x'/'y'. So it seems to me that
> this situation is actually somewhat ambiguous. I don't see an
> obviously correct answer.
For once, I do. As far as a debugger dares to distinguish, any
location is always the beginning of the next instruction, not the end
of the preceeding instruction. If you want to see the zeroes, stop in
probe1 and say "up" instead of "finish".
A hypothetical -Og which placed observation points between statements
would probably need a minimum of one nop per source line. Similarly
for observation points at sequence points.
--
Daniel Jacobowitz
CodeSourcery
Re: Strange error message from gdb
Daniel Jacobowitz writes: > On Wed, Dec 19, 2007 at 05:54:10PM +, Andrew Haley wrote: > > > That DIE doesn't have any content. It says "I am a declartion of an > > > interface". But not which interface or what it's called or what the > > > type is. > > > > Well, the type is the interface: there's nothing else it might be. > > >From the DWARF standard: > > Interface types are represented by debugging information entries with > the tag DW_TAG_interface_type. > > An interface type entry has a DW_AT_name attribute, whose value is a > null-terminated string containing the type name as it appears in the > source program. > > The members of an interface are represented by debugging information > entries that are owned by the interface type entry and that appear in > the same order as the corresponding declarations in the source > program. OK, so the name is missing, and that's wrong. I should find out why. > So this is a declaration of an interface, but without a name. GDB is > doing the wrong thing with it, but it still seems wrong to me. Or do > Java interfaces have no name? > > > Anyway, on inspection it seems like read_type_die() in dwarf2read.c > > doesn't know how to handle DW_TAG_interface_type. This is rather odd, > > given that dwarf_tag_name() does know about interface types. > > That's just a complete transcription of the DWARF tags (at some point > in history). Right, so read_type_die() doesn't know how to handle DW_TAG_interface_type. The weird thing is that I have never seen this error mesage before today, and AFAIAA gcj has been generating these interface types for a long while. It seems to me that even if gcj did generate the name for the interface, gdb would still die because it doesn't have any handlers for DW_TAG_interface_type in dwarf2read.c Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Strange error message from gdb
On Wed, Dec 19, 2007 at 07:00:41PM +, Andrew Haley wrote: > It seems to me that even if gcj did generate the name for the > interface, gdb would still die because it doesn't have any handlers > for DW_TAG_interface_type in dwarf2read.c Yes, you're probably right. It thinks it's some kind of symbol, probably. There's a default: in the DIE processing that, strictly speaking, ought not to be there. -- Daniel Jacobowitz CodeSourcery
Re: Designs for better debug info in GCC
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote: > On 12/18/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> Dwarf enables arbitrary value expressions too. > Well, uh, no. > The only way to directly specify the value of a variable is for > constants. DW_AT_const_value does not allow location descriptions. DW_AT_const_value is irrelevant for location lists. It's DW_OP_* that I'm talking about. That said... I can't find any more the equivalent of DW_CFA_val_expression in DW_OP_*s that could be used in location expressions. I just *knew* it was there, but I guess I just imagined it. This is embarrassing. At this point, there are three options available: - go back to the drawing board - discard altogether expressions that don't represent lvalues (maybe don't even keep track of them) - introduce a DWARF extension that enables value expressions to be used in location lists (say DW_OP_value, DW_OP_temp_location, or even DW_OP_self_location (*)) (*) maps value to a virtual location that, if dereferenced, evaluates to the value. Could be "easily" implemented through a virtual out-of-range base address, plus the offset that represents the value on dereference, but there are many other ways to implement this in debug information consumers. > I'm still curious where you think it describes value expressions for > variables other than constants Me too :-) :-( Thanks for drawing my attention to this incorrect assumption I made about DWARF location lists. > i'd support such an extension Cool. Do you happen to know the procedure to propose DWARF standard extensions? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: > > > > Here is the easy one: > > > > z_5 = a_3 + b_3 > > x_4 = z_5 + c_3 > > > > DEBUG(x, x_4) > > > > > > Reassoc may transform this into: > > > > > > z_5 = c_3 + b_3 > > x_4 = z_5 + a_3 > > > > DEBUG(x, x_4) > > > > Now x has the wrong value. > > > ?? > > x_4 looks like it has the value 'a_3 + b_3 + c_3' in both examples to > me, although computed in different orders... > > so isn't that still the right value? Yes, sorry, you have to add one more set of adds below and move one so you can make it have a different value You get the general idea though :) Reassoc knows they are all only used in each other, and that it is okay to change their intermediate value as long as the last thing int he chain retains its value (which it does since they are all commutative operations) > > Andrew >
Re: Designs for better debug info in GCC
On Wed, 2007-12-19 at 10:00 -0800, Ian Lance Taylor wrote: > One way to make a principled choice is to consider the line notes we > are going to emit with the debugging information. Presumably we do > not have the goal of emitting correct debug information in between > line notes--e.g., when using the "stepi" command in gdb. Our goal is > to emit correct debug information at the points where a debugger would > naturally stop--the notes for where a line starts. Debugging in between line notes is important for core files and when moving up and down the call stack, so at such locations the debugger needs to at least know whether debug information is reliable or not. Janis
Re: Designs for better debug info in GCC
It gets worse, however c_3 = a_1 + b_2 z_5 = c_3 + d_9 x_4 = z_5 + e_10 DEBUG(x, x_4) y_7 = x_4 + f_11 z_8 = y_7 + g_12 -> c_3 = a_1 + b_2 z_5 = c_3 + g_12 x_4 = z_5 + e_10 DEBUG(x, x_4) y_7 = x_4 + f_11 z_8 = y_7 + d_9 x_4 now no longer represents the value of x, but we haven't directly changed x_4, it's immediate users, or the statements that immediately make up it's defining values. This does seem more troublesome. Reassociation shuffles things around without changing the LHS presumably because it has looked at the uses and knows there are no uses outside the expression, so it can manipulate them however it wants. It elects not to create new temps since it knows the old ones aren't being used elsewhere, so why wast new entries. So if it was aware of the debug stmt, there would be a use of x_4 outside the expression, and it would no longer do the same reassociation. Is that the jist of it? Andrew
Re: Designs for better debug info in GCC
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote: > Here is the easy one: > z_5 = a_3 + b_3 > x_4 = z_5 + c_3 > DEBUG(x, x_4) > Reassoc may transform this into: > z_5 = c_3 + b_3 > x_4 = z_5 + a_3 > DEBUG(x, x_4) > Now x has the wrong value. As Andrew said, no, it doesn't. Now, if z_5 were present in a debug expression, then it would need adjusting. No different from the adjusting need for any other instruction in which z_5 was present, though. That's what I mean when I talk about letting the optimizers do their job on debug instructions too. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
> On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> On Dec 18, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>>
>> > Consider PRE alone,
>>
>> > If your debug statement strategy is "move debug statements when we
>> > insert code that is equivalent"
>>
>> Move? Debug statements don't move, in general. I'm not sure what you
>> have in mind, but I sense some disconnect here.
> OKay, so if you aren't going to move them, you have to erase them when
> you move statements around.
Why? They still represent the point of binding between user variable
and value.
> How were you going to generate the initial set of debug annotations?
It's in the document: after each assignment to user variable, and at
PHI nodes for user variables. The debug statement means the variable
holds that value from that point on until conflicting information
arises (i.e., another debug statement for the same variable, or a
control flow merge with different values for the same variable)
> How were you going to update it if you saw a statement was updated to
> say x_5 = x_4 instead of x_5 = x_3 + x_2.
No update needed, if x_5 is the value of interest. I'm not sure
that's what you're asking, though.
> So then how will using your debug annotations and updating them come
> out any different than say performing a value numbering pass where you
> also associate user variables with the ssa names (IE alongside our
> value numbers), and propagate them around as well?
First, debug annotations may be at different points than the
corresponding SSA definitions, because the same SSA definition may be
bound to different variables at different ranges.
Second, debug annotations may contain more complex expressions than a
single SSA name, and there may not be any SSA name that represents the
value of these expressions left. For example, given:
x_3 = a_1 + b_2;
# DEBUG x => x_3
foo();
if we find that x_3 is unused elsewhere, we can drop it without
discarding debug information about the value of x at that point
# DEBUG x => a_1 + b_2
foo();
such that, if we stop at the call and print x, we get the expected
value, even though the actual variable was optimized away.
> At the end, you could emit DEBUG(user var, ssa name) right after each
> SSA_NAME_DEF_STMT for all user vars in the user var set for ssa name.
This doesn't work. Consider:
a_2 = whatever1;
b_4 = whatever2;
x_1 = a_2;
probe();
if (condition) {
probe();
x_3 = b_4;
probe();
}
x_5 = PHI ;
probe();
Now, if you optimize it and apply the debug stmt generation
technique you suggested, this is what you get:
T_2 = whatever1;
# DEBUG a => T_2
# DEBUG x => T_2
T_4 = whatever2;
# DEBUG b => T_4
# DEBUG x => T_4
probe();
if (condition) {
probe();
probe();
}
T_5 = PHI
# DEBUG x => T_5
probe();
What do you get if you print x at each of the probe points?
> I don't see why you believe user variables/bindings are special and
> can't be propagated in this manner,
It's not that I don't believe it, it's just that just being able to
propagate them is not enough. We must also take the binding point
into account.
Now, as I wrote to Ian last night, if we just add a binding point
annotation to this mix, then we have sufficient information:
T_2 = whatever1;
# DEBUG a => T_2 here
# DEBUG x => T_2 at P1
T_4 = whatever2;
# DEBUG b => T_4 here
# DEBUG x => T_4 at P2
probe();
# DEBUG point P1
if (condition) {
probe();
# DEBUG point P2
probe();
}
T_5 = PHI
# DEBUG x => T_5
probe();
I still don't see how, in this notation, we'd represent something like
"at this point, the value of this user variable is unknown". Any
ideas?
Also, this strategy works for the nice and well-behaved Tree SSA
optimization passes. For RTL, that is far less abstract, especially
after register allocation, I don't see that we can rely on such a
simple strategy. But, in a way, I hope I'm wrong ;-)
>> > #3 is a dataflow problem, and not something you want to do every time
>> > you insert a call.
>> I'm not sure what you mean by "inserting calls". We don't do that.
> Sure we do.
> We will definitely insert new calls when we PRE const/pure calls, or
> calls we determine to be movable to the point we want to move them
I think of that as moving, rather than inserting. That said, I still
don't quite see what you're getting at. Calls don't mess with gimple
registers of their callers, ever, so it appears to me that inserting a
call in the tree level is a NOP in terms of debug information
annotations.
> I'm not sure why you believe all the calls that we end up with in the
> IR are actually in the source (or even implied by it).
Conceptually, they are, kind-a sort of :-) Except perhaps for
profiling calls, that are meant to be fully transparent anyway.
Others are more akin to inlining, or using a call for convenience
rather than expandin
-Wparentheses lumps too much together
Hello Gentlemen, Much as I'm a fan of the GCC and rely on -Wall, I would like to suggest to you that -Wparentheses should be split up, and things it checks/suggests be moved out of -Wall. If this is not the right forum or if you'd rather see this as a bug report, I'm happy to go where I'm pointed. The basic problem with this warning is that it includes some helpful advice about some subtle bugs with some "dear beginner" advice about "operators ... whose precedence people often get confused about." My assertion is that operator precedence is fundamental to C. No one can read C without knowing. If you're unsure about precedence, you're only guessing. Moreover, to interpret operator precedence, it's not necessary to, say, rememember the variables' declarations 100 lines earlier and it's impossible to be misled by non-syntactic indentation. Everything you need to know to understand the statement is contained in the statement itself. My specific candidate for exclusion from -Wall is this one: if (a && b || c && d) which yields (as you know) advice to parenthesize the two && pairs. I very much think this is unhelpful, counterproductive advice. Yes, I know beginners get confused by and/or precedence. But *every* language that I know of that has operator precedence places 'and' before 'or'. More important, a C programmer will encounter many thousands such expressions in his dealings with the language. To "help" him is merely to retard his education. But -Wall isn't really concerned with helping beginners, right? It's really about avoiding errors and pitfalls. That's why I suggest this and other precedence warnings be moved to -Woperator (notional). If you need help learning C, GCC will help you. But if you're maintaining 100,000 lines of portable, standards-compliant C (as I do), you don't want warnings to parenthesize things that don't need it. At the risk of overstaying my welcome, let me answer the commonest reply, "what's a few parentheses among friends?" The problem is that, for the experienced programmer, "extra" parenthesis are a signal: something unusual is going on here. By forcing your most careful users -- those who bother with -Wall -- to use parenthesis to enforce what the compiler would do anyway where the meaning was clear(er) without them, you're removing a signalling tool by "insisting" on white noise. I don't think that's a good outcome and I doubt it was the intention, but there it is. By the way, I distinguish the 'and/or' advice from the more helpful concern: while ((erc=foo()) != 0) because there the programmer's intent is likely impossible to express without parentheses; the idiom requires the override. One last point. In looking for the rationale behind this warning, I searched for examples of it. I didn't find any discussion on this list. What I did find were many examples of people rototilling perfectly fine code, "improving" it by adding unneeded parenthesis specifically so that it would compile cleanly with -Wall. I think that's a shame: a waste of effort at best. I ask you, please, to consider splitting advice about operator precedence from advice about mismatched if/else branches, and to exclude advice about making sure && is parenthesized ahead of || from -Wall. -Wall is the standard for "good, clean code" in many projects. This warning doesn't belong there. Thank you for your time and consideration. Regards, --jkl
Re: Designs for better debug info in GCC
On Wed, Dec 19, 2007 at 05:02:52PM -0200, Alexandre Oliva wrote: > That said... I can't find any more the equivalent of > DW_CFA_val_expression in DW_OP_*s that could be used in location > expressions. I just *knew* it was there, but I guess I just imagined > it. This is embarrassing. I am pretty sure such an extension has already been proposed. Might want to check with the committee (see dwarf.org). -- Daniel Jacobowitz CodeSourcery
Re: -Wparentheses lumps too much together
On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote: > One last point. In looking for the rationale behind this warning, I searched > for examples of it. I didn't find any discussion on this list. What I did > find were many examples of people rototilling perfectly fine code, "improving" > it by adding unneeded parenthesis specifically so that it would compile > cleanly with -Wall. I think that's a shame: a waste of effort at best. > > I ask you, please, to consider splitting advice about operator precedence from > advice about mismatched if/else branches, and to exclude advice about > making sure && is parenthesized ahead of || from -Wall. -Wall is the > standard for "good, clean code" in many projects. This warning doesn't > belong there. For what it is worth, I completely agree with everything you have said here. This warning oversteps the bounds of what -Wall should do, and forces people to change perfectly good, clean code. Operator precedence is an important concept that any C or C++ programmer should know, and we're not helping anyone by pretending that programmer's won't understand this concept. We should certainly remove the warning from -Wall, and perhaps remove it entirely. - Doug
Re: -Wparentheses lumps too much together
On Wed, Dec 19, 2007 at 03:02:35PM -0500, [EMAIL PROTECTED] wrote: > My specific candidate for exclusion from -Wall is this one: > > if (a && b || c && d) > > which yields (as you know) advice to parenthesize the two && pairs. > > I very much think this is unhelpful, counterproductive advice. > Yes, I know beginners get confused by and/or precedence. But > *every* language that I know of that has operator precedence places > 'and' before 'or'. More important, a C programmer will encounter > many thousands such expressions in his dealings with the language. > To "help" him is merely to retard his education. I am happy to stand as a counterexample; I am an experienced C programmer and I greatly appreciate this warning. And I loathe reading code which cavalierly assumes you remember the precedence. + and *, sure, you learn that in grade school. && and || is trickier because there are sensible arguments for both directions; it is harder to derive from first principles. If you are more bothered by any clarifying parentheses than I am, use -Wno-parentheses. -- Daniel Jacobowitz CodeSourcery
Re: -Wparentheses lumps too much together
Wednesday 19 December 2007 22:11:22 tarihinde Doug Gregor şunları yazmıştı: > On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote: > > One last point. In looking for the rationale behind this warning, I > > searched for examples of it. I didn't find any discussion on this list. > > What I did find were many examples of people rototilling perfectly fine > > code, "improving" it by adding unneeded parenthesis specifically so that > > it would compile cleanly with -Wall. I think that's a shame: a waste of > > effort at best. > > > > I ask you, please, to consider splitting advice about operator precedence > > from advice about mismatched if/else branches, and to exclude advice > > about making sure && is parenthesized ahead of || from -Wall. -Wall is > > the standard for "good, clean code" in many projects. This warning > > doesn't belong there. > > For what it is worth, I completely agree with everything you have said > here. This warning oversteps the bounds of what -Wall should do, and > forces people to change perfectly good, clean code. Operator > precedence is an important concept that any C or C++ programmer should > know, and we're not helping anyone by pretending that programmer's > won't understand this concept. > > We should certainly remove the warning from -Wall, and perhaps remove > it entirely. Agreed, for example it has lots of useless warnings when compiling ffmpeg. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Designs for better debug info in GCC
On 12/19/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > It gets worse, however > > > > c_3 = a_1 + b_2 > > z_5 = c_3 + d_9 > > x_4 = z_5 + e_10 > > DEBUG(x, x_4) > > y_7 = x_4 + f_11 > > z_8 = y_7 + g_12 > > -> > > > > c_3 = a_1 + b_2 > > z_5 = c_3 + g_12 > > x_4 = z_5 + e_10 > > DEBUG(x, x_4) > > y_7 = x_4 + f_11 > > z_8 = y_7 + d_9 > > > > > > x_4 now no longer represents the value of x, but we haven't directly > > changed x_4, it's immediate users, or the statements that immediately > > make up it's defining values. > > > > > > This does seem more troublesome. Reassociation shuffles things around > without changing the LHS presumably because it has looked at the uses > and knows there are no uses outside the expression, so it can manipulate > them however it wants. It elects not to create new temps since it knows > the old ones aren't being used elsewhere, so why wast new entries. Yes. > > So if it was aware of the debug stmt, there would be a use of x_4 > outside the expression, and it would no longer do the same reassociation. Either that, or you would have to hunt all the uses of every single thing in the chain to see if any were debug expressions, and if the value is going to change. > > Is that the jist of it? Yes > > Andrew >
Re: Designs for better debug info in GCC
On 12/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote: > > > Here is the easy one: > > > z_5 = a_3 + b_3 > > x_4 = z_5 + c_3 > > > DEBUG(x, x_4) > > > > Reassoc may transform this into: > > > > z_5 = c_3 + b_3 > > x_4 = z_5 + a_3 > > > DEBUG(x, x_4) > > > Now x has the wrong value. > > As Andrew said, no, it doesn't. > Yes, I corrected it later. You didn't address the other one, which is much harder and does require addressing by you. > Now, if z_5 were present in a debug expression, then it would need > adjusting. No different from the adjusting need for any other > instruction in which z_5 was present, though. uh, but if you don't adjust in the fixed examples, DEBUG(x, x_4) will give an invalid value. You can cause this to value to change without ever changing x_4, and do so legally. How do i know i need to change this DEBUG expression.
Re: Designs for better debug info in GCC
Janis Johnson <[EMAIL PROTECTED]> writes: > On Wed, 2007-12-19 at 10:00 -0800, Ian Lance Taylor wrote: > > One way to make a principled choice is to consider the line notes we > > are going to emit with the debugging information. Presumably we do > > not have the goal of emitting correct debug information in between > > line notes--e.g., when using the "stepi" command in gdb. Our goal is > > to emit correct debug information at the points where a debugger would > > naturally stop--the notes for where a line starts. > > Debugging in between line notes is important for core files and > when moving up and down the call stack, so at such locations the > debugger needs to at least know whether debug information is > reliable or not. For some things, sure, but we are just talking about the values in user visible variables stored in registers. There is no way we can make that information be correct between line notes. Ian
Re: Regression count, and how to keep bugs around forever
On Dec 19, 2007 4:32 PM, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > On Wed, Dec 19, 2007 at 01:59:51AM +0100, Steven Bosscher wrote: > > The current list of "All regressions" should be a list of bugs that > > people are actively trying to resolve, preferably before the release > > of GCC 4.3. > >No, it should be exactly what it says it is. I don't mind renaming it ;-) > If you want an additional > list of bugs that are being actively worked on (and labelled as such), > that's fine (although I have no idea how that list would be useful). Let's take a bug as an example case: http://gcc.gnu.org/23835 Here, there is a bug report about a huge compile time increase. The release manager decided that this was not a release blocker for GCC 4.2. So it was marked P4, and it disappeared from the radar for GCC 4.3 for everyone who only looks at the "Serious regressions". Gr. Steven
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
On Thu, 2007-12-13 at 08:27 -0500, Diego Novillo wrote: > On 12/13/07 2:39 AM, Ollie Wild wrote: > > > The lto branch is already doing this, so presumably that discussion > > was resolved (Maybe someone in the know should pipe up.). > > Yes, streaming the IL to/from disk is a resolved issue. > ... > > Diego. I found this thread http://gcc.gnu.org/ml/gcc/2005-11/msg00735.html >> From: Mark Mitchell >> To: gcc mailing list >> Date: Wed, 16 Nov 2005 14:26:28 -0800 >> Subject: Link-time optimzation >> The GCC community has talked about link-time optimization for some time. >> ... >> We would prefer not to have this thread devolve into a discussion about >> legal and "political" issues relating to reading and writing GCC's >> internal representation. I've said publicly for a couple of years that >> GCC would need to have this ability, and, more constructively, David >> Edelsohn has talked with the FSF (both RMS and Eben Moglen) about it. >> The FSF has indicated that GCC now can explore adding this feature, >> although there are still some legal details to resolve. >> ... >> http://gcc.gnu.org/projects/lto/lto.pdf >> ... Was there any more about this? I have restarted work on my COBOL front end. Based on my previous experiences writing a GCC front end I want to have as little code as possible in the same process as the GCC back end. This means passing over a file. So I would like to understand how to avoid getting into political/legal trouble when doing this. Thanks, Tim Josling
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
On Dec 19, 2007 5:19 PM, Tim Josling <[EMAIL PROTECTED]> wrote: > This means passing over a file. So I would like to understand how to > avoid getting into political/legal trouble when doing this. Passing over a file in what format? If you are writing a COBOL to C translator, that will certainly be fine. If you are emitting GENERIC or GIMPLE, you are much better off implementing your FE like any other GCC FE. Fortran is a good example of an FE that is totally independent from the rest of GCC. It hands out a GENERIC representation built out of its internal data structures. Otherwise, you will need to translate to GIMPLE, stream it out from the COBOL FE and feed it into the LTO FE. Diego.
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
On Dec 19, 2007, at 2:19 PM, Tim Josling wrote: ... http://gcc.gnu.org/projects/lto/lto.pdf ... Was there any more about this? I have restarted work on my COBOL front end. Based on my previous experiences writing a GCC front end I want to have as little code as possible in the same process as the GCC back end. This means passing over a file. So I would like to understand how to avoid getting into political/legal trouble when doing this. While it is possible to make this work once LTO is finished, it seems unlikely that it will be pleasant. Doing so will basically mean reimplementing a 'writer' for the LTO format to interoperate with the GCC code. This seems to be a hard task, as there is no document on the structure and contents of the LTO file. OTOH, you can get this by reverse engineering the code to find out what it does. Further, it has been publicly stated that the format will evolve and is not going to be stable (though I don't recall where). Unless you want to fight to keep up with the format, this sounds like a major pain. You might be interested in checking out LLVM: http://llvm.org/ which has a well defined and well specified file formats (one text and one binary), and preserves backwards compatibility with them across major release (i.e. 1.0 -> 1.9 and 2.0 -> 2.x). http://llvm.org/docs/ LangRef.html I'd be interested to hear if keeping the LTO format stable is something the GCC community plans to do, -Chris
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
On Dec 19, 2007 5:29 PM, Chris Lattner <[EMAIL PROTECTED]> wrote: > I'd be interested to hear if keeping the LTO format stable is > something the GCC community plans to do, I doubt it. We may end up doing it for practical reasons within a release, but I'm not sure if it's high on anyone's priority list. Diego.
gcc-4.2-20071219 is now available
Snapshot gcc-4.2-20071219 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071219/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 131091 You'll find: gcc-4.2-20071219.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20071219.tar.bz2 C front end and core compiler gcc-ada-4.2-20071219.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20071219.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20071219.tar.bz2 C++ front end and runtime gcc-java-4.2-20071219.tar.bz2 Java front end and runtime gcc-objc-4.2-20071219.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20071219.tar.bz2The GCC testsuite Diffs from 4.2-20071212 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: -Wparentheses lumps too much together
[EMAIL PROTECTED] writes: > Much as I'm a fan of the GCC and rely on -Wall, I would like to suggest > to you that -Wparentheses should be split up, and things it checks/suggests > be moved out of -Wall. If this is not the right forum or if you'd rather > see this as a bug report, I'm happy to go where I'm pointed. I have no objection to splitting -Wparentheses into separate warnings controlled by separate options. > My specific candidate for exclusion from -Wall is this one: > > if (a && b || c && d) > > which yields (as you know) advice to parenthesize the two && pairs. That particular warning happened to find dozens of real errors when I ran it over a large code base. It may be noise for you, but I know from personal experience that it is very useful. Ian
Re: Regression count, and how to keep bugs around forever
On Wed, Dec 19, 2007 at 10:17:00PM +0100, Steven Bosscher wrote: > On Dec 19, 2007 4:32 PM, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: > > > If you want an additional > > list of bugs that are being actively worked on (and labelled as such), > > that's fine (although I have no idea how that list would be useful). > > Let's take a bug as an example case: http://gcc.gnu.org/23835 > > Here, there is a bug report about a huge compile time increase. The > release manager decided that this was not a release blocker for GCC > 4.2. So it was marked P4, and it disappeared from the radar for GCC > 4.3 for everyone who only looks at the "Serious regressions". Right. I tend to look at the list of "All regressions" for that reason. I have also bookmarked about 20 PRs that I'm likely to work on. It does not come as a surprice to me that one size doesn't fit all. The list of "Serious regressions" just gives you a peek over the release manager's shoulders. I use it mainly as an indication of how far away regressions only mode is. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: Regression count, and how to keep bugs around forever
On 12/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: > Let's take a bug as an example case: http://gcc.gnu.org/23835 > > Here, there is a bug report about a huge compile time increase. The > release manager decided that this was not a release blocker for GCC > 4.2. So it was marked P4, and it disappeared from the radar for GCC > 4.3 for everyone who only looks at the "Serious regressions". Under this system, do P4's and P5's ever get fixed?
Disabling the heuristic inliner
Is it possible to disable the heuristic inline function logic? I would like to select the following behaviour: * all static inline functions are always inlined * all static functions that are called once are inlined (-finline-functions-called-once) * no other functions are inlined I'm using -Os and I'm trying to find the right combination of -f switches to enable this behaviour. I tried -finline-limit=1 -finline-functions-called-once but it caused static inline functions to not be inlined. Thanks, Shaun
Re: Disabling the heuristic inliner
Is there a switch to never inline a non-static function? Thanks, Shaun On Dec 19, 2007 6:25 PM, Shaun Jackman <[EMAIL PROTECTED]> wrote: > Is it possible to disable the heuristic inline function logic? I would > like to select the following behaviour: > > * all static inline functions are always inlined > * all static functions that are called once are inlined > (-finline-functions-called-once) > * no other functions are inlined > > I'm using -Os and I'm trying to find the right combination of -f > switches to enable this behaviour. I tried > -finline-limit=1 -finline-functions-called-once > but it caused static inline functions to not be inlined. > > Thanks, > Shaun
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
On Dec 19, 2007 1:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > I am hoping that in the next couple of days, Nathan and I will be able > to say that we have completed to work that Codesourcery/NaturalBridge > contracted to do with IBM. Completion means that we are able to compile > and run the C language spec 2000 benchmarks in LTO mode, as well as > compile all of the gcc compiler itself (this does not include the runtime). Sounds good. Do you folks have some criteria for merging into mainline? I ran the C testsuite today by forcing every single test to use -flto, there were about <8,000 testsuite failures (FAIL + UNRESOLVED), which is about a 16% failure rate. We (Google) plan to keep working on those failures and getting the C++ front end in shape. We (GCC) should probably figure out a set of criteria to consider merging the branch into mainline. Should we shoot for being able to bootstrap with -flto enabled? I would at least be able to pass all the testsuites with -flto enabled. > There are still many open issues that we are hoping that the community > would address Thanks. I've added some of these items to the implementation plan on the wiki page. The rest were already there, please take a look and add/modify to the list. > I personally was planning to start restructuring the ipa passes and > serializing the cgraph. Great. Those are items under the WPA phase. If you have a list of things to be done besides the ones that are already there, could you add them? The more specific we are in this list, the easier it will be for folks to pick up stuff to do. > I personally think that the most pressing problems are > > 1) making lto/whopr work in the presence of modules that do not fit > perfectly together, because of type or function argument mismatches. Agreed. > that is available in non C languages. Toon's paper at last year's > summit is a good example of exactly how badly we do, and the problem is > likely to only get worse with LTO/whopr as the lang hooks go away. Are you talking about aliasing or things like high-level array operations? > While the last section of the whopr pays some lip service to this Well, no. That only addresses some of the aliasing problems. Representing high-level concepts like array/vector arithmetic or class hierarchies is not something we have done well in GIMPLE. In terms of whole program optimization, we will be interested in addressing class hierarchy optimizations. > a community have never really addressed the issues of how we could > expand/change our internal representation to accomodate the high level > features supported by the non c frontends. We have for concurrency with the extensions to support OpenMP which are useful in contexts like auto-parallelism. But in general, we don't transfer some things like array syntax or class hierarchies very well. Now, adding high-level concepts to an IL is usually expensive in several ways. Beyond arrays and class hierarchies, do you see any other high-level concept worth transferring into GIMPLE? I wouldn't want to represent very many high-level concepts in GIMPLE. > The wiki does not indicate that there is any semantic difference between > gimple trees > and gimple tuples Right, there isn't. The work on tuples is orthogonal and can go in/out at any time. It's just mechanically big, as it changes data structures used by most of the compiler. All this work can proceed in parallel. > Both of these are very hard problems and they are likely to require the > same level of commitment that will be required to make Whopr work. It > is not that i think that making lto/whopr work in a distributed > environment is not an important problem, it is just that i think that we > need to make LTO produce good code on real programs first. Oh, absolutely. The design simply allows the first (LGEN) and last stage (LTRANS) to operate in a distributed environment. The initial implementation can simply assume a shared file system. Distribution can be added later. The only important parameter is to avoid implementation decisions that will prevent processing massively large applications. Thanks. Diego.
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
Diego Novillo wrote: > On Dec 19, 2007 1:41 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > > >> I am hoping that in the next couple of days, Nathan and I will be able >> to say that we have completed to work that Codesourcery/NaturalBridge >> contracted to do with IBM. Completion means that we are able to compile >> and run the C language spec 2000 benchmarks in LTO mode, as well as >> compile all of the gcc compiler itself (this does not include the runtime). >> > > Sounds good. Do you folks have some criteria for merging into > mainline? I ran the C testsuite today by forcing every single test to > use -flto, there were about <8,000 testsuite failures (FAIL + > UNRESOLVED), which is about a 16% failure rate. > I never tried such a test. My listing of things to do was based on the execute tests. It is hard to say what that 16% really means without going thur case by case. I did this for the execute tests. That was what I based my list on. It would not surprise me if there are other issues, but it could also be the case that the listed failures are just over expressed in the test suite. The "last" bug that nathan and I are working on is that local statics are not done correctly. The hope is that will be fixed tomorrow. An idea that has been kicked around is that when lto is good enough to replace the old --combine, then we should remove --combine and replace it with lto. I have not really thought thru the details of this, but given that --combine is (i believe) a c only thing, having lto be c only is not that big a deal. Certainly no extra regressions in the c testsuite is required. > We (Google) plan to keep working on those failures and getting the C++ > front end in shape. We (GCC) should probably figure out a set of > criteria to consider merging the branch into mainline. Should we > shoot for being able to bootstrap with -flto enabled? I would at > least be able to pass all the testsuites with -flto enabled. > > My guess is that you are not going to get C++ working until all of the lang hooks are properly resolved. Some of the ways that some of these langhooks were resolved in the lto branch was to assume c. >> There are still many open issues that we are hoping that the community >> would address >> > > Thanks. I've added some of these items to the implementation plan on > the wiki page. The rest were already there, please take a look and > add/modify to the list. > > >> I personally was planning to start restructuring the ipa passes and >> serializing the cgraph. >> > > Great. Those are items under the WPA phase. If you have a list of > things to be done besides the ones that are already there, could you > add them? The more specific we are in this list, the easier it will > be for folks to pick up stuff to do. > > sure >> I personally think that the most pressing problems are >> >> 1) making lto/whopr work in the presence of modules that do not fit >> perfectly together, because of type or function argument mismatches. >> > > Agreed. > > >> that is available in non C languages. Toon's paper at last year's >> summit is a good example of exactly how badly we do, and the problem is >> likely to only get worse with LTO/whopr as the lang hooks go away. >> > > Are you talking about aliasing or things like high-level array operations? > > Arrays and type heirarchy games are certainly the two that come to mind. Strings are also a possibility. Many languages do magical things with strings that go way beyond what one can do with arrays. >> While the last section of the whopr pays some lip service to this >> > > Well, no. That only addresses some of the aliasing problems. > Representing high-level concepts like array/vector arithmetic or class > hierarchies is not something we have done well in GIMPLE. In terms of > whole program optimization, we will be interested in addressing class > hierarchy optimizations. > > >> a community have never really addressed the issues of how we could >> expand/change our internal representation to accomodate the high level >> features supported by the non c frontends. >> > > We have for concurrency with the extensions to support OpenMP which > are useful in contexts like auto-parallelism. But in general, we > don't transfer some things like array syntax or class hierarchies very > well. > > Now, adding high-level concepts to an IL is usually expensive in > several ways. Beyond arrays and class hierarchies, do you see any > other high-level concept worth transferring into GIMPLE? I wouldn't > want to represent very many high-level concepts in GIMPLE. > > >> The wiki does not indicate that there is any semantic difference between >> gimple trees >> and gimple tuples >> > > Right, there isn't. The work on tuples is orthogonal and can go > in/out at any time. It's just mechanically big, as it changes data > structures used by most of the compiler. All this work can proceed in
Re: Regression count, and how to keep bugs around forever
NightStrike wrote: On 12/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: Let's take a bug as an example case: http://gcc.gnu.org/23835 Here, there is a bug report about a huge compile time increase. The release manager decided that this was not a release blocker for GCC 4.2. So it was marked P4, and it disappeared from the radar for GCC 4.3 for everyone who only looks at the "Serious regressions". Under this system, do P4's and P5's ever get fixed? Under the existing system *no* bugs get fixed unless someone wants to fix them. And to answer your question: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&priority=P4&priority=P5
Re: Designs for better debug info in GCC
On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote: >> Now, if z_5 were present in a debug expression, then it would need >> adjusting. No different from the adjusting need for any other >> instruction in which z_5 was present, though. > uh, but if you don't adjust in the fixed examples, DEBUG(x, x_4) will > give an invalid value. My point was that optimizers already had to know how to adjust things such that it doesn't break code. Now, in this optimization, it takes additional liberties with existing variables because it sees they're only used within the sequence. IMHO, it would be more appropriate to introduce alternate temporaries, rather than reusing SSA names for different purposes, in this case. If this approach was taken, the debug annotations referring to a no-longer-defined SSA name would be recognized as invalid, and the variable binding would be removed (i.e., turned into a "value unknown" annotation). Or, if we left the definitions in place, even though they're dead, the same code that cleans up undefined SSA names could recognize these SSA names as unused except in debug information and substitute them for their values, maintaining accurate and complete debug information. But can we do better without introducing more SSA names and keeping assignments around that are known to be dead? Yes, with some additional effort, see below. > How do i know i need to change this DEBUG expression. As reassoc looks for sets of variables it can freely mess with, it should take note of variables that are used in debug annotations in addition to the kind of single (?) non-debug uses it's interested in, such that, when it modifies these variables, the annotations can be compensated for. OTOH, if the compiler performs reassoc on user variables today, it means we do get mangled debug information for such variables already, and they get incorrect values. So, even if we didn't address this problem right away, it wouldn't be much of a regression. But, of course, not dealing with it breaks the goal of having correct debug information, so it ought to be dealt with properly. Do you happen to have a yummy testcase handy that I could use to trigger this kind of transformation in ways that affect the value of user variables? Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Strange error message from gdb
On Dec 19, 2007, Andrew Haley <[EMAIL PROTECTED]> wrote: > Right, so read_type_die() doesn't know how to handle > DW_TAG_interface_type. The weird thing is that I have never seen this > error mesage before today, and AFAIAA gcj has been generating these > interface types for a long while. For very small values of "long while" :-) This was added by: 2007-12-15 Alexandre Oliva <[EMAIL PROTECTED]> PR debug/7081 * lang.c (java_classify_record): New. (LANG_HOOKS_CLASSIFY_RECORD): Override. Sorry, I didn't check whether GDB or other debug information consumers supported this tag. I just ASSumed they did, given how long they've been specified (today Dwarf 3 turns 2 :-) and how noisy a failure would be should one run into such a tag without supporting it. What now, revert until GDB et al are fixed, or leave it in, for it's the right thing to do, and it serves as an additional incentive for debug information consumers to support new Dwarf 3 features? Or introduce the -gdwarf-3 and get -gdwarf-2 (and -g?) to avoid using Dwarf 3 features that are not backward compatible? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: -Wparentheses lumps too much together
Ian Lance Taylor wrote: > I have no objection to splitting -Wparentheses into separate warnings > controlled by separate options. Thank you, Ian. > > which yields (as you know) advice to parenthesize the two && pairs. > > That particular warning happened to find dozens of real errors when I > ran it over a large code base. It may be noise for you, but I know > from personal experience that it is very useful. I would like to hear more about that, if you wouldn't mind. I'm really quite surprised. Honestly. I don't claim to be the last arbiter in good taste. It sounds like you're saying that this warning, when applied to code of uncertain quality, turned up errors -- cases when the code didn't reflect (what must have been) the programmer's intentions. My untested (and consequently firmly held) hypothesis is that 1) most combinations of && and || don't need parentheses because (a && b) || (c && d) is by far more common than a && (b || c) && d and, moreover, broken code fails at runtime, and 2) Most programmers know (because they need to know) that && comes before ||. I'm sure a few years spent working with the GCC and fielding questions about it would lower my opinion of the average programmer, so I won't try to convince you. But I would like to know more about what you found, because that's at least objective evidence. I was unable to find any metrics supporting the inclusion of this particular warning in -Wall. I would hold to this, though: the warnings about precedence are of a different order than warnings about nesting. I suggest that well vetted code doesn't benefit from the kind of false positives that -Wparentheses can generate. I very much appreciate your time and effort. Kind regards, --jkl
Re: Designs for better debug info in GCC
On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > For some things, sure, but we are just talking about the values in > user visible variables stored in registers. There is no way we can > make that information be correct between line notes. Err... I think there is, and one way to do it is with the design I've proposed. Do you have anything to back up your implied assertion that the design can't accomplish this? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> You snipped (skipped?) one aspect of the reasoning on why it is
>> appropriate. Of course this doesn't prove it's the best possibility,
>> but I haven't seen evidence of why it isn't.
> You will find it easier to demonstrate the worth of your proposal if
> you act publically as though your interlocutors are people of good
> will, even when it doesn't seem that way to you, and omit
> interjections like "(skipped?)".
Sorry, I didn't mean it in a demeaning tone. I realize I should have
been more careful, given the heat of the debate, for which I
apologize.
It just so happens that I'm just used to having texts I write skimmed
through rather than read in detail, so, when someone makes a point
that appears to disregard something that I write about, I tend to
assume that the person missed the portion in which I discussed it.
That was what the 'skipped?' was about. I know I tend to pack too
much information in small spaces when I write (and I'm not proud of
it, mind you :-), so having readers miss points I did try to address
is unfortunately quite common.
Again, I apologize for not realizing this could be interpreted in a
different way than the one I meant. It was indeed inappropriate.
> To be sure we are on the same page, I think your argument here is that
> with this code:
> int f(int x, int y) {
> int i = 0, j = 0;
> probe1();
> i = x;
> j = y;
> probe2();
> if (x < y)
> i += y;
> else
> j -= x;
> probe3();
> return g (i ,j);
> }
> if I set a breakpoint just before the call to probe2(), and I print
> the values of 'i' and 'j', I should get the values of 'x' and 'y'.
> That is, you want to emit a DWARF variable note at that point that the
> value of 'i' can be found in the location corresponding to 'x'.
Yep. That would be correct and complete. It would also be
acceptable, but undesirable, to emit information to the effect that
the locations of 'i' and 'j' are unknown at those points; for this
would be correct, even if incomplete.
> Of course there are no actual instructions between the calls to
> probe1() and probe2(). If I use gdb's "finish" command out of
> probe1(), what values should I see for 'i' and 'j' at that point?
> Arguably I am now before the assignment statements, and should see '0'
> and '0', the values that 'i' and 'j' have before they are changed. Of
> course, this is the same location as the breakpoint before probe2(),
> and we can't see both '0'/'0' and 'x'/'y'. So it seems to me that
> this situation is actually somewhat ambiguous. I don't see an
> obviously correct answer.
Dan has dealt with this point, but, if it floats your boat, you can
disregard any hope of getting it right between probe1() and probe2(),
since there aren't instructions in between them, and focus on getting
it right at probe2() or while probe2() is active in a lower stack
frame.
> I think the general issue you are describing is how to handle an
> assignment which appears in user code but which has been eliminated
> during optimization.
Yes, this is a way to describe it.
I'm addressing this in a bit more detail in a revised version of the
spec, that I intend to publish in the GCC wiki RSN.
> It seems to me that such eliminated assignments are inherently
> ambiguous. If the assignment is gone, then there is a point in the
> generated code where the variable logically has both the old and the
> new values. I assume that the debugger can only display one value.
> Which one should it be?
I don't think this characterization is correct. There are points that
are logically before the removed assignment, and there are points that
are logically after it. If we actually emitted a nop for the removed
assignment, then we could single-step through it and observe the
change in the logical variable even though no observable change
occurred in the program state (other than the advance of the PC past
this nop). Except that, in the implementation plan I have in mind,
the observable change would quite often be from "unknown value" to
"assigned value", because the location holding the previous value will
likely have already been overwritten when we reach the debug insn.
> Consider a series of assignments to a local variable, and suppose
> that all the assignments are deleted becaues they are unused. Are
> there dependencies between the DEBUG notes which keep them in the
> right order?
There ought to be, for sure, such that the last one prevails.
> Presumably we do not have the goal of emitting correct debug
> information in between line notes
I do. Stack traces, for one, are seldom taken at line note
boundaries, for stack frames other than the top active one. If we
didn't have correct debug information at those points, monitors
wouldn't be able to do a correct job. Going from that to backtraces
that cross signal handling frames makes it only slightly more complex,
from a
