'TREE_READONLY' for 'const' array in C vs. C++

TION_INFO', GCC/nvptx then uses special-cased instructions for accessing the respective memory regions. Now, given a 'const' array (with whatever element type; not interesting here), like: extern int * const arr[]; ..., for GCC/C compilation, we access this as '.const'

nvptx: Don't use PTX '.const', constant state space [PR119573] (was: 'TREE_READONLY' for 'const' array in C vs. C++)

gt; .const Shared, read-only memory. >> > .global Global memory, shared by all threads. >> > >> > Implemented via 'TARGET_ENCODE_SECTION_INFO', GCC/nvptx then uses >> > special-cased instructions for accessing the respective memory regions. >> > >>

Re: 'TREE_READONLY' for 'const' array in C vs. C++

nteresting > here), like: > > extern int * const arr[]; > > ..., for GCC/C compilation, we access this as '.const' memory: GCC/nvptx > 'DATA_AREA_CONST', but for GCC/C++ compilation, we access it as > 'DATA_AREA_GLOBAL', and then fault at run t

Re: 'TREE_READONLY' for 'const' array in C vs. C++

On Tue, 1 Apr 2025, Richard Biener via Gcc wrote: > In C++ there could be runtime initializers for a const qualified > object. I think all > you need to do is make sure the logic that places the object in .const > vs. .global > is consistent with the logic deciding how to acce

Re: 'TREE_READONLY' for 'const' array in C vs. C++

the respective memory regions. > > > > Now, given a 'const' array (with whatever element type; not interesting > > here), like: > > > > extern int * const arr[]; > > > > ..., for GCC/C compilation, we access this as '.const' memory: GC

Re: [GSOC 2025] Interests in extending the static analysis pass(es): support for C++ or CPython API

ng on a medium-sized (or > large-sized) project that, broadly speaking, extends the static-analysis > pass(es). In particular, I’ve been dabbling between extending the analyzer’s > support for C++ and extending the plugin to add checking for usage of the > CPython API, such as refere

[GSOC 2025] Interests in extending the static analysis pass(es): support for C++ or CPython API

