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 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: error: ISO > > >> C++17 does not allow dynamic exception specifications > > >> 51 | _M_get(size_t __sz) throw(std::bad_alloc) > > >> > > >> After > > >> > > >> unset CXXFLAGS > > >> > > >> compilation works > > > > >Don't do it. > > > > Dont do *what*? > > export CXXFLAGS=... ? > > Include explicit -std= settings in such exported variables, especially when > building GCC. Packages should decide themselves in which language version > they are written in, or if they are written in common subset, they should > just defer to the compiler default. > Note, doing that would break building even much older GCC versions. Maybe configure should catch that? diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 0dd550a4b4b..f0d998aad94 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -86,6 +86,9 @@ AH_TEMPLATE(VERSION, [Version number of package]) # -fno-builtin must be present here so that a non-conflicting form of # std::exit can be guessed by AC_PROG_CXX, and used in later tests. +AS_CASE(["$CXXFLAGS"], + [*-std=*], [AC_MSG_ERROR([don't do that])]) + save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -fno-builtin" AC_PROG_CC
Re: Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20
On Mon, 8 May 2023, 09:38 NightStrike via Gcc, wrote: > 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 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: error: > ISO C++17 does not allow dynamic exception specifications > > > >> 51 | _M_get(size_t __sz) throw(std::bad_alloc) > > > >> > > > >> After > > > >> > > > >> unset CXXFLAGS > > > >> > > > >> compilation works > > > > > > >Don't do it. > > > > > > Dont do *what*? > > > export CXXFLAGS=... ? > > > > Include explicit -std= settings in such exported variables, especially > when > > building GCC. Packages should decide themselves in which language > version > > they are written in, or if they are written in common subset, they should > > just defer to the compiler default. > > Note, doing that would break building even much older GCC versions. > > Maybe configure should catch that? > > diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac > index 0dd550a4b4b..f0d998aad94 100644 > --- a/libstdc++-v3/configure.ac > +++ b/libstdc++-v3/configure.ac > @@ -86,6 +86,9 @@ AH_TEMPLATE(VERSION, [Version number of package]) > # -fno-builtin must be present here so that a non-conflicting form of > # std::exit can be guessed by AC_PROG_CXX, and used in later tests. > > +AS_CASE(["$CXXFLAGS"], > + [*-std=*], [AC_MSG_ERROR([don't do that])]) > + > save_CXXFLAGS="$CXXFLAGS" > CXXFLAGS="$CXXFLAGS -fno-builtin" > AC_PROG_CC > Seems like a reasonable idea at first glance, somebody could test and submit a patch. That pattern will match a hypothetical option like -ffoo-std=bar which is not a -std option. I think a better pattern would be needed.
GCC 12.3.1 Status Report (2023-05-08)
Status == The gcc-12 branch is again open for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P10 P2 501 - 1 P3 54 + 5 P4 232 P5 24 --- --- Total P1-P3 555 + 4 Total 811 + 4 Previous Report === https://gcc.gnu.org/pipermail/gcc/2023-May/241235.html
GCC 12.3 Released
The GNU Compiler Collection version 12.3 has been released. GCC 12.3 is the first bug-fix release from the GCC 12 branch containing important fixes for regressions and serious bugs in GCC 12.2 with more than 127 bugs fixed since the previous release. This release is available from the WWW servers listed here: https://sourceware.org/pub/gcc/releases/gcc-12.3.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
GSoC: Porting cpychecker to a -fanalyzer plugin
Hi, Eric and Dave, I did not make it to the GSoC program. I am not surprised. In this email, I would like to share some thoughts on this project with Eric and pose some questions to Dave. In the past month, I have been active in the CPython community. Now I am nominated as a triage member. https://github.com/python/core-workflow/issues/503 I took a look at how the GCC extension and how the analyzer works. I have the basic idea of how this project should work. Questions: 1. Where should this project (cpychecker) resides? Since it's an extension, it may live outside of the GCC project. But it currently also relies on some internal headers of the analyzer. If it lives outside, making the analyzer's internal header stable for public use would be the best choice here. 2. Where do people in GCC discuss development plans or new ideas? In other large projects, I observed people discussing such things in a forum. I emailed one of the contributors. He replied that this email list would be such a place, as well as the IRC channel. But this mailing list is less active than the project itself. I guess the most discussions are through the `gcc-patch` mailing list. Thoughts/Experiences/Advice: (to Eric) 1. Plugins GCC has plugin mechanisms: https://gcc.gnu.org/wiki/plugins If you provide a shared library, the compiler loads your library and calls your function. It initiates your plugin. Your plugin registers some callbacks. The compiler invokes the callbacks later. Specific to the analyzer, you can see this initialization happen at `gcc/analyzer/engine.cc`. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/engine.cc;h=a5965c2b8ff048e47d9c1687d5298a11020a5bee;hb=HEAD#l6102 You can try writing a basic "nop" plugin first. You need to include those headers defining the virtual function interfaces. 1. State Machine and Known Functions As you can see from the interface: the class `plugin_analyzer_init_iface` https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/analyzer.h;h=a1619525afaf9322f1ef6d6ec387d6eea70f7c0f;hb=HEAD#l275 You can register two things: state machine and known functions. The state machine is defined in `sm.h`. These provide core functionality. You can check all those `sm-*.cc` files. For instance, we have several states on a pointer, malloced or freed. You can read the logic in `sm-malloc.cc` Known function is defined in `analyzer.h`. It provides you the ability to do checks on function calls. You can check `kf.cc` for reference implementations. When completed, this plugin would consist of several `state_machine`s and `known_function`s. 3. Go through the code logic with GDB I don't know to what extent you have interacted with GCC or if you have coded in C++. I strongly recommend using gdb. I found it very helpful to debug with gdb. You can go through the code with gdb and do breakpoints anywhere. You don't need to add some debug lines, then recompile. (Once you have tried compiling GCC, you will understand what I am saying.) You can also see the full backtrace, knowing the callee of each function (even where function pointers are used). You can breakpoint all `ana::*` functions using a wildcard character `*.` Then gcc will break at any function related to the analyzer. You can then use `c` to continue. 4. Start with easy issues. You can read David's guide here. https://gcc-newbies-guide.readthedocs.io/en/latest/index.html My personal experience is that if you don't know what to do. Try solving relevant issues. You can merely find out what caused the bug. Solving them would be a plus. I did this in issues #109190 and #109027 and understood how the analyzer works. --- I will act more like a reviewer and adviser for this project. (To Eric:) I can review your code and give you advice. I will help you more when you are stuck with some implementation bugs. CC me the relevant changes. I will review them when I am available. Best, Steven
Re: For GCC, newlib combined tree, newlib build-tree testing, use standard search paths
Hi!
Ping: OK to push to newlib main branch the attached
"For GCC, newlib combined tree, newlib build-tree testing, use standard search
paths"?
Or, has anybody got adverse comments/insight into this?
Grüße
Thomas
On 2023-04-14T22:03:28+0200, I wrote:
> Hi!
>
> OK to push to newlib main branch the attached
> "For GCC, newlib combined tree, newlib build-tree testing, use standard
> search paths"
> -- or is something else wrong here, or should this be done differently?
> (I mean, I'm confused why this doesn't just work; I'm certainly not the
> first person to be testing such a setup?)
>
> I'm not doing anything special here: just symlink 'newlib' into the GCC
> source directory, build the combined tree, and then run 'make check', as
> mentioned in the attached Git commit log.
>
>
> Grüße
> Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From e56b38625929c3cf62c71d3fbd9264aaeef39d0c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Fri, 14 Apr 2023 21:26:32 +0200
Subject: [PATCH] For GCC, newlib combined tree, newlib build-tree testing, use
standard search paths
For example, for GCC/GCN target (AMD GPUs), target libraries are built
individually per supported hardware ISA ('-march=[...]'). Testing such a
toolchain via, for example:
$ make RUNTESTFLAGS='--target_board=[...]/-march=gfx90a' check[...]
... does work fine for all 'check-gcc-[...]' as well as GCC-provided target
libraries, 'check-target-[...]'. Just for 'check-target-newlib', for the
example above, not the '-march=gfx90a' newlib libraries are linked in, but
instead always the default ones, which results in link FAILure. This is cured
simply by skipping use of 'newlib/testsuite/lib/flags.exp', so that the
standard search paths as determined by GCC, DejaGnu are used for newlib, too.
---
newlib/testsuite/lib/flags.exp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/newlib/testsuite/lib/flags.exp b/newlib/testsuite/lib/flags.exp
index e1e9acb18..697291e7a 100644
--- a/newlib/testsuite/lib/flags.exp
+++ b/newlib/testsuite/lib/flags.exp
@@ -4,6 +4,13 @@
# is freely granted, provided that this notice is preserved.
#
+if [info exists env(XGCC_FLAGS_FOR_TARGET)] {
+verbose "GCC, newlib combined tree, build-tree testing; using standard search paths"
+# ... instead of the search paths built here, based on 'objdir' as set in
+# newlib's 'site.exp', which always points to the default multilib.
+return
+}
+
# flags.exp: overrides the dejagnu versions of libgloss_link_flags,
# newlib_link_flags, and newlib_include_flags.
--
2.25.1
