On 5/29/20 2:04 PM, Liu Hao via Gcc-patches wrote:
> 在 2020/5/29 22:01, Liu Hao 写道:
>> This is necessary as libmsvcrt.a is not a pure import library, but
>> also contains some functions that invoke others in KERNEL32.DLL.
>>
>> * config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
>> ---
>
On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote:
>>> I was able to successfully bootstrap and regression test with
>>> your patch on x86_64-pc-linux-gnu. I also verified that the
>>> result of
>> "make
>>> install" was not affected for my configuration.
>>
>> Great.
>>
>>> I've pushed yo
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 in the lambda's deduced
> > templ
On Fri, 29 May 2020, Jason Merrill wrote:
> On 5/22/20 10:56 AM, Patrick Palka wrote:
> > On Fri, 22 May 2020, Patrick Palka wrote:
> >
> > > When comparing two special member function templates to see if one hides
> > > the other (as per P0848R3), we need to check satisfaction which we can't
> >
On Sat, May 30, 2020 at 12:20:19AM +0200, Harald Anlauf wrote:
> > Gesendet: Freitag, 29. Mai 2020 um 23:57 Uhr
> > Von: "H.J. Lu"
>
> > This breaks bootstrap:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072642.html
> >
> > ../../src-master/gcc/fortran/class.c:487:13: error: ‘
There are various VSX insns that do the same job as (older) AltiVec
insns, just with a wider range of possible registers. Many patterns
for such insns have the "v" alternative before the "wa" alternative,
which makes the output less readable than possible (since vs32 is v0,
and most insns before o
On Fri, May 29, 2020 at 3:20 PM Harald Anlauf wrote:
>
> Hi H.J.,
>
> > Gesendet: Freitag, 29. Mai 2020 um 23:57 Uhr
> > Von: "H.J. Lu"
>
> > This breaks bootstrap:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072642.html
> >
> > ../../src-master/gcc/fortran/class.c:487:13: error
Hi H.J.,
> Gesendet: Freitag, 29. Mai 2020 um 23:57 Uhr
> Von: "H.J. Lu"
> This breaks bootstrap:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2020-May/072642.html
>
> ../../src-master/gcc/fortran/class.c:487:13: error: ‘char*
> strncpy(char*, const char*, size_t)’ specified bound 67 equal
On 5/22/20 10:56 AM, Patrick Palka wrote:
On Fri, 22 May 2020, Patrick Palka wrote:
When comparing two special member function templates to see if one hides
the other (as per P0848R3), we need to check satisfaction which we can't
do on templates. So this patch makes add_method skip the eligibi
any_template_parm_r was assuming that the DECL_TEMPLATE_RESULT of a template
will have a suitable TEMPLATE_INFO from which we can look at the generic
arguments for that template. But that wasn't true for a template template
parameter; this patch makes it so.
Tested x86_64-pc-linux-gnu, applying t
Hi!
Re: [PATCH] rs6000: PR target/95347 Correctly identify stfs if prefixed
Please put the PR id at the end of the subject (it is the least
important information). You can also shorten it to "PR95347" -- total
subject length ideally is maybe 50 chars, so something like
"rtl-optimization" would be
On Fri, May 29, 2020 at 1:39 PM Harald Anlauf wrote:
>
> The initial patch for this PR had some fallout which for unknown reason
> did only show up on i686, but not on x86_64. With initial guidance by
> Manfred Schwarb three further locations exhibiting buffer overrun could
> be identified in a g
Because reg_to_non_prefixed() only looks at the register being used, it
doesn't get the right answer for stfs, which leads to us not seeing
that it has a PCREL symbol ref. This patch works around this by
introducing a helper function that inspects the insn to see if it is in
fact a stfs. Then if w
>
> ---
> gcc/tree.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/gcc/tree.h b/gcc/tree.h
> index bd0c51b2a18..86a4542f58b 100644
> --- a/gcc/tree.h
> +++ b/gcc/tree.h
> @@ -6156,6 +6156,17 @@ int_bit_position (const_tree field)
> + wi::to_offset (DECL_FIELD_BIT_
Hello,
>
>
> ---
> gcc/ipa-ref.c | 22 ++
> gcc/ipa-ref.h | 3 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/gcc/ipa-ref.c b/gcc/ipa-ref.c
> index 241828ee973..76459e9cc3d 100644
> --- a/gcc/ipa-ref.c
> +++ b/gcc/ipa-ref.c
> @@ -103,3 +103,25 @@ ipa_ref::referred
The initial attempt to fix this PR unfortunately produced a regression
in the testsuite that was overlooked. The real fix is to apply this
check in the appropriate place.
Regtested on x86_64-pc-linux-gnu. Really.
OK for master and backports?
Thanks,
Harald
PR fortran/95373 - ICE in build_re
On Fri, May 15, 2020 at 10:32:00AM -0600, Jeff Law via Gcc-patches wrote:
> > I wasn't sure if it wouldn't be safer to add some bool flag set to true by
> > the new code and then add gcc_assert in all the other paths, like following
> > incremental patch. I believe none of the asserts can trigger
[6~On Fri, May 29, 2020 at 12:52:09PM -0700, H.J. Lu via Gcc-patches wrote:
> Avoid nested save_CFLAGS and save_LDFLAGS by replacing save_CFLAGS and
> save_LDFLAGS with cet_save_CFLAGS and cet_save_LDFLAGS in cet.m4.
Ok, thanks.
Jakub
Avoid nested save_CFLAGS and save_LDFLAGS by replacing save_CFLAGS and
save_LDFLAGS with cet_save_CFLAGS and cet_save_LDFLAGS in cet.m4.
config/
PR bootstrap/95413
* cet.m4: Replace save_CFLAGS and save_LDFLAGS with
cet_save_CFLAGS and cet_save_LDFLAGS.
gcc/
PR b
The initial patch for this PR had some fallout which for unknown reason
did only show up on i686, but not on x86_64. With initial guidance by
Manfred Schwarb three further locations exhibiting buffer overrun could
be identified in a gdb session and were fixed.
Committed as 'obvious' to master.
T
On 5/28/20 7:23 PM, Marek Polacek wrote:
Barry pointed out to me that our braced-init-list as a template-argument
extension doesn't work as expected when we aggregate-initialize. Thus
fixed by calling digest_init in convert_nontype_argument so that we can
actually convert the CONSTRUCTOR.
I don
On 5/29/20 1:40 PM, Patrick Palka wrote:
On Fri, 29 May 2020, Jason Merrill wrote:
On 5/29/20 11:59 AM, Patrick Palka wrote:
In the testcase below, the satisfaction value of fn1's constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_nod
On Fri, May 29, 2020 at 6:02 PM Tom Tromey wrote:
> This patch changes gcc's spell checker to prefer simple case changes
> when possible.
>
> I tested this using the self-tests. A new self-test is also included.
I think that's great, but it should be mentioned in the comment that
the distance fu
On Fri, 29 May 2020, Jason Merrill wrote:
> On 5/29/20 11:59 AM, Patrick Palka wrote:
> > In the testcase below, the satisfaction value of fn1's constraint
> > is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
> > to the standard boolean_type_node. But satisfaction_value expe
On Fri, May 29, 2020 at 06:26:55PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Most patterns *do* FAIL on some target. We cannot rewind time.
>
> Sure. But the point is that FAILing isn't “explicitly allowed” for vcond*.
> In fact it's the opposite.
It has FAILed on rs6000
---
gcc/ipa-ref.h| 2 +-
gcc/ipa-visibility.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/ipa-ref.h b/gcc/ipa-ref.h
index 95e29605548..9ff26e2693c 100644
--- a/gcc/ipa-ref.h
+++ b/gcc/ipa-ref.h
@@ -139,5 +139,5 @@ public:
const char *
stringify_ipa_
This pass is a variant of constant propagation where global
primitive constants with a single write are propagated to multiple
read statements.
ChangeLog:
2020-05-20 Erick Ochoa
gcc/Makefile.in: Adds new pass
gcc/passes.def: Same
gcc/tree-pass.h: Same
gcc/co
---
gcc/ipa-utils.c | 33 +
gcc/ipa-utils.h | 4 +++-
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/gcc/ipa-utils.c b/gcc/ipa-utils.c
index 23e7f714306..bd3e79bd2e2 100644
--- a/gcc/ipa-utils.c
+++ b/gcc/ipa-utils.c
@@ -781,3 +781,36 @@ recursi
---
gcc/tree.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/tree.h b/gcc/tree.h
index bd0c51b2a18..86a4542f58b 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -6156,6 +6156,17 @@ int_bit_position (const_tree field)
+ wi::to_offset (DECL_FIELD_BIT_OFFSET (field))).t
---
gcc/ipa-ref.c | 22 ++
gcc/ipa-ref.h | 3 +++
2 files changed, 25 insertions(+)
diff --git a/gcc/ipa-ref.c b/gcc/ipa-ref.c
index 241828ee973..76459e9cc3d 100644
--- a/gcc/ipa-ref.c
+++ b/gcc/ipa-ref.c
@@ -103,3 +103,25 @@ ipa_ref::referred_ref_list (void)
{
return
On Fri, May 29, 2020 at 06:05:14PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote:
> >> Segher - do you actually know this code to guess why the patterns are
> >> defensive?
> >
> > Yes.
>
> In that case, can you gi
Hello everyone,
I wanted to highlight this ticket on bugzilla [0]. It is a missed
optimization that I worked on. It involves propagating constants across
function calls at link-time. I am relatively new to GCC and this would
be my first significant contribution. I have developed a prototype of
Segher Boessenkool writes:
> On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote:
>> >> Now it looks like that those verification also simply checks optab
>> >> availability only but t
On 5/29/20 6:25 AM, Jakub Jelinek wrote:
Hi!
cxx_eval_outermost_constant_expr had a check for reinterpret_casts from
pointers (well, it checked from ADDR_EXPRs) to integral type, but that
only caught such cases at the toplevel of expressions.
As the comment said, it should be done even inside of
On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote:
> >> Now it looks like that those verification also simply checks optab
> >> availability only but then this is just a preexisting iss
Am 24.05.20 um 20:55 schrieb Thomas Koenig via Fortran:
Hello world,
this patch fixes a 8/9/10/11 regression, where finalized types
were not finalized (and deallocated), which led to memory
leaks.
Hi,
OK for trunk? The patch is simple enough (and the regression bad enough)
that I'll commit on
Segher Boessenkool writes:
> On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote:
>> So I tried to understand the circumstances the rs6000 patterns FAIL
>> but FAILed ;) It looks like some outs of rs6000_emit_vector_cond_expr
>> are unwarranted and the following should work:
>>
>> dif
Segher Boessenkool writes:
> On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote:
>> Now it looks like that those verification also simply checks optab
>> availability only but then this is just a preexisting issue (and we can
>> possibly build a testcase that FAILs RTL expansion for po
I got this error message when editing gcc and recompiling:
../../gcc/gcc/ada/gcc-interface/decl.c:7714:39: error:
‘DWARF_GNAT_ENCODINGS_all’ was not declared in this scope; did you mean
‘DWARF_GNAT_ENCODINGS_GDB’?
7714 | = debug_info && gnat_encodings == DWARF_GNAT_ENCODINGS_all;
|
Am 28.05.20 um 21:58 schrieb Harald Anlauf:
The initial commit for this PR uncovered a latent issue with unit locking
in the Fortran run-time library. Add check for valid unit.
This only came up because Solaris, unlike Linux, links the pthreads
library by default, so it will not be found in a
On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote:
> So I tried to understand the circumstances the rs6000 patterns FAIL
> but FAILed ;) It looks like some outs of rs6000_emit_vector_cond_expr
> are unwarranted and the following should work:
>
> diff --git a/gcc/config/rs6000/rs6000.
On 5/29/20 11:59 AM, Patrick Palka wrote:
In the testcase below, the satisfaction value of fn1's constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_node. But satisfaction_value expects to
see exactly boolean_true_node or integer_one_nod
Hi Jakub,
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and 10.2?
OK. Thanks a lot!
Regards
Thomas
On 5/28/20 7:11 PM, Marek Polacek wrote:
On Thu, May 28, 2020 at 05:01:51PM -0400, Jason Merrill wrote:
On 5/26/20 8:25 PM, Marek Polacek wrote:
Since r267272, which added location wrappers, cp_fold loses
TREE_NO_WARNING on a MODIFY_EXPR that finish_parenthesized_expr set, and
that results in a
We weren't able to find OBJ_TYPE_REF_OBJECT walking through
OBJ_TYPE_REF_EXPR because we had folded away the ADDR_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Don't fold the INDIRECT_REF.
gcc/
In the testcase below, the satisfaction value of fn1's constraint
is INTEGER_CST '1' of type BOOLEAN_TYPE value_type, which is a typedef
to the standard boolean_type_node. But satisfaction_value expects to
see exactly boolean_true_node or integer_one_node, which this value is
neither, causing us t
On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote:
> Now it looks like that those verification also simply checks optab
> availability only but then this is just a preexisting issue (and we can
> possibly build a testcase that FAILs RTL expansion for power...).
>
> So given that this
I've just pushed that to master.
Jakub: Can you please rsync the script to the server hook?
Thanks,
Martin
On 5/28/20 7:13 PM, Mark Wielaard wrote:
Hi Martin,
On Thu, May 28, 2020 at 06:21:39PM -0600, Martin Sebor wrote:
Although few tests bother with it, since you add an option for
the existing warning where there was none before, an even more
exhaustive test than the one you added would also verif
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545856.html
On 5/15/20 5:31 PM, Martin Sebor wrote:
Besides better buffer overflow checking, the new GCC 10 attribute
access also provides an opportunity to detect other kinds of bugs,
including uninitialized accesses by user-defined funct
On Thu, May 28, 2020, 4:25 PM David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 2020-05-27 at 22:27 -0300, Nicolas Bértolo wrote:
> > > New C++ source files should have a .cc extension.
> > > I hope that at some point we'll rename all the existing .c ones
> > > accordingly.
Pushed to master.
maintainer-scripts/ChangeLog:
* bugzilla-close-candidate.py: Fix sorting of branches.
---
maintainer-scripts/bugzilla-close-candidate.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/maintainer-scripts/bugzilla-close-candidate.py
b/maintai
On 29/05/2020 13:28, duanbo (C) wrote:
>
>
>> -Original Message-
>> From: Andrew Pinski [mailto:pins...@gmail.com]
>> Sent: Monday, May 18, 2020 11:49 AM
>> To: duanbo (C)
>> Cc: GCC Patches
>> Subject: Re: [PATCH] aarch64: Change the definition of Pmode [pr95182]
>>
>> On Sun, May 17,
Tested and pushed to master.
maintainer-scripts/ChangeLog:
* bugzilla-close-candidate.py: Fix parsing of SVN revisions.
Fix skipping of PRs that contain Can be closed message.
---
.../bugzilla-close-candidate.py | 36 +++
1 file changed, 22 insertio
在 2020/5/29 22:01, Liu Hao 写道:
> This is necessary as libmsvcrt.a is not a pure import library, but
> also contains some functions that invoke others in KERNEL32.DLL.
>
> * config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
> ---
> gcc/config/i386/mingw32.h | 2 +-
> 1 file changed, 1
This is necessary as libmsvcrt.a is not a pure import library, but
also contains some functions that invoke others in KERNEL32.DLL.
* config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt
---
gcc/config/i386/mingw32.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/g
On Fri, May 29, 2020 at 6:45 AM duanbo (C) wrote:
>
>
>
> > -Original Message-
> > From: Andrew Pinski [mailto:pins...@gmail.com]
> > Sent: Monday, May 18, 2020 11:49 AM
> > To: duanbo (C)
> > Cc: GCC Patches
> > Subject: Re: [PATCH] aarch64: Change the definition of Pmode [pr95182]
> >
> -Original Message-
> From: Richard Sandiford
> Sent: 29 May 2020 11:59
> To: Alex Coplan
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft ;
> Kyrylo Tkachov
> Subject: Re: [PATCH] [aarch64] Fix PR94591: GCC generates invalid rev64
> insns
>
> Alex Coplan writ
I've committed this backport of two master commits, originally posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545771.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546800.html
These correct a wrong-code bug that could affect spilled vectors.
Andrew
amdgcn: fix vcc clob
On Fri, May 29, 2020 at 2:17 PM Richard Biener
wrote:
>
> On Thu, May 28, 2020 at 5:28 PM Richard Sandiford
> wrote:
> >
> > Martin Liška writes:
> > > Hi.
> > >
> > > There's a new patch that adds normal internal functions for the 4
> > > VCOND* functions.
> > >
> > > The patch that survives bo
Hi!
On Fri, May 29, 2020 at 09:32:49AM +0100, Richard Sandiford wrote:
> There's nothing to stop us using masks and lengths in the same loop
> in future if we need to. It would “just” be a case of setting up both
> the masks and the lengths in vect_set_loop_condition. But the point is
> that doi
On Fri, 2020-05-29 at 01:33 +0200, Mark Wielaard wrote:
> Hi,
>
> On Mon, May 25, 2020 at 12:26:33PM -0400, Jason Merrill wrote:
> > On 5/23/20 8:30 PM, Mark Wielaard wrote:
> > > When reporting an error in cp_parser and we notice a string
> > > literal
> > > followed by an unknown name check whet
> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Monday, May 18, 2020 11:49 AM
> To: duanbo (C)
> Cc: GCC Patches
> Subject: Re: [PATCH] aarch64: Change the definition of Pmode [pr95182]
>
> On Sun, May 17, 2020 at 8:23 PM duanbo (C) wrote:
> >
> > Hi,
> >
On Thu, May 28, 2020 at 5:28 PM Richard Sandiford
wrote:
>
> Martin Liška writes:
> > Hi.
> >
> > There's a new patch that adds normal internal functions for the 4
> > VCOND* functions.
> >
> > The patch that survives bootstrap and regression
> > tests on x86_64-linux-gnu and ppc64le-linux-gnu.
>
Hello.
The change finds situations where somebody missing description of a change
in a ChangeLog entry.
I tested:
git gcc-verify 51e10276d6792f67f1d88d90f299e7ac1b1f1f24..HEAD -n
and it's fine for ~250 last commits.
I'll install it if there are no objections.
Thanks,
Martin
contrib/ChangeLog:
On 28.05.20 20:24, Stefan Schulze Frielinghaus wrote:
> Vector alignment hints are fully supported since z14. On z13 alignment
> hints have no effect, however, instructions with alignment hints are
> still legal. Thus, emit alignment hints also for z13 targets so that if
> the binary is actually
Hello,
libgcc is currently missing the support for unwinding over signal
trampolines on GNU/Hurd. The attached patch implements it.
Samuel
hurd: libgcc unwinding support over signal trampolines
* libgcc/config.host (md_unwind_header): Set to i386/gnu-unwind.h on
i[34567]86-*-gnu*.
* src/libgcc/c
This patch fixes a bug in which the register allocator could place
arbitrary data into the VCC (vector condition code) register, and then
use it as input to an instruction that writes condition codes there.
This would be fine except that 64 bit integers are split into high-part
and low-part op
Tested and pushed to master.
Martin
maintainer-scripts/ChangeLog:
* bugzilla-close-candidate.py: Support both SVN and GIT messages
in PRs. Remove need of usage of the bugzilla API key.
---
.../bugzilla-close-candidate.py | 50 +++
1 file changed, 2
This adds SLP_TREE_REPRESENTATIVE - a representative stmt-info that
is used by SLP analysis and code generation. This avoids the need
for the hack in vect_slp_rearrange_stmts which previously avoided
to re-arrange stmts that might not have been isomorphic because
of operand swapping. It also pl
Alex Coplan writes:
> On 19/05/2020 17:59, Richard Sandiford wrote:
>> Alex Coplan writes:
>> > Hello,
>> >
>> > This patch fixes PR94591. The problem was the function
>> > aarch64_evpc_rev_local()
>> > matching vector permutations that were not reversals. In particular, prior
>> > to
>> > this
The previous fix clashed with the rewrite to emit SLP invariants
during the SLP walk. Thus the following adjusts the SLP tree
hacking vectorizable_shift does appropriately.
Still resisting the attempt of a rewrite of vectorizable_shift ...
2020-05-29 Richard Biener
PR tree-optimizati
On Tue, May 26, 2020 at 10:44 AM Jan Hubicka wrote:
>
> Hi,
> this patch cleans up tree streaming. The code is prepared to stream nested
> trees, but we only handle flat trees. As a result we have quite heavy function
> to stream in/out tree reference which is used many times and shows up in
> pr
Hi!
cxx_eval_outermost_constant_expr had a check for reinterpret_casts from
pointers (well, it checked from ADDR_EXPRs) to integral type, but that
only caught such cases at the toplevel of expressions.
As the comment said, it should be done even inside of the expressions,
but at the point of the w
Hi,
it turns out I lost one hunk in the patch disabling extra streaming
which causes streamer to go out of sync in the case non-trivial scc
containing the node being streamed appears in local stream (which seems
quite rare since it does not happen during bootstrap).
I am regtesting on x86_64-linux
On 29/05/20 10:18 +0200, François Dumont via Libstdc++ wrote:
I added a try_emplace at the underlying _Hashtable level which I use
in both insert_or_assign and try_emplace.
I am not making any use of the hint for the moment. I'll review this
once my other hashtable patches are being validated
Simple documentation update based on usage of GIT by both
LLVM and GCC.
libsanitizer/ChangeLog:
* HOWTO_MERGE: Do not mention not existing argument.
* README.gcc: Update LLVM repository location.
---
libsanitizer/HOWTO_MERGE | 3 +--
libsanitizer/README.gcc | 16 --
Thank you.
Regards,
Dong JianQiang
> On 5/28/20 8:19 AM, Martin Liška wrote:
> > On 5/28/20 4:07 AM, dongjianqiang (A) wrote:
> >> Thanks for reviewing this. Could you please help install this patch? I am
> >> not
> a gcc commiter.
> >
> > I've just done that.
> >
> > For the next time, please a
Hi Richard,
Thanks for your comments. It's a good idea to simplify the code and remove
get_inner_reference. I've updated the patch accordingly. I also simplified the
code to ignore other loads, which can not help to check if a store can be
trapped.
About tests:
1. All previously XFAIL te
On 5/28/20 8:19 AM, Martin Liška wrote:
On 5/28/20 4:07 AM, dongjianqiang (A) wrote:
Thanks for reviewing this. Could you please help install this patch? I am not a
gcc commiter.
I've just done that.
For the next time, please add ChangeLog entries to a git commit message. We do
not
longer m
I've just tested the script and I'm going to install the patch
to all active branches.
contrib/ChangeLog:
* git-backport.py: The script did 'git co HEAD~' when
there was no modified ChangeLog file in a successful
git cherry pick.
Run cherry-pick --continue without
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
2020-05-29 Richard Biener
PR tree-optimization/95403
* tree-vect-stmts.c (vect_init_vector_1): Guard against NULL
stmt_vinfo.
* gfortran.dg/vect/pr95403.f: New testcase.
---
gcc/testsuite/gfortran.d
The assembly code in libgcc/config/riscv/div.S does not handle the division by
zero as specified in the riscv-spec v2.2 chapter 6.2 in case of signed division:
"The quotient of division by zero has all bits set, i.e. 2XLEN−1 for unsigned
division or−1 for signed division."
When a negative numbe
Hi!
As noticed by Arseny, I got the condition when to call the add removal hook
wrong wrong. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, committed to trunk.
2020-05-28 Jakub Jelinek
PR middle-end/95315
* omp-general.c (omp_resolve_declare_variant): Fi
Hi!
I have noticed we don't export these 6 symbols and thus the testcase
below fails to link.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and 10.2?
2020-05-28 Jakub Jelinek
PR libfortran/95390
* gfortran.dg/findloc_8.f90: New test.
"Kewen.Lin" writes:
> on 2020/5/27 下午6:02, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>> Hi Richard,
>>>
>>> Thanks for your comments!
>>>
>>> on 2020/5/26 锟斤拷锟斤拷8:49, Richard Sandiford wrote:
"Kewen.Lin" writes:
> @@ -626,6 +645,12 @@ public:
>/* True if have decided to u
I added a try_emplace at the underlying _Hashtable level which I use in
both insert_or_assign and try_emplace.
I am not making any use of the hint for the moment. I'll review this
once my other hashtable patches are being validated.
PR libstdc++/95079
* include/bits/ha
This makes sure to fold generated stmts so they do not survive
until RTL expansion and cause awkward code generation.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
2020-05-29 Richard Biener
PR tree-optimization/95393
* tree-ssa-phiopt.c (minmax_replacement): Use
Joe Ramsay writes:
> This patch improves code generation for EOR, ORR and AND on unpacked vectors
> with SVE. The following function:
> void f (unsigned int *x, unsigned short *y, unsigned short *z) {
> for (int i = 0; i < 7; ++i)
> x[i] = (unsigned short) (y[i] & z[i]);
> }
>
> previously
The patch is about to handle situations like seen
in 3ea6977d0f1813d982743a09660eec1760e981ec.
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Properly
handle duplicite authors.
* gcc-changelog/test_email.py: New test.
* gcc-changelog/test_patches.txt: New patch
90 matches
Mail list logo
