Re: GCC does not optimize well enough with vectors on bitshift

Thanks for the report! Please file it at https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc On Mon, Mar 10, 2025 at 10:47 AM Qwert Nerdish via Gcc > wrote: > > > Correct link is https://godbolt.org/z/GfeTobMvs > > > > On Mon, Mar 10, 2025 at 4:45 PM Qwert Nerdish > > wrote: > > > > > On thi

Re: Interest in Contributing Diagnostic System to GCC

On Mon, Feb 3, 2025 at 5:58 AM JohnyTheCarrot via Gcc wrote: > Dear Basile and other GCC friends, > > I may have not been clear about the purpose of my code. > It does not analyze code, it merely formats / constructs diagnostics for > printing to a terminal. > > I am looking to perhaps contribute

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

On 10/17/24 12:09 PM, Alejandro Colomar via Gcc wrote: CC += JeanHeyd CC += Robert, Joseph, gcc@ CC += Doug, as the author of the original malloc(3). Please don't CC random people (and mailing lists) on a glibc bug report. See https://sourceware.org/glibc/wiki/FilingBugs for bug reporting i

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

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 response to a cou

Re: On the subject of module consumer diagnostics.

On 9/6/24 9:41 AM, Ben Boeckel wrote: On Fri, Sep 06, 2024 at 09:30:26 -0400, David Malcolm wrote: On Fri, 2024-09-06 at 08:44 -0400, Ben Boeckel via Gcc wrote: Does this have (additional) implications for caching tools and modules? They cache diagnostic output, but if these other paths showing

Re: On the subject of module consumer diagnostics.

On 9/3/24 11:53 AM, Iain Sandoe wrote: On 3 Sep 2024, at 16:08, Jason Merrill via Gcc wrote: On 9/3/24 7:30 AM, Jonathan Wakely wrote: On Tue, 3 Sept 2024, 10:15 Iain Sandoe, mailto:i...@sandoe.co.uk>> wrote: Hi Folks, When we build a C++ binary module (CMI/BMI), we obviousl

Re: On the subject of module consumer diagnostics.

On 9/3/24 7:30 AM, Jonathan Wakely wrote: On Tue, 3 Sept 2024, 10:15 Iain Sandoe, > wrote: Hi Folks, When we build a C++ binary module (CMI/BMI), we obviously have access to its source to produce diagnostics, all fine. However, when we consume that mod

Re: GCC 14.2 Release Candidate available from gcc.gnu.org

On Mon, Jul 29, 2024 at 4:34 AM Richard Biener wrote: > On Sun, Jul 28, 2024 at 11:46 PM Jason Merrill via Gcc > wrote: > > > > Since the RC I've fixed a few 14/15 C++ regressions with extremely safe > > patches, and wonder what you think about pushing them to t

Re: GCC 14.2 Release Candidate available from gcc.gnu.org

Since the RC I've fixed a few 14/15 C++ regressions with extremely safe patches, and wonder what you think about pushing them to the branch at this point: 115583, 115986, 115561 Sorry these came so late. Jason On Tue, Jul 23, 2024 at 8:51 AM Jakub Jelinek via Gcc wrote: > The first release ca

Re: consistent unspecified pointer comparison

On Thu, Jun 27, 2024 at 2:38 PM Richard Biener wrote: > > Am 27.06.2024 um 19:04 schrieb Jason Merrill via Gcc : > > > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html > > proposes to require that repeated unspecified comparisons be > > s

consistent unspecified pointer comparison

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2434r1.html proposes to require that repeated unspecified comparisons be self-consistent, which does not match current behavior in either GCC or Clang. The argument is that the current allowance to be inconsistent is user-unfriendly and doe

Re: configure adds -std=gnu++11 to CXX variable

On Wed, May 29, 2024 at 1:34 PM Tom Tromey wrote: > > "Jason" == Jason Merrill writes: > > Jason> Thanks, though I don't think all that code needs to go; > Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that > Jason> relies on features from a particular standard. We j

