On Nov 9, 2017, Jeff Law wrote:
>> I didn't want yet another rtl code that would have to be added to
>> cases all over; the distinction between markers matters at only very
>> few points in the compiler.
> Is it fair to say one is just a variant of the other?
I don't see them that way, but the
On 11/01/2017 12:35 PM, Alexandre Oliva wrote:
> On Oct 31, 2017, Jeff Law wrote:
>
>>> @@ -5691,6 +5691,15 @@ expand_gimple_basic_block (basic_block bb, bool
>>> disable_tail_calls)
>>> goto delink_debug_stmt;
>>> else if (gimple_debug_begin_stmt_p (stmt))
>>> val = gen_rtx_DEBUG_MARKER (VOIDmo
On Oct 31, 2017, Jeff Law wrote:
>> @@ -5691,6 +5691,15 @@ expand_gimple_basic_block (basic_block bb, bool
>> disable_tail_calls)
>> goto delink_debug_stmt;
>> else if (gimple_debug_begin_stmt_p (stmt))
>> val = gen_rtx_DEBUG_MARKER (VOIDmode);
>> + else if (gimple_debug_inline_entry_p
On 09/30/2017 03:08 AM, Alexandre Oliva wrote:
> Output DW_AT_entry_pc based on markers.
>
> Introduce DW_AT_GNU_entry_view as a DWARF extension.
>
> If views are enabled are we're not in strict compliance mode, output
> DW_AT_GNU_entry_view if it might be nonzero.
>
> This patch depends on SFN
Output DW_AT_entry_pc based on markers.
Introduce DW_AT_GNU_entry_view as a DWARF extension.
If views are enabled are we're not in strict compliance mode, output
DW_AT_GNU_entry_view if it might be nonzero.
This patch depends on SFN and LVU patchsets, and on the IEPM patch that
introduces the in
Output DW_AT_entry_pc based on markers.
Introduce DW_AT_GNU_entry_view as a DWARF extension.
If views are enabled are we're not in strict compliance mode, output
DW_AT_GNU_entry_view if it might be nonzero.
This patch depends on SFN and LVU patchsets, and on the IEPM patch that
introduces the in
