Debian Bug report logs - #932989
gcc-avr: Package version severely outdated compared to main gcc-toolchain

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: nightwalker-87 < Nightwalker-87@t-online.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 25 Jul 2019 17:23:31 +0200

Package: gcc-avr
Version: 1:5.4.0+Atmel3.6.1-2
Severity: normal
Tags: newcomer

Dear Maintainer,

It appears that the gcc-avr toolchain in the debian repository is severely
outdated compared to the current level of version support for the main gcc
toolchain. This leaves avr-developers wishing to use newer C language features
behind and makes it necessary to use external toolchains (source based or pre-
compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
following idea: "if it was in mainline, the gcc-avr package could be dropped in
favour of a package built from the mainline version of gcc." as well as "an
example of such a source package is gcc-arm-none-eabi, the equivalent for avr
could be added by someone interested, then gcc-avr could be removed." (user:
pabs) From my point of view this could be a promising approach to resume
development on this topic. I would appreciate, if debian developers could take
action on this topic to resolve this long lasting backlog and make contribution
to make debian even more attractive for development. As it stands the avr-8
architecture will remain for many years to come in some parts even with new
applications.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-avr depends on:
ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
ii  libc6         2.28-10
ii  libgcc1       1:8.3.0-7
ii  libgmp10      2:6.1.2+dfsg-4
ii  libmpc3       1.1.0-1
ii  libmpfr6      4.0.2-1
ii  libstdc++6    8.3.0-7
ii  zlib1g        1:1.2.11.dfsg-1

gcc-avr recommends no packages.

Versions of packages gcc-avr suggests:
ii  avr-libc  1:2.0.0+Atmel3.6.1-2
ii  gcc       4:8.3.0-1
pn  gcc-doc   <none>

-- no debconf information

Message #10 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Hakan Ardo <hakan.ardo@gmail.com>

To: nightwalker-87 <Nightwalker-87@t-online.de>, 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 25 Jul 2019 18:17:50 +0200

[Message part 1 (text/plain, inline)]

Hi,
gcc-avr was originally built from the mainline gcc, but was later split out
by to build depend on gcc-source as it was not wanted in the mainstream gcc
package. Has that situation changed?

It was then decided to base the package on the Atmel distribution instead
of the upstream source as that gave support for newer devices faster.

Now, as far as I can tell, Atmel have dropped their source distribution and
only provided binaries. So something have to be done indeed.

Switching back to use upstream source would be one option. But will that
mean we'll have to dropp support for newer devices?

Den tors 25 juli 2019 17:27nightwalker-87 <Nightwalker-87@t-online.de>
skrev:

> Package: gcc-avr
> Version: 1:5.4.0+Atmel3.6.1-2
> Severity: normal
> Tags: newcomer
>
> Dear Maintainer,
>
> It appears that the gcc-avr toolchain in the debian repository is severely
> outdated compared to the current level of version support for the main gcc
> toolchain. This leaves avr-developers wishing to use newer C language
> features
> behind and makes it necessary to use external toolchains (source based or
> pre-
> compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
> following idea: "if it was in mainline, the gcc-avr package could be
> dropped in
> favour of a package built from the mainline version of gcc." as well as "an
> example of such a source package is gcc-arm-none-eabi, the equivalent for
> avr
> could be added by someone interested, then gcc-avr could be removed."
> (user:
> pabs) From my point of view this could be a promising approach to resume
> development on this topic. I would appreciate, if debian developers could
> take
> action on this topic to resolve this long lasting backlog and make
> contribution
> to make debian even more attractive for development. As it stands the avr-8
> architecture will remain for many years to come in some parts even with new
> applications.
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages gcc-avr depends on:
> ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
> ii  libc6         2.28-10
> ii  libgcc1       1:8.3.0-7
> ii  libgmp10      2:6.1.2+dfsg-4
> ii  libmpc3       1.1.0-1
> ii  libmpfr6      4.0.2-1
> ii  libstdc++6    8.3.0-7
> ii  zlib1g        1:1.2.11.dfsg-1
>
> gcc-avr recommends no packages.
>
> Versions of packages gcc-avr suggests:
> ii  avr-libc  1:2.0.0+Atmel3.6.1-2
> ii  gcc       4:8.3.0-1
> pn  gcc-doc   <none>
>
> -- no debconf information
>

[Message part 2 (text/html, inline)]

Message #15 received at 932989@bugs.debian.org (full text, mbox, reply):

From: nightwalker-87@t-online.de

To: 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 25 Jul 2019 18:41:00 +0200

[Message part 1 (text/plain, inline)]

Dear Hakan,

Thank You very much for your quick reply.

Unfortunately I don’t know too much about the development history of this package @Debian and the related decisions.
It would be helpful though to have other developers and maintainers to have their say on this to help find a common solution.
At first one should find out if support for newer devices would suffer from such an approach. I have not come across that topic yet...

Best regards
Nightwalker-87

> Am 25.07.2019 um 18:17 schrieb Hakan Ardo <hakan.ardo@gmail.com>:
> 
> Hi, 
> gcc-avr was originally built from the mainline gcc, but was later split out by to build depend on gcc-source as it was not wanted in the mainstream gcc package. Has that situation changed? 
> 
> It was then decided to base the package on the Atmel distribution instead of the upstream source as that gave support for newer devices faster. 
> 
> Now, as far as I can tell, Atmel have dropped their source distribution and only provided binaries. So something have to be done indeed. 
> 
> Switching back to use upstream source would be one option. But will that mean we'll have to dropp support for newer devices? 
> 
> Den tors 25 juli 2019 17:27nightwalker-87 <Nightwalker-87@t-online.de <mailto:Nightwalker-87@t-online.de>> skrev:
> Package: gcc-avr
> Version: 1:5.4.0+Atmel3.6.1-2
> Severity: normal
> Tags: newcomer
> 
> Dear Maintainer,
> 
> It appears that the gcc-avr toolchain in the debian repository is severely
> outdated compared to the current level of version support for the main gcc
> toolchain. This leaves avr-developers wishing to use newer C language features
> behind and makes it necessary to use external toolchains (source based or pre-
> compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
> following idea: "if it was in mainline, the gcc-avr package could be dropped in
> favour of a package built from the mainline version of gcc." as well as "an
> example of such a source package is gcc-arm-none-eabi, the equivalent for avr
> could be added by someone interested, then gcc-avr could be removed." (user:
> pabs) From my point of view this could be a promising approach to resume
> development on this topic. I would appreciate, if debian developers could take
> action on this topic to resolve this long lasting backlog and make contribution
> to make debian even more attractive for development. As it stands the avr-8
> architecture will remain for many years to come in some parts even with new
> applications.
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gcc-avr depends on:
> ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
> ii  libc6         2.28-10
> ii  libgcc1       1:8.3.0-7
> ii  libgmp10      2:6.1.2+dfsg-4
> ii  libmpc3       1.1.0-1
> ii  libmpfr6      4.0.2-1
> ii  libstdc++6    8.3.0-7
> ii  zlib1g        1:1.2.11.dfsg-1
> 
> gcc-avr recommends no packages.
> 
> Versions of packages gcc-avr suggests:
> ii  avr-libc  1:2.0.0+Atmel3.6.1-2
> ii  gcc       4:8.3.0-1
> pn  gcc-doc   <none>
> 
> -- no debconf information

[Message part 2 (text/html, inline)]

Message #20 received at 932989@bugs.debian.org (full text, mbox, reply):

From: nightwalker-87@t-online.de

To: 932989@bugs.debian.org

Cc: Hakan Ardo <hakan.ardo@gmail.com>

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Sat, 27 Jul 2019 17:29:59 +0200

[Message part 1 (text/plain, inline)]

Hi Hakan,

pointing to this issue in a developer discussion and also this link (https://savannah.nongnu.org/forum/forum.php?forum_id=8460 <https://savannah.nongnu.org/forum/forum.php?forum_id=8460>) led to the maintainer Jörg Wunsch.
It looks like as if he could be one of the key persons to address regarding this issue, as the key-package avr-libc has a dependency on gcc-avr which determines device compatibility.
The obviously current state of device support for avr-libc 2.0.0 as part of the latest AVR-toolchain 3.6.1 by Microchip can be found here: https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1supp_devices.html <https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1supp_devices.html>.
Would that mean that a new version of avr-libc with full compatibility to gcc 8.3 (for example) could ease portability of the complete toolchain, while preserving device support at the same time?

Another info I came across is that the distribution Arch Linux maintains a very recent version of the toolchain (https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/avr-gcc-9.1.0-1-x86_64.pkg.tar.xz.html <https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/avr-gcc-9.1.0-1-x86_64.pkg.tar.xz.html>).
Would it be possible to port these sources to the Debian? How did the maintainers at Arch manage to achieve compatibility with the latest gcc-mainline? According to the package content this is even based on avr-libc 2.0.0.
Do they have limitations regarding device support?

Nightwalker-87


> Am 25.07.2019 um 18:41 schrieb Nightwalker-87@t-online.de:
> 
> Dear Hakan,
> 
> Thank You very much for your quick reply.
> 
> Unfortunately I don’t know too much about the development history of this package @Debian and the related decisions.
> It would be helpful though to have other developers and maintainers to have their say on this to help find a common solution.
> At first one should find out if support for newer devices would suffer from such an approach. I have not come across that topic yet...
> 
> Best regards
> Nightwalker-87
> 
>> Am 25.07.2019 um 18:17 schrieb Hakan Ardo <hakan.ardo@gmail.com <mailto:hakan.ardo@gmail.com>>:
>> 
>> Hi, 
>> gcc-avr was originally built from the mainline gcc, but was later split out by to build depend on gcc-source as it was not wanted in the mainstream gcc package. Has that situation changed? 
>> 
>> It was then decided to base the package on the Atmel distribution instead of the upstream source as that gave support for newer devices faster. 
>> 
>> Now, as far as I can tell, Atmel have dropped their source distribution and only provided binaries. So something have to be done indeed. 
>> 
>> Switching back to use upstream source would be one option. But will that mean we'll have to dropp support for newer devices? 
>> 
>> Den tors 25 juli 2019 17:27nightwalker-87 <Nightwalker-87@t-online.de <mailto:Nightwalker-87@t-online.de>> skrev:
>> Package: gcc-avr
>> Version: 1:5.4.0+Atmel3.6.1-2
>> Severity: normal
>> Tags: newcomer
>> 
>> Dear Maintainer,
>> 
>> It appears that the gcc-avr toolchain in the debian repository is severely
>> outdated compared to the current level of version support for the main gcc
>> toolchain. This leaves avr-developers wishing to use newer C language features
>> behind and makes it necessary to use external toolchains (source based or pre-
>> compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
>> following idea: "if it was in mainline, the gcc-avr package could be dropped in
>> favour of a package built from the mainline version of gcc." as well as "an
>> example of such a source package is gcc-arm-none-eabi, the equivalent for avr
>> could be added by someone interested, then gcc-avr could be removed." (user:
>> pabs) From my point of view this could be a promising approach to resume
>> development on this topic. I would appreciate, if debian developers could take
>> action on this topic to resolve this long lasting backlog and make contribution
>> to make debian even more attractive for development. As it stands the avr-8
>> architecture will remain for many years to come in some parts even with new
>> applications.
>> 
>> 
>> 
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> 
>> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
>> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>> 
>> Versions of packages gcc-avr depends on:
>> ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
>> ii  libc6         2.28-10
>> ii  libgcc1       1:8.3.0-7
>> ii  libgmp10      2:6.1.2+dfsg-4
>> ii  libmpc3       1.1.0-1
>> ii  libmpfr6      4.0.2-1
>> ii  libstdc++6    8.3.0-7
>> ii  zlib1g        1:1.2.11.dfsg-1
>> 
>> gcc-avr recommends no packages.
>> 
>> Versions of packages gcc-avr suggests:
>> ii  avr-libc  1:2.0.0+Atmel3.6.1-2
>> ii  gcc       4:8.3.0-1
>> pn  gcc-doc   <none>
>> 
>> -- no debconf information
> 

[Message part 2 (text/html, inline)]

Message #25 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: 932989@bugs.debian.org

Cc: 932989-submitter@bugs.debian.org

Subject: gcc-avr: which upstream to track

Date: Sat, 11 Jan 2020 22:46:48 +0900

Hi,

This is a review of CC/C++ for AVR.

Debian Buster:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version                Architecture Description
+++-==============-======================-============-===================================
ii  avr-libc       1:2.0.0+Atmel3.6.1-2   all          Standard C library for Atmel AVR de
ii  avrdude        6.3-20171130+svn1429-2 amd64        software for programming Atmel AVR
ii  gcc            4:8.3.0-1              amd64        GNU C compiler
ii  gcc-avr        1:5.4.0+Atmel3.6.1-2   amd64        GNU C compiler (cross compiler for
ii  gdb-avr        7.7-4+b12              amd64        GNU Debugger for avr

Choice of CC/C++ for AVR can be several choices.  As I googled situation, it looks
like:

(1) Hard ware vendor (microchip) supported CC:
    GCC 5.4.0 based gcc-avr (current state in Debian)

    Yah... it's old compared to the normal GCC 8.3 on buster
    The vendor seems to have no intent to move to newer GCC.

(2) Latest GCC used as the cross-compiler:
    Grntoo promote this: https://wiki.gentoo.org/wiki/Arduino

    But it doesn't look good in near future ....
    https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
    https://www.reddit.com/r/linux/comments/e3flt6/bountysource_campaign_to_modernize_the_avr/
    https://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-now
    GCC 10: AVR is deprecated
    GCC 11: AVR will be dropped

    So moving to the latest GCC is not easy to do.

(3) Forward port vendor patches by someone
    GCC 9.2 ??? by Archlinux
    https://www.archlinux.org/packages/community/x86_64/avr-gcc/

    GCC 9.1 by stevenj
    https://github.com/stevenj/avr-gcc-build-script/releases/tag/20190728
    https://www.avrfreaks.net/forum/avr-gcc-91-avr-libc-xmega3-device-support

    Following such efforts seems fragile at best ... we don't even know
    how well they are tested.

(4) Stable updated GCC with forward ported vendor patches supported by
    the active user community --- Arduino
    Arduino 1.8.10 (Larest release)
    avr-gcc-7.3.0

Considering gcc-avr is mostly aimed for use with Arduino platform and
Arduino forks seem to maintain and test GCC well, switching the UPSTREAM
of this Debian package to the Arduino ine seems good idea.

Arduino seems to just download binary from:
 http://downloads.arduino.cc/tools/avr-gcc-7.3.0-atmel3.6.1-arduino5-x86_64-apple-darwin14.tar.bz2

So we need to find where is the source of above package.

Osamu

Message #33 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: 932989@bugs.debian.org

Cc: 932989-submitter@bugs.debian.org

Subject: Bug#932989: gcc-avr: which upstream to track

Date: Sun, 12 Jan 2020 08:48:16 +0900

Hi

(The URL for avr-gcc for Linux in my previous post was wrong but it
isn't important ...)

Arduino seems to built avr-gcc with
  https://github.com/arduino/toolchain-avr

It's opening page states:
    binutils-2.26
    gcc-5.4.0
    avr-libc-2.0.0
    gdb-7.8

Not gcc-7.3.0 as released as 1.8.10 at
    https://www.arduino.cc/en/Main/Software
as I see today.  It seems to patch upstream a bit.

Further check realized that, staging branch was using gcc-7.3.0 in code
   https://github.com/arduino/toolchain-avr/commit/3e30e20948a5e3445823ecef23c007937b36583e
The applied patches are extensive!!! (Readme.md was not updated yet)

So this is one key resource.  Providing both avr-gcc 5.4.0 and 7.3.0 as
patched by Arduino toolchain-avr main and staging branches with
update-alternatives may be the best for next release.

I also found
   https://gcc.gnu.org/gcc-10/changes.html#avr

|     Support for the XMEGA-like devices
|
|         ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406,
|         ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606,
|         ATtiny1607, ATmega808, ATmega809, ATmega1608, ATmega1609,
|         ATmega3208, ATmega3209, ATmega4808, ATmega4809
|
|     has been added.
|     A new command line option -nodevicespecs has been added. It allows
|     to provide a custom device-specs file by means of
|
|         avr-gcc -nodevicespecs -specs=my-spec-file <options>
|
|     and without the need to provide options -B and -mmcu=. See AVR
|     command line options for details. This feature is also available in
|     v9.3+ and v8.4+.  New command line options -mdouble=[32,64] and
|     -mlong-double=[32,64] have been added. They allow to chose the size
|     (in bits) of the double and long double types, respectively. Whether
|     or not the mentioned layouts are available, whether the options act
|     as a multilib option, and what is the default for either option is
|     controlled by the new AVR configure options --with-double= and
|     --with-long-double=.  A new configure option --with-libf7= has been
|     added. It controls to which level avr-libgcc provides 64-bit
|     floating point support by means of Libf7.  A new configure option
|     --with-double-comparison= has been added. It's unlikely you need to
|     set this option by hand.

So gcc-10 had some AVR support efforts.

Osamu

Message #41 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: 932989@bugs.debian.org

Cc: 932989-submitter@bugs.debian.org

Subject: Bug#932989: gcc-avr: which upstream to track

Date: Sun, 12 Jan 2020 10:27:44 +0900

Hi again,

I checked meaning of GCC versions.

GCC development time lines:
   https://gcc.gnu.org/develop.html#timeline

As for ISO C99 conformance:
   https://gcc.gnu.org/c99status.html

The last mentioned version was GCC 5 for "extended identifiers".  So GCC
5 as supported by the vendor (microchip) isn't bad choice for C programs
mostly used by embedded programs.

Since Arduino sketches are in-essence C++ program(*), let's see C++
conformance:
   https://gcc.gnu.org/projects/cxx-status.html

For C++14, GCC 5 is good enough.
For C++17, GCC 7 is needed and is good enough.
For C++2a, GCC 8-10 are addressing some features.

Unicode UTF-8 support is important. This u8 character literals support
is made available at GCC 6 as a part of C++17 feature:
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
   https://gcc.gnu.org/gcc-6/changes.html#cxx

This kind of explains why Arduino is updating GCC 7.

Osamu

(*) https://github.com/arduino/arduino-preprocessor
    https://github.com/arduino/arduino-builder
    https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

Message #49 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Hakan Ardo <hakan@debian.org>

To: Osamu Aoki <osamu@debian.org>, 932989@bugs.debian.org

Cc: 932989-submitter@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: which upstream to track

Date: Sun, 12 Jan 2020 08:36:49 +0100

[Message part 1 (text/plain, inline)]

Hi,
thanx a lot for the great summary of the situation! Historically, the issue
with "community" versions of the avr toolchain have been the lack of
support for all AVR devices. Especially newer once. I don't know what the
situation is there with the Arduino toolcahin.

I agree that providing two version of gcc (one with Arduino as upstream and
one with microchip) is probably the best solution. That will however
require some packaging work, and I'm afraid that my current
personal situation wont allow me to put in that work anytime soon. But I
will gladly support it if anyone steps up to do the work.

So, the plan is to have a new release based on Atmel-3.6.2 from microchip
soon, and we can then make a separate release adding the Arduino version as
an alternative once it is packaged.


On Sun, Jan 12, 2020 at 2:30 AM Osamu Aoki <osamu@debian.org> wrote:

> Hi again,
>
> I checked meaning of GCC versions.
>
> GCC development time lines:
>    https://gcc.gnu.org/develop.html#timeline
>
> As for ISO C99 conformance:
>    https://gcc.gnu.org/c99status.html
>
> The last mentioned version was GCC 5 for "extended identifiers".  So GCC
> 5 as supported by the vendor (microchip) isn't bad choice for C programs
> mostly used by embedded programs.
>
> Since Arduino sketches are in-essence C++ program(*), let's see C++
> conformance:
>    https://gcc.gnu.org/projects/cxx-status.html
>
> For C++14, GCC 5 is good enough.
> For C++17, GCC 7 is needed and is good enough.
> For C++2a, GCC 8-10 are addressing some features.
>
> Unicode UTF-8 support is important. This u8 character literals support
> is made available at GCC 6 as a part of C++17 feature:
>    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
>    https://gcc.gnu.org/gcc-6/changes.html#cxx
>
> This kind of explains why Arduino is updating GCC 7.
>
> Osamu
>
> (*) https://github.com/arduino/arduino-preprocessor
>     https://github.com/arduino/arduino-builder
>
> https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
>


-- 
Håkan Ardö

[Message part 2 (text/html, inline)]

Message #57 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Hakan Ardo <hakan@debian.org>

Cc: 932989@bugs.debian.org, 932989-submitter@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: which upstream to track

Date: Sun, 12 Jan 2020 23:48:06 +0900

Hi,

On Sun, Jan 12, 2020 at 08:36:49AM +0100, Hakan Ardo wrote:
> Hi,
> thanx a lot for the great summary of the situation! Historically, the
> issue with "community" versions of the avr toolchain have been the
> lack of support for all AVR devices. Especially newer once. I don't
> know what the situation is there with the Arduino toolcahin.

https://github.com/arduino/toolchain-avr/issues/60
Update toolchain to include ATmega_DFP 1.2.209

https://github.com/arduino/toolchain-avr/issues/48
toolchain 3.6.0 produces wrong binary with 328p target

It looks like Arduino is porting microchip updates on GCC 5 to GCC 7.

toolchain-avr is a shell script to download upstream sources, patching
them, and building them.

The staging branch's toolchain-avr/avr-gcc-patches/ has

  * 0001-gcc-lto-wrapper.patch
  * atmel-patches-gcc.5.4.0.patch
  * atmel-patches-gcc.5.5.0.patch
  * atmel-patches-gcc.6.5.0-arduino1.patch
  * atmel-patches-gcc.7.3.0-arduino2.patch

> I agree that providing two version of gcc (one with Arduino as
> upstream and one with microchip) is probably the best solution. That
> will however require some packaging work, and I'm afraid that my
> current personal situation wont allow me to put in that work anytime
> soon. But I will gladly support it if anyone steps up to do the work.

> So, the plan is to have a new release based on Atmel-3.6.2
> from microchip soon, and we can then make a separate release adding
> the Arduino version as an alternative once it is packaged.

I see. It is new location.
  AVR 8-bit Toolchain 3.6.2 - Linux 64-bit
  https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers

But U only see binaries.  Where is the source???

Arduino still seems to be using Atmel-3.6.1 for both master and staging.
Here is a log from staging.

+ source build.conf^M
++ AVR_VERSION=3.6.1^M
++ BUILD_NUMBER=arduino5^M
++ AVR_SOURCES=http://downloads.arduino.cc/tools/opensource/Atmel-AVR-GNU-Toolchain/3.6.1^
++ ATMEL_PACKS_SOURCES=http://packs.download.atmel.com/^M
++ GNU_SOURCES=https://ftp.gnu.org/gnu/^M
++ MPC_SOURCES=http://repository.timesys.com/buildsources/m/mpc/^M
++ GCC_VERSION=7.3.0^M
++ MPFR_VERSION=3.1.0^M
++ ATMEL_ATMEGA_PACK_VERSION=1.3.300^M
++ ATMEL_ATMEGA_PACK_FILENAME=Atmel.ATmega_DFP.1.3.300^M
++ ATMEL_ATMEGA_PACK_URL=http://packs.download.atmel.com//Atmel.ATmega_DFP.1.3.300.atpack^
++ ATMEL_ATTINY_PACK_VERSION=1.3.229^M
++ ATMEL_ATTINY_PACK_FILENAME=Atmel.ATtiny_DFP.1.3.229^M
++ ATMEL_ATTINY_PACK_URL=http://packs.download.atmel.com//Atmel.ATtiny_DFP.1.3.229.a

I don't know if patches applied addresses 3.6.2 changes.

Anyway, this script build:
  * avr-gcc
  * avr-gdb
  * avr-libc
  * binutils

At this moment, I have build failure for avr-gdb for both master and
staging branch and I don't have time to figure out now ...

Considering our resource limitation, sticking with 5.0 may be good idea.

Supporting both GCC 5 and GCC 7 for libc, gdb ... may be a headache.

Anyway I now know even current Debian GCC 5 one is good for my needs.

Thanks for your work.

Osamu

PS: I am figuring out to use ARDUINO 1.8.10 on Debian buster.

Message #65 received at 932989@bugs.debian.org (full text, mbox, reply):

From: George Chapman <george.andrew.chapman@gmail.com>

To: 932989@bugs.debian.org

Subject: Microchip AVR GCC v3.6.2

Date: Mon, 10 Feb 2020 16:14:29 -0600

[Message part 1 (text/plain, inline)]

> But U only see binaries. Where is the source???
https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
via
https://www.avrfreaks.net/forum/where-have-atmel-avr-gcc-sourcecode-gone#comment-2742731
though it's walled; will need a myMicrochip account to get a copy.

[Message part 2 (text/html, inline)]

Message #72 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Benjamin Valentin <benjamin.valentin@beuth-hochschule.de>

To: 932989@bugs.debian.org

Subject: gcc-avr: which MCUs are not supported by upstream gcc?

Date: Wed, 10 Feb 2021 16:06:59 +0100

I just compared the --mmcpu options of my avr-gcc 5.4.0 with [0]
and I don't see any missing device family upstream.
Is there a list of hardware that is only supported by the Microchip
fork?

There are also patches posted to port the upstream AVR backend to CC0
(see [1])

[0] https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/AVR-Options.html
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

Message #77 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Benjamin Valentin <benjamin.valentin@beuth-hochschule.de>

To: 932989@bugs.debian.org

Subject: Re: gcc-avr: which MCUs are not supported by upstream gcc?

Date: Thu, 11 Feb 2021 10:52:44 +0100

Just comparing the output of avr-gcc --target-help gives

--- gcc-5.4.txt 	2021-02-11 09:56:37.490084599 +0100
+++ gcc-10.2.txt	2021-02-11 09:56:30.918162094 +0100
@@ -160,9 +160,14 @@
 attiny13
 attiny13a
 attiny15
+attiny1614
+attiny1616
+attiny1617
 attiny1634
 attiny167
 attiny20
+attiny212
+attiny214
 attiny22
 attiny2313
 attiny2313a
@@ -173,8 +178,13 @@
 attiny261
 attiny261a
 attiny28
+attiny3214
+attiny3216
+attiny3217
 attiny4
 attiny40
+attiny412
+attiny414
 attiny416
 attiny417
 attiny4313
@@ -186,6 +196,7 @@
 attiny461a
 attiny48
 attiny5
+attiny814
 attiny816
 attiny817
 attiny828

So gcc10 actually knows about some more parts.
I don't know if there are any missing patches upstream though.
Arch seems to carry the latest upstream gcc for AVR with no complaints
though.

Message #82 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Hakan Ardo <hakan@debian.org>

To: Benjamin Valentin <benjamin.valentin@beuth-hochschule.de>, 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: which MCUs are not supported by upstream gcc?

Date: Thu, 18 Feb 2021 08:41:09 +0100

[Message part 1 (text/plain, inline)]

OK, so upstream does indeed currently seem to be ahead. That has not always
been the case historically. I'm fine with switching if anyone steps up to
do the work. I've put the packages up for adoption, but I'll be happy to
give some support...

On Thu, Feb 11, 2021 at 10:57 AM Benjamin Valentin <
benjamin.valentin@beuth-hochschule.de> wrote:

> Just comparing the output of avr-gcc --target-help gives
>
> --- gcc-5.4.txt         2021-02-11 09:56:37.490084599 +0100
> +++ gcc-10.2.txt        2021-02-11 09:56:30.918162094 +0100
> @@ -160,9 +160,14 @@
>  attiny13
>  attiny13a
>  attiny15
> +attiny1614
> +attiny1616
> +attiny1617
>  attiny1634
>  attiny167
>  attiny20
> +attiny212
> +attiny214
>  attiny22
>  attiny2313
>  attiny2313a
> @@ -173,8 +178,13 @@
>  attiny261
>  attiny261a
>  attiny28
> +attiny3214
> +attiny3216
> +attiny3217
>  attiny4
>  attiny40
> +attiny412
> +attiny414
>  attiny416
>  attiny417
>  attiny4313
> @@ -186,6 +196,7 @@
>  attiny461a
>  attiny48
>  attiny5
> +attiny814
>  attiny816
>  attiny817
>  attiny828
>
> So gcc10 actually knows about some more parts.
> I don't know if there are any missing patches upstream though.
> Arch seems to carry the latest upstream gcc for AVR with no complaints
> though.
>


-- 
Håkan Ardö

[Message part 2 (text/html, inline)]

Message #87 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Gregor Riepl <onitake@gmail.com>

To: 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 16 Dec 2021 14:01:26 +0100

>> Switching back to use upstream source would be one option. But will
>> that mean we'll have to dropp support for newer devices?

> Unfortunately I don’t know too much about the development history of
> this package @Debian and the related decisions. It would be helpful
> though to have other developers and maintainers to have their say on
> this to help find a common solution. At first one should find out if
> support for newer devices would suffer from such an approach. I have
> not come across that topic yet...

To be honest, I don't think newer device support is a big issue any
more. While Microchip is still releasing new AVR MCUs, they are usually
not that different from existing devices. Even if Debian is lagging
behind, I think developers targeting older devices will benefit greatly
from an updated gcc. If they must, they can always rely on the binary
releases provided by Microchip.

It's also not that hard to feed in support for new devices:
https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices

And last but not least, upstream has kept pace with new AVR devices, as
can be seen in the gcc release notes:

https://gcc.gnu.org/gcc-7/changes.html#avr
https://gcc.gnu.org/gcc-8/changes.html#avr
https://gcc.gnu.org/gcc-10/changes.html#avr

I believe it's time to make the switch - same for binutils-avr and avr-libc.

Message #92 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Gregor Riepl <onitake@gmail.com>

To: 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 16 Dec 2021 14:57:51 +0100

Please disregard my last message, I totally missed the whole discussion
that has already been going on.

Sorry.

Message #97 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Hakan Ardo <hakan@debian.org>

To: Gregor Riepl <onitake@gmail.com>, 932989@bugs.debian.org, 1001273@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 16 Dec 2021 14:58:28 +0100

[Message part 1 (text/plain, inline)]

I believe your right, and I would support any such efforts. I've orphaned
these packages quite some time ago as I've not been able to find the time
to implement this myself though.

On Thu, Dec 16, 2021 at 2:03 PM Gregor Riepl <onitake@gmail.com> wrote:

>
> >> Switching back to use upstream source would be one option. But will
> >> that mean we'll have to dropp support for newer devices?
>
> > Unfortunately I don’t know too much about the development history of
> > this package @Debian and the related decisions. It would be helpful
> > though to have other developers and maintainers to have their say on
> > this to help find a common solution. At first one should find out if
> > support for newer devices would suffer from such an approach. I have
> > not come across that topic yet...
>
> To be honest, I don't think newer device support is a big issue any
> more. While Microchip is still releasing new AVR MCUs, they are usually
> not that different from existing devices. Even if Debian is lagging
> behind, I think developers targeting older devices will benefit greatly
> from an updated gcc. If they must, they can always rely on the binary
> releases provided by Microchip.
>
> It's also not that hard to feed in support for new devices:
> https://gcc.gnu.org/wiki/avr-gcc#Supporting_.22unsupported.22_Devices
>
> And last but not least, upstream has kept pace with new AVR devices, as
> can be seen in the gcc release notes:
>
> https://gcc.gnu.org/gcc-7/changes.html#avr
> https://gcc.gnu.org/gcc-8/changes.html#avr
> https://gcc.gnu.org/gcc-10/changes.html#avr
>
> I believe it's time to make the switch - same for binutils-avr and
> avr-libc.
>


-- 
Håkan Ardö

[Message part 2 (text/html, inline)]

Message #102 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Hakan Ardo <hakan@debian.org>

To: Gregor Riepl <onitake@gmail.com>, 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Thu, 16 Dec 2021 15:02:51 +0100

[Message part 1 (text/plain, inline)]

No worries. Thanx for caring!

On Thu, Dec 16, 2021 at 3:00 PM Gregor Riepl <onitake@gmail.com> wrote:

> Please disregard my last message, I totally missed the whole discussion
> that has already been going on.
>
> Sorry.
>


-- 
Håkan Ardö

[Message part 2 (text/html, inline)]

Message #107 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Marco <lists@homerow.info>

To: 932989@bugs.debian.org

Subject: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Tue, 14 Jun 2022 19:19:09 +0200

What's the current status? This bug is almost 3 years old and Debian
is still shipping 5.4.0, even in Sid. nightwalker-87 mentions that
Arch Linux may have found a working solution:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989#20

Message #112 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Hakan Ardo <hakan@debian.org>

To: Marco <lists@homerow.info>, 932989@bugs.debian.org

Subject: Re: Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Tue, 14 Jun 2022 19:41:40 +0200

[Message part 1 (text/plain, inline)]

There is no progress I'm afraid. The package is up for adoption. We need to
find someone who's willing to put in the time needed...

On Tue, Jun 14, 2022 at 7:27 PM Marco <lists@homerow.info> wrote:

> What's the current status? This bug is almost 3 years old and Debian
> is still shipping 5.4.0, even in Sid. nightwalker-87 mentions that
> Arch Linux may have found a working solution:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989#20
>


-- 
Håkan Ardö

[Message part 2 (text/html, inline)]

Message #117 received at 932989@bugs.debian.org (full text, mbox, reply):

From: Nightwalker-87 <nightwalker-87@t-online.de>

To: 932989@bugs.debian.org

Subject: gcc-avr: Package version severely outdated compared to main gcc-toolchain

Date: Tue, 6 Jun 2023 14:37:13 +0200

Hi,

Microchip has updated it's official AVR-toolchain in May 2022 as well 
and provided related technical details.

https://www.microchip.com/en-us/tools-resources/develop/microchip-studio/gcc-compilers

Please (at least) port this version into the debian package sources ASAP.
Debian seems to have lost track with recent developments for this 
architecture, resulting in lacking support for newer devices.
This is deeply disappointing to see.

Nightwalker-87

Send a report that this bug log contains spam.