On Thu, 2018-06-21 at 17:35 +0200, Grégoire Jadi wrote:
> Kurt Miller writes:
> > >
> > On Wed, 2018-06-20 at 16:25 +0200, Grégoire Jadi wrote:
> >
> > >
> > > Christian Weisgerber writes:
> > > Hello,
> > >
> > > I may have encountered the same bug when I tried to build programs
> > > genera
Kurt Miller writes:
> On Wed, 2018-06-20 at 16:25 +0200, Grégoire Jadi wrote:
>
>> Christian Weisgerber writes:
>> Hello,
>>
>> I may have encountered the same bug when I tried to build programs
>> generated with devel/arduino. cc1 aborts with a coredump during the
>> compilation.
>
> I just co
On Wed, 2018-06-20 at 16:25 +0200, Grégoire Jadi wrote:
> Christian Weisgerber writes:
> Hello,
>
> I may have encountered the same bug when I tried to build programs
> generated with devel/arduino. cc1 aborts with a coredump during the
> compilation.
I just committed a fix for devel/avr/gcc, pl
Christian Weisgerber writes:
Hello,
I may have encountered the same bug when I tried to build programs
generated with devel/arduino. cc1 aborts with a coredump during the
compilation.
I think I have found the culprits: both ISR() and SIGNAL() macros from
avr/interrupt.h use the __attribute__((si
Another way people can approach this is to build the port with
-fstack-protector-all, and all it's dependencies. The 1-byte
overflow may be easier to diagnose without retguard protection,
but the old school -all protector probably exposes it.
These days, -fstack-protector defaults to -fstack-prot
Since the introduction of retguard, devel/simulavr has continuously
failed to build on amd64. This is actually a bug in devel/avr/gcc.
The problem was diagnosed early by mortimer@. As I'm not making
any progress, I'm forwarding his analysis here to give other people
a chance to help out.
---
