Re: GSoC mandatory step error

On Tue, Apr 01, 2025 at 10:09:56AM +0200, Martin Jambor wrote: > The simple fix is to initialize the variable to nullptr in the source, > of course. :-) It is a false positive. gimple *stmt; ... for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi)) { stmt = gsi_stmt (gsi);

Re: GSoC mandatory step error

Hi Leul! On 2025-03-31T18:33:51-0400, Leul Abiy via Gcc wrote: > I just wanted to ask about the build of gcc. I know it is a required step > before applying to GCC for the GSoC 2025. However, I get an error. Welcome to GCC, and good luck for GSoC 2025! In addition to what Martin already

Re: GSoC mandatory step error

Hello, On Mon, Mar 31 2025, Leul Abiy via Gcc wrote: > Dear Sir/Madam, > > I just wanted to ask about the build of gcc. I know it is a required step > before applying to GCC for the GSoC 2025. However, I get an error. > > Here is the error: > > /home/stoplight/GitProjec

GSoC mandatory step error

Dear Sir/Madam, I just wanted to ask about the build of gcc. I know it is a required step before applying to GCC for the GSoC 2025. However, I get an error. Here is the error: /home/stoplight/GitProjects/GCC-PROJECT/gcc/build/object/./prev-gcc/xg++ -B/home/stoplight/GitProjects/GCC-PROJECT/gcc

Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

Hi! On 2025-03-17T20:03:48+, Iain Sandoe via Gcc wrote: >> On 17 Mar 2025, at 19:43, Toon Moene wrote: >> >> I was eager to try the new rust updates ... >> >> But I got this: >> >> error[E0554]: `#![feature]` may not be used on the stab

Re: Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

> On 17 Mar 2025, at 19:43, Toon Moene wrote: > > I was eager to try the new rust updates ... > > But I got this: > > error[E0554]: `#![feature]` may not be used on the stable release channel > --> src/lib.rs:19:1 > |

Rust: error[E0554]: `#![feature]` may not be used on the stable release channel

I was eager to try the new rust updates ... But I got this: error[E0554]: `#![feature]` may not be used on the stable release channel --> src/lib.rs:19:1 | 19 | #![feature(extern_types)] | ^ For more information about this error, try `rustc --explain E0

Re: make error when builing gcc

On Mon, 10 Mar 2025 at 09:09, Gwen Fu wrote: > > Thank you! After replacing the outdated centOS operating system and compiling > for eight hours（That's carzy to me）, I have successfully installed and built > gcc😂😂 Like it says at https://gcc.gnu.org/wiki/InstallingGCC "If your computer has mult

Re: make error when builing gcc

gt; 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

Re: make error when builing gcc

elongs 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

Re: make error when builing gcc

 --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 cause

Re: make error when builing gcc

n --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.

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.

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 occ

Re: make error when builing gcc

在 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 kn

make error when builing 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 ! ...(,omit unnecessary info) checking whether gcc -std=gnu99 supports -pedantic -Wlong-long... yes checking whethe

Re: gcc-git-customization.sh error

t; While onboarding somebody today we noticed an error in the > >>> customization script if you use a non-default value for the local > >>> prefix. > >>> > >>> I reproduced it with bash -x to show where it happens. In the output > >>> below

Re: gcc-git-customization.sh error

On 05/03/2025 13:47, Jonathan Wakely wrote: > On Wed, 5 Mar 2025 at 13:37, Richard Earnshaw (lists) > wrote: >> >> On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote: >>> While onboarding somebody today we noticed an error in the >>> customization script if

Re: gcc-git-customization.sh error

On Wed, 5 Mar 2025 at 13:37, Richard Earnshaw (lists) wrote: > > On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote: > > While onboarding somebody today we noticed an error in the > > customization script if you use a non-default value for the local > > prefix. > >

Re: gcc-git-customization.sh error

On 05/03/2025 13:10, Jonathan Wakely via Gcc wrote: > While onboarding somebody today we noticed an error in the > customization script if you use a non-default value for the local > prefix. > > I reproduced it with bash -x to show where it happens. In the output > below I e

gcc-git-customization.sh error

While onboarding somebody today we noticed an error in the customization script if you use a non-default value for the local prefix. I reproduced it with bash -x to show where it happens. In the output below I entered "jw" as the local prefix, instead of the default "me":

small install.texi error

I noticed an error in gcc/doc/install.texi, but I don't know how to correct it. It occurs here, > @xref{with-included-gettext,,--with-included-gettext} for more > information on the conditions required to get gettext support. The build produces this warning: > install.texi

Re: Promote -Wno-sizeof-array-argument to an error

you are doing, why not. > If using sizeof in that case is an error, you'd need to know, I can use this > macro on everything except this special case. Hmmm, I guess the array updates of <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2906.pdf> and __lengthof__ supporting array

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 03:42:06PM +0200, Jakub Jelinek via Gcc wrote: > On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote: > > The problem with that is that the error will still be enforced _after_ > > GCC would change the behavior of sizeof(aparam). > > I

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, 9 Aug 2024, Alejandro Colomar via Gcc wrote: > Since I don't see any legitimate uses of sizeof(aparam) as of today, I > don't expect having any consequences on existing code. (But please > point me wrong if there are any, maybe in generic macros.) It's perfectly legitimate when the user

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 03:25:00PM +0200, Alejandro Colomar wrote: > The problem with that is that the error will still be enforced _after_ > GCC would change the behavior of sizeof(aparam). I don't think it should unless C2Y requires that. > Admittedly, I could write confi

Re: Promote -Wno-sizeof-array-argument to an error

Hi Jakub, On Fri, Aug 09, 2024 at 02:24:48PM GMT, Jakub Jelinek wrote: > You can compile your sources with -Werror=sizeof-array-argument if you want > it to be an error, The problem with that is that the error will still be enforced _after_ GCC would change the behavior of sizeof(

Re: Promote -Wno-sizeof-array-argument to an error

-Wno-sizeof-array-argument to a hard error? I don't > > > think there's any legitimate use sizeof() on such a parameter. > > > > I am a bit worried that it might prevent people from adding size information > > to arguments, by transforming later use of sizeof

Re: Promote -Wno-sizeof-array-argument to an error

Hi Martin, On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's

Re: Promote -Wno-sizeof-array-argument to an error

On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's any legiti

Re: Promote -Wno-sizeof-array-argument to an error

Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > Hi Martin, > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > think there's any legitimate use sizeof() on such a parameter. I am a bit worried that it might prevent p

Re: Promote -Wno-sizeof-array-argument to an error

On Thu, Aug 08, 2024 at 02:36:36AM GMT, Alejandro Colomar wrote: > Hi Martin, > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't D'oh! I obviously meant -Wsizeof-array-argument. > think there's any legitimate use sizeof() on such a par

Promote -Wno-sizeof-array-argument to an error

Hi Martin, Can we promote -Wno-sizeof-array-argument to a hard error? I don't think there's any legitimate use sizeof() on such a parameter. It would be an incompatible extension to ISO C, which would make sure that there are no remaining uses of sizeof(array_param), which would itsel

[RFC] genoutput: Error on unresolved iterator

I just ran into an unresolved iterator https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657360.html which motivated me to dig into genoutput.cc where in process_template() we already emit an error but only if the new compact syntax is used. There is probably a reason for limiting the check to

Re: Error in gcc 14 porting document

On Mai 08 2024, Richard Biener via Gcc wrote: > removed from C99. I think you mean "removed from C *after* C99". -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: Error in gcc 14 porting document

On Wed, May 8, 2024 at 2:06 PM Jakub Jelinek wrote: > > On Wed, May 08, 2024 at 01:15:21PM +0200, Matthias Urlichs via Gcc wrote: > > On 08.05.24 11:50, Richard Biener wrote: > > > > "With the |-fpermissive| option, programs can use C99 inlining semantics > > > > and features that were removed fro

Re: Error in gcc 14 porting document

On Wed, May 08, 2024 at 01:15:21PM +0200, Matthias Urlichs via Gcc wrote: > On 08.05.24 11:50, Richard Biener wrote: > > > "With the |-fpermissive| option, programs can use C99 inlining semantics > > > and features that were removed from C99" > > > > > > Umm, what? this sentence doesn't make sense

Re: Error in gcc 14 porting document

On 08.05.24 11:50, Richard Biener wrote: "With the |-fpermissive| option, programs can use C99 inlining semantics and features that were removed from C99" Umm, what? this sentence doesn't make sense. In the context of mentioning the -std=gnu89/-std=c89 workarounds I thought as much, but shoul

Re: Error in gcc 14 porting document

On Wed, May 8, 2024 at 11:39 AM Matthias Urlichs via Gcc wrote: > > Hello, > > https://gcc.gnu.org/gcc-14/porting_to.html states: > > "With the |-fpermissive| option, programs can use C99 inlining semantics > and features that were removed from C99" > > Umm, what? this sentence doesn't make sense.

Error in gcc 14 porting document

Hello, https://gcc.gnu.org/gcc-14/porting_to.html states: "With the |-fpermissive| option, programs can use C99 inlining semantics and features that were removed from C99" Umm, what? this sentence doesn't make sense. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description:

Re: 'posix_spawnp' error in build

blems caused by this. Easy > enough to find out. First "make distclean", and then "git status". > > The error message says that the newly compiled compiler driver ("xgcc", > which will be insbtalled as just "gcc" eventually) cannot execute the &

Re: 'posix_spawnp' error in build

Hello, Any solution you have in mind? Thanks, Prashanth On Tue, 26 Dec 2023 at 04:32, Segher Boessenkool wrote: > On Tue, Dec 26, 2023 at 12:33:40AM +0800, Xi Ruoyao wrote: > > On Mon, 2023-12-25 at 10:28 -0600, Segher Boessenkool wrote: > > > > 1) git clone git://gcc.gnu.org/git/gcc.git > > >

Re: 'posix_spawnp' error in build

On Tue, Dec 26, 2023 at 12:33:40AM +0800, Xi Ruoyao wrote: > On Mon, 2023-12-25 at 10:28 -0600, Segher Boessenkool wrote: > > > 1) git clone git://gcc.gnu.org/git/gcc.git > > > 2) cd gcc & ./contrib/download_prerequisites > > > 3) mkdir objdir & cd objdir > > > 4) ../gcc/configure --prefix=/home/pa

