Hi!
On Sat, Apr 28, 2018 at 12:32:26AM +0100, Thomas Preudhomme wrote:
> On Arm (Aarch32 and Aarch64) the stack protector's guard is accessed by
> loading its address first before loading its value from it as part of
> the stack_protect_set or stack_protect_check insn pattern. This creates
> the r
Hi, Richi
I had been using two source trees to speed the bisection and didn't realize
that one defaulted to DWARF debugging and the other defaulted to XCOFF
debugging, which confused the bisection result. The -f[no-]checking patch
is the culprit.
Thanks, David
On Sat, Apr 28, 2018 at 4:08 AM Ri
Thanks to Mr. Meyers for his comments. Here is an updated version of
the patch. Test cases are included this time.
Tested with 'make bootstrap' on x86_64-pc-linux-gnu. Results from make
-k check available upon request.
I hope that this one is better! Thanks again for everyone's patience!
Will
On Sat, Apr 28, 2018 at 08:54:00PM +0200, Eric Botcazou wrote:
> > I don't know what LLVMish does, or whether it implements the GNU
> > DebugFission variant of split DWARF, the DWARF5 variant or something
> > else. For GCC -gsplit-dwarf generates GNU DebugFission output
> > (including .debug_addr)
On Sat, Apr 28, 2018 at 08:54:00PM +0200, Eric Botcazou wrote:
> > For GCC -gsplit-dwarf generates GNU DebugFission output
> > (including .debug_addr) for older DWARF versions.
> > It is described here: https://gcc.gnu.org/wiki/DebugFission
>
> Yes, that's what I was referring to. DebugFission is
On Sat, Apr 28, 2018 at 09:01:45PM +0200, Mark Wielaard wrote:
> gcc/ChangeLog
>
> * dwarf2out.c (dwarf2out_finish): Add .debug_addr table header for
> dwarf_version >= 5.
> (dwarf_AT): Handle DW_AT_addr_base.
> (add_top_level_skeleton_die_attrs): Use dwarf_AT for DW_AT_add
On Sat, Apr 28, 2018 at 06:36:02PM +0200, Jakub Jelinek wrote:
> On Sat, Apr 28, 2018 at 05:23:12PM +0200, Mark Wielaard wrote:
> >switch_to_section (debug_addr_section);
> > + /* GNU DebugFission didn't have a header for .debug_addr. */
> > + if (dwarf_version >= 5)
> > + {
>
Hi,
with number of cores increasing our partitioning algorithm needs some love,
because it works quite bad.
This patch fixes few issues with ballanced partitioning algorithm:
1) I have switched all size/boundary summaries to 64bit arthmetics as they
may overflow for very large units
2) inter
> I don't know what LLVMish does, or whether it implements the GNU
> DebugFission variant of split DWARF, the DWARF5 variant or something
> else. For GCC -gsplit-dwarf generates GNU DebugFission output
> (including .debug_addr) for older DWARF versions.
> It is described here: https://gcc.gnu.org/w
On Fri, Apr 27, 2018 at 7:26 PM, Paolo Carlini wrote:
> Hi again,
>
> I'm now pretty sure that we have a latent issue in ocp_convert. The bug
> fixed by Jakub shows that we used to not have issues with integer_zero_node.
> That's easy to explain: at the beginning of ocp_convert there is code which
On Sat, Apr 28, 2018 at 05:23:12PM +0200, Mark Wielaard wrote:
> GNU DebugFission didn't add table headers for the .debug_addr
> tables, but DWARF5 does. The table header make it possible
> for a DWARF consumer to parse the address tables without having
> to index all .debug_info CUs first. We can
Hi Eric,
On Sat, 2018-04-28 at 18:00 +0200, Eric Botcazou wrote:
> > index d3d925d..51d0ca4 100644
> > --- a/gcc/dwarf2out.c
> > +++ b/gcc/dwarf2out.c
> > @@ -31293,6 +31293,21 @@ dwarf2out_finish (const char *)
> > }
> >
> > switch_to_section (debug_addr_section);
> > + /* GNU De
> index d3d925d..51d0ca4 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -31293,6 +31293,21 @@ dwarf2out_finish (const char *)
> }
>
>switch_to_section (debug_addr_section);
> + /* GNU DebugFission didn't have a header for .debug_addr. */
> + if (dwarf_version
On 04/27/2018 07:12 AM, Nathan Sidwell wrote:
On 04/26/2018 01:31 PM, Sandra Loosemore wrote:
Hmmm, I'm not crazy about putting this material in the middle of a
discussion about how the compiler comes up with its default dump file
names. How about splitting the existing paragraph into 3:
Ye
On 04/28/2018 12:46 AM, Richard Biener wrote:
> On Fri, 27 Apr 2018, Richard Biener wrote:
>
>> On Fri, 27 Apr 2018, David Edelsohn wrote:
>>
>>> Hi, Richi
>>>
>>> This patches causes a boostrap failure on AIX. Everything miscompares.
>>> The code itself is the same, but the DWARF debug informati
GNU DebugFission didn't add table headers for the .debug_addr
tables, but DWARF5 does. The table header make it possible
for a DWARF consumer to parse the address tables without having
to index all .debug_info CUs first. We can keep using the
.debug_addr section label as is, because the DW_AT_addr_
Hi all,
because pr81773 is a 6-/7-/8-regression I have backported it to gcc-6 as r259741
and gcc-7 as r259742.
Regards,
Andre
On Sat, 14 Apr 2018 16:46:53 +0200
Andre Vehreschild wrote:
> Hi Paul,
>
> thank you for the review. Committed as r259385.
>
> Regards,
> Andre
>
> On
Thomas Preudhomme writes:
> On Arm (Aarch32 and Aarch64) the stack protector's guard is accessed by
> loading its address first before loading its value from it as part of
> the stack_protect_set or stack_protect_check insn pattern. This creates
> the risk of spilling between the two.
>
> It is pa
I'm back for stage 1!
The same patch from https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01549.html
rebases cleanly and I didn't change anything but the date on the log entry
since what I posted there. The fresh rebase is on the roland/pr77609 git
branch for your convenience.
It has no check-gcc
> This looks not a generic enough fix to me - consider
>
> void foo(void) { int a[10]; a[0] = 1; a[9] = 1; }
> int main() { try { foo (); } catch (...) {} }
>
> with -fnon-call-exceptions. If we'd like to catch the SEGV from stack
> overflows then your fix doesn't handle the non-recursiv
On Sat, 28 Apr 2018, Richard Biener wrote:
> On Fri, 27 Apr 2018, Richard Biener wrote:
>
> > On Fri, 27 Apr 2018, David Edelsohn wrote:
> >
> > > Hi, Richi
> > >
> > > This patches causes a boostrap failure on AIX. Everything miscompares.
> > > The code itself is the same, but the DWARF debug
2018-04-28 Uros Bizjak
PR target/84431
* config/i386/i386.md (*ashl3_doubleword_mask): New pattern.
(*ashl3_doubleword_mask_1): Ditto.
(*3_doubleword_mask): Ditto.
(*3_doubleword_mask_1): Ditto.
testsuite/ChangeLog:
2018-04-28 Uros Bizjak
PR target/84431
* gcc.
On Fri, 27 Apr 2018, Richard Biener wrote:
>
> This makes us not record all stmts in the visited_stmts hash-set
> but only those that are possibly valid EH stmts. Should save us
> some cycles here.
>
> Bootstrap running on x86_64-unknown-linux-gnu.
This is what i have applied.
Richard.
2018-
23 matches
Mail list logo