Re: configure adds -std=gnu++11 to CXX variable

On Tue, May 28, 2024 at 12:49 PM Paul Eggert wrote: > > On 2024-05-28 08:02, Jakub Jelinek wrote: > > even for C GCC updates the default > > True, but C seems to be different, in that using a later-than-default > -std=whatever is more likely to help than hurt, because the C > standardization folks

Re: configure adds -std=gnu++11 to CXX variable

On Tue, May 28, 2024 at 10:36 AM Paul Eggert wrote: > > On 2024-05-28 01:20, Jonathan Wakely wrote: > > I am not aware of any distro ever changing the default -std setting for g++ > > or clang++. Are you attempting to solve a non-problem, but introducing new > > ones? > > If it's a non-problem for

Re: Updated Sourceware infrastructure plans

On 5/1/24 12:15, Jeff Law wrote: On 4/22/24 9:24 PM, Tom Tromey wrote: Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it.  We tried to integrate it into the traditional gdb development style, having it send email

Re: 1.76% performance loss in VRP due to inlining

On 4/30/24 12:22, Jakub Jelinek wrote: On Tue, Apr 30, 2024 at 03:09:51PM -0400, Jason Merrill via Gcc wrote: On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc wrote: In implementing prange (pointer ranges), I have found a 1.74% slowdown in VRP, even without any code path actually using

Re: 1.76% performance loss in VRP due to inlining

On Fri, Apr 26, 2024 at 5:44 AM Aldy Hernandez via Gcc wrote: > > In implementing prange (pointer ranges), I have found a 1.74% slowdown > in VRP, even without any code path actually using the code. I have > tracked this down to irange::get_bitmask() being compiled differently > with and without

Re: Updated Sourceware infrastructure plans

On Mon, Apr 22, 2024 at 11:24 PM Tom Tromey wrote: > Jason> Someone mentioned earlier that gerrit was previously tried > Jason> unsuccessfully. > > We tried it and gdb and then abandoned it. We tried to integrate it > into the traditional gdb development style, having it send email to > gdb-patc

Re: Updated Sourceware infrastructure plans

On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote: > > "Frank" == Frank Ch Eigler writes: > > >> [...] I suggest that a basic principle for such a system is that it > >> should be *easy* to obtain and maintain a local copy of the history > >> of all pull requests. That includes all version

Re: How to get the default values for parameters?

On Wed, Apr 3, 2024 at 9:35 AM Hanke Zhang via Gcc wrote: > > Hi, > I'm trying to get the default values for parameters of some functions > in my GIMPLE-PASS. The example code is here: > > enum { > edefault1 = 1, > edefault2 = 2, > edefault3 = 3 > } > > void func(int p0, int p1 = edefault1,

Re: Patches submission policy change

On Wed, Apr 3, 2024 at 6:23 AM Jan Beulich via Gcc wrote: > On 03.04.2024 10:57, Richard Biener wrote: > > On Wed, 3 Apr 2024, Jan Beulich wrote: > >> On 03.04.2024 10:45, Jakub Jelinek wrote: > >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > Any concerns/objections? >

Re: AutoFDO tools for GCC

On Tue, Mar 26, 2024 at 6:41 PM Andi Kleen via Gcc wrote: > > On Tue, Mar 26, 2024 at 08:45:22AM +0100, Richard Biener wrote: > > On Mon, Mar 25, 2024 at 9:54 PM Eugene Rozenfeld via Gcc > > wrote: > > > > > > Hello, > > > > > > I've been the AutoFDO maintainer for the last 1.5 years. I've resurr

Re: Improvement of CLOBBER descriptions