Re: 'posix_spawnp' error in build

uot;make distclean", and then "git status". > > I don't know if we require it to execute above, specially if it's outside the actual gcc repo. > >The error message says that the newly compiled compiler driver ("xgcc", > > which will be insbtalle

Re: 'posix_spawnp' error in build

On Mon, 2023-12-25 at 10:28 -0600, Segher Boessenkool wrote: > Hi! > > On Mon, Dec 25, 2023 at 08:11:23PM +0530, Prashant via Gcc-help wrote: > >  I'm trying to build the gcc repository. Based on the instructions given on > > the SummerOfCode - GCC Wiki (gnu.org) > >

Re: 'posix_spawnp' error in build

equisites > 3) mkdir objdir & cd objdir > 4) ../gcc/configure --prefix=/home/path/to/gcc --enable-languages=c,c++ That is wrong. Build dir as a subdir of the source dir is not supported. It might work in many cases, but that does not mean it is okay to do. > Running the 5th throws th

'posix_spawnp' error in build

c.git 2) cd gcc & ./contrib/download_prerequisites 3) mkdir objdir & cd objdir 4) ../gcc/configure --prefix=/home/path/to/gcc --enable-languages=c,c++ 5) make -j 4 Running the 5th throws the following error: 'xgcc: fatal error: cannot execute ‘cc1plus’: posix_spawnp: No such file or di

