Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Matthias Schiffer]

On 03/09/2018 01:56 PM, Matthias Schiffer wrote:
> On 03/07/2018 06:49 PM, Lucian Cristian wrote:
>> testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3
>> gives this error in luci
>>
>> daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6:
>> attempt to call a number value
>> daemon.err uhttpd[873]: stack traceback:
>> daemon.err uhttpd[873]:    /usr/lib/lua/luci/debug.lua:6: in main chunk
>> daemon.err uhttpd[873]:    [C]: in function 'require'
>> daemon.err uhttpd[873]:    /usr/lib/lua/luci/util.lua:8: in main chunk
>> daemon.err uhttpd[873]:    [C]: in function 'require'
>> daemon.err uhttpd[873]:    /usr/lib/lua/luci/config.lua:4: in main chunk
>> daemon.err uhttpd[873]:    [C]: in function 'require'
>> daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk
>> daemon.err uhttpd[873]:    [C]: in function 'require'
>> daemon.err uhttpd[873]:    /www/cgi-bin/luci:2: in main chunk
>> daemon.err uhttpd[873]:    [C]: ?
> 
> 
> I was able to reproduce this on ar71xx. Minimal testcase:
> 
>> s = 'foo'
>> print(s:sub(2))
> 
> fails, while
> 
>> print(s.sub(s, 2))
> 
> works correctly, even though the former is only syntactic sugar for the
> latter. FWIW, type(s) correctly states that s is a string. Looking into it 
> now.
> 
> Matthias

Bug reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790

Matthias



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Matthias Schiffer]

On 03/07/2018 06:49 PM, Lucian Cristian wrote:
> testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3
> gives this error in luci
> 
> daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6:
> attempt to call a number value
> daemon.err uhttpd[873]: stack traceback:
> daemon.err uhttpd[873]:    /usr/lib/lua/luci/debug.lua:6: in main chunk
> daemon.err uhttpd[873]:    [C]: in function 'require'
> daemon.err uhttpd[873]:    /usr/lib/lua/luci/util.lua:8: in main chunk
> daemon.err uhttpd[873]:    [C]: in function 'require'
> daemon.err uhttpd[873]:    /usr/lib/lua/luci/config.lua:4: in main chunk
> daemon.err uhttpd[873]:    [C]: in function 'require'
> daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk
> daemon.err uhttpd[873]:    [C]: in function 'require'
> daemon.err uhttpd[873]:    /www/cgi-bin/luci:2: in main chunk
> daemon.err uhttpd[873]:    [C]: ?


I was able to reproduce this on ar71xx. Minimal testcase:

> s = 'foo'
> print(s:sub(2))

fails, while

> print(s.sub(s, 2))

works correctly, even though the former is only syntactic sugar for the
latter. FWIW, type(s) correctly states that s is a string. Looking into it now.

Matthias



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Lucian Cristian]

On 04.03.2018 17:15, Hauke Mehrtens wrote:

On 02/16/2018 01:46 PM, John Crispin wrote:

Hi,

whats on the critical todo list for the upcoming release ? i still have
a few minor things that I'll be adding shortly, apart from that I am
currently not aware of any huge problems. the release will be a mix
between 4.9 and 4.14 afaik !?

I think the kernel situation is ok now and not blocking a release, we
will have a mixed kernel 4.9 and 4.14 release. All important targets are
on one of these two kernel versions by now.
The patches for the gemini target will probably get included soon.
Some targets will probably be updated from 4.9 to 4.14, but this is not
blocking.


What do we want to do with GCC 5.5 versus 7.3?
GCC 5.5 is getting old, we have multiple problems with it, the big
blocker for GCC 7 was just fixed upstream and we backported that fix.
see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
The x86 and x86_64 architectures are already on GCC 7.3, the ARC
architecture uses their own GCC fork based on version 7.X all other
architectures are on GCC 5.5.

We have the following problems with GCC 5.5:
  * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
   * GCC 5 and older are producing too big binaries, e.g. the SPL on the
Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
  * busybox on the gemini target updated to kernel 4.14 does not work
correctly.
  * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
the retpoline fixes against Spectre included

As the x86 target use GCC 7.3 now, there are multiple pull requests
fixing some build problems in some packages with GCC 7.
I am not aware of any regressions in GCC 7 compared to GCC 5.
Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
problems are the regressions we are not aware of by now, if we change
the default compiler for all architectures to GCC 7 we should probably
wait 4 weeks before doing an RC release to be sure most of the runtime
problems with GCC 7 are found.

