ping
On Wed, May 20, 2020 at 3:01 PM Kito Cheng wrote:
>
> - Run gcc testsuite with qemu will print out ascii color code for
>ubsan related testcase, however several testcase didn't consider
>that, so disable colorization prevent such problem and simplify the
>process when adding te
On Mon, Jun 01, 2020 at 03:43:00PM +0800, Kito Cheng wrote:
> ping
>
>
> On Wed, May 20, 2020 at 3:01 PM Kito Cheng wrote:
> >
> > - Run gcc testsuite with qemu will print out ascii color code for
> >ubsan related testcase, however several testcase didn't consider
> >that, so disable co
Hi,
Since the co_await expression is mostly opaque to the existing
machinery, we were hiding the details of the await_resume return
value. If that needs to be wrapped in a target expression, then
emulate this with the whole co_await. Similarly, if the await
expression we build in response to co_
(resending, this didn’t appear to make it to the list)
Hi,
I had implemented a move out of rvalue refs for such ramp values (since
these are most likely to be dangling references). However this does cause
a divergence with the clang implementation - and the patch fixes that.
tested on x86_64,po
Hi
This corrects a pasto, where I copied the constraint on bare
parameter packs from the co_return to co_yield/await without
properly reviewing it.
tested on x86_64,powerpc64-linux, x86_64-darwin
OK for master?
OK for 10.2?
thanks
Iain
gcc/cp/ChangeLog:
PR c++/95345
* coroutines
This patch is meant to add match rules to simplify patterns as:
o. (pointer + offset_a) - (pointer + offset_b) -> (ptrdiff_t) (offset_a -
offset_b)
o. (pointer_a + offset) - (pointer_b + offset) -> (pointer_a - pointer_b)
Bootstrapped/regtested on x86_64-linux and aarch64-linux.
Feng
--
Hi,
this addresses the issue raised by Andrew a few weeks ago about the usage of
memory copy functions to toggle the scalar storage order. Recall that you
cannot (the compiler errors out) take the address of a scalar which is stored
in reverse order, but you can do it for the enclosing aggrega
Hi
Confusingly, "get_return_object ()" can do two things:
- Firstly it can provide the return object for the ramp function (as
the name suggests).
- Secondly if the type of the ramp function is different from that
of the get_return_object call, this is used as a single parameter
to a CTOR fo
"Yangfei (Felix)" writes:
> Hi,
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Sunday, May 31, 2020 12:01 AM
>> To: Yangfei (Felix)
>> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak ; Jakub
>> Jelinek ; Hongtao Liu ; H.J. Lu
>>
>> Subject: Re: [P
Hi
This corrects an typo in the CO_RETURN_EXPR tree class.
Although it doens’t fix any PR or regression - it seems to me that it would be
sensible to apply this to 10.2 as well as master (or it’s an accident waiting to
happen).
OK for master?
10.2 (after some bake)?
thanks
Iain
gcc/cp/ChangeLog
Clone materialization might produce some improper debug output as:
Original--
cloning foo/271 to foo.constprop/334
replace map: 0 -> xxx1->yyy
m_always_copy_start: 1
IPA adjusted parameters: foo (...)
{
...
}
And a better output could be:
cloning foo/271 to foo.constprop/334
repl
On Sun, 31 May 2020, H.J. Lu via Gcc-patches wrote:
> --- a/gcc/config/i386/i386-expand.c
> +++ b/gcc/config/i386/i386-expand.c
> @@ -7656,6 +7656,90 @@ ix86_expand_set_or_cpymem (rtx dst, rtx src, rtx
> count_exp, rtx val_exp,
>return true;
> }
>
> +/* Expand cmpstrn or memcmp. */
> +
>
Hi Feng,
On Mon, Jun 01 2020, Feng Xue OS wrote:
> Clone materialization might produce some improper debug output as:
>
> Original--
>
> cloning foo/271 to foo.constprop/334
>replace map: 0 -> xxx1->yyy
> m_always_copy_start: 1
> IPA adjusted parameters: foo (...)
> {
> ...
> }
>
> And
The patch improves readability of the memcpy and memset
expansion strategies.
gcc/ChangeLog:
* config/i386/x86-tune-costs.h: Change code formatting.
---
gcc/config/i386/x86-tune-costs.h | 38 +++-
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git
Based on the collected numbers in PR95435, I suggest the following
tuning changes:
gcc/ChangeLog:
PR target/95435
* config/i386/x86-tune-costs.h: Use libcall for large sizes for
-m32. Start using libcall from 128+ bytes.
---
gcc/config/i386/x86-tune-costs.h | 12 ++--
Adding Honza as Uros recommended him for a review.
Martin
On 6/1/20 1:35 PM, Martin Liška wrote:
Based on the collected numbers in PR95435, I suggest the following
tuning changes:
gcc/ChangeLog:
PR target/95435
* config/i386/x86-tune-costs.h: Use libcall for large sizes for
-m3
On Sun, May 24, 2020 at 02:30:13AM +0200, Mark Wielaard wrote:
> This adds a flag to c_parser so we know when we were trying to
> construct a string literal. If there is a parse error and we were
> constructing a string literal, and the next token is an unknown
> identifier name, and we know there
On Mon, Jun 1, 2020 at 3:19 AM Alexander Monakov wrote:
>
> On Sun, 31 May 2020, H.J. Lu via Gcc-patches wrote:
>
> > --- a/gcc/config/i386/i386-expand.c
> > +++ b/gcc/config/i386/i386-expand.c
> > @@ -7656,6 +7656,90 @@ ix86_expand_set_or_cpymem (rtx dst, rtx src, rtx
> > count_exp, rtx val_exp,
On 5/20/20 1:03 PM, Franz Sirl wrote:
Am 2020-05-19 um 21:05 schrieb Martin Liška:
Hi.
We make direct emission for asan_emit_stack_protection for smaller stacks.
That's fine but we're missing the piece that marks the stack as released
and we run out of pre-allocated stacks. I also included some
On Mon, Jun 01, 2020 at 02:28:51PM +0200, Martin Liška wrote:
> --- a/gcc/asan.c
> +++ b/gcc/asan.c
> @@ -1598,8 +1598,24 @@ asan_emit_stack_protection (rtx base, rtx pbase,
> unsigned int alignb,
>if (use_after_return_class < 5
> && can_store_by_pieces (sz, builtin_memset_read_str
Please CC libstd...@gcc.gnu.org on all libstdc++ patches, even if the
approval is coming from a target port maintainer, not from a libstdc++
maintainer.
Thanks.
On 6/1/20 2:52 PM, Jakub Jelinek wrote:
On Mon, Jun 01, 2020 at 02:28:51PM +0200, Martin Liška wrote:
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1598,8 +1598,24 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
if (use_after_return_class < 5
&& can_store_by_p
Hi,
I reported a PR in gcc Bugzilla about the medium code model in aarch64. A
solution is proposed and some discussion has been posted.
The details of the discussion can be found here :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
Wilco suggest me to make a PIC 48-bit code model by makin
Apologies! Will do so in the future.
Doug
On 6/1/20 6:15 AM, Jonathan Wakely wrote:
Please CC libstd...@gcc.gnu.org on all libstdc++ patches, even if the
approval is coming from a target port maintainer, not from a libstdc++
maintainer.
Thanks.
Hi,
this patch further simplifies way we reffer to global stream. Every function
section has vector of references to global trees which are populated during
streaming. This vector is for some reason divided into field_decls, fn_decls,
type_decls, types, namespace_decls, labels_decls and var_decls
On 6/1/20 3:44 AM, Iain Sandoe wrote:
Hi,
I had implemented a move out of rvalue refs for such ramp values (since
these are most likely to be dangling references). However this does cause
a divergence with the clang implementation - and the patch fixes that.
ok for both
tested on x86_64,po
On 6/1/20 3:55 AM, Iain Sandoe wrote:
Hi,
Since the co_await expression is mostly opaque to the existing
machinery, we were hiding the details of the await_resume return
value. If that needs to be wrapped in a target expression, then
emulate this with the whole co_await. Similarly, if the awai
On 6/1/20 3:59 AM, Iain Sandoe wrote:
(resending, this didn’t appear to make it to the list)
Hi,
I had implemented a move out of rvalue refs for such ramp values (since
these are most likely to be dangling references). However this does cause
a divergence with the clang implementation - and th
On 6/1/20 4:09 AM, Iain Sandoe wrote:
Hi
This corrects a pasto, where I copied the constraint on bare
parameter packs from the co_return to co_yield/await without
properly reviewing it.
tested on x86_64,powerpc64-linux, x86_64-darwin
OK for master?
OK for 10.2?
ok for both
thanks
Iain
gcc/
Like many sites over the last year(s) valgrind.org has now moved to
https. While there, replace the second of two links in the same vicinity
by a purely textual reference -- easier to maintain, and in particular
also better from a user experience perspective.
Gerald
* doc/xml/faq.xml:
GCC maintianers:
The following patch set adds builtins for the various Permute Class
Operations specified in IBM RFC 2609.
Based on previous IBM internal reviews of the patch set, the desire is
for all of the vector insert and extract support to be in vsx.md as
there is a longer term plan to re-w
GCC maintainers:
The following patch adds support for the vector shift double builtins
for RFC2609.
The patch has been compiled and tested on
powerpc64le-unknown-linux-gnu (Power 9 LE)
and Mambo with no regression errors.
Please let me know if this patch is acceptable for the mainline
bran
GCC maintainers:
This patch adds support for vec_insertl and vec_inserth builtins.
The patch has been compiled and tested on
powerpc64le-unknown-linux-gnu (Power 9 LE)
and mambo with no regression errors.
Please let me know if this patch is acceptable for the mainline branch.
Thanks.
GCC maintainers:
The following patch adds support for the vec_splati, vec_splatid and
vec_splati_ins builtins.
Note, this patch adds support for instructions that take a 32-bit
immediate
value that represents a floating point value. This support adds new
predicates and a support function to pr
GCC maintainers:
Move the existing vector extract support in altivec.md to vsx.md
so all of the vector insert and extract support is in the same file.
The patch also updates the name of the builtins and descriptions for the
builtins in the documentation file so they match the approved builtin
n
GCC maintainers:
The following patch adds support for the vec_blendv and vec_permx
builtins.
The patch has been compiled and tested on
powerpc64le-unknown-linux-gnu (Power 9 LE)
with no regression errors.
The test cases were compiled on a Power 9 system and then tested on
Mambo.
Please le
GCC maintainers:
The following patch adds support for builtins vec_replace_elt and
vec_replace_unaligned.
The patch has been compiled and tested on
powerpc64le-unknown-linux-gnu (Power 9 LE)
and mambo with no regression errors.
Please let me know if this patch is acceptable for the mainlin
> "David" == David Malcolm writes:
>> I tested this using the self-tests. A new self-test is also
>> included.
> Did the full DejaGnu testsuite get run? There are a lot of tests in it
> that make use of this code.
I didn't try it, but I can.
> The patch should probably update the leading
Steve Lhomme writes:
> Hello,
>
> Any update on this ? This prevents libssp from being usable in UWP apps.
>
> (BTW the name of the old API is not wincrypt, the header, but CryptoAPI
> or CAPI)
Sorry for the slow review. I fear most global reviewers would have
no idea whether the patch is right
On 31/05/2020 23:40, Iain Buclaw via Gcc-patches wrote:
> Hi,
>
> In the removal of arm-wrs-vxworks, the default cpu was updated from arm8
> to armv7-a, but this is not recognized as a valid -mcpu target. There
> is however generic-armv7-a, which was likely the intended cpu that
> should have bee
When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints. Fix this by substituting through the constraints during
tsubst_lambda_expr.
Passes 'make check-c++', and also tested by building the testsuites of
c
Hello Iain,
> On 01 Jun 2020, at 00:40, Iain Buclaw wrote:
>
> Hi,
>
> In the removal of arm-wrs-vxworks, the default cpu was updated from arm8
> to armv7-a, but this is not recognized as a valid -mcpu target. There
> is however generic-armv7-a, which was likely the intended cpu that
> should
Greetings,
Curious if you've had a chance to look at this patch yet?
--Doug
On 5/18/20 4:02 PM, Douglas B Rupp wrote:
Greetings,
The attached patch is proposed for rs6000/linux64.h.
The problem it addresses is that the current checking only tests for
existence not for an incompatible/compat
Hi,
this patch removes unnecesary ref tags and replaces them by one tag
for all references to the global stream.
lto-bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
2020-06-01 Jan Hubicka
* lto-streamer.h (enum LTO_tags): Remove LTO_field_decl_ref,
LTO_fu
On 6/1/20 4:46 AM, Iain Sandoe wrote:
Hi
Confusingly, "get_return_object ()" can do two things:
- Firstly it can provide the return object for the ramp function (as
the name suggests).
- Secondly if the type of the ramp function is different from that
of the get_return_object call, this is
On 6/1/20 4:56 AM, Iain Sandoe wrote:
Hi
This corrects an typo in the CO_RETURN_EXPR tree class.
Although it doens’t fix any PR or regression - it seems to me that it would be
sensible to apply this to 10.2 as well as master (or it’s an accident waiting to
happen).
OK for master?
10.2 (after s
On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc wrote:
>
> Hi!
>
> I've turned the strict mode of Martin Liška's hook changes,
> which means that from now on no commits to the trunk or release branches
> should be changing any ChangeLog files together with the other files,
> ChangeLog entry sh
* gcc-changelog/git_commit.py (GitCommit.check_mentioned_files):
Improve error text.
OK for master?
commit b0eb103fc6a8b12905ce8feea299e02048b7f820
Author: Jonathan Wakely
Date: Mon Jun 1 18:28:35 2020 +0100
contrib: Improve comments and error text
* gcc-c
I noticed recently that our input_iterator_wrapper utility for writing
tests has the following post-increment operator:
void
operator++(int)
{
++*this;
}
That fails to meet the Cpp17InputIterator requirement that *r++ is
valid. This change makes it return a non-void proxy ty
On 01/06/20 17:06 +0200, Gerald Pfeifer wrote:
Like many sites over the last year(s) valgrind.org has now moved to
https. While there, replace the second of two links in the same vicinity
by a purely textual reference -- easier to maintain, and in particular
also better from a user experience pe
On 5/30/20 12:37 AM, Patrick Palka wrote:
On Wed, 13 May 2020, Jason Merrill wrote:
On 5/11/20 6:43 PM, Patrick Palka wrote:
In the testcase below we're prematurely folding away the
requires-expression to 'true' after substituting in the function's
template arguments, but before substituting i
On 6/1/20 12:47 PM, Patrick Palka wrote:
When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints. Fix this by substituting through the constraints during
tsubst_lambda_expr.
Passes 'make check-c++', and
Could you go into more detail about this choice of cost calculation?
It looks like we first calculate per-group flags, which are true only if
the unrolled offsets are valid for all uses in the group. Then we create
per-candidate flags when associating candidates with groups.
Instead, couldn't we
This thread adds seven patches to add tests for the -mcpu=future code
generation. These patches are an update to the patches I sent out in April.
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544653.html
I have done bootstrap builds with/without the patches on a little end power9
box, and
2020-06-01 Michael Meissner
* lib/target-supports.exp (check_effective_target_powerpc_pcrel):
New.
(check_effective_target_powerpc_prefixed_addr): New.
---
gcc/testsuite/lib/target-supports.exp | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gcc
Add test to make sure prefixed load/store instructions are generated if the
offset would not fit in the DS/DQ encodings.
2020-06-01 Michael Meissner
* gcc.target/powerpc/prefix-ds-dq.c: New test.
---
gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c | 159
1 fil
Add tests to make sure for -mcpu=future that prefixed load/store instructions
are generated if the offset is larger than 16 bits.
2020-06-01 Michael Meissner
* gcc.target/powerpc/prefix-large-dd.c: New test.
* gcc.target/powerpc/prefix-large-df.c: New test.
* gcc.target
Add tests for -mcpu=future that test the generation of PADDI (and PLI which
becomes PADDI).
2020-06-01 Michael Meissner
* gcc.target/powerpc/prefix-add.c: New test.
* gcc.target/powerpc/prefix-si-constant.c: New test.
* gcc.target/powerpc/prefix-di-constant.c: New test.
This test makes sure we do not generate a prefixed instruction with an update
form.
2020-06-01 Michael Meissner
* gcc.target/powerpc/prefix-no-update.c: New test.
---
.../gcc.target/powerpc/prefix-no-update.c | 50 ++
1 file changed, 50 insertions(+)
crea
Test that stack protection generates prefixed stack instructions if you are
using large stack frame for -mcpu=future.
2020-06-01 Michael Meissner
* gcc.target/powerpc/prefix-stack-protect.c: New test.
---
.../gcc.target/powerpc/prefix-stack-protect.c| 20
These tests make sure that PC-relative variant is generated for -mcpu=future on
systems that support PC-relative addressing.
2020-06-01 Michael Meissner
* gcc.target/powerpc/prefix-pcrel-dd.c: New test.
* gcc.target/powerpc/prefix-pcrel-df.c: New test.
* gcc.target/powe
Add support for the new IEEE 128-bit minimum, maximum, and set compare mask
instructions when -mcpu=future was used.
gcc/
2020-06-01 Michael Meissner
* config/rs6000/rs6000.c (rs6000_emit_hw_fp_minmax): Update
comment.
(rs6000_emit_hw_fp_cmove): Update comment.
Add support for generating BRH/BRW/BRD when -mcpu=future is used.
gcc/
2020-06-01 Michael Meissner
* config/rs6000/rs6000.md (bswaphi2_reg): If -mcpu=future,
generate the BRH instruction.
(bswapsi2_reg): If -mcpu=future, generate the BRW instruction.
(bswapdi2):
These 3 patches add support for some new instructions in the 'future'
processor.
The first patch adds support for the new byte swap instructions that byte swap
valies in the GPRs.
The second patch renames some functions from _p9 to _hw. This is
in preparation for the third patch that adds suppor
This patch renames some functions that were added for power9 support that are
named '_p9' to be '_hw'. This is preparation for the next patch that wants to
extend these functions for -mcpu=power support.
2020-06-01 Michael Meissner
* config/rs6000/rs6000.c (rs6000_emit_hw_fp_minmax):
> Did the full DejaGnu testsuite get run? There are a lot of tests in it
> that make use of this code.
I did "make check" and only saw some XFAILs.
Here's v2 of the patch, which I think addresses your comments. I did
not add a new test of get_edit_distance, because as I mentioned earlier,
an ex
Windows ABI (MinGW) is different than Linux ABI when bitfileds are involved.
The following patch adds __attribute__ ((gcc_struct)) to struct fenv in order
to match the layout of x87 state image in memory.
2020-06-01 Uroš Bizjak
libatomic/ChangeLog:
* config/x86/fenv.c (struct fenv): Add __
Another case where we can't find the OBJ_TYPE_REF_OBJECT in the
OBJ_TYPE_REF_EXPR. So let's just evaluate the sanitize call first.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/95466
PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): R
msp430-elf has had regressions for a while. There was other instability at the
time the regression started, so I waited to see if it'd correct itself, but it
didn't and I finally took a looksie.
We're processing this in lower-subreg:
(insn 30 64 42 6 (set (subreg:SI (reg/v:HI 33 [ oz ]) 0)
The following patch to libgcc/libgcc2.c __divdc3 provides an
opportunity to gain important improvements to the quality of answers
for the default double precision complex divide routine when dealing
with very large or very small exponents.
The current code correctly implements Smith's method (1962
On Mon, 2020-06-01 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> These tests make sure that PC-relative variant is generated for -mcpu=future
> on
> systems that support PC-relative addressing.
>
> 2020-06-01 Michael Meissner
>
> * gcc.target/powerpc/prefix-pcrel-dd.c: New t
On Mon, 2020-06-01 at 15:53 -0400, Michael Meissner via Gcc-patches
wrote:
> This thread adds seven patches to add tests for the -mcpu=future code
> generation. These patches are an update to the patches I sent out in
> April.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544653.html
>
On Fri, May 29, 2020 at 01:26:32PM -0400, Jason Merrill via Gcc-patches wrote:
> This is a diagnostic quality regression, moving the error message away from
> the line where the actual problem is.
>
> Maybe use error_at (loc, ...)?
That works fine, bootstrapped/regtested on x86_64-linux and i686-
On Mon, 2020-06-01 at 16:01 -0400, Michael Meissner via Gcc-patches
wrote:
> Add support for generating BRH/BRW/BRD when -mcpu=future is used.
>
Hi,
> gcc/
> 2020-06-01 Michael Meissner
>
> * config/rs6000/rs6000.md (bswaphi2_reg): If -mcpu=future,
> generate the BRH instruction
On 23/05/20 09:44 +0100, Jonathan Wakely wrote:
This simplifies the logic of converting Source arguments and pairs of
InputIterator arguments into the native string format. For any input
that is a contiguous range of path::value_type (or char8_t for POSIX)
a string view can be created and the con
On Mon, 2020-06-01 at 16:01 -0400, Michael Meissner via Gcc-patches wrote:
> Add support for the new IEEE 128-bit minimum, maximum, and set compare mask
> instructions when -mcpu=future was used.
>
> gcc/
> 2020-06-01 Michael Meissner
>
> * config/rs6000/rs6000.c (rs6000_emit_hw_fp_minma
On Mon, 2020-06-01 at 16:01 -0400, Michael Meissner via Gcc-patches
wrote:
> These 3 patches add support for some new instructions in the 'future'
> processor.
>
> The first patch adds support for the new byte swap instructions that
> byte swap
> valies in the GPRs.
values
>
> The second patch
Jiufu Guo writes:
Hi,
I updated the patch just a little accordinlgy. Thanks!
diff --git a/gcc/common.opt b/gcc/common.opt
index 4464049fc1f..570e2aa53c8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2856,6 +2856,10 @@ funroll-all-loops
Common Report Var(flag_unroll_all_loops) Optimizat
Committed, thanks :)
On Mon, Jun 1, 2020 at 4:10 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Mon, Jun 01, 2020 at 03:43:00PM +0800, Kito Cheng wrote:
> > ping
> >
> >
> > On Wed, May 20, 2020 at 3:01 PM Kito Cheng wrote:
> > >
> > > - Run gcc testsuite with qemu will print out ascii color co
n though.
Yes, that's a good suggestion. I see the code becomes more cleaner with
another lambda.
> Yeah, looks good.
>
> Formatting nit though: multi-line conditions should be wrapped in (...),
> i.e.:
>
> return (...
> && ...
>
Hi Richard,
Thanks for the comments!
on 2020/6/2 上午1:59, Richard Sandiford wrote:
> Could you go into more detail about this choice of cost calculation?
> It looks like we first calculate per-group flags, which are true only if
> the unrolled offsets are valid for all uses in the group. Then we
(cherry picked from commit 21bb1625bd4f183984223ce31bd03ba47ed62f27)
---
libsanitizer/asan/asan_globals.cpp| 19 ---
libsanitizer/asan/asan_interceptors.h | 7 ++-
libsanitizer/asan/asan_mapping.h | 2 +-
.../sanitizer_linux_libcdep.cpp
libsanitizer/ChangeLog:
* LOCAL_PATCHES: Update hash of local patches.
---
libsanitizer/LOCAL_PATCHES | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libsanitizer/LOCAL_PATCHES b/libsanitizer/LOCAL_PATCHES
index 7732de3d436..f0c99a3b7ea 100644
--- a/libsanitizer/LOCAL
On 6/1/20 7:30 PM, Jonathan Wakely wrote:
* gcc-changelog/git_commit.py (GitCommit.check_mentioned_files):
Improve error text.
OK for master?
Yes, I've just pushed the patch with your authorship.
Martin
On 6/1/20 7:24 PM, Jonathan Wakely wrote:
On Mon, 25 May 2020 at 23:50, Jakub Jelinek via Gcc wrote:
Hi!
I've turned the strict mode of Martin Liška's hook changes,
which means that from now on no commits to the trunk or release branches
should be changing any ChangeLog files together with th
85 matches
Mail list logo