Re: Compilation Error Regarding RID_MAX

> > > > > > > Hi, > > > > > > > > I have merged all my patches into a single branch for better > > > > maintainability for me, but I am unable to build GCC. Initially, I > > > > faced an error related to RID_MAX, which was fixed

Re: Compilation Error Regarding RID_MAX

le branch for better > > > maintainability for me, but I am unable to build GCC. Initially, I > > > faced an error related to RID_MAX, which was fixed in > > > https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. > > > The ICE

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:23 PM Andrew Pinski wrote: > > On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > > > Hi, > > > > I have merged all my patches into a single branch for better > > maintainability for me, but I am unable to build GCC. Initia

Re: Compilation Error Regarding RID_MAX

On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc wrote: > > Hi, > > I have merged all my patches into a single branch for better > maintainability for me, but I am unable to build GCC. Initially, I > faced an error related to RID_MAX, which was fixed in > https://gith

Compilation Error Regarding RID_MAX

Hi, I have merged all my patches into a single branch for better maintainability for me, but I am unable to build GCC. Initially, I faced an error related to RID_MAX, which was fixed in https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378. The ICE was caused by

Re: Confusing location of error in source code

Hi Jonathan, On 2023-09-01 08:49, Jonathan Wakely wrote: > On Thu, 31 Aug 2023, 17:05 Alejandro Colomar via Gcc, > wrote: > >> Hi! >> >> I've been confused for some time with a compilation error that >> pointed to a slightly-off location. I wasn't se

