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
en making a lot of
improvements to GCC diagnostic output lately and is generally in charge of
diagnostics.
Jason
rting
instructions.
Jason
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
ponse to a couple of different
patches that could have been simplified in C++14, but am failing to find
those messages now.
Jason
ably the
same, but I haven't been in its code myself to know.
Certainly these tools are complicated when the preprocessor output isn't
enough to reproduce the compilation. It might be nice to have some
combined preprocessed form of the primary translation unit and any
interface units it depends on...
Jason
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
r or not embedding source files) (security concerns) are not technically
mutually exclusive. The fundamental technical problem may be that clang require
to open the actual file during the compilation. It looks like both GCC and MSVC
doesn’t have the problem.
Sounds like the primary motivation for this clang change doesn't apply
to GCC.
Jason
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
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
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
does not enable significant
optimizations. Any feedback about this?
Jason
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&
C++
> >> > version as that's more likely to hurt than help.
> >
> > Yes.
>
> OK, thanks, I installed the attached.
Thanks, though I don't think all that code needs to go;
AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that
relies on features from a particular standard. We just don't want
AC_PROG_CXX to invoke it.
Jason
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
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 i
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
inkage, which allows
inlining.
Relatedly, I wonder if we want to build GCC with -fno-semantic-interposition?
Jason
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 i
echnology; people are more or less
comfortable with their current workflow and uninclined to experiment with
someone else's new thing, even if it could eventually be a big improvement.
I think that the office hours, for both sourceware and the toolchain, offer
a better path for building enthusiasm about a new direction.
Is gerrit still installed?
Jason
ECL. And the comments say that the default values for parameters
> are encoded in the type of the function. But I can't find it.
The TYPE_ARG_TYPES of a FUNCTION_TYPE is a TREE_LIST where the
TREE_PURPOSE is the default argument.
Jason
rmine "fits the mailing list
> limits"? My mail UI (Thunderbird) doesn't show me the size of a message
> until I've actually sent it.
>
> > As a last resort
> > do a series splitting the re-generation out (but I guess this would
> > confuse the CI as well and of course for the push you want to squash
> > again).
>
> Yeah, unless the CI would only ever test full series, this wouldn't help.
> It's also imo even more cumbersome than simply stripping the generated
> file parts from emails.
>
Massive patches need special handling either way; I wouldn't lift the
mailing list limits because of this change.
I'm in favor of this change for typical patches.
Jason
wonder how much common code
> > there is
> > between the LLVM and the GCC tooling though and whether it makes sense
> > to keep it common (and working with both frontends)? The
> > pragmatic solution would have been to fork the repo on github to a
> > place not within the google group ...
>
> In tree would need convincing Google to assign the copyright.
Would it? Looks like it's under a free license (apache 2), not
everything in the tree is copyright FSF or GPL3.
Jason
ms inappropriate, as all clobbers
indicate that the target does not have a meaningful value at that point.
Probably better to use some front-end-local representation that gets
discarded by genericize.
Jason
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
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&#
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
et))
I think we probably want the same formatting for lambdas in function
argument lists, e.g.
algorithm ([] (parms)
{
return foo;
});
Any other opinions?
Jason
ry is still the subject of research
and standardization efforts, though the current proposal (wg21.link/n4923)
is significantly simpler than the earlier TS that GCC implemented. I don't
know how much of the current implementation would carry over, but I'd be
cautious about tearing everything out just yet.
Jason
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
Code Gen Options
> @section Options for Code Generation Conventions
>
> Maybe we should move them over there.
>
> But that wasn't really the direction of my question. I was wondering
> where we should document a future C version of -fpermissive.
>
My permerror patch proposes moving it to the Warning Options node, right
after -pedantic-errors.
Jason
ling, and it seems
appropriate to respect that.
I'm also (though less strongly) inclined to be permissive in C99 mode, and
only introduce the new strictness by default for C11/C17 modes.
Jason
g the compiler directly.
Thanks,
--Ben
---
v7 -> v8:
- rename `DEPS_FMT_` enum variants to `FDEPS_FMT_` to match the
associated flag
- memory leak fix in the `join` specfunc implementation (also better
comments), both from Jason
- formatting fix in `mkdeps.cc` for `write_make_modules_d
+507,117 @@ deps_write (const cpp_reader *pfile, FILE *fp, unsigned
int colmax)
make_write (pfile, fp, colmax);
}
+static void
+p1689r5_write_filepath (const char *name, FILE *fp)
This and the other p1689r5 functions need more comments, at least one at
the top explaining their purpose.
Jason
oking for.
>
> I've now managed to dump the syntax tree of the compilation unit
> (tree_function_decl.saved_tree -> tree_exp.operands ->
> tree_statement_list.nodes). Thank you very much for the help!
>
> In order to print out the original code, I need to know which program
> code was translated to the individual nodes. Is there a chance to get
> the original tokens (or the offsets in the program code file) per
> tree_node without modifying the parser?
>
Generally we try to track the corresponding source location for a lot of
things and attach them to the relevant tree nodes (EXPR_LOCATION,
DECL_SOURCE_LOCATION). In many cases there is a lot of room for
improvement in this. For instance, for a class, instead of just storing
the location of the name, we could remember the range from the class-key to
the closing brace.
Jason
glibc. As I recall the glibc ld.so used
to have the behavior you seem to expect, but was deliberately changed
many years ago to the behavior you observe, I think for performance reasons.
Jason
for this documentation.
Aaron noted that we should ask the Clang folks before using them, so they
> can evaluated whether the extension makes sense, since they might not be
> aware of them, and some might be broken. So I'd be interested whether you
> would also like us to ask whether you want to actually support these
> extensions.
>
Sounds good.
Jason
f a transitive
import changes you need to rebuild the direct import and then the importer.
I guess it shouldn't hurt to have the transitive imports in the -MF
file, as long as they aren't also in the p1689 file, so I'm not
particularly opposed to this change, but I don't see how it makes a
practical difference.
Jason
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 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/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 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 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
---
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 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
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 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.
oint it enough if you
> have the cycles.
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.C:9:1: internal
compiler error: Segmentation fault
.html ; for features not yet
implemented, the "No" links to the corresponding PR.
I definitely agree that we want the feature, but I don't expect to have
time to implement it myself for GCC 14. If you're interested in looking at
it, that's great! Please feel free to contact me with any questions.
Jason
t for Usenet-style flame wars like the one
he and you seem determined to start.
If you lead with "your work is bad and you should feel bad" that doesn't
tend to lead to constructive discussion.
Jason
? If so, which GCC
> > version is expected to have this included?
>
> I wrote that prototype, but I haven't touched it since 2017, and I
> already have more than enough other work, alas. I'm happy to help if
> someone wants to pick up the work and finish it.
>
Maybe create a BZ and gcc.gnu.org/projects entry for this work?
Jason
rming code is the
job of -pedantic(-errors).
Can you explain again why upgrading -Wint-conversion (instead of
-Wimplicit) isn't the right solution for catching these bugs? You
mentioned that this would need more changes to Fedora packages, but
wouldn't those cases also be fixing real bugs, unlike the changes needed to
avoid -Wimplicit in autoconf?
Jason
> is it in the interests of users for them to be errors by default (for C99
> > and later modes, in the cases that were valid in C89).
>
> Just to recap, those are controlled by
> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
> -Wincompatible-pointer-types, roughly in increasing order of
> compatibility impact with old sources.
What would the impact be of making -Wint-conversion an error by
default only if the types are different sizes?
Jason
to upgrade all currently enabled pedwarns to errors without also
enabling pedwarns that depend on -pedantic/-Wpedantic;
-pedantic-errors does both; -Werror=pedantic makes only the latter set
errors, which seems unlikely to be useful to anyone.)
Jason
how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4
You shouldn't have to change any of those, just configure with CC="gcc
-fwhatever".
Jason
lar diagnostics from category 3 up to
category 2, both because code that relies on these patterns has gotten
less common and using these patterns by mistake has gotten more
harmful.
Jason
set, this (some C++ and a
> C89 requirement) must be exceedingly rare because it's a subset of the
> already tiny set of -fno-gnu89-inline -std=gnu89 packages.
Another reason for -fpermissive is ease of use. So if someone just
wants to get an older package to build, they can add -fpermissive
without having to figure out more detailed flags.
Alternatively, if we go the default -Werror=various route, adding
-Wno-error without any =foo to override everything might also be
fairly convenient.
In any case, I think we want an easy answer for the second group.
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/sna
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
prototype, this change seems unneeded.
{
make_write (pfile, fp, colmax);
}
+static void
+p1689r5_write_filepath (const char *name, FILE *fp)
+{
+ if (_cpp_valid_utf8_str (name))
+{
+ fputc ('"', fp);
+ for (const char* c = name; *c; c++)
+
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:
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
ass" for
> any given type. (And then the convention would presumably be that a POD
> type is called "struct" and other types are "class".)
>
Yes, it might be worth adding -Wmismatched-tags to STRICT_WARN. Is
bootstrapping with VC++ is supported?
Jason
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
ime options
elsewhere in the thread, but the #pragma idea sounds promising, as older
compilers can just ignore it.
Jason
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 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 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 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
ave a great day!
Done, thanks.
Jason
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/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/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/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/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/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/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/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/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
fixes the
libstdc++ test FAILs.
However, after discussing this briefly with Jason it occurred to us
that if the user declares an 'int main()' function, it's a pretty big
hint that they do want main() to return an int. And so having
undefined behaviour do to a missing return isn'
benefit GCC, but the case
> against std::unordered_map is often overstated.
>
> If the question was whether to prefer std::unordered_map or
> absl::node_hash_map then I would agree that std::unordered_map is a
> bad choice. But that's not the question.
>
Generally we want to use the GCC hash_map because it works with GCC garbage
collection (and PCH). Is that not relevant to your patch?
Jason
t; }
>
Neither return should involve a copy, you don't need any extra annotation.
Jason
html
Let us know if anything is unclear.
Jason
=i686 --build=i686-redhat-linux
--enable-serial-configure
Thread model: posix
gcc version 4.9.4 (GCC)
All other compiler components built fine except libjava .
I see in :
i686-redhat-linux/libjava/classpath/config.log :
configure:25378:
/home/adm-jason/rpmbuild/BUILD/gcc-releases-gcc-4.9
ary? Are there interesting targets that don't have a trap insn?
> 3. Add a new target hook for the gcc_assert() failure. This has the same
> problem as 2. with respect to customization by system and not architecture.
>
> 4. Disable gcc_assert() if inhibit_libc is defined.
>
> 5. Use builtin __rtems__ define in tsystem.h as a hack.
6. Suppress ENABLE_RUNTIME_CHECKING when inhibit_libc.
Jason
;
> > #endif
> >
> > Who is supposed to define abort here optionally? Can this be defined for
> > example by a target configuration header like gcc/config/rtems.h?
>
> I suppose for inhibit_libc we could use __builtin_trap () (but that might
> expand to abort() on some targets)
That seems straightforward. Does it address the RTEMS concern?
Or, should we suppress ENABLE_RUNTIME_CHECKING when inhibit_libc?
Jason
vance_one_utf8_char, unicode_space,
> unicode_digits, unicode_letters, Lex::is_unicode_space, etc. But you
> probably won't be able to use the code directly, and the code in the
> gofrontend directory is also shared with GoLLVM so it can't trivially
> be moved.
>
I believe the UTF-8 handling for the C family front ends is all in libcpp;
I don't think it's factored in a way to be useful to other front ends.
Jason
return
> Once something is considered a ChangeLog part, everything after it has
> to be a valid ChangeLog entry format.
> Matching just PR component/N with random text afterwards at the start
> of line or even somewhere in the middle would trigger any time one talks
> about some
> PR in the description.
>
But this *could* accept ^PR comp/N - descr$ , it just doesn't currently.
There's certainly a lot of precedent for including the description in the
PR line in ChangeLog files.
I agree we don't want to match a PR number in the middle of the line, or
without the dash.
Jason
nd passing data through env.
variable?
The hook seems like the way to adjust the commit message, and we can't
affect its command line arguments, so we're left with environment
variables or a file somewhere for communicating to it.
Jason
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
d line in addition
>(currently, they are only extracted from the testsuite patches)
>
This bit seems unnecessary to me, since we want the commit to include tests
that identify the PR.
Martin Sebor's patch to extract the PR number from the testcase filename,
as an alternative to a comment, should be enough.
Jason
cautious about adding such automation. But
there isn't any now; the only danger is of an unrelated patch showing up in
a comment on a PR. Which we already get when I mess up the PR number in my
test (oops).
Jason
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 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 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/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,
describe.)
>
> The word that comes to mind is Technophobia. Is it wise to trust
> compilers to transform programs from their source form into
> executables? What if there are bugs in either? What about the OS?
> The whole computer, or the Internet? Our cars? Fortunately, there's
> more to gain than to lose by trusting automation. If there weren't
> human progress would be stuck sometime in the 1700's.
>
> But we're not talking about anything anywhere that sophisticated
> here: a sed script to copy and paste a piece of text in
> the description of a change from one place to another. It's been
> done a few times before with more important data than ChangeLogs.
>
git gcc-commit-mklog already automates most of the process. It could also
automate adding [PRx] to the first line. Is that what you're asking
for?
Jason
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
;
void b() {};
};
#pragma GCC diagnostic pop
But I also agree that GCC shouldn't warn here.
Jason
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
1 - 100 of 587 matches
Mail list logo
