On 07/20/2015 08:11 PM, Jakub Jelinek wrote:
On Mon, Jul 20, 2015 at 07:55:46PM +0300, Nikolai Bozhenov wrote:
On 07/17/2015 08:31 PM, Michael Eager wrote:
On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
Consider the following example:
1 extern void bar(int *i1, int *i2, int *i3);
On 07/20/2015 09:55 AM, Nikolai Bozhenov wrote:
On 07/17/2015 08:31 PM, Michael Eager wrote:
A related issue is where the breakpoint is taken. GCC sets breakpoints
at the first instruction generated for a statement, which in this case,
appears to be before any of the arguments to bar are eva
On Mon, Jul 20, 2015 at 07:55:46PM +0300, Nikolai Bozhenov wrote:
> On 07/17/2015 08:31 PM, Michael Eager wrote:
> >On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
> >>Consider the following example:
> >>
> >> 1 extern void bar(int *i1, int *i2, int *i3);
> >> 2
> >> 3 int __attribute__
On 07/17/2015 08:31 PM, Michael Eager wrote:
On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
Consider the following example:
1 extern void bar(int *i1, int *i2, int *i3);
2
3 int __attribute__((noinline)) foo(int i1, int i2) {
4 int a, b, c;
5 a = i1 << i2;
6
On 07/17/2015 03:43 AM, Nikolai Bozhenov wrote:
Hello!
It is certainly true that debugging an optimized code is an inherently
difficult task. Though, I wonder if the compiler could make such
debugging experience slightly less surprising.
Consider the following example:
1 extern void bar(i
On 07/17/2015 02:16 PM, Kyrill Tkachov wrote:
Have you tried the -Og option?
Well, with -Og operations are not rearranged, so binary code is very
close to the source code and debugging is very straightforward. As for
debug info, it is generally the same: when I try to inspect yet
uninitialize
On 17/07/15 11:43, Nikolai Bozhenov wrote:
Hello!
It is certainly true that debugging an optimized code is an inherently
difficult task. Though, I wonder if the compiler could make such
debugging experience slightly less surprising.
Consider the following example:
1 extern void bar(int
