gcc-14-20250308 is now available
Snapshot gcc-14-20250308 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20250308/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision 9608070a386f71148aa76a34aef60b342caa73b8 You'll find: gcc-14-20250308.tar.xz Complete GCC SHA256=8b49c43ecc077312aee1f3427f8cf6f3be5f517bbf6021cee3d3e8b04a906f78 SHA1=da9647e7c57f4e5fa8bf99c1bb9f1d8b9d1d86fc Diffs from 14-20250301 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: make error when builing gcc
在 2025-3-8 15:20, Gwen Fu 写道:
OS : CentOS7
The official documentation doesn't mention any installation requirement about
lib{isl , zstd} .
[please reply to all.]
They are mentioned, but are optional:
https://gcc.gnu.org/install/prerequisites.html
And I run "../gcc/configure --enable-languages=c,c++,fortran --disable-multilib" and
then rerun"make -j 2"
the same error occurred .
Here is the gcc version:
[gwen@localhost objdir]$ gcc -v
使用内建 specs。
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
This is caused by failure to compile a simple C++ program, but the cause can vary: Your system might have
no c++ compiler (which i think is unlikely), or the existent c++ compiler rejected the program due to an
unknown option. You can take a look at the end of config.log.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
a super regular RISC that encodes constants in immediate blocks.
Hi Folks, here is an idea expressed as a simple proof-of-concept simulator. - https://github.com/michaeljclark/glyph/ I have been working on a proof-of-concept simulator for a RISC architecture with an immediate base register next to the program counter to split the front-end stream into independent instruction and constant streams. I named it glyph. it features a super-regular encoding scheme designed for vectorized decoding, and it uses a _i32x2_ vector of relative displacements in the link register to branch both instructions and constants at the same time. this evolved from thinking about a "virt" machine that was good for software to decode but could potentially be hardware. I am still writing tests for it, but it is possible to test out the relative link register _(pc,ib)_ vector concept using subroutine branch displacements and constant block displacements in constant memory, which is read-only like instruction text. it has some interesting consequences. stack does not leak spilled absolute addresses so ASLR may be harder to bypass. it uses flags for compare. register 0 can currently contain data. near branches are +/-512 bytes _(9-bit is the largest embedded immediate in the 16-bit format)_. the proof-of-concept has 8 registers, and there is a Python script for generating vectorized switch decoders for the variable-length instruction scheme. however, the proof-of-concept simulator currently only supports the 16-bit compressed opcode space. it doesn't have a compiler or assembler yet. but considerable thought has gone into the design of the instruction format and the split instruction and constant streams. the 16-bit opcode space can access 64-bit constants, but the 32-bit opcodes will support all typical constant sizes, and up to 64 read-write registers and more constants. linker relocations are quite neat with this architecture. return from procedure needs a reloc due to the use of relative displacements in the link register. I am keen for feedback. there are a lot of details in the repo, including a Python script to explore combinatoric expansion for vectorized decoders. it has a simpler length coding scheme than RISC-V at the expense of one bit of coding space in the 16-bit packet. as a result, it uses less wires and logic for length decoding of 64-bit instructions. it borrows an idea from LEB128. i.e. it is _super regular_. but we won't know how it will do on density until we have the 32-bit opcodes. Michael
Re: make error when builing gcc
On Sat, 8 Mar 2025, 06:34 Gwen Fu via Gcc, wrote: > After I finished ../gcc/configure --prefix=$HOME/GCC-4.6.2 > --enable-languages=c,c++,fortran --disable-multilib , I executed "make -j > 2" . However , error occurred ! > I assume you copied this from https://GCC.gnu.org/wiki/InstallingGCC Those instructions were written when GCC 4.6 was a recent release, but now it's very very old. Try a new release from some time this decade. I'll update the instructions. > ...(,omit unnecessary info) > checking whether gcc -std=gnu99 supports -pedantic -Wlong-long... yes > checking whether gcc -std=gnu99 supports -fno-exceptions... yes > yes > checking for vasprintf... checking whether gcc -std=gnu99 supports > -fno-rtti... yes > yes > configure: error: C++ compiler missing or inoperational > checking for vfprintf... make[2]: *** [configure-build-libcpp] 错误 1 > make[2]: *** 正在等待未完成的任务 > yes > ..(omit unnecessary info) > checking for working mmap... yes > checking for working strncmp... yes > configure: updating cache ./config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > make[2]: 离开目录“/home/gwen/github_repo/objdir” > make[1]: *** [stage1-bubble] error2 > make[1]: 离开目录“/home/gwen/github_repo/objdir” > make: *** [all] error 2 >
Re: make error when builing gcc
Also please use the gcc-help list for questions like this. On Sat, 8 Mar 2025, 08:24 Jonathan Wakely, wrote: > > > On Sat, 8 Mar 2025, 06:34 Gwen Fu via Gcc, wrote: > >> After I finished ../gcc/configure --prefix=$HOME/GCC-4.6.2 >> --enable-languages=c,c++,fortran --disable-multilib , I executed "make -j >> 2" . However , error occurred ! >> > > I assume you copied this from https://GCC.gnu.org/wiki/InstallingGCC > > Those instructions were written when GCC 4.6 was a recent release, but now > it's very very old. Try a new release from some time this decade. > > I'll update the instructions. > > > >> ...(,omit unnecessary info) >> checking whether gcc -std=gnu99 supports -pedantic -Wlong-long... yes >> checking whether gcc -std=gnu99 supports -fno-exceptions... yes >> yes >> checking for vasprintf... checking whether gcc -std=gnu99 supports >> -fno-rtti... yes >> yes >> configure: error: C++ compiler missing or inoperational >> checking for vfprintf... make[2]: *** [configure-build-libcpp] 错误 1 >> make[2]: *** 正在等待未完成的任务 >> yes >> ..(omit unnecessary info) >> checking for working mmap... yes >> checking for working strncmp... yes >> configure: updating cache ./config.cache >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating testsuite/Makefile >> config.status: creating config.h >> config.status: executing default commands >> make[2]: 离开目录“/home/gwen/github_repo/objdir” >> make[1]: *** [stage1-bubble] error2 >> make[1]: 离开目录“/home/gwen/github_repo/objdir” >> make: *** [all] error 2 >> >
Re: make error when builing gcc
On Sat, 8 Mar 2025, 06:55 LIU Hao via Gcc, wrote:
> 在 2025-3-8 14:33, Gwen Fu via Gcc 写道:
> > After I finished ../gcc/configure --prefix=$HOME/GCC-4.6.2
> > --enable-languages=c,c++,fortran --disable-multilib , I executed "make -j
> > 2" . However , error occurred !
> >
>
> What system are you using? You should not specify `--prefix` unless you
> know what it does.
Eh? That says where to install GCC after it's built. The instructions are
copied from
https://gcc.gnu.org/wiki/InstallingGCC and ate correct.
Newer GCC
> versions require a C++14 compiler, and 4.6.2 is too old for that.
>
The --prefix has nothing to do with the bootstrap compiler.
> For example, on Debian or Ubuntu or Mint, you may build GCC with these
> commands:
>
> ```
> sudo aptitude install gcc gettext python3 awk make flex
> lib{gmp,mpfr,mpc,isl,zstd}-dev
> ../gcc/configure --enable-languages=c,c++,fortran --disable-multilib
> make -j$(nproc)
> ```
>
>
> --
> Best regards,
> LIU Hao
>
Re: make error when builing gcc
On Sat, 8 Mar 2025, 08:43 LIU Hao via Gcc, wrote:
> 在 2025-3-8 15:20, Gwen Fu 写道:
> > OS : CentOS7
> > The official documentation doesn't mention any installation requirement
> about lib{isl , zstd} .
>
> [please reply to all.]
>
But not on this list, it belongs on gcc-help
> They are mentioned, but are optional:
> https://gcc.gnu.org/install/prerequisites.html
>
>
> > And I run "../gcc/configure --enable-languages=c,c++,fortran
> --disable-multilib" and then rerun"make -j 2"
> > the same error occurred .
> >
> > Here is the gcc version:
> > [gwen@localhost objdir]$ gcc -v
> > 使用内建 specs。
> > COLLECT_GCC=gcc
> >
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
>
> This is caused by failure to compile a simple C++ program, but the cause
> can vary: Your system might have
> no c++ compiler (which i think is unlikely), or the existent c++ compiler
> rejected the program due to an
> unknown option. You can take a look at the end of config.log.
>
>
>
>
> --
> Best regards,
> LIU Hao
>
Re: What branch to use for the Algol 68 front-end
> Hi, > > On Fri, Mar 07, 2025 at 03:57:40PM +, Richard Earnshaw (lists) via Gcc > wrote: >> On 07/03/2025 15:41, Jose E. Marchesi via Gcc wrote: >> > The Steering Committee has decided not to merge the Algol 68 Front-End >> > in master at this point, but is ok with us using a branch in gcc.git to >> > develop and maintain the front-end as well as a mailing list in >> > algo...@gcc.gnu.org. The mailing list has been already set up by the >> > sourceware friends. >> > >> > What branch should we use in gcc.git? >> >> I would have thought something like devel/algol68. Unless you push >> a personal branch, devel/ is pretty much the only place you can put >> it. > > Since you already have a fork on the (experimental) forge we could > also move your fork under https://forge.sourceware.org/gcc that way > you can experiment with merge requests if you like. Even if all your > patches still go to the algol68 list first. I am all for continuing using the forge if it is useful for the experiment. Let's see. Right now the resources we are using are: Website: https://gcc.gnu.org/wiki/Algol68FrontEnd Mailing list: algo...@gcc.gnu.org Bugzilla: https://gcc.gnu.org/bugzilla Git repo: https://forge.sourceware.org/jemarch/a68-gcc (branch a68) If I understand you suggestion right, we would simply move the git repo to: https://forge.sourceware.org/gcc/algol68 (branch a68) Then people could fork it, send patch series based on their forks to be reviewed in the mailing list, get feedback, do corrections, rinse and repeat. Then when the series has been OKed a PR can be made and the maintainer just merges it. Is this the idea? Is it possible to get emails sent to the mailing list when merges happen, merge requests are issued, etc?