If we do the switch to GCC 7 I think we should also change binutils from
2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
was already fixed in 2.28.1:
https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
The minor versions contains more bugfixes.


There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.


I do not know what the status of the software fast path patches are, but
they are looking interesting.


My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3 
gives this error in luci


daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6: 
attempt to call a number value

daemon.err uhttpd[873]: stack traceback:
daemon.err uhttpd[873]:    /usr/lib/lua/luci/debug.lua:6: in main chunk
daemon.err uhttpd[873]:    [C]: in function 'require'
daemon.err uhttpd[873]:    /usr/lib/lua/luci/util.lua:8: in main chunk
daemon.err uhttpd[873]:    [C]: in function 'require'
daemon.err uhttpd[873]:    /usr/lib/lua/luci/config.lua:4: in main chunk
daemon.err uhttpd[873]:    [C]: in function 'require'
daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk
daemon.err uhttpd[873]:    [C]: in function 'require'
daemon.err uhttpd[873]:    /www/cgi-bin/luci:2: in main chunk
daemon.err uhttpd[873]:    [C]: ?


Regards


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Rosen Penev]

On Sun, Mar 4, 2018 at 7:15 AM, Hauke Mehrtens  wrote:
> On 02/16/2018 01:46 PM, John Crispin wrote:
>> Hi,
>>
>> whats on the critical todo list for the upcoming release ? i still have
>> a few minor things that I'll be adding shortly, apart from that I am
>> currently not aware of any huge problems. the release will be a mix
>> between 4.9 and 4.14 afaik !?
>
> I think the kernel situation is ok now and not blocking a release, we
> will have a mixed kernel 4.9 and 4.14 release. All important targets are
> on one of these two kernel versions by now.
> The patches for the gemini target will probably get included soon.
> Some targets will probably be updated from 4.9 to 4.14, but this is not
> blocking.
>
>
> What do we want to do with GCC 5.5 versus 7.3?
> GCC 5.5 is getting old, we have multiple problems with it, the big
> blocker for GCC 7 was just fixed upstream and we backported that fix.
> see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
> The x86 and x86_64 architectures are already on GCC 7.3, the ARC
> architecture uses their own GCC fork based on version 7.X all other
> architectures are on GCC 5.5.

Preliminary testing with GCC 7.3 reveals that it fixes the SATA data
corruption issue on MIPS (at least ramips and ar71xx, possibly
others). @dissent1 started seeing the issue after going back to 5.5 in
his builds.

Both GCC 5.5 and 7.3 fail with -O3, but that's beyond the scope of OpenWrt.
>
> We have the following problems with GCC 5.5:
>  * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
>   * GCC 5 and older are producing too big binaries, e.g. the SPL on the
> Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
> 2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
>  * busybox on the gemini target updated to kernel 4.14 does not work
> correctly.
>  * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
> the retpoline fixes against Spectre included
>
> As the x86 target use GCC 7.3 now, there are multiple pull requests
> fixing some build problems in some packages with GCC 7.
> I am not aware of any regressions in GCC 7 compared to GCC 5.
> Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
> problems are the regressions we are not aware of by now, if we change
> the default compiler for all architectures to GCC 7 we should probably
> wait 4 weeks before doing an RC release to be sure most of the runtime
> problems with GCC 7 are found.
>
> If we do the switch to GCC 7 I think we should also change binutils from
> 2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
> was already fixed in 2.28.1:
> https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
> The minor versions contains more bugfixes.
>
>
> There is also a pull request for busybox 2.28.1 at github, this will
> probably also introduce some more regressions, so I am not sure if we
> should take it before or after the release.
> https://github.com/openwrt/openwrt/pull/733
> I do not have a real opinion on this and I am probably the wrong person
> to judge this.
Likewise. I vote for getting it in.
>
>
> I do not know what the status of the software fast path patches are, but
> they are looking interesting.
>
>
> My proposal would be to update all targets to GCC 7.3 and also use
> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
> possible and then we branch of end of March or beginning of April for
> 18.X and do a RC1 one week after creating the branch.
>
> Hauke
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Hauke Mehrtens]

On 03/04/2018 04:40 PM, Felix Fietkau wrote:
> On 2018-03-04 16:15, Hauke Mehrtens wrote:
>> There is also a pull request for busybox 2.28.1 at github, this will
>> probably also introduce some more regressions, so I am not sure if we
>> should take it before or after the release.
>> https://github.com/openwrt/openwrt/pull/733
>> I do not have a real opinion on this and I am probably the wrong person
>> to judge this.
> Anything useful in there?

