On Fri, Mar 09, 2018 at 09:48:45AM +, Bin.Cheng wrote:
> On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote:
> > On Feb 21, 2018, Alexandre Oliva wrote:
> >
> >> On Feb 15, 2018, Szabolcs Nagy wrote:
> >>> i see assembler slow downs with these location view patches
> >>> i opened https:/
On Fri, Mar 9, 2018 at 9:48 AM, Bin.Cheng wrote:
> On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote:
>> On Feb 21, 2018, Alexandre Oliva wrote:
>>
>>> On Feb 15, 2018, Szabolcs Nagy wrote:
i see assembler slow downs with these location view patches
i opened https://gcc.gnu.org/b
On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote:
> On Feb 21, 2018, Alexandre Oliva wrote:
>
>> On Feb 15, 2018, Szabolcs Nagy wrote:
>>> i see assembler slow downs with these location view patches
>>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
>
>
>> [LVU] reset view at
On 02/21/2018 03:11 AM, Alexandre Oliva wrote:
> On Feb 15, 2018, Szabolcs Nagy wrote:
>
>> i see assembler slow downs with these location view patches
>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
>
>
> [LVU] reset view at function entry, omit views at line zero
>
> Location
On Feb 21, 2018, Alexandre Oliva wrote:
> On Feb 15, 2018, Szabolcs Nagy wrote:
>> i see assembler slow downs with these location view patches
>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
> [LVU] reset view at function entry, omit views at line zero
Ping? https://gcc.gnu.or
On Wed, Feb 21, 2018 at 11:32 AM, Alexandre Oliva wrote:
> On Jan 24, 2018, Jakub Jelinek wrote:
>
>>> --- a/gcc/tree-ssa-live.c
>>> +++ b/gcc/tree-ssa-live.c
>>> @@ -520,6 +520,11 @@ remove_unused_scope_block_p (tree scope, bool
>>> in_ctor_dtor_block)
>>> else if (!BLOCK_SUPERCONTEXT (scope)
>
On 21/02/18 10:11, Alexandre Oliva wrote:
On Feb 15, 2018, Szabolcs Nagy wrote:
i see assembler slow downs with these location view patches
i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
[LVU] reset view at function entry, omit views at line zero
Location views might be associ
On Wed, Feb 21, 2018 at 11:11 AM, Alexandre Oliva wrote:
> On Feb 15, 2018, Szabolcs Nagy wrote:
>
>> i see assembler slow downs with these location view patches
>> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
>
>
> [LVU] reset view at function entry, omit views at line zero
>
> Lo
On Jan 24, 2018, Jakub Jelinek wrote:
>> --- a/gcc/tree-ssa-live.c
>> +++ b/gcc/tree-ssa-live.c
>> @@ -520,6 +520,11 @@ remove_unused_scope_block_p (tree scope, bool
>> in_ctor_dtor_block)
>> else if (!BLOCK_SUPERCONTEXT (scope)
>> || TREE_CODE (BLOCK_SUPERCONTEXT (scope)) == FUNCTION_DECL)
>> u
On Feb 15, 2018, Szabolcs Nagy wrote:
> i see assembler slow downs with these location view patches
> i opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
[LVU] reset view at function entry, omit views at line zero
Location views might be associated with locations that lack line
number
On 13/02/18 13:43, Alexandre Oliva wrote:
On Feb 12, 2018, Alexandre Oliva wrote:
This patch supersedes the previous one. Testing underway... Ok if it
succeeds?
I failed to update the patch I posted after making a correct to symbol
poisoning, that had caused builds to fail right away, sorr
On 02/13/2018 06:43 AM, Alexandre Oliva wrote:
> On Feb 12, 2018, Alexandre Oliva wrote:
>
>> This patch supersedes the previous one. Testing underway... Ok if it
>> succeeds?
>
> I failed to update the patch I posted after making a correct to symbol
> poisoning, that had caused builds to fail
On Feb 12, 2018, Alexandre Oliva wrote:
> This patch supersedes the previous one. Testing underway... Ok if it
> succeeds?
I failed to update the patch I posted after making a correct to symbol
poisoning, that had caused builds to fail right away, sorry. Thanks,
Rainer, for catching the error
On Feb 9, 2018, Alexandre Oliva wrote:
> On Feb 9, 2018, Jakub Jelinek wrote:
>> On Fri, Feb 09, 2018 at 07:01:25PM -0200, Alexandre Oliva wrote:
>>> So, as discussed on IRC, I'm trying to use a target hook to allow
>>> targets to indicate that their length attrs have been assessed for this
>>
On Feb 10, 2018, Jeff Law wrote:
>> Ports call final_scan_insn with seen == NULL, and then
>> maybe_output_next_view crashes because it assumes it's
>> non-NULL. Oops. Fixed.
> A bit icky. But OK.
Thanks. Testing revealed some ports had already introduced their own
'seen' variables passed to
On 02/10/2018 05:34 AM, Alexandre Oliva wrote:
> Hi, Joseph,
>
> On Feb 9, 2018, Joseph Myers wrote:
>
>> sh4 is:
>> during RTL pass: final
>> In file included from strtof_l.c:45:
>> strtod_l.c: In function 'strtof_l_internal':
>> strtod_l.c:1769:1: internal compiler error: Segmentation fau
On 02/10/2018 06:04 AM, Alexandre Oliva wrote:
> On Feb 10, 2018, Jeff Law wrote:
>
>> So given what I've seen in the ARM port, I don't think we can generally
>> assume any insn advances the PC.
>
> Ugh. Thanks, I'll adjust the patch to not count call insns, I guess.
>
> Maybe what we should h
On Feb 10, 2018, Jeff Law wrote:
> So given what I've seen in the ARM port, I don't think we can generally
> assume any insn advances the PC.
Ugh. Thanks, I'll adjust the patch to not count call insns, I guess.
Maybe what we should have is some target hook that, instead of vowing
for ATTR_leng
Hi, Joseph,
On Feb 9, 2018, Joseph Myers wrote:
> sh4 is:
> during RTL pass: final
> In file included from strtof_l.c:45:
> strtod_l.c: In function 'strtof_l_internal':
> strtod_l.c:1769:1: internal compiler error: Segmentation fault
> }
> ^
> 0xb98e3f crash_signal
> /scratch/jmy
On 02/09/2018 09:39 PM, Alexandre Oliva wrote:
> On Feb 9, 2018, Alexandre Oliva wrote:
>
>> On Feb 9, 2018, Jeff Law wrote:
>>> On 02/08/2018 08:53 PM, Alan Modra wrote:
On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
> Here's what I checked in, right after the LVU p
On Feb 9, 2018, Alexandre Oliva wrote:
> On Feb 9, 2018, Jeff Law wrote:
>> On 02/08/2018 08:53 PM, Alan Modra wrote:
>>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
Here's what I checked in, right after the LVU patch.
[IEPM] Introduce inline entry point ma
On Fri, 9 Feb 2018, Joseph Myers wrote:
> I'm seeing regressions from my glibc bot for all of arm, mips, s390 and
> sh.
>
> https://sourceware.org/ml/libc-testresults/2018-q1/msg00283.html
>
> arm and mips are "view number mismatch" building glibc and s390 is the
> same error but building libg
On Feb 9, 2018, Jakub Jelinek wrote:
> On Fri, Feb 09, 2018 at 07:01:25PM -0200, Alexandre Oliva wrote:
>> So, as discussed on IRC, I'm trying to use a target hook to allow
>> targets to indicate that their length attrs have been assessed for this
>> purpose, and a param to make that overridable
On Fri, Feb 09, 2018 at 07:01:25PM -0200, Alexandre Oliva wrote:
> So, as discussed on IRC, I'm trying to use a target hook to allow
> targets to indicate that their length attrs have been assessed for this
> purpose, and a param to make that overridable, but I'm having trouble
> initializing the p
I'm seeing regressions from my glibc bot for all of arm, mips, s390 and
sh.
https://sourceware.org/ml/libc-testresults/2018-q1/msg00283.html
arm and mips are "view number mismatch" building glibc and s390 is the
same error but building libgcc, so presumably those are the present issue.
sh is
On Feb 9, 2018, Jeff Law wrote:
> On 02/08/2018 08:53 PM, Alan Modra wrote:
>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
>>> Here's what I checked in, right after the LVU patch.
>>>
>>> [IEPM] Introduce inline entry point markers
>>
>> One of these two patches breaks ppc
On 02/09/2018 03:34 AM, Alexandre Oliva wrote:
> On Feb 9, 2018, Jeff Law wrote:
>
>> On 02/08/2018 08:53 PM, Alan Modra wrote:
>>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
Here's what I checked in, right after the LVU patch.
[IEPM] Introduce inline entry p
On Fri, Feb 09, 2018 at 08:34:08AM -0200, Alexandre Oliva wrote:
> * config/rs6000/rs6000.md (blockage): Set length to zero.
Thanks! This fixed the ppc64le libdecnumber error for me.
--
Alan Modra
Australia Development Lab, IBM
On Feb 9, 2018, Jeff Law wrote:
> On 02/08/2018 08:53 PM, Alan Modra wrote:
>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
>>> Here's what I checked in, right after the LVU patch.
>>>
>>> [IEPM] Introduce inline entry point markers
>>
>> One of these two patches breaks ppc
On 02/08/2018 08:53 PM, Alan Modra wrote:
> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
>> Here's what I checked in, right after the LVU patch.
>>
>> [IEPM] Introduce inline entry point markers
>
> One of these two patches breaks ppc64le bootstrap with the assembler
> complain
On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
> Here's what I checked in, right after the LVU patch.
>
> [IEPM] Introduce inline entry point markers
One of these two patches breaks ppc64le bootstrap with the assembler
complaining "Error: view number mismatch" when compiling
lib
On Jan 25, 2018, Alexandre Oliva wrote:
> On Jan 24, 2018, Jakub Jelinek wrote:
>> I think this asks for
>> if (flag_checking)
>> gcc_assert (block_within_block_p (block,
>> DECL_INITIAL (current_function_decl),
>> true));
> 'k, changed.
>> Otherwise the patch looks reasonable to me, but I thi
On Jan 24, 2018, Jakub Jelinek wrote:
> I think this asks for
> if (flag_checking)
> gcc_assert (block_within_block_p (block,
> DECL_INITIAL (current_function_decl),
> true));
'k, changed.
> Otherwise the patch looks
On Tue, Dec 12, 2017 at 12:54:13AM -0200, Alexandre Oliva wrote:
> +/* Check whether BLOCK, a lexical block, is nested within OUTER, or is
> + OUTER itself. If BOTHWAYS, check not only that BLOCK can reach
> + OUTER through BLOCK_SUPERCONTEXT links, but also that there is a
> + path from OUT
On Dec 21, 2017, Jeff Law wrote:
> On 12/11/2017 07:54 PM, Alexandre Oliva wrote:
>> + ASM_GENERATE_INTERNAL_LABEL (label, "LVU", ied->view);
>> + /* FIXME: this will resolve to a small number. Could we
>> + possibly emit smaller data? Ideally we'd emit a
>> +
On 12/11/2017 07:54 PM, Alexandre Oliva wrote:
> On Nov 10, 2017, Alexandre Oliva wrote:
>
>> Output DW_AT_entry_pc based on markers.
>
> Here's an updated version of the patch.
>
> [IEPM] Introduce inline entry point markers
>
> Output DW_AT_entry_pc based on markers.
>
> Introduce DW_AT_GNU
On Nov 10, 2017, Alexandre Oliva wrote:
> Output DW_AT_entry_pc based on markers.
Here's an updated version of the patch.
[IEPM] Introduce inline entry point markers
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 no
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
38 matches
Mail list logo
