On Tue, 12 Mar 2019, I wrote:
> ... I did another experiment with the latter (forced inline) approach,
> to see if some optimizations can still be used with -ffreestanding.
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index 7927b875f80c..25b5bf689018 100644
> ---
On Mon, 11 Mar 2019, Geert Uytterhoeven wrote:
> On Mon, Mar 11, 2019 at 11:13 AM Andreas Schwab wrote:
> > On M?r 11 2019, Geert Uytterhoeven wrote:
> > > On Mon, Mar 11, 2019 at 10:56 AM Andreas Schwab
> > > wrote:
> > >> On M?r 11 2019, Geert Uytterhoeven wrote:
> > >> > On Thu, Mar 7,
Hi Andreas,
On Mon, Mar 11, 2019 at 11:13 AM Andreas Schwab wrote:
> On Mär 11 2019, Geert Uytterhoeven wrote:
> > On Mon, Mar 11, 2019 at 10:56 AM Andreas Schwab
> > wrote:
> >> On Mär 11 2019, Geert Uytterhoeven wrote:
> >> > On Thu, Mar 7, 2019 at 10:42 PM Finn Thain
> >> > wrote:
> >>
On Mär 11 2019, Geert Uytterhoeven wrote:
> Hi Andreas,
>
> On Mon, Mar 11, 2019 at 10:56 AM Andreas Schwab wrote:
>> On Mär 11 2019, Geert Uytterhoeven wrote:
>> > On Thu, Mar 7, 2019 at 10:42 PM Finn Thain
>> > wrote:
>> >> No, the link fails because the compiler still emits some
Hi Andreas,
On Mon, Mar 11, 2019 at 10:56 AM Andreas Schwab wrote:
> On Mär 11 2019, Geert Uytterhoeven wrote:
> > On Thu, Mar 7, 2019 at 10:42 PM Finn Thain
> > wrote:
> >> No, the link fails because the compiler still emits some references to
> >> strlen().
> >
> > Despite -ffreestanding?!?
On Mär 11 2019, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Thu, Mar 7, 2019 at 10:42 PM Finn Thain wrote:
>> No, the link fails because the compiler still emits some references to
>> strlen().
>
> Despite -ffreestanding?!?
*Because* of -ffreestanding. Without that, strlen would be recognized
Hi Finn,
On Thu, Mar 7, 2019 at 10:42 PM Finn Thain wrote:
> On Thu, 7 Mar 2019, Geert Uytterhoeven wrote:
> > On Thu, Mar 7, 2019 at 3:59 AM Finn Thain
> > wrote:
> > > On Tue, 5 Mar 2019, Andreas Schwab wrote:
> > > > On Mar 05 2019, Finn Thain wrote:
> > > >
> > > > > interesting that the
On Thu, 7 Mar 2019, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 3:59 AM Finn Thain wrote:
> > On Tue, 5 Mar 2019, Andreas Schwab wrote:
> > > On Mar 05 2019, Finn Thain wrote:
> > >
> > > > interesting that the kernel's strlen implementation in
> > > > include/linux/string.h can't
Hi Finn,
On Thu, Mar 7, 2019 at 3:59 AM Finn Thain wrote:
> On Tue, 5 Mar 2019, Andreas Schwab wrote:
> > On Mar 05 2019, Finn Thain wrote:
> >
> > > interesting that the kernel's strlen implementation in
> > > include/linux/string.h can't achieve this.
> >
> > This implementation is only
On Tue, 5 Mar 2019, Andreas Schwab wrote:
> On Mar 05 2019, Finn Thain wrote:
>
> > interesting that the kernel's strlen implementation in
> > include/linux/string.h can't achieve this.
>
> This implementation is only available if ARCH_HAS_FORTIFY_SOURCE.
>
I see. Perhaps we could add
On Mär 05 2019, Finn Thain wrote:
> interesting that the kernel's strlen implementation in
> include/linux/string.h can't achieve this.
This implementation is only available if ARCH_HAS_FORTIFY_SOURCE.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5
Hi Finn,
On Tue, Mar 5, 2019 at 9:58 AM Finn Thain wrote:
> On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> > On Tue, Mar 5, 2019 at 3:58 AM Finn Thain
> > wrote:
> > > On Tue, 5 Mar 2019, Finn Thain wrote:
> > > > Looks bogus to me.
> > > >
> > > > If you change memcpy to __builtin_memcpy,
On Tue, 5 Mar 2019, Geert Uytterhoeven wrote:
> On Tue, Mar 5, 2019 at 3:58 AM Finn Thain wrote:
> > On Tue, 5 Mar 2019, Finn Thain wrote:
> > > Looks bogus to me.
> > >
> > > If you change memcpy to __builtin_memcpy, then we avoid the macro and the
> > > warning changes to,
> > >
> > >
Hi Finn,
On Tue, Mar 5, 2019 at 3:58 AM Finn Thain wrote:
> On Tue, 5 Mar 2019, Finn Thain wrote:
> > Looks bogus to me.
> >
> > If you change memcpy to __builtin_memcpy, then we avoid the macro and the
> > warning changes to,
> >
> > ./include/linux/string.h:456:3: warning: '__builtin_memcpy'
On Tue, 5 Mar 2019, Finn Thain wrote:
>
> Looks bogus to me.
>
> If you change memcpy to __builtin_memcpy, then we avoid the macro and the
> warning changes to,
>
> ./include/linux/string.h:456:3: warning: '__builtin_memcpy' forming offset
> [7, 8] is out of the bounds [0, 6]
On Mon, 4 Mar 2019, Geert Uytterhoeven wrote:
> On Mon, Mar 4, 2019 at 1:44 PM kbuild test robot wrote:
> > tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git master
> > head: e223cadc191661c67cb419b3a53c7854ecc39e8b
> > commit:
On Mon, Mar 4, 2019 at 1:44 PM kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
> master
> head: e223cadc191661c67cb419b3a53c7854ecc39e8b
> commit: e223cadc191661c67cb419b3a53c7854ecc39e8b [1174/1174] Merge tag 'v5.0'
> config:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
master
head: e223cadc191661c67cb419b3a53c7854ecc39e8b
commit: e223cadc191661c67cb419b3a53c7854ecc39e8b [1174/1174] Merge tag 'v5.0'
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu-gcc (Debian
18 matches
Mail list logo