Mark Mitchell wrote:
> We had a discussion about this a while back:
>
> http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html
Ah right, I forgot about that. Thanks.
Joseph S. Myers wrote:
There's an additional issue to deal with now: proposals to include some
form of attributes in C++0x and C1x and
Mark Mitchell wrote:
That seems reasonable to me. The transparent_union trick (copying the
fields, along with making a new TYPE_MAIN_VARIANT) might work, but even
there you have to worry about making sure you a different type_info
object, how do you mangle the name, etc. You're also likely to g
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage.
...if you try to use U as an argument type to a function with C++ linkage.
Jason
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage. Perhaps that's why
build_duplicate_type got broken.
Actually, this happens re
Was there a decision somewhere to require ChangeLog entries for all
testcase changes now, as the hook is enforcing? They were optional before.
remote: *** ChangeLog format failed:
remote: ERR: changed file not mentioned in a
ChangeLog:"gcc/testsuite/g++.dg/parse/error33.C"
On Thu, May 21, 2020 a
On Thu, May 21, 2020 at 2:58 PM Martin Liška wrote:
> On 5/21/20 8:52 PM, Jason Merrill wrote:
> > Was there a decision somewhere to require ChangeLog entries for all
> testcase changes now, as the hook is enforcing? They were optional before.
>
> Right now we ignore new
On Thu, May 21, 2020 at 4:27 PM Martin Liška wrote:
> On 5/21/20 9:51 PM, Jason Merrill wrote:
> > Modified. Adjustments to expected errors in testcases don't seem to me
> worth documenting in a ChangeLog.
>
> I see. As Jakub mentioned, I would keep the hook stricter fo
On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
>
> On 5/15/20 3:22 PM, Marek Polacek wrote:
> > On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> >> On 5/15/20 2:42 PM, Marek Polacek wrote:
> >>> I actually use mklog -i all the time. But I can work around it if it
> >>> disapp
On Thu, May 21, 2020 at 6:03 PM Jason Merrill wrote:
>
> On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
> >
> > On 5/15/20 3:22 PM, Marek Polacek wrote:
> > > On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> > >> On 5/15/20 2:42 PM,
On Mon, May 25, 2020 at 5:23 AM Martin Liška wrote:
>
> On 5/22/20 11:01 PM, Jason Merrill wrote:
> > On Thu, May 21, 2020 at 6:03 PM Jason Merrill wrote:
> >>
> >> On Fri, May 15, 2020 at 11:39 AM Martin Liška wrote:
> >>>
> >>> On 5/15/
On Tue, May 26, 2020 at 11:38 AM Martin Sebor wrote:
> On 5/26/20 7:14 AM, Martin Liška wrote:
> > On 5/26/20 3:11 PM, Richard Earnshaw wrote:
> >> On 26/05/2020 14:09, Martin Liška wrote:
> >>> On 5/26/20 1:18 PM, Richard Earnshaw wrote:
> On 26/05/2020 12:14, Martin Liška wrote:
> > On
On Wed, Apr 14, 2021 at 8:08 AM Richard Biener via Gcc wrote:
> On April 14, 2021 12:19:16 PM GMT+02:00, Jonathan Wakely via Gcc
> wrote:
> >N.B. Jeff is no longer @redhat.com so I've changed the CC
> >On Wed, 14 Apr 2021 at 11:03, Thomas Koenig
> >wrote:
> >> - All gfortran developers move to
On Fri, Apr 16, 2021 at 10:49 AM Christopher Dimech via Gcc
wrote:
> > Sent: Saturday, April 17, 2021 at 1:03 AM
> > From: "Ville Voutilainen"
> > To: "Christopher Dimech"
> > Cc: "GCC Development"
> > Subject: Re: A suggestion for going forward from the RMS/FSF debate
> >
> > On Fri, 16 Apr 20
On Tue, Apr 20, 2021 at 8:31 PM Martin Sebor via Gcc wrote:
>
> On 4/20/21 5:03 PM, Martin Sebor wrote:
> > On 4/20/21 4:15 PM, Martin Sebor wrote:
> >> On 4/20/21 2:36 PM, Martin Sebor wrote:
> >>> On 4/20/21 2:13 PM, Marek Polacek wrote:
> On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Se
On Fri, Apr 23, 2021 at 5:13 AM Martin Liška wrote:
>
> Few weeks ago, I noticed we have a new remote branch that follows
> origin/master:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/trunk
>
> Do we know who added it? And what was the motivation?
I did; I've always preferred tha
On Fri, Apr 23, 2021 at 7:55 AM Jakub Jelinek wrote:
>
> Status
> ==
>
> GCC 8.5 release and closing of the 8 branch is several months overdue,
> we don't have enough time to maintain trunk and 4 supported release branches.
> Therefore, I'd like to do 8.5-rc1 on 7th of May and release 8.5 and
I understand that the difference between the _ macro and the N_ macro is
that the former is used to force a gettext call on the argument and the
latter is used for strings for which gettext will be called later. But I
don't see any documentation about why/when we should use the G_ macro
instead of
On 5/13/21 6:13 PM, Jakub Jelinek wrote:
On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote:
I understand that the difference between the _ macro and the N_ macro is
that the former is used to force a gettext call on the argument and the
latter is used for strings for which
On 5/14/21 3:41 AM, Jakub Jelinek wrote:
On Thu, May 13, 2021 at 08:56:39PM -0400, Jason Merrill wrote:
>From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 13 May 2021 20:53:50 -0400
Subject: [PATCH] intl: add comments to _, N_, and G_
To:
Sorry, just pushed 3 patches before I noticed this. They're safe but not
critical, should I back them out?
On Wed, May 19, 2021 at 4:06 AM Richard Biener wrote:
>
> Status
> ==
>
> The GCC 9 branch is now frozen for the upcoming GCC 9.4 release.
> I will announce a first release candidate s
On Mon, May 24, 2021 at 9:25 AM Philip Herron
wrote:
> Hi everyone,
>
> As some of you might know, I have been working on GCC Rust over on
> GitHub https://github.com/Rust-GCC/gccrs. As the project is moving
> forward and enforcing GCC copyright assignments for contributors, I
> would like to cre
PR100797 seems like a P1 regression from 9.3, I'd like to fix it before the
release.
On Tue, May 25, 2021 at 5:36 PM William Seurer via Gcc
wrote:
> Bootstrapped and tested it on powerpc64 power 7 and 8 BE and 8, 9, and
> 10 LE and saw nothing untoward.
>
> On 5/19/21 5:28 AM, Richard Biener wro
On 5/27/21 11:59 PM, Jason Merrill wrote:
PR100797 seems like a P1 regression from 9.3, I'd like to fix it before
the release.
Here's a candidate patch. Going to bed now.
Jason
>From c5e228d0b49154e78feb8f64659ce491bdf118c1 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu
On Tue, Jun 1, 2021 at 10:52 AM D. Hugh Redelmeier wrote:
> | From: Mark Wielaard
>
> | This seems a pretty bad policy to be honest.
> | Why was there no public discussion on this?
>
> Agreed. I also agree with the rest of Mark's message.
>
> (Note: I haven't contributed to GCC but I have contr
On Tue, Jun 1, 2021 at 11:15 AM Jose E. Marchesi via Gcc
wrote:
>
> > GCC was created as part of the GNU Project but has grown to operate as
> > an autonomous project.
> >
> > The GCC Steering Committee has decided to relax the requirement to
> > assign copyright for all changes to the Free Softw
On Wed, Jun 2, 2021 at 4:10 AM Mark Wielaard wrote:
> On Tue, Jun 01, 2021 at 11:05:24AM -0400, Richard Kenner wrote:
> > > > What about the parts of GCC with FSF copyrights that are not covered
> by
> > > > the GPL, but the GPL with exceptions? How is it possible to move
> code
> > > > between
On Wed, Jun 2, 2021 at 4:18 AM Mark Wielaard wrote:
> Hi Thomas,
>
> On Tue, Jun 01, 2021 at 12:58:12PM -0700, Thomas Rodgers wrote:
> > On 2021-06-01 07:28, Mark Wielaard wrote:
> > > If we no longer want the FSF to be the legal guardian and copyright
> > > holder for GCC could we please find an
On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio wrote:
>
> I would have really appreciated if the GCC SC had announced such change
> for the upcoming GCC 12 while sticking to the old policy in GCC 11.
>
That is how I was thinking of the change, but I agree that it needs
clarification.
Jason
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
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 assignmen
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
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 l
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
On 6/15/21 11:42 PM, Jason Merrill wrote:
On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc <mailto:gcc@gcc.gnu.org>> 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,
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 >> <mailto:gcc@gcc.gnu.org>> wrote:
> >>
> >&g
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 <mailto:mse...@gmail.com>> 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
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 <mailto:mse...@gmail.com>> wrote:
On 6/16/21 2:49 PM, Jason Merr
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
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
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
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
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
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
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
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
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
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
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++
> > >
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)
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
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
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:
-
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'
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
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
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,
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 decod
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) an
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
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.
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
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
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
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
---
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
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
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
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
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
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
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
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>:
> > > >
> >
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
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
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
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
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
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
401 - 500 of 528 matches
Mail list logo
