On Mon, Jun 24, 2013 at 12:06:27PM +0530, Vineet Gupta wrote:
> I had a question about interpretation of FDE's CIE_pointer field (for
> .debug_frame)
>
> The spec say (from dwarf4 version although it really doesn't matter):
>
> "2. CIE_pointer (4 or 8 bytes, see Section 7.4)
> A constant offset
On 06/24/2013 12:33 PM, Jakub Jelinek wrote:
> On Mon, Jun 24, 2013 at 12:06:27PM +0530, Vineet Gupta wrote:
>> I had a question about interpretation of FDE's CIE_pointer field (for
>> .debug_frame)
>>
>> The spec say (from dwarf4 version although it really doesn't matter):
>>
>> "2. CIE_pointer (
On Mon, Jun 24, 2013 at 12:43:15PM +0530, Vineet Gupta wrote:
> Pardon me if I sound dense (not really my area of expertise), wowever, the 2nd
> word in FDE above (@.Lframe0) is a direct reference to start of .debbug_frame
> shouldn't it be something like
>
> @.Lframe0 - @.Lframe0
>
> i.e. zero.
On 06/24/2013 12:58 PM, Jakub Jelinek wrote:
> On most targets, .debug_* sections are placed at address 0, so absolute
> relocations are the same as relocations relative to the start of the
> section.
> [snipped]
>
> So, either .debug_* sections are placed at address 0 and then absolute
> relocatio
Hello,
I see this item in http://gcc.gnu.org/wiki/LinkTimeOptimization :
7. Browsing/dumping tools for LTO files
Is there anything already out there, even if half-baked?
I am having trouble understanding a problem in LTO and I think the bug is in
the writing of trees into the object file but
On Mon, Jun 24, 2013 at 1:20 PM, Paulo Matos wrote:
> Hello,
>
> I see this item in http://gcc.gnu.org/wiki/LinkTimeOptimization :
> 7. Browsing/dumping tools for LTO files
>
> Is there anything already out there, even if half-baked?
Nothing.
> I am having trouble understanding a problem in
Richard,
I've noticed that f.i. *thumb2_alusi3_short has no explicit setting of the conds
attribute, which means the value of the conds attribute for this insn is nocond:
...
(define_insn "*thumb2_alusi3_short"
[(set (match_operand:SI 0 "s_register_operand" "=l")
(match_operator
Hello Iain. I'm adding ghm-discuss in Cc. I think we shouldn't follow
up on gcc@ any more at this point. Let's not bother the hardworking
compiler masters :-).
On 2013-06-24 at 01:15, Iain Buclaw wrote:
> I did a similar such talk at DConf 2013 with my GCC front-end for the
> D programming lan
Hi,
I’ve recently started to work on libgomp with the goal of proposing
a new way of handling queues of tasks based on the work done by a
PhD student.
While working on libgomp’s code I noticed two things that puzzled me:
- The code uses gcc’s atomic builtins but doesn’t use the
__ATOMIC_
On 24 June 2013 17:02, Luca Saiu wrote:
> Hello Iain. I'm adding ghm-discuss in Cc. I think we shouldn't follow
> up on gcc@ any more at this point. Let's not bother the hardworking
> compiler masters :-).
>
> On 2013-06-24 at 01:15, Iain Buclaw wrote:
>
>> I did a similar such talk at DConf 20
On 2013-06-24 at 19:14, Iain Buclaw wrote:
> My talk at Dconf2013 can be bulleted into the following:
>
> - What is GDC?
> - A brief history of porting the D language to GCC.
> - D language and library support, including current challenges being faced.
> - Introduction to GCC, in particular an ove
On 24 June 2013 18:38, Luca Saiu wrote:
> On 2013-06-24 at 19:14, Iain Buclaw wrote:
>
>> My talk at Dconf2013 can be bulleted into the following:
>>
>> - What is GDC?
>> - A brief history of porting the D language to GCC.
>> - D language and library support, including current challenges being fac
On 06/24/2013 12:37 AM, Vineet Gupta wrote:
> Aha, I see what's happening. For historical reasons, ARC Linux kernel stack
> unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being non
> allocatable it would default to address zero hence the orig absolute
> relocations
> would wo
On 06/25/2013 12:35 AM, Richard Henderson wrote:
> On 06/24/2013 12:37 AM, Vineet Gupta wrote:
>> Aha, I see what's happening. For historical reasons, ARC Linux kernel stack
>> unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being
>> non
>> allocatable it would default to addr
On 13/6/24 下午11:43, Tom de Vries wrote:
> Richard,
>
> I've noticed that f.i. *thumb2_alusi3_short has no explicit setting of the
> conds
> attribute, which means the value of the conds attribute for this insn is
> nocond:
> ...
> (define_insn "*thumb2_alusi3_short"
> [(set (match_operand:SI
15 matches
Mail list logo