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 *i1, int *i2, int *i3);
2
3 int __attri
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
On 17/07/15 08:40, Sebastian Huber wrote:
Hello,
the libgomp configuration for RTEMS uses currently the POSIX
implementation. Unfortunately the performance is unacceptable bad, so
I work currently on a specialized RTEMS configuration. I would like to
reuse the code of the Linux futex barrier.
On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> On 17/07/15 08:40, Sebastian Huber wrote:
> >Hello,
> >
> >the libgomp configuration for RTEMS uses currently the POSIX
> >implementation. Unfortunately the performance is unacceptable bad, so I
> >work currently on a specialized RT
On 17/07/15 13:26, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
>On 17/07/15 08:40, Sebastian Huber wrote:
> >Hello,
> >
> >the libgomp configuration for RTEMS uses currently the POSIX
> >implementation. Unfortunately the performance is unacceptable bad,
On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote:
> >>>Attached is a more complete example.
> >I'd prefer not to share the two implementations, just copy and adjust
> >the linux/bar.[ch] into rtems/bar.[ch].
>
> Ok, I understand that you want to separate support for a niche system f
On 17/07/15 13:43, Jakub Jelinek wrote:
On Fri, Jul 17, 2015 at 01:33:41PM +0200, Sebastian Huber wrote:
Attached is a more complete example.
I'd prefer not to share the two implementations, just copy and adjust
the linux/bar.[ch] into rtems/bar.[ch].
Ok, I understand that you want to separa
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
> On 17/07/15 13:26, Jakub Jelinek wrote:
> > On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >the libgomp configuration for RTEMS uses curren
On 17/07/15 14:36, Torvald Riegel wrote:
On Fri, 2015-07-17 at 13:33 +0200, Sebastian Huber wrote:
>On 17/07/15 13:26, Jakub Jelinek wrote:
> >On Fri, Jul 17, 2015 at 01:17:32PM +0200, Sebastian Huber wrote:
> >> >On 17/07/15 08:40, Sebastian Huber wrote:
> >>> > >Hello,
> >>> > >
> >>> > >
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 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
11 matches
Mail list logo