pass(es). In particular, I’ve been dabbling between extending the analyzer’s support for C++ and extending the plugin to add checking for usage of the CPython API, such as reference counting. Both topics can be found in the [ideas list](https://gcc.gnu.org/wiki/SummerOfCode). Nevertheless, I haven’t

web page c++-status proposal revision updates

For some C++26 language features listed on https://gcc.gnu.org/projects/cxx-status.html there are newer proposal revisions available: Remove undefined behavior from lexing P2621R3 <https://wg21.link/P2621R3> constexpr structured bindings and references to constexpr variables P2686R5

Re: [PATCH v18 0/2] c: Add __countof__ operator

Hi Joseph, Jakub, On Thu, Feb 27, 2025 at 09:51:35PM +0100, Jakub Jelinek wrote: > On Thu, Feb 27, 2025 at 08:44:25PM +, Joseph Myers via Gcc wrote: > > On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote: > > > > > Can you please confirm if we should add a version of this operator that > >

Re: [PATCH v18 0/2] c: Add __countof__ operator

On Thu, Feb 27, 2025 at 08:44:25PM +, Joseph Myers via Gcc wrote: > On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote: > > > Can you please confirm if we should add a version of this operator that > > need not be diagnosed under pedantic mode? If so, I'll propose this > > I'm doubtful of

Re: [PATCH v18 0/2] c: Add __countof__ operator

On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote: > Can you please confirm if we should add a version of this operator that > need not be diagnosed under pedantic mode? If so, I'll propose this I'm doubtful of the need for a second variant, but in any case the starting point should be a pat

Re: [PATCH v18 0/2] c: Add __countof__ operator

Hi Joseph, Aaron, (Aaron, there's no code in this email, so you should be able to read it, I guess. We're just discussing the naming of the operator.) Context for readers: The C Committee has finally accepted this as _Countof instead of _Lengthof, due to the concerns regarding conf

Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level

wever, I am not very familiar with GCC source code at present, and that is the reason why I am asking for help here. Thanks, Hanke Zhang Florian Weimer 于2025年1月18日周六 20:50写道： > > * Hanke Zhang via Gcc: > > > I have recently been delving into optimizing dynamic_cast calls in C++ > &

Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level

* Hanke Zhang via Gcc: > I have recently been delving into optimizing dynamic_cast calls in C++ > within the context of GIMPLE code. In particular, for scenarios > involving single inheritance, I'm aiming to convert the following > code: > > _1 = __dynamic_cas

Question about optimizing dynamic_cast call in C++ at GIMPLE Level

Hi, I have recently been delving into optimizing dynamic_cast calls in C++ within the context of GIMPLE code. In particular, for scenarios involving single inheritance, I'm aiming to convert the following code: _1 = __dynamic_cast (obj_1(D), &_ZTI7Base, &_ZTI10Derived, 0); if (_1!

Xx No m. M C B m

I’m k B Sent from my iPhone

Help with setting the order of default system include directories of c,c++ preprocessor

t: aarch64-unknown-linux-gnu 5 Configured with: ../configure --prefix=/mnt/builder/gcc --disable-bootstrap --enable-languages=c,c++ 6 Thread model: posix 7 Supported LTO compression algorithms: zlib 8 gcc version 13.2.1 20240309 (GCC) 9 COLLECT_GCC_OPTIONS='-E' '-v' &#x

Re: [committed] c: Default to -std=gnu23

On Fri, 22 Nov 2024, Sam James wrote: > > Some estimate of the build failure would also be helpful. Is it the > > same as, e.g. the GCC 12 to GCC 13 update, or is it igher? > > It's pretty large so far. Between 12 and 13, the main issues were: > libstdc++ transitive include changes and a small n

Re: [committed] c: Default to -std=gnu23

Florian Weimer writes: > * Sam James: > >>> Has anyone performed experiments to determine the impact of this change >>> on typical free software distributions? >> >> I filed https://gcc.gnu.org/PR117298 for an issue Joseph noticed in one >> of the GCC tests (that is actually an improvement, but a

Re: [committed] c: Default to -std=gnu23

* Joseph Myers: > Change the default language version for C compilation from -std=gnu17 > to -std=gnu23. A few tests are updated to remove local definitions of > bool, true and false (where making such an unconditional test change > seemed to make more sense than changing the test c

Re: [committed] c: Default to -std=gnu23

* Sam James: >> Has anyone performed experiments to determine the impact of this change >> on typical free software distributions? > > I filed https://gcc.gnu.org/PR117298 for an issue Joseph noticed in one > of the GCC tests (that is actually an improvement, but a missed opt for > older standards

Re: [committed] c: Default to -std=gnu23

Florian Weimer writes: > * Joseph Myers: > >> Change the default language version for C compilation from -std=gnu17 >> to -std=gnu23. A few tests are updated to remove local definitions of >> bool, true and false (where making such an unconditional test change >>

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Fri, 8 Nov 2024, Alejandro Colomar wrote: >I've just checked that JeanHeyd opened a survey about the name. >It's here: <https://thephd.dev/the-big-array-size-survey-for-c>. Yes, I saw it on Fedi, where it was announced big, and filled it in. Thanks, //mirabilos --

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi Joseph, On Fri, Nov 08, 2024 at 03:54:51PM GMT, Joseph Myers wrote: > On Fri, 8 Nov 2024, Alejandro Colomar wrote: > > > Hi Thorsten, JeanHeyd, > > > > I've just checked that JeanHeyd opened a survey about the name. > > It's here: <https:/

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Fri, 8 Nov 2024, Alejandro Colomar wrote: > Hi Thorsten, JeanHeyd, > > I've just checked that JeanHeyd opened a survey about the name. > It's here: <https://thephd.dev/the-big-array-size-survey-for-c>. > Thanks for the survey, JeanHeyd; It's a fair one. (

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi Thorsten, JeanHeyd, I've just checked that JeanHeyd opened a survey about the name. It's here: <https://thephd.dev/the-big-array-size-survey-for-c>. Thanks for the survey, JeanHeyd; It's a fair one. (The only thing I miss is anouncing it to some relevant publics, but I g

Re: [PATCH v17 2/2] c: Add __countof__ operator

. I don't care about it at all, so whatever. Ah, okay. >> PS: Got any contacts in the OpenBSD and NetBSD worlds that can >> add input? They invest a lot into good C code as well, in >> the OpenBSD case rather heavily (if opinionated). > >I don't. If you d

Re: [PATCH v17 2/2] c: Add __countof__ operator

at the root context of this thread is, but in BSD land > > > > > >The root context is that > > > > > >- _Lengthof was added to C2y in the Minnesota meeting. It was proposed > > > > where/how would this be used for? Also, do you have the n.pdf l

Re: [PATCH v17 2/2] c: Add __countof__ operator

> > > >- _Lengthof was added to C2y in the Minnesota meeting. It was proposed > > where/how would this be used for? Also, do you have the n.pdf link > handy? I don’t actively follow C other than what thephd posts. Yes; there are four n papers. See below, plus the h

Re: [PATCH v17 2/2] c: Add __countof__ operator

sed for? Also, do you have the n.pdf link handy? I don’t actively follow C other than what thephd posts. >- I'm sending a patch to GCC proposing __countof__, since overloading > length for both string length and array number of elements is (IMO) > going to promote off-by-on

Re: [PATCH v17 2/2] c: Add __countof__ operator

of the operator (which BTW was influenced by a survey conducted on programmers some of which declared hating C and not wanting to use it ever, so I refuse to acknowledge validity of the results of that survey; that survey also didn't inform of possible problems of each name). So

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Sat, 26 Oct 2024, Alejandro Colomar wrote: >> It would also be interesting to hear the opinion of people from the BSDs >> >#define sizeof_array(a) (countof(a) * sizeof((a)[0])) >> >#define sizeof_array(a) (array_size(a) * sizeof((a)[0])) Not too sure what the root context of this th

Re: [PATCH v17 2/2] c: Add __countof__ operator

t might result in buffer overflows, or > > other kinds of errors (and it would be interesting to mention that I've > > presented a link to an actual bug of that class in shadow-utils, which I > > fixed recently). I would also like the survey to be presented to > > progra

Re: [PATCH v17 2/2] c: Add __countof__ operator

ug of that class in shadow-utils, which I > > > fixed recently). I would also like the survey to be presented to > > > programmers that like programming in C; I would refuse to acknowledge > > > the results of any survey that is presented to C++ or rust programmers > >

Re: [PATCH v17 2/2] c: Add __countof__ operator

;ve > presented a link to an actual bug of that class in shadow-utils, which I > fixed recently). I would also like the survey to be presented to > programmers that like programming in C; I would refuse to acknowledge > the results of any survey that is presented to C++ or rust programmer

Re: [PATCH v17 2/2] c: Add __countof__ operator

e the survey to be presented to programmers that like programming in C; I would refuse to acknowledge the results of any survey that is presented to C++ or rust programmers who acknowledge not wanting to program in C ever again. They have a clear conflict of interest. If this survey is conducted, it s

C

 Sent from my iPhone gf fy

Re: C Standard Libraries

chy that I can find > implementation > > code for standard C library functions like fgetc / fputs, etc, or would > > that be outside the scope of GCC? I've been hunting around on the source > > tree for the last few days and found the headers, but not the > > impleme

Re: C Standard Libraries

> On 15 Oct 2024, at 18:09, Bryon Quackenbush via Gcc wrote: > > External email: Use caution opening links or attachments > > > Does anyone know where in the GCC hierarchy that I can find implementation > code for standard C library functions like fgetc / fputs, et

C Standard Libraries

Does anyone know where in the GCC hierarchy that I can find implementation code for standard C library functions like fgetc / fputs, etc, or would that be outside the scope of GCC? I've been hunting around on the source tree for the last few days and found the headers, but not the implement

Re: Update bootstrap requirement to C++14?

On 2024-09-17 22:31, Jason Merrill via Gcc wrote: On 9/16/24 11:14 AM, Florian Weimer wrote: * Jason Merrill via Gcc: We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after support was stable in GCC 4.8. Note that some documentation still says C++03, for example: | The

Re: Educational question on compiling (analyzing) the C programming language

On Okt 10 2024, Florian Weimer wrote: > * Laurent Cimon via Gcc: > >> I realize that compilers have evolved with time, and that many >> things required the use of function prototypes, but my question is, >> what is the historical reason that a function defined further do

Re: Educational question on compiling (analyzing) the C programming language

* Laurent Cimon via Gcc: > I realize that compilers have evolved with time, and that many > things required the use of function prototypes, but my question is, > what is the historical reason that a function defined further down > in a C file cannot be used without a function prototyp

Educational question on compiling (analyzing) the C programming language

. While learning L-attributed SDD, where dependency trees are strictly built from left to right, I wondered if that is why the C programming language requires function prototypes at the top of a file to use functions that are implemented further down. The professor couldn't say and advised me t

RE: Understanding bogus? gcc.dg/signbit-6.c

> -Original Message- > From: Georg-Johann Lay > Sent: Wednesday, October 2, 2024 3:06 PM > To: GCC Development ; Tamar Christina > > Subject: Re: Understanding bogus? gcc.dg/signbit-6.c > > Am 02.10.24 um 15:55 schrieb Georg-Johann Lay: > > I am having pr

Re: Understanding bogus? gcc.dg/signbit-6.c

Am 02.10.24 um 15:55 schrieb Georg-Johann Lay: I am having problems understanding test case gcc.dg/signbit-6.c which fails on a 16-bit platform (avr). https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/signbit-6.c;h=da186624cfa057dfc3780c8af4f6b1335ba07e7e;hb=HEAD The relevant

RE: Understanding bogus? gcc.dg/signbit-6.c

> -Original Message- > From: Georg-Johann Lay > Sent: Wednesday, October 2, 2024 2:55 PM > To: GCC Development ; Tamar Christina > > Subject: Understanding bogus? gcc.dg/signbit-6.c > > I am having problems understanding test case gcc.dg/signbit-6.c > which

Understanding bogus? gcc.dg/signbit-6.c

I am having problems understanding test case gcc.dg/signbit-6.c which fails on a 16-bit platform (avr). https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gcc.dg/signbit-6.c;h=da186624cfa057dfc3780c8af4f6b1335ba07e7e;hb=HEAD The relevant part of the code is: int main () { TYPE a[N

Global Module Implications of extern "C/C++", or Partition python

Global Module Implications of extern "C/C++", or PartitionAndroid.root .rarB37272737474888274488838480944809660603550969660603550₿₿BTC 37272737474888274488838480944809660603550969660603550.00B

I need a Linux C Project.

Hi there, I need a help. I need a Linux C Project. How much does it cost? I pay well. Can you help me? Give some directions to use GCC. Sincerely, Marco Paulo S. Marques

Re: Update bootstrap requirement to C++14?

On 9/16/24 11:14 AM, Florian Weimer wrote: * Jason Merrill via Gcc: We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after support was stable in GCC 4.8. Note that some documentation still says C++03, for example: | The directories gcc, libcpp and fixincludes may use C++03

Re: Update bootstrap requirement to C++14?

* Jason Merrill via Gcc: > We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after > support was stable in GCC 4.8. Note that some documentation still says C++03, for example: | The directories gcc, libcpp and fixincludes may use C++03. They may | also use the long long t

Re: Update bootstrap requirement to C++14?

On Sat, Sep 14, 2024 at 11:53 AM Jason Merrill via Gcc wrote: > > We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after > support was stable in GCC 4.8. > > It is now 8 years since C++14 was the default mode in GCC 6 (and 9 years > since support was complete

Re: Update bootstrap requirement to C++14?

On Sat, Sep 14, 2024, 11:37 AM Andrew Pinski via Gcc wrote: > On Sat, Sep 14, 2024 at 8:53 AM Jason Merrill via Gcc > wrote: > > > > We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after > > support was stable in GCC 4.8. > > > > It is now

Re: Update bootstrap requirement to C++14?

On Sat, Sep 14, 2024 at 8:53 AM Jason Merrill via Gcc wrote: > > We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after > support was stable in GCC 4.8. > > It is now 8 years since C++14 was the default mode in GCC 6 (and 9 years > since support was complete in GC

Update bootstrap requirement to C++14?

We moved to a bootstrap requirement of C++11 in GCC 11, 8 years after support was stable in GCC 4.8. It is now 8 years since C++14 was the default mode in GCC 6 (and 9 years since support was complete in GCC 5); perhaps it's time to update? IIRC I've previously suggested this in res

[PATCH v10 0/3] c: Add __nelementsof__ operator

en some informal ones, but I prefer to pick them from explicit ones. Have a lovely day! Alex Alejandro Colomar (3): gcc/: Rename array_type_nelts() => array_type_nelts_minus_one() Merge definitions of array_type_nelts_top() c: Add __nelementsof__ operator gcc/c-family/c-common.cc

C++: Coroutine lambdas and the incomplete closure type

Hi! Currently, I'm looking at PR115731. To summarize the issue, it is possible for the user to, through coroutines, observe the closure type of a lambda before it is completed. This closure type, in GCC, is started before and finished after parsing the lambda body, meaning that it is incomplete

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 17:54 +0100, Joern Wolfgang Rennecke wrote: > > > On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote: >   > I guess you could reduce the differences between platforms if you > didn't > > use types as defined by headerfiles directly, as they might be > > #defines > > or type

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 17:13 +0100, Joern Wolfgang Rennecke wrote: > > > On 22/07/2024 16:44, David Malcolm wrote: > > Does it help to hack this change into prune.exp: > > > > diff --git a/gcc/testsuite/lib/prune.exp > > b/gcc/testsuite/lib/prune.exp > > index d00d37f015f7..f467d1a97bc6 100644 >

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote: > I guess you could reduce the differences between platforms if you didn't use types as defined by headerfiles directly, as they might be #defines or typedefs or whatever, and instead used your own typedef or struct types. It seems a type

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

aderfiles directly, as they might be #defines or typedefs or whatever, and instead used your own typedef or struct types.Index: c-c++-common/analyzer/out-of-bounds-diagram-8.c =========== --- c-c++-common/analyzer/out-of-bounds-diag

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

with make check-gcc RUNTESTFLAGS="-v -v --target_board=unix\{-m32,-m64\} analyzer.exp=out-of-bounds-diagram-11.c" I see this output for the 2nd test: ┌───┐

c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

While on x86_64-pc-linux-gnu, the second diagram shows the type written as 'int', as expected, on a 16 and 32 bit newlib based toolchain, it is being output as int32_t . And all the formatting is also a bit different, probably due to the change in how the int32_t is displayed. What do other p

Re: insn attributes: Support blocks of C-code?

Am 17.07.24 um 20:49 schrieb Richard Sandiford: Georg-Johann Lay writes: [...] Am 13.07.24 um 13:44 schrieb Richard Sandiford: It shouldn't be necessary to emit the enum tag these days. If removing Hi Richard, I am not familiar with the gensupport policies, which is the reason why the feat

Re: insn attributes: Support blocks of C-code?

Georg-Johann Lay writes: > [...] > Am 13.07.24 um 13:44 schrieb Richard Sandiford: >> Georg-Johann Lay writes: >>> diff --git a/gcc/read-md.h b/gcc/read-md.h >>> index 9703551a8fd..ae10b651de1 100644 >>> --- a/gcc/read-md.h >>> +++ b/gcc/read-md.h >>> @@ -132,6 +132,38 @@ struct overloaded_name {

Re: insn attributes: Support blocks of C-code?

ubmission, but it looks mostly ready to go. Some comments below: diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi index 7f4335e0aac..3e46693e8c2 100644 --- a/gcc/doc/md.texi +++ b/gcc/doc/md.texi @@ -10265,6 +10265,56 @@ so there is no need to explicitly convert the expression into a boolean

Re: insn attributes: Support blocks of C-code?

below: > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi > index 7f4335e0aac..3e46693e8c2 100644 > --- a/gcc/doc/md.texi > +++ b/gcc/doc/md.texi > @@ -10265,6 +10265,56 @@ so there is no need to explicitly convert the > expression into a boolean > (match_test "(x & 2) != 0

insn attributes: Support blocks of C-code?

65,56 @@ so there is no need to explicitly convert the expression into a boolean (match_test "(x & 2) != 0") @end smallexample +@cindex @code{symbol_ref} and attributes +@item (symbol_ref "@var{quoted-c-expr}") + +Specifies the value of the attribute sub-expression as a C e

Ccccc. C. C.

x CC from my iPhone

Re: FE C++ requirement

ptions -fno-rtti > -fasynchronous-unwind-tables [...] -fno-common -DHAVE_CONFIG_H -no-pie > -static-libstdc++ -static-libgcc attribs.o -o cobol1 [...] > > As we would expect, ldd(1) reports that output is not linked to libstdc+ > +.so. > > Where things appear to go awry is wh

Re: FE C++ requirement

gcc attribs.o -o cobol1 [...] As we would expect, ldd(1) reports that output is not linked to libstdc+ +.so. Where things appear to go awry is when I try to take a shortcut: $ make -C build install where "build" is the top of the gcc build tree, where we'll eventually find b

Re: isl 0.26 C++17 issues when bootstrapping with GCC

e via Gcc wrote: >>>>> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: >>>>> >>>>> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >>>>>> I suppose for bootstrapping we could disable ISL during stage1 since >

Re: isl 0.26 C++17 issues when bootstrapping with GCC

t;> >>>> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >>>>> I suppose for bootstrapping we could disable ISL during stage1 since >>>>> it enables an optional feature only. Other than that GCC only >>>>> requires a C

Re: isl 0.26 C++17 issues when bootstrapping with GCC

;>> I suppose for bootstrapping we could disable ISL during stage1 since > >>> it enables an optional feature only. Other than that GCC only > >>> requires a C++11 compiler for building, so ISL breaks that constraint > >>> with requiring C++17. > >&

Re: isl 0.26 C++17 issues when bootstrapping with GCC

gt; it enables an optional feature only. Other than that GCC only >>> requires a C++11 compiler for building, so ISL breaks that constraint >>> with requiring C++17. >> >> Note that it doesn't *require* it per sé; the tests that try it are >> compiled if C++

Re: isl 0.26 C++17 issues when bootstrapping with GCC

This > On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc wrote: > > On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >> I suppose for bootstrapping we could disable ISL during stage1 since >> it enables an optional feature only. Other than that GCC only >>

Re: FE C++ requirement

lang.in E.g. the linking of the FE binaries need to be specially chained for --enable-link-serialization or --enable-link-serialization=N such that only N binaries are linked together, etc. c++.serial = cc1plus$(exeext) ... cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) $(LIB

FE C++ requirement

/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by build-O2/gcc/cobol1 The above error comes from ldd(1). I'm experimenting with what's minimally needed to install gcc when configured with --languages=cobol. Until this week, we always use

Re: Update on GCC 14 C type safety changes/warnings as errors

* Martin Jambor: > Given you probably have the most experience with it, can you please also > suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that > would describe this change? (I was thinking of proposing something > myself, but I don't really know just how much verbose such an en

Re: Update on GCC 14 C type safety changes/warnings as errors

Hello, On Thu, Nov 30 2023, Florian Weimer via Gcc wrote: > The patch series is currently under review: > > [PATCH v3 00/11] : More warnings as errors by default > > > > Jeff as a global reviewer has delegated

The codeblocks which I installed is not compiling the program so guid me How to install a c compiler to codeblocks

Re: GCC 12.3 ICE: format(printf...) failing in C++ with virtual inheritance

his ICE (can anyone repro it in > the current release?), but does anyone know if there's any way to make > it work in GCC 12.3? If it is suitable to modify the source code of the application, a workaround is to let the constructor take a ref/ptr to va_list instead, and wrap a call to i

GCC 12.3 ICE: format(printf...) failing in C++ with virtual inheritance

Exception("something bad"); |^ /tmp/virt.cpp:12:36: internal compiler error: in get_constant, at c-family/c-format.cc:323 0x7fba675a3082 __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preproces

RE: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023)

...@lists.riscv.org Subject: RE: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023) Hi eop, When I checked the calendar, https://tech.riscv.org/calendar/, last night, the meeting was scheduled for 6am PT, which was a conflict in my schedule. Could any

RE: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023)

From: "eop Chen via lists.riscv.org" Date: 12/4/23 1:29 AM (GMT-08:00) To: tech-rvv-intrins...@lists.riscv.org, tech-vector-...@lists.riscv.org, gcc@gcc.gnu.org, sig-toolcha...@lists.riscv.org Subject: [RISC-V][tech-rvv-intrinsics] RISC-V V C Intrinsic API v1.0 release meeting reminder

RISC-V V C Intrinsic API v1.0 release meeting reminder (December 4th, 2023)

Hi all, A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic API v1.0 is going to be held on 2023/12/04 7AM (GMT -7) / 11PM (GMT +8). The agenda can be found in the second page of the meeting slides (link <https://docs.google.com/presentatio

Re: Update on GCC 14 C type safety changes/warnings as errors

Florian Weimer via Gcc writes: > [...] > Numbers do not tally up because one package can have multiple issues. > The autoconf column counts packages where file-name based heuristics > suggest the critical errors are in autoconf-style feature probes, where > they are ignored and could silently a

Update on GCC 14 C type safety changes/warnings as errors

or the GCC 14 release, although that would run counter to the request for one transition only. Thoughts? Excluded above are systemic issues related to Vala, which does not produce valid C in many cases. I will probably have to look into teaching Vala to emit diagnostic pragmata in the generated C sou

[PATCH] C++: Introduce the extended attribute for asm declarations

Hi all, This is the beginning of a patch to introduce the extended attribute for asm declarations proposed in https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636563.html. I will need some reviewer help in implementing this patch, as I am not very familiar with gcc's internals. The attribu

Re: Typo in "C++ Standards Support in GCC"

On Wed, 2023-11-15 at 08:23 +, Taisei Katô via Gcc wrote: > Dear GCC developers, > > There is a typo in Section "C++14 Support in GCC" in "C++ Standards > Support in GCC."<https://gcc.gnu.org/projects/cxx-status.html#cxx14> > "GCC has full suppo

Typo in "C++ Standards Support in GCC"

Dear GCC developers, There is a typo in Section "C++14 Support in GCC" in "C++ Standards Support in GCC."<https://gcc.gnu.org/projects/cxx-status.html#cxx14> "GCC has full support for the of the 2014 C++ standard." Yours sincerely, Katô Taisei

Re: Suboptimal warning formatting with `bool` type in C

is. Yes, that is part of the reason. The C standards mandate a number of things to be macros when it would seem that typedef's, functions, enumeration constants or other things would be "nicer" in some sense. Macros have two advantages, however - you can "#undef" the

Re: Suboptimal warning formatting with `bool` type in C

On 2023-11-01 23:13, Joseph Myers wrote: On Wed, 1 Nov 2023, peter0x44 via Gcc wrote: Why is #define used instead of typedef? I can't imagine how this could possibly break any existing code. That's how stdbool.h is specified up to C17. In C23, bool is a keyword instead. I see, I didn't kn

Re: Suboptimal warning formatting with `bool` type in C

On Wed, 1 Nov 2023, peter0x44 via Gcc wrote: > Why is #define used instead of typedef? I can't imagine how this could > possibly break any existing code. That's how stdbool.h is specified up to C17. In C23, bool is a keyword instead. -- Joseph S. Myers jos...@codesourcery.com

Suboptimal warning formatting with `bool` type in C

Recently, I was writing some code, and noticed some slightly strange warning formatting on a function taking a `bool` parameter #include void test(bool unused) { } bruh.c: In function 'test': bruh.c:2:16: warning: unused parameter 'unused' [-Wunused-parameter] 2 | void test(bool unused)

RISC-V V C Intrinsic API v1.0 release meeting reminder (October 30th, 2023)

Hi all, A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic API v1.0 is going to be held on 2023/10/30 7AM (GMT -7) / 10PM (GMT +8). The agenda can be found in the second page of the meeting slides (link <https://docs.google.com/presentatio

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

hen a > > > simple "yes" or "no" answer is sufficient. > > > > > > libcpp/ > > > > > > * charset.cc: Add `_cpp_valid_utf8_str` which determines > > > whether > > > a C string is valid UTF-8 or not. &

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

tr` which determines whether a C string is valid UTF-8 or not. * internal.h: Add prototype for `_cpp_valid_utf8_str`. Signed-off-by: Ben Boeckel [going through patches in patchwork] What's the status of this patch; did this ever get committed? It was superseded. Jason

Re: [PATCH v5 2/5] libcpp: add a function to determine UTF-8 validity of a C string

On Wed, Jan 25, 2023 at 4:09 PM Ben Boeckel via Gcc wrote: > > This simplifies the interface for other UTF-8 validity detections when a > simple "yes" or "no" answer is sufficient. > > libcpp/ > > * charset.cc: Add `_cpp_valid_utf8_str` which d

  1   2   3   4   5   6   7   8   9   10   >