GCC 15.1 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 15.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/15.1.0-RC-20250418/ ftp://gcc.gnu.org/pub/gcc/snapshots/15.1.0-RC-20250418/ and shortly its mirrors. It has been generated from git commit r15-9556-g96171a5cc7b99cb6. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, we'd like to release 15.1 on Friday, April 25th. Happy Easter!
gcc-13-20250418 is now available
Snapshot gcc-13-20250418 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20250418/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-13 revision 5e23f9be635c1db34d494e1c4f980fd224406af4 You'll find: gcc-13-20250418.tar.xz Complete GCC SHA256=3b7c8c92f0400802df12f250803d9733c775f59c527bf9a01babc60502d60cbb SHA1=e9b65d7526633cc12ca7b19e6b4abe1376ba6143 Diffs from 13-20250411 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 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: Accessability of the site gcc.gnu.org
On Fri, 18 Apr 2025, 20:14 Siva Sai Manchem via Gcc, wrote: > Hi Team, > > I hope you're doing well. > > We wanted to bring to your attention that one of our customers, who is > utilizing Zscaler services, is currently facing difficulties accessing your > website. Upon reviewing the issue, we found that the website is being > blocked when accessed via Zscaler IPs. > I will pass this onto the system admins, but the problem is that some of your customers have been abusing our services constantly, making it harder for GCC developers to access our own services. The only solution we've been able to find is to block entire IP ranges. > To ensure seamless accessibility for our customer, could you please > whitelist the IPs associated with our San Francisco IV data center? > Below is the list of IPs for your reference: > > List of IPs: > 104.129.192.0/23 > 170.85.154.0/23 > 170.85.182.0/23 > 165.225.246.0/23 > 136.226.78.0/23 > 2605:4300:1200::/40 > > Your support in getting these IPs whitelisted would be greatly appreciated. > Please let us know if you require any additional information from our side > to expedite this process. > > Looking forward to your confirmation. > > > Best Regards, > Siva Sai Manchem > Zscaler Technical Support > > -- > > > This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication by unintended recipients is not authorized. If you received > this communication in error, please immediately notify the sender and then > delete all copies of this communication from your system. >
Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-elf
On 17/04/2025 12:19, Wasim Khan via Gcc wrote: > > >> -Original Message- >> From: Richard Earnshaw (lists) >> Sent: 17 April 2025 14:57 >> To: Wasim Khan ; gcc-h...@gcc.gnu.org; >> gcc@gcc.gnu.org >> Subject: Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64- >> none-elf >> >> [You don't often get email from richard.earns...@arm.com. Learn why this is >> important at https://aka.ms/LearnAboutSenderIdentification ] >> >> On 17/04/2025 07:49, Wasim Khan via Gcc wrote: >>> Hi, >>> >>> I have a custom implementation of memcpy() function and don't want to use >> implementation provided by libc.a. >>> Things works fine with toolchain version 12.3 and my local implementation in >> utils.c is considered. >>> But when I move to toolchain version 14.2 , I am getting below error. >>> >>> >>> Linking ... >>> /opt/arm-gnu-toolchain-*-aarch64-none-elf/bin/aarch64-none-elf-gcc \ >>> -nodefaultlibs \ >>> -nostartfiles \ >>> -mcpu=cortex-a55 \ >>> -Wl,--gc-sections \ >>> -Wl,--build-id=none \ >>> -T /opt/test.lds \ >>> -Wl,-Map=/opt/test.map \ >>> -Wl,--no-warn-rwx-segments \ >>> /opt/test.o /opt/utils.o \ >>> -L /opt/arm-gnu-toolchain-*-aarch64-none-elf/aarch64-none-elf/lib \ >>> -Wl,--start-group -l:libc.a -l:libgcc.a -Wl,--end-group \ >>> -o /opt/test.elf >>> >>> /opt/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none- >> elf/bin/../lib/gcc/aarch64-none-elf/14.2.1/../../../../aarch64-none-elf/bin/ld: >> /opt/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-none-elf/aarch64-none- >> elf/lib/libc.a(libc_a-memcpy.o): in function `memcpy': >>> /data/jenkins/workspace/GNU-toolchain/arm-14/src/newlib- >> cygwin/newlib/libc/machine/aarch64/memcpy.S:60: multiple definition of >> `memcpy'; /opt/utils.o:/opt/utils.c:247: first defined here >>> collect2: error: ld returned 1 exit status >>> make: *** [Makefile:282: linkobj] Error 1 >>> >>> >>> >>> Need help on how to use custom implementation of memcpy() (but use all >> other standard functions from libc.a). >>> Also, any idea on why the issue is with 14.2 and not with earlier versions >>> (like >> 12.3) ? >>> >>> Regards, >>> >> >> Perhaps your code is calling memmove() as well? The two functions are >> generally tightly integrated in the C library, especially when memmove() is >> assuming particular properties of the memcpy implementation. >> >> For example, you can't override free without also overriding all the other >> functions that go with heap management (malloc, realloc, etc). >> >> BTW, if you generate a linker map, it should tell you why the libc >> implementation >> of memcpy is being pulled in as well. >> >> R. > > > I am not using memove() anywhere in my code. However, defining custom > memove() solves the problem with 14.2. Thanks!! > I wonder why it is not required with 12.3 , because as per linker map, > memcpy() is coming from my custom implementation and memmove() is coming from > libc for 12.3. > > .text.memcpy 0x2048d1d0 0x20 /opt/test.o >0x2048d1d0memcpy > > .text 0x2049b240 0xac > /opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-elf/aarch64-none-elf/lib/libc.a(libc_a-memmove.o) >0x2049b240memmove > > > This dependency is something introduced after 12.3 ? > Also, is there any way to know about such dependencies of such functions? > Because compiler does not complaints if custom definitions are ignored . > > Compilers can generate code where they know a memcpy or memmove operation are needed without the direct need for an explicit call to that function (memcpy is more common, since the compiler can usually be sure that the objects being copied do not overlap). But of course, it might come from a library function that needs this as well. The linker map will tell you which object file contains the first reference to memmove and hence why it is adding libc_a-memmove.o to the image; it won't tell you of all the cases though. You need to look at the section of the map file that begins something like: Archive member included to satisfy reference by file (symbol) /usr/lib/x86_64-linux-gnu/libm-2.35.a(w_sqrt.o) /tmp/ccPpkxxR.o (sqrt) /usr/lib/x86_64-linux-gnu/libm-2.35.a(e_sqrt.o) /usr/lib/x86_64-linux-gnu/libm-2.35.a(w_sqrt.o) (__ieee754_sqrt) ... The syntax of each entry is () () R.
Re: Accessability of the site gcc.gnu.org
Hi, On Fri, Apr 18, 2025 at 09:42:57PM +0100, Jonathan Wakely via Gcc wrote: > On Fri, 18 Apr 2025, 20:14 Siva Sai Manchem via Gcc, > wrote: > > We wanted to bring to your attention that one of our customers, who is > > utilizing Zscaler services, is currently facing difficulties accessing your > > website. Upon reviewing the issue, we found that the website is being > > blocked when accessed via Zscaler IPs. > > I will pass this onto the system admins, but the problem is that some of > your customers have been abusing our services constantly, making it harder > for GCC developers to access our own services. > > The only solution we've been able to find is to block entire IP ranges. We are experimenting with https://anubis.techaro.lol/ but it isn't deployed yet. For now we do indeed just block ip ranges which host many abusers. > > To ensure seamless accessibility for our customer, could you please > > whitelist the IPs associated with our San Francisco IV data center? > > Below is the list of IPs for your reference: > > > > List of IPs: > > 104.129.192.0/23 > > 170.85.154.0/23 > > 170.85.182.0/23 > > 165.225.246.0/23 > > 136.226.78.0/23 > > 2605:4300:1200::/40 > > > > Your support in getting these IPs whitelisted would be greatly appreciated. > > Please let us know if you require any additional information from our side > > to expedite this process. None of those ranges are currently blocked. If you could monitor you customers not generating abusive traffic they should stay unblocked. We are currently fighting LLM/AI scraperbots hitting various sites very hard. https://lwn.net/Articles/1008897/ https://arstechnica.com/ai/2025/03/devs-say-ai-crawlers-dominate-traffic-forcing-blocks-on-entire-countries/ Cheers, Mark
Accessability of the site gcc.gnu.org
Hi Team, I hope you're doing well. We wanted to bring to your attention that one of our customers, who is utilizing Zscaler services, is currently facing difficulties accessing your website. Upon reviewing the issue, we found that the website is being blocked when accessed via Zscaler IPs. To ensure seamless accessibility for our customer, could you please whitelist the IPs associated with our San Francisco IV data center? Below is the list of IPs for your reference: List of IPs: 104.129.192.0/23 170.85.154.0/23 170.85.182.0/23 165.225.246.0/23 136.226.78.0/23 2605:4300:1200::/40 Your support in getting these IPs whitelisted would be greatly appreciated. Please let us know if you require any additional information from our side to expedite this process. Looking forward to your confirmation. Best Regards, Siva Sai Manchem Zscaler Technical Support -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
gcc-12-20250417 is now available
Snapshot gcc-12-20250417 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20250417/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 2ea39e7b58376b2fb57cd74098a374604b627266 You'll find: gcc-12-20250417.tar.xz Complete GCC SHA256=e1e3160b8c3c51f628532ec3a80c1b571f9d5103739ccb22a5c3ce8a777e2c3f SHA1=ddcd802857c6b653a496903138a5d7f4cb65d16c Diffs from 12-20250410 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