On 2/21/24 10:43, Michael Matz wrote: Hello, On Wed, 21 Feb 2024, Daniil Frolov wrote: Following the recent introduction of more detailed CLOBBER types in GCC, a minor inconsistency has been identified in the description of CLOBBER_OBJECT_BEGIN: /* Beginning of object lifetime, e.g. C++ co

Re: lambda coding style

On 1/11/24 12:48, Martin Jambor wrote: On Wed, Jan 10 2024, Jason Merrill via Gcc wrote: What formatting style do we want for non-trivial lambdas in GCC sources? I'm thinking the most consistent choice would be auto l = [&] (parms) // space between ] ( { // bra

Re: lambda coding style

On 1/10/24 16:41, Marek Polacek wrote: On Wed, Jan 10, 2024 at 04:24:42PM -0500, Jason Merrill wrote: On 1/10/24 15:59, Marek Polacek wrote: On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote: What formatting style do we want for non-trivial lambdas in GCC sources? I&#

Re: lambda coding style

On 1/10/24 15:59, Marek Polacek wrote: On Wed, Jan 10, 2024 at 02:58:03PM -0500, Jason Merrill via Gcc wrote: What formatting style do we want for non-trivial lambdas in GCC sources? I'm thinking the most consistent choice would be auto l = [&] (parms) // spac

lambda coding style

What formatting style do we want for non-trivial lambdas in GCC sources? I'm thinking the most consistent choice would be auto l = [&] (parms) // space between ] ( { // brace on new line, indented two spaces return stuff; }; By default, recent emacs lines up the { with

Re: Deprecating -fgnu-tm support for GCC 14 and removing it for GCC 15

On Mon, Dec 18, 2023 at 3:04 AM Richard Biener via Gcc wrote: > On Mon, Dec 18, 2023 at 2:35 AM Andrew Pinski via Gcc > wrote: > > > > On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager > wrote: > > > > > > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc > wrote: > > > > > > > > -fgnu-tm supp

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

On 10/23/23 11:16, David Malcolm wrote: 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 determines whe

Re: Documenting common C/C++ options

On Tue, Oct 10, 2023 at 7:12 AM Florian Weimer via Gcc wrote: > * Richard Earnshaw: > > > On 10/10/2023 11:46, Richard Earnshaw (lists) via Gcc wrote: > >> On 10/10/2023 10:47, Florian Weimer via Gcc wrote: > >>> Currently, -fsigned-char and -funsigned-char are only documented as C > >>> language

Re: C89 question: Do we need to accept -Wint-conversion warnings

On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc wrote: > Are these code fragments valid C89 code? > > int i1 = 1; > char *p1 = i; > > char c; > char *p2 = &c; > int i2 = p2; > > Or can we generate errors for them even with -std=gnu89? > > (It will still be possible to override th

Re: [PATCH v8 0/4] P1689R5 support

On 9/1/23 09:04, Ben Boeckel wrote: Hi, This patch series adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ord

Re: [PATCH v7 2/4] p1689r5: initial support

On 7/2/23 12:32, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: - `-fdeps-for

Re: Mapping of TREE_CODE to tree_node

On Fri, Aug 11, 2023 at 7:31 PM Aaron Lorey via Gcc wrote: > Am Mo., 3. Juli 2023 um 02:50 Uhr schrieb Andrew Pinski >: > > > > On Sun, Jul 2, 2023 at 5:48 PM Aaron Lorey via Gcc > wrote: > > > > > > Am Mo., 26. Juni 2023 um 20:09 Uhr schrieb David Malcolm < > dmalc...@redhat.com>: > > > > > >

Re: Weak attribute function limitation

On 8/10/23 05:22, Ashraf, Islam via Gcc wrote: I have a question regarding a limitation in gcc which is when I use gcc to link my main.o file with 2 .so files each one has a function with the same name but one of them has it with the __attribute__(weak) and I call this function from main.o the

Re: GCC support for extensions from later standards

On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser wrote: > Hi everyone! > > I'm working on libc++ and we are currently discussing using language > extensions from later standards ( > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > By that I mean th

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 7/23/23 20:26, Ben Boeckel wrote: On Fri, Jul 21, 2023 at 16:23:07 -0400, Nathan Sidwell wrote: It occurs to me that the model I am envisioning is similar to CMake's object libraries. Object libraries are a convenient name for a bunch of object files. IIUC they're linked by naming the indivi

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 6/25/23 12:36, Ben Boeckel wrote: On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote: On 6/22/23 22:45, Ben Boeckel wrote: On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote: On 1/25/23 16:06, Ben Boeckel wrote: They affect the build, so report them via `-MF` mechanisms.

Re: [PATCH 1/1] libcpp: allow UCS_LIMIT codepoints in UTF-8 strings

On 6/21/23 14:58, Ben Boeckel wrote: libcpp/ * charset.cc: Allow `UCS_LIMIT` in UTF-8 strings. Reported-by: Damien Guibouret Fixes: c1dbaa6656a (libcpp: reject codepoints above 0x10, 2023-06-06) Signed-off-by: Ben Boeckel Applied, moving the Fixes line up and changing the commit

Re: [PATCH v5 3/5] p1689r5: initial support

On 6/20/23 15:46, Ben Boeckel wrote: On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: On 1/25/23 13:06, Ben Boeckel wrote: Header units (including the standard library headers) are 100% unsupported right now because the `-E` mechanism wants to import their BMIs. A new mode (i.e.,

Re: [PATCH v5 5/5] c++modules: report module mapper files as a dependency

On 1/25/23 16:06, Ben Boeckel wrote: It affects the build, and if used as a static file, can reliably be tracked using the `-MF` mechanism. Hmm, this seems a bit like making all .o depend on the Makefile; it shouldn't be necessary to rebuild all TUs that use modules when we add another module

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 1/25/23 16:06, Ben Boeckel wrote: They affect the build, so report them via `-MF` mechanisms. Why isn't this covered by the existing code in preprocessed_module? gcc/cp/ * module.cc (do_import): Report imported CMI files as dependencies. Signed-off-by: Ben Boeckel ---

Announcing GCC Code of Conduct

I am pleased to announce that the GCC Steering Committee has decided to adopt a Code of Conduct (https://gcc.gnu.org/conduct.html) for interactions in GCC project spaces, including mailing lists, bugzilla, and IRC. The vast majority of the time, the GCC community is a very civil, cooperative space

Re: [PATCH v6 0/4] P1689R5 support

On 6/17/23 10:43, Ben Boeckel wrote: On Fri, Jun 16, 2023 at 23:55:53 -0400, Jason Merrill wrote: I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g. FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) Excess errors: /home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.

Re: [PATCH v6 1/4] libcpp: reject codepoints above 0x10FFFF

On 6/6/23 16:50, Ben Boeckel wrote: Unicode does not support such values because they are unrepresentable in UTF-16. Pushed. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints and therefore all Unicode rejects

Re: [PATCH v5 3/5] p1689r5: initial support

On 5/12/23 10:24, Ben Boeckel wrote: On Tue, Feb 14, 2023 at 16:50:27 -0500, Jason Merrill wrote: I notice that the actual flags are all -fdep-*, though some of them are -fdeps-* here, and the internal variables all seem to be fdeps_*. I lean toward harmonizing on "deps", I think. Done. I d

Re: [PATCH v6 0/4] P1689R5 support

On Fri, Jun 16, 2023 at 3:49 PM Ben Boeckel wrote: > > On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > > This patch series causes ICEs on arm-linux-gnueabihf. Would you > > please investigate? Please let me know if you need any in reproducing > > these. > > Finally back at it. I

Re: Targetting p0847 for GCC14 (explicit object parameter)

On Thu, Jun 8, 2023 at 3:54 AM Jonathan Wakely via Gcc wrote: > On Thu, 8 Jun 2023, 05:07 waffl3x via Gcc, wrote: > > > I would like to boldly suggest implementing P0847 should be targeted at > > GCC14. In my anecdotal experiences, this feature is very important to > > people, and very important

Re: Will GCC eventually support correct code compilation?

On Sat, May 27, 2023 at 2:15 PM Dave Blanchard wrote: > If nobody wants to have detailed discussions about the technical workings > of a very serious tool that millions are relying on day in and day out, > what is this mailing list FOR, exactly? > For discussions, absolutely. Not for Usenet-sty

Re: LSP based on GCC

On Wed, May 17, 2023 at 11:47 AM David Malcolm via Gcc wrote: > On Wed, 2023-05-17 at 17:28 +0300, Eli Zaretskii via Gcc wrote: > > Dear GCC developers, > > [CCing Frank, re the systemtap LSP implementation] > > Hi Eli > > > Emacs 29, to be released soon, will come with a built-in client for > >

Re: More C type errors by default for GCC 14

On Tue, May 16, 2023 at 3:06 AM Florian Weimer via Gcc wrote: > * Eric Gallager via Gcc: > > > I support this plan for using -Werror= and having it be split based on > > whether -std= is set to a strict ANSI option or a GNU option; is there > > a way to do that in the optfiles, or would it have t

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: > > * Joseph Myers: > > > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > > > >> That is not the case we are discussing, AFAIU. Or at least no one has > >> yet explained why accepting those old K&R programs will adversely > >> affect the

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 9:20 AM Po Lu via Gcc wrote: > Yes, just these quotes from a former GCC maintainer: > > In C, we cannot divide all user code into "right" and "wrong" in this > kind of simple way, and certainly not based on the ISO standard. That > standard is just the decisions of a

Re: More C type errors by default for GCC 14

On Thu, May 11, 2023 at 10:39 PM Po Lu via Gcc wrote: > > Eli Schwartz writes: > > > This discussion thread is about having very good technical reasons -- as > > explained multiple times, including instances where you agreed that the > > technical reasons were good. > > > > Furthermore, even desp

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 7:28 PM Jonathan Wakely via Gcc wrote: > On Thu, 11 May 2023 at 00:18, James K. Lowden > wrote: > > > > On Tue, 9 May 2023 23:45:50 +0100 > > Jonathan Wakely via Gcc wrote: > Technically, the standard only requires a diagnostic, and a warning is > a diagnostic. So stric

Re: More C type errors by default for GCC 14

On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc wrote: > > * Richard Biener: > > > > Am 09.05.2023 um 18:13 schrieb David Edelsohn : > > > > > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc > > > wrote: > > > > > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc

Re: GCC 12.3 Release Candidate available from gcc.gnu.org

My patch for 106890 caused 109666, so I'd like to revert the 106890 patch (r12-9441-g94569d91bd4c60) for 12.3. Jason On Tue, May 2, 2023 at 4:10 AM Richard Biener via Gcc wrote: > The first release candidate for GCC 12.3 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/12.3-RC-202305

Tobias Burnus as OpenMP and libgomp reviewer

I am pleased to announce that the GCC Steering Committee has appointed Tobias Burnus as an additional OpenMP and libgomp maintainer. Tobias, please update your listing in the MAINTAINERS file. Cheers, Jason

Re: [PATCH v5 3/5] p1689r5: initial support

On 1/25/23 13:06, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Thanks again. Support is communicated through the following three new fla

Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies

On 1/25/23 13:06, Ben Boeckel wrote: They affect the build, so report them via `-MF` mechanisms. gcc/cp/ * module.cc (do_import): Report imported CMI files as dependencies. Both this and the mapper dependency patch seem to cause most of the modules testcases to crash; please

Re: [PATCH v5 1/5] libcpp: reject codepoints above 0x10FFFF

On 1/25/23 13:06, Ben Boeckel wrote: Unicode does not support such values because they are unrepresentable in UTF-16. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints and therefore all Unicode rejects such value

Re: struct vs. class in GCC source

On Tue, Jan 10, 2023 at 9:51 AM Paul Koning via Gcc wrote: > Building on Mac with Clang I get warnings like this: > > ../../../gcc/gcc/cgraph.h:2629:28: warning: struct 'cgraph_edge' was > previously declared as a class; this is valid, but may result in linker > errors under the Microsoft C++ ABI

Re: Contribution

Hi, thanks for your interest. There are some ideas at https://gcc.gnu.org/wiki/EasyHacks You might also look at Bugzilla PRs with a lot of interest, particularly with severity of "enhancement". In the search results screen you can display the number of CCs and duplicates using the "change column

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Sat, Nov 12, 2022 at 7:44 PM Paul Eggert wrote: > On 2022-11-11 07:11, Aaron Ballman wrote: > > Clang doesn't require such a linker (we work with various system > linkers). > > As long as the system linkers continue to work as they have > traditionally worked, we're fine. > > > the frontend pe

Re: [PATCH v3 1/3] libcpp: reject codepoints above 0x10FFFF

On 11/8/22 16:10, Ben Boeckel wrote: Unicode does not support such values because they are unrepresentable in UTF-16. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints and therefore all Unicode rejects such value

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

On 11/8/22 16:10, Ben Boeckel 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 determines whether a C string is valid UTF-8 or not. * internal.

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

On 10/27/22 13:16, Ben Boeckel wrote: This simplifies the interface for other UTF-8 validity detections when a simple "yes" or "no" answer is sufficient. Signed-off-by: Ben Boeckel --- libcpp/ChangeLog | 6 ++ libcpp/charset.cc | 18 ++ libcpp/internal.h | 2 ++ 3 fi

Re: [PATCH v2 1/3] libcpp: reject codepoints above 0x10FFFF

On 10/27/22 13:16, Ben Boeckel wrote: Unicode does not support such values because they are unrepresentable in UTF-16. Signed-off-by: Ben Boeckel --- libcpp/ChangeLog | 6 ++ libcpp/charset.cc | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/libcpp/ChangeLog b/l

Re: Ping (c,c++): Handling of main() function for freestanding

On 10/23/22 07:54, Arsen Arsenović via Gcc-patches wrote: On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote: I have no objections to the C changes. Great! Thanks for the review. I don't have push rights currently, so I must ask that someone else pushes this patch for me. Have a gr

Re: [PATCH RESEND 1/1] p1689r5: initial support

On 10/20/22 13:31, Ben Boeckel wrote: On Thu, Oct 20, 2022 at 11:39:25 -0400, Jason Merrill wrote: Oops, I was thinking this was in gcc as well. In libcpp there's _cpp_valid_utf8 (which calls one_utf8_to_cppchar). This routine has a lot more logic (including UCN decoding) and the `one_utf8_to

Re: [PATCH RESEND 1/1] p1689r5: initial support

On 10/18/22 08:18, Ben Boeckel wrote: On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote: On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote: Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc? I can look at factoring that out. I'll have to decode its logi

Re: [RFC] c++, libstdc++: Default make check vs. tests for newest C++ standard

On 10/19/22 04:40, Jakub Jelinek wrote: Hi! The screw-up on my side with libstdc++ testing (tested normally rather than in C++23 mode) makes me wonder if we couldn't tweak the default testing. Dunno what libstdc++ testing normally does (just C++17?), make check-g++ tests by default { 98, 14, 17,

Re: Handling of main() function for freestanding

On 10/14/22 06:04, Arsen Arsenović wrote: On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote: I liked in the previous version that you checked the return type of main when !flag_hosted, here and in c_missing_noreturn_ok_p. Let's bring that back. Ah, right; I forgot about that. Wha

Re: Handling of main() function for freestanding

On 10/13/22 16:14, Arsen Arsenović wrote: On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote: I was arguing that we don't need the new flag; there shouldn't be any need to turn it off. At the time, I opted to go with a more conservative route; I haven't been around enough to have ve

Re: Handling of main() function for freestanding

On 10/13/22 13:02, Arsen Arsenović wrote: Hi, On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote: * gcc.dg/noreturn-4.c: Likewise. I'd be inclined to drop this test. That seems like an odd choice, why do that over using another function for the test case? (there's nothing sp

Re: [PATCH RESEND 1/1] p1689r5: initial support

On 10/4/22 11:12, Ben Boeckel wrote: This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Thanks! Support is communicated through the following three new flags: -

Re: [PATCH RESEND 0/1] RFC: P1689R5 support

On 10/4/22 11:11, Ben Boeckel wrote: This patch adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ordered to ens

Re: Handling of main() function for freestanding

On 10/7/22 07:30, Jonathan Wakely wrote: On Tue, 4 Oct 2022 at 23:25, Jason Merrill wrote: On 9/28/22 16:15, Jonathan Wakely wrote: As part of implementing a C++23 proposal [1] to massively increase the scope of the freestanding C++ standard library some questions came up about the special ha

Re: Handling of main() function for freestanding

On 9/28/22 16:15, Jonathan Wakely wrote: As part of implementing a C++23 proposal [1] to massively increase the scope of the freestanding C++ standard library some questions came up about the special handling of main() that happens for hosted environments. As required by both C++ (all versions)

Re: Usage of the C++ stdlib unordered_map in GCC

On Wed, Aug 31, 2022 at 5:38 AM Jonathan Wakely via Gcc wrote: > On Tue, 30 Aug 2022 at 21:08, Marek Polacek via Gcc > wrote: > > > > On Tue, Aug 30, 2022 at 09:57:45PM +0200, Tim Lange wrote: > > > Hello, > > > > > > I was preparing a patch for GCC and used the unordered_map from the C++ > > >

Re: Can I provide a hint to gcc for return value optimization?

On Mon, Nov 15, 2021 at 3:17 AM unlvsur unlvsur via Gcc wrote: > Oh I mean copy elision. > > std::string str; > do_something(str); > return str; > > Something like this. > > Or factory function: > std::string foo() > { > return factory(a.begin(),a.end()); > } > Neither return should involve a co

Re: how can I contribute to your organisation

On Mon, Sep 27, 2021 at 9:54 AM Aditya Saini wrote: > Hey ,I am Aditya saini and I can code in c/c++ .I want to be a part of > your organization so please guide me how can I contribute to your > organization . > There's a lot of information at https://gcc.gnu.org/contribute.html Let us know

Re: gcc_assert() and inhibit_libc

On Mon, Aug 16, 2021 at 9:51 AM Sebastian Huber wrote: > > On 16/08/2021 14:33, Martin Liška wrote: > > On 8/12/21 4:31 PM, Sebastian Huber wrote: > >> This would be suitable for me, however, I am not sure if you want such > >> a customization feature just for a niche operating system. > > > > I d

Re: gcc_assert() and inhibit_libc

On Thu, Jul 22, 2021 at 8:18 AM Richard Biener via Gcc wrote: > > On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber > wrote: > > > > Hello, > > > > while testing this patch > > > > https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking > > > > I noticed that __gcov_info_to_g

Re: rust frontend and UTF-8/unicode processing/properties

On Sun, Jul 18, 2021 at 1:13 PM Ian Lance Taylor via Gcc wrote: > On Sun, Jul 18, 2021 at 6:23 AM Mark Wielaard wrote: > > > > For the gcc rust frontend I was thinking of importing a couple of > > gnulib modules to help with UTF-8 processing, conversion to/from > > unicode codepoints and determi

Re: where is PRnnnn required again?

On Wed, Jul 7, 2021 at 1:54 PM Jakub Jelinek via Gcc wrote: > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote: > > I came away from the recent discussion of ChangeLogs requirements > > with the impression that the PR bit should be in the subject > > (first) line and also

Re: [RFC][PATCH] contrib: add git-commit-mklog wrapper

On 6/22/21 3:30 AM, Martin Liška wrote: Hello. There's a patch candidate that comes up with a wrapper for 'git commit-mklog' alias. Using my patch, one can do: $ git commit-mklog -a -b 12345, Thoughts? Looks good to me. Can one do that without the wrapper script and passing data throu

Hongtao Liu as x86 vectorization maintainer

I am pleased to announce that the GCC Steering Committee has appointed Hongtao Liu as maintainer of the i386 vector extensions in GCC. Hongtao, please update your listing in the MAINTAINERS file. Cheers, Jason

Re: [Patch] contrib/mklog.py: Improve PR handling (was: git gcc-commit-mklog doesn't extract PR number to ChangeLog)

On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus wrote: > On 18.06.21 11:32, Richard Earnshaw via Gcc wrote: > > On 17/06/2021 18:21, Jakub Jelinek wrote: > >> mklog as is doesn't fill in the details (descriptions of the changes > >> to each function etc.), nor is realiable in many cases, and with J

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Thu, Jun 17, 2021 at 1:14 PM Joseph Myers wrote: > On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote: > > > It seems a bit dangerous to me to rely on just extracting PR numbers from > > tests. What if the patch is just adjusting a test to make it compatible > with > > the remainder of the c

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/16/21 9:01 PM, Martin Sebor wrote: On 6/16/21 6:40 PM, Jason Merrill wrote: On 6/16/21 8:17 PM, Martin Sebor wrote: On 6/16/21 5:45 PM, Jason Merrill wrote: On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:     On 6/16/21 2:49 PM, Jason Merrill wrote: >

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/16/21 8:17 PM, Martin Sebor wrote: On 6/16/21 5:45 PM, Jason Merrill wrote: On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:     On 6/16/21 2:49 PM, Jason Merrill wrote: > On 6/15/21 11:42 PM, Jason Merrill wrote: >> On Tue, Jun 15, 2021 at 10:04 PM

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor wrote: > On 6/16/21 2:49 PM, Jason Merrill wrote: > > On 6/15/21 11:42 PM, Jason Merrill wrote: > >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc >> > wrote: > >> > >> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On 6/15/21 11:42 PM, Jason Merrill wrote: On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc > wrote: On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc wrote: > On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote: > > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote: > > > >> On 6/11/21 11:32 AM, Jonathan Wakely wrote: > >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote: > My objection is to

Re: GCC/clang warning incompatibility with unused private member variables

On Fri, Jun 11, 2021 at 4:03 PM Jason Merrill wrote: > On 6/11/21 3:37 PM, Markus Faehling wrote: > > Hello, > > > > I'm currently facing a problem where I cannot get both gcc and clang > > warning-free simultaneously in my project. My code looks somewhat like > > this: > > > > class Test { > >

Re: GCC/clang warning incompatibility with unused private member variables

On 6/11/21 3:37 PM, Markus Faehling wrote: Hello, I'm currently facing a problem where I cannot get both gcc and clang warning-free simultaneously in my project. My code looks somewhat like this: class Test {     int a_;     void b() {}; }; This code gives me the(usually very useful) "-Wu

Re: Update to GCC copyright assignment policy

On Mon, Jun 7, 2021 at 12:12 PM Giacomo Tesio wrote: > > > On June 7, 2021 3:45:49 PM UTC, Jason Merrill wrote: > > On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio > > wrote: > > > > > > So, a few extra copyright holders under DCO instead of assignment > > > > to FSF will not really change anythin

Re: Update to GCC copyright assignment policy

On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio wrote: > On June 7, 2021 2:44:56 PM UTC, Jakub Jelinek wrote: > > > > Nonsense. GCC codebase doesn't have a single copyright holder for > > decades, just look at the source. > > > > libffi has various copyright holders > > include/hsa* has AMD as cop

  1   2   >