I haven't seen there anything useful, except support for some new MIPS
ISAs, but I do not know if they ever will be relevant.
binutils:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/tags/binutils-2_30
gas:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;hb=refs/tags/binutils-2_30
ld:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=ld/NEWS;hb=refs/tags/binutils-2_30

>> I do not know what the status of the software fast path patches are, but
>> they are looking interesting.
> I think the flow offload support will be ready soon. So far it's looking
> good aside from some issues with TCP connection timeout handling that
> I'm going to deal with soon. We should make it clear that those patches
> are still experimental though.
> 
>> My proposal would be to update all targets to GCC 7.3 and also use
>> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
>> possible and then we branch of end of March or beginning of April for
>> 18.X and do a RC1 one week after creating the branch.
> Fine with me. I'll run some more test builds for various architectures.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Felix Fietkau]

On 2018-03-04 16:15, Hauke Mehrtens wrote:
> There is also a pull request for busybox 2.28.1 at github, this will
> probably also introduce some more regressions, so I am not sure if we
> should take it before or after the release.
> https://github.com/openwrt/openwrt/pull/733
> I do not have a real opinion on this and I am probably the wrong person
> to judge this.
Anything useful in there?

> I do not know what the status of the software fast path patches are, but
> they are looking interesting.
I think the flow offload support will be ready soon. So far it's looking
good aside from some issues with TCP connection timeout handling that
I'm going to deal with soon. We should make it clear that those patches
are still experimental though.

> My proposal would be to update all targets to GCC 7.3 and also use
> binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
> possible and then we branch of end of March or beginning of April for
> 18.X and do a RC1 one week after creating the branch.
Fine with me. I'll run some more test builds for various architectures.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.03/4 -> GCC 5 or 7

[Hauke Mehrtens]

On 02/16/2018 01:46 PM, John Crispin wrote:
> Hi,
> 
> whats on the critical todo list for the upcoming release ? i still have
> a few minor things that I'll be adding shortly, apart from that I am
> currently not aware of any huge problems. the release will be a mix
> between 4.9 and 4.14 afaik !?

I think the kernel situation is ok now and not blocking a release, we
will have a mixed kernel 4.9 and 4.14 release. All important targets are
on one of these two kernel versions by now.
The patches for the gemini target will probably get included soon.
Some targets will probably be updated from 4.9 to 4.14, but this is not
blocking.


What do we want to do with GCC 5.5 versus 7.3?
GCC 5.5 is getting old, we have multiple problems with it, the big
blocker for GCC 7 was just fixed upstream and we backported that fix.
see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f
The x86 and x86_64 architectures are already on GCC 7.3, the ARC
architecture uses their own GCC fork based on version 7.X all other
architectures are on GCC 5.5.

We have the following problems with GCC 5.5:
 * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64
  * GCC 5 and older are producing too big binaries, e.g. the SPL on the
Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot
2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem.
 * busybox on the gemini target updated to kernel 4.14 does not work
correctly.
 * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has
the retpoline fixes against Spectre included

As the x86 target use GCC 7.3 now, there are multiple pull requests
fixing some build problems in some packages with GCC 7.
I am not aware of any regressions in GCC 7 compared to GCC 5.
Changing the default compiler from GCC 5 to GCC 7 is no big problem, the
problems are the regressions we are not aware of by now, if we change
the default compiler for all architectures to GCC 7 we should probably
wait 4 weeks before doing an RC release to be sure most of the runtime
problems with GCC 7 are found.

If we do the switch to GCC 7 I think we should also change binutils from
2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which
was already fixed in 2.28.1:
https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc
The minor versions contains more bugfixes.


There is also a pull request for busybox 2.28.1 at github, this will
probably also introduce some more regressions, so I am not sure if we
should take it before or after the release.
https://github.com/openwrt/openwrt/pull/733
I do not have a real opinion on this and I am probably the wrong person
to judge this.


I do not know what the status of the software fast path patches are, but
they are looking interesting.


My proposal would be to update all targets to GCC 7.3 and also use
binutils 2.29.1 and musl 1.1.19. This change would be done as soon as
possible and then we branch of end of March or beginning of April for
18.X and do a RC1 one week after creating the branch.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev