riscv-gnu-toolchain stable versioning

[Palmer Dabbelt]

As you may have noticed, we recently had an upstream release of GCC that
contains RISC-V support. Since we're now upstream in binutils and GCC it seems
like a good time to start tagging releases of riscv-gnu-toolchain as stable.
I've tagged the current release on github. Since this is a sort of meta-repo,
I thought the best versioning scheme would just be the current date, so that's
what I'm going with.

I'll try to regularly tag stable releases of the toolchain. I'm going to just
play it by ear as to how frequently I release these, but I anticipate it being
between weekly and monthly. All these tagged release will have passed the
various test suites we run, and I'll write a change log on all the future
releases so users don't have to track commits.

Note that just because we've tagged a release doesn't mean things are stable:
glibc and Linux still aren't upstream so their ABIs aren't set in stone yet
(though we hope not to have to change them). I'm checking the "This is a
pre-release" button on GitHib due to possibility of ABI changes.

[Stefan O'Rear]

On Wed, May 3, 2017 at 3:51 PM, Palmer Dabbelt <pal...@sifive.com> wrote:
> As you may have noticed, we recently had an upstream release of GCC that
> contains RISC-V support. Since we're now upstream in binutils and GCC it seems

This is wonderful news!

> like a good time to start tagging releases of riscv-gnu-toolchain as stable.
> I've tagged the current release on github. Since this is a sort of meta-repo,
> I thought the best versioning scheme would just be the current date, so that's
> what I'm going with.
>
> I'll try to regularly tag stable releases of the toolchain. I'm going to just
> play it by ear as to how frequently I release these, but I anticipate it being
> between weekly and monthly. All these tagged release will have passed the
> various test suites we run, and I'll write a change log on all the future
> releases so users don't have to track commits.

(fine by me, although I'm not much of a direct user of riscv-gnu-toolchain)

> Note that just because we've tagged a release doesn't mean things are stable:
> glibc and Linux still aren't upstream so their ABIs aren't set in stone yet
> (though we hope not to have to change them). I'm checking the "This is a
> pre-release" button on GitHib due to possibility of ABI changes.

Question: What is the status of the gcc-{4,5,6} patches ongoing? They
appear to have been deleted on GitHub, which seems a little fast to me
(it will take a few years for everyone to adopt gcc-7, and if the
system you're working on uses 5.3 it's easier to go to a patched 5.3
than to 7.1?).

-s

[Tommy Murphy]

Hi Palmer 

Thanks for this.

But is there a problem with the source archives here:

https://github.com/riscv/riscv-gnu-toolchain/releases

As fare as I can see all source folders are empty.

Cheers

Tommy

[Palmer Dabbelt]

The github release don't track submodules, so downloading the tarballs won't do
anything. You need to just clone from the tag.

[Tommy Murphy]

Ok - thanks.

I assumed that the source tarballs were usable directly.

[Palmer Dabbelt]

They're gone because they were pretty broken. The best way to resurrect
support for older GCC versions would be to port what we have now (7.1) to
something older (I think probably 4.8/4.9 would be the best bet). This would
be a big project, and I'm not sure GCC version compatibility is such a big deal
any more since it's gotten a lot more stable.

[Tommy Murphy]

Just to be clear is this how to get the tagged sources?

git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
cd riscv-gnu-toolchain
git checkout tags/v20170503

[Kito Cheng]

>> Question: What is the status of the gcc-{4,5,6} patches ongoing? They
>> appear to have been deleted on GitHub, which seems a little fast to me
>> (it will take a few years for everyone to adopt gcc-7, and if the
>> system you're working on uses 5.3 it's easier to go to a patched 5.3
>> than to 7.1?).
>
> They're gone because they were pretty broken. The best way to resurrect
> support for older GCC versions would be to port what we have now (7.1) to
> something older (I think probably 4.8/4.9 would be the best bet). This would
> be a big project, and I'm not sure GCC version compatibility is such a big deal
> any more since it's gotten a lot more stable.

Back porting to older gcc is a painful process especially 7 to 4.9
since gcc have many internal API change during gcc 5/6 due to convert
to c++...

[Manuel A. Fernandez Montecelo]

Hi,

2017-05-04 00:51 Palmer Dabbelt:

First, congrats to all people involved for all the work and that
important tools are released now.

And second, thanks for explaining the current status, it's much easier
than to track different threads, branches and go down to commits :-)


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.m...@gmail.com>