Re: Confusing location of error in source code

On Thu, 31 Aug 2023, 17:05 Alejandro Colomar via Gcc, wrote: > Hi! > > I've been confused for some time with a compilation error that > pointed to a slightly-off location. I wasn't seeing that I used > a temporary variable in a constant expression. The code could b

Confusing location of error in source code

Hi! I've been confused for some time with a compilation error that pointed to a slightly-off location. I wasn't seeing that I used a temporary variable in a constant expression. The code could be reduced to: $ cat const.c int main(void) { int x = 42; _Static_assert(

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

gi?id=110926 . Thanks, Andrew > > > > > > > > To quote: > > > > > > > > during RTL pass: split1 > > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function > > > > 'matmul_i1_avx512f&

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

> 'matmul_i1_avx512f': > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: > > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have > > > 'w' (rtx const_int) in vpternlog_redundant_operand_m

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

I guess --enable-checking=yes,rtl,extra is key to reproduce the issue? > > > > To quote: > > > > during RTL pass: split1 > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function > > 'matmul_i1_avx512f': > > /home/toon/compil

Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

ed/matmul_i1.c: In function > 'matmul_i1_avx512f': > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at

/home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at

/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at config/i386/i386.cc:19460 1781 | } | ^ during RTL pass: split1 /home/toon/compilers/gcc/libgfo

Re: Regarding bypass-asm patch and help in an error during bootstrapped build

strap option but > while > > doing a bootstrapped build, I am getting these errors ( as warnings while > > doing the non-bootstrapped build.) > > > > In file included from ../../gcc/gcc/lto-object.cc:23:0: > > ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static

Re: Regarding bypass-asm patch and help in an error during bootstrapped build

arnings while > doing the non-bootstrapped build.) > > In file included from ../../gcc/gcc/lto-object.cc:23:0: > ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool > is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but > never defined [enabled b

Regarding bypass-asm patch and help in an error during bootstrapped build

-bootstrapped build.) In file included from ../../gcc/gcc/lto-object.cc:23:0: ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but never defined [enabled by default] static inline bool test (U *p

problem building gcc-13.1.0: error: Pthreads are required error: Pthreads are required to build libgompto build libgomp

Trying to build default target in 13.1.0 source, and am hitting a Pthreads are required error. I have the .h and lib on my system, so not sure why hitting this error. I goog'd the error and see nothing recent about why I'd get the error. Any suggestions? Please include me in respon

Re: Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

ut Zeisel" > > > >Cc: gcc@gcc.gnu.org > > > >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20 > > > >On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote: > > > >> I compiled GCC 13.1.0 with GCC 12

Re: Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

On Thu, Apr 27, 2023 at 5:41 AM Jakub Jelinek via Gcc wrote: > > On Thu, Apr 27, 2023 at 11:35:23AM +0200, Helmut Zeisel wrote: > > >Von: "Jakub Jelinek" > > >An: "Helmut Zeisel" > > >Cc: gcc@gcc.gnu.org > > >Betreff: Re: GCC 13.1 co

Re: Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

On Thu, Apr 27, 2023 at 11:35:23AM +0200, Helmut Zeisel wrote: > >Von: "Jakub Jelinek" > >An: "Helmut Zeisel" > >Cc: gcc@gcc.gnu.org > >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20 > >On Thu, Apr 27, 2023 at 11:09:19AM +0200

Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

>Von: "Jakub Jelinek" >An: "Helmut Zeisel" >Cc: gcc@gcc.gnu.org >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20 >On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote: >> I compiled GCC 13.1.0 with GCC 12 and had the

Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20

On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote: > I compiled GCC 13.1.0 with GCC 12 and had the environment variable CXXFLAGS > set to -std=c++20 > This gives the error (both linux and cygin) > > gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: e

GCC 13.1 compile error when using CXXFLAGS=-std=c++20

I compiled GCC 13.1.0 with GCC 12 and had the environment variable CXXFLAGS set to -std=c++20 This gives the error (both linux and cygin) gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: error: ISO C++17 does not allow dynamic exception specifications 51 | _M_get(size_t __sz

Re: gcc 13 Build error

, because it should build without errors. > On Sun, Apr 2, 2023 at 7:13 PM Damian Tometzki > wrote: > > > > Hello together, > > > > i have the following build error gcc 13 current git: > > > > /home/damian/data/gcc13built/./prev-gcc/xg++ > > -B/home/dam

Re: gcc 13 Build error

s conflict with \float extensions", arch); return subset_list; On Sun, Apr 2, 2023 at 7:13 PM Damian Tometzki wrote: > > Hello together, > > i have the following build error gcc 13 current git: > > /home/damian/data/gcc13built/./prev-gcc/xg++ > -B/home/damian/d

gcc 13 Build error

Hello together, i have the following build error gcc 13 current git: /home/damian/data/gcc13built/./prev-gcc/xg++ -B/home/damian/data/gcc13built/./prev-gcc/ -B/usr/riscv64-linux-gnu/bin/ -nostdinc++ -B/home/damian/data/gcc13built/prev-riscv64-linux-gnu/libstdc++-v3/src/.libs -B/home/damian/data

Re: Separate warning/error thresholds for -Wfoo=

On Tue, 6 Dec 2022, Richard Biener via Gcc wrote: > Implementation-wise one could do a similar trick as we have for > global_options vs. global_options_set - add a global_options_error copy (ick!) > (and global_options_error_set!?) and have the logic that decides whether > a warning

Re: Separate warning/error thresholds for -Wfoo=

On Tue, Dec 6, 2022 at 4:53 PM Alexander Monakov via Gcc wrote: > > Greetings, David, community, > > I'd like to get your input on how GCC command line interface should support > making a "tiered" warning like -Warray-bounds={1,2} an error for "tier 1" &g

Separate warning/error thresholds for -Wfoo=

Greetings, David, community, I'd like to get your input on how GCC command line interface should support making a "tiered" warning like -Warray-bounds={1,2} an error for "tier 1" where fewer false positives are expected, and a plain warning otherwise. There was a rec

Re: Error: attempt to get value of unresolved symbol `L0'

set CONFIG_SYS_TEXT_BASE, 0x80008000 > > .word 44 > > .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) > > .word - (. - 0x80008000) > > .word 0x4 - (. - 0x0) > > > > The assembler now produces the following output: > > > > t.s: Assem

Re: Error: attempt to get value of unresolved symbol `L0'

.word - (. - 0x80008000) > .word 0x4 - (. - 0x0) > > The assembler now produces the following output: > > t.s: Assembler messages: > t.s:5: Error: expression is too complex to be resolved or converted into > relocations > t.s:6: Error: expression is t

Re: Error: attempt to get value of unresolved symbol `L0'

messages: t.s:5: Error: expression is too complex to be resolved or converted into relocations t.s:6: Error: expression is too complex to be resolved or converted into relocations Note - some targets do support applying multiple relocations to a single address, but even then there can be

Re: Error: attempt to get value of unresolved symbol `L0'

... > But just for reference the following would work: > > .word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - . > > > I agree however that this message: > > t.s: Error: attempt to get value of unresolved symbol `L0' > > is unhelpful. So I am going to

Re: Error: attempt to get value of unresolved symbol `L0'

e KERNEL_OFFSET and CONFIG_SYS_TEXT_BASE values are known at assembly > time. > > A clever assembler might be able to rearrange the expression, assuming that > overflow is unimportant, but gas does not do that. But just for reference > the following would work: > > .word KER

Re: Error: attempt to get value of unresolved symbol `L0'

would work: .word KERNEL_OFFSET + CONFIG_SYS_TEXT_BASE - . I agree however that this message: t.s: Error: attempt to get value of unresolved symbol `L0' is unhelpful. So I am going to check in a patch to change it to: t.s: Error: expression is too complex to be resolv

Re: Error: attempt to get value of unresolved symbol `L0'

On Tuesday 11 October 2022 08:46:58 Richard Biener wrote: > On Mon, Oct 10, 2022 at 7:19 PM Pali Rohár via Gcc wrote: > > > > Hello! > > > > During development and debugging of U-Boot bootloader I got strange > > error from ARM GNU assembler, which lo

Re: Error: attempt to get value of unresolved symbol `L0'

On Mon, Oct 10, 2022 at 7:19 PM Pali Rohár via Gcc wrote: > > Hello! > > During development and debugging of U-Boot bootloader I got strange > error from ARM GNU assembler, which looks like a bug in binutils or gcc. > > Below is simplified code which can trigger i

Error: attempt to get value of unresolved symbol `L0'

Hello! During development and debugging of U-Boot bootloader I got strange error from ARM GNU assembler, which looks like a bug in binutils or gcc. Below is simplified code which can trigger it: $ cat test.S kernoffs: .word KERNEL_OFFSET - (. - CONFIG_SYS_TEXT_BASE) $ arm-linux-gnueabi

Re: Buggy error message when dereferencing once a double pointer to struct

gt; > i = p->val; > } > > > is obviously incorrect. But gcc 8.3.0 says > > pointer.c: In function ‘main’: > pointer.c:14:8: error: ‘*p’ is a pointer; did you mean to use ‘->’? > i = p->val; > ^~ > -> > >

Buggy error message when dereferencing once a double pointer to struct

This snippet that I wrote struct str { int val; }; void main (int argc, char **argv) { struct str **p; int i; i = p->val; } is obviously incorrect. But gcc 8.3.0 says pointer.c: In function ‘main’: pointer.c:14:8: error: ‘*p’ is a pointer; did

Re: "cannot convert to a pointer type" error repeated tens of times

On Sat, 12 Feb 2022, Andrea Monaco via Gcc wrote: #include int main (void) { float a; curl_easy_setopt (NULL, 0, (void *) a); } with "gcc -c bug.c" gives bug.c: In function ‘main’: bug.c:15:3: error: cannot convert to a pointer type curl_easy_setopt (NULL, 0,

"cannot convert to a pointer type" error repeated tens of times

tion ‘main’: bug.c:15:3: error: cannot convert to a pointer type curl_easy_setopt (NULL, 0, (void *) a); ^~~~ bug.c:15:3: error: cannot convert to a pointer type bug.c:15:3: error: cannot convert to a pointer type bug.c:15:3: error: cannot convert to a pointer type [...]

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

On 2/2/22 10:11, Marc Glisse wrote: On Wed, 2 Feb 2022, Toon Moene wrote: Fascinating. My gcc directory had both gmp-6.2.1 and -6.1.0, but the symbolic link 'gmp' pointed to the old one. A similar problem for mpc, mpfr and isl ... You need to pass --force to contrib/download_prerequisites i

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

On Wed, 2 Feb 2022, Toon Moene wrote: Fascinating. My gcc directory had both gmp-6.2.1 and -6.1.0, but the symbolic link 'gmp' pointed to the old one. A similar problem for mpc, mpfr and isl ... You need to pass --force to contrib/download_prerequisites if you want them to be updated. -- M

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

On 2/1/22 22:44, Marc Glisse wrote: On Tue, 1 Feb 2022, Toon Moene wrote: I just ran a "ubsan" build on my x86_64-linux-gnu system. Maybe try with a more recent version of GMP first? gcd_1.c has only 103 lines in release 6.2.1. A stack trace (UBSAN_OPTIONS=print_stacktrace=1) would make i

Re: gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

/testsuite/gfortran.dg/graphite/pr39516.f -fdiagnostics-plain-output -fdiagnostics-plain-output -O -O2 -ftree-loop-linear -S -o pr39516.s gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' FAIL: gfortran.dg/graphite/pr39516.f -O (test for e

gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

iagnostics-plain-output -fdiagnostics-plain-output -O -O2 -ftree-loop-linear -S -o pr39516.s gcd_1.c:188:13: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' FAIL: gfortran.dg/graphite/pr39516.f -O (test for excess errors) Excess errors: gcd_1.c:1

Re: gcc's error description for missing MACRO arguments is wrong.

t; #define TEST(x,y) test(x,y) > int main() { > int x=TEST(); > }: > > Error message: > F:/test.cpp:4:20: error: macro "TEST" requires *2* arguments, but only *1* > given > > 4 | int x=TEST(); > > | ^ > No, you called it with one argument. An empty toke

gcc's error description for missing MACRO arguments is wrong.

Version: GCC 11.2 (msys2 mingw-w64 X86_64) When a macro have more than one arguments, and u call it with no argument, gcc will compliant with " only 1 given" instead of " 0 given" Demo code: #define TEST(x,y) test(x,y) int main() { int x=TEST(); }: Error message: F:/test.cp

Error for unknown spec function 'dumps' when compiling GCC 11.X

Dear GCC community, when I try to compile a 11 Version of GCC I get while compiling in the directory …./gcc-11.2.0/host-x86_64-pc-linux-gnu/gcc the following: x86_64-pc-linux-gnu-g++ -std=c++11 -fno-PIE ….. ../.././gcc/cp/g++spec.c error occurs: x86_64-pc-linux-gnu-g++: fatal error: unknown spec

GCC link error help!

Hello GCC, we use gcc compiler to complile my project on windows10 system, but it always report bellow error: c:/program files (x86)/gnu tools arm embedded/7 2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lgh3x2x_drv_co collect2.exe

Re: nvtpx: error: array subscript -1 is below array bounds of 'short int [2][16]'

] /usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long

Re: Error when accessing git read-only archive

Hi, On Wed, 2021-09-15 16:10:50 +0200, Mark Wielaard wrote: [UTF-8 email address containing a 'ł'] > The issue is the gravatar support, which calls md5_hex($email). > For now I disabled gravatar support on sourceware.org/gcc.gnu.org in > /etc/gitweb.conf I am not a Perl guy, but it seems this wo

  1   2   3   4   5   6   7   8   9   10   >