From: Xiong Hu Luo
Backport r268834 of "Add support for the vec_sbox_be, vec_cipher_be etc."
from mainline to gcc-8-branch.
Regression-tested on Linux POWER8 LE. Backport patch for gcc-8-branch
already got approved and commited. OK for gcc-7-branch?
gcc/ChangeLog:
2019-03-05 Xiong Hu Luo
On Tue, Mar 5, 2019 at 1:46 AM H.J. Lu wrote:
>
> On Mon, Mar 04, 2019 at 12:55:04PM +0100, Richard Biener wrote:
> > On Sun, Mar 3, 2019 at 10:13 PM H.J. Lu wrote:
> > >
> > > On Sun, Mar 03, 2019 at 06:40:09AM -0800, Andrew Pinski wrote:
> > > > )
> > > > ,On Sun, Mar 3, 2019 at 6:32 AM H.J.
On 03/04/2019 07:41 PM, Peter Bergner wrote:
On 3/4/19 4:24 PM, Peter Bergner wrote:
On 3/4/19 4:16 PM, Peter Bergner wrote:
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 269028)
+++
On Tue, Mar 5, 2019 at 11:41 AM Ian Lance Taylor wrote:
>
> This patch to the Go frontend changes from using MPFR_RNDN to using
> GMP_RNDN. This should fix the build when using MPFR 2.4.2, fixing PR
> 89598. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.
> Committed to mainline.
I
On 02/26/2019 04:23 PM, Padraig Brady wrote:
>
>> Note jemalloc >= 5.1 is required to fix a bug with 0 sizes.
>>
>> How serious is the bug? What are the symptoms?
>>
> I've updated the commit summary to say it's a crash.
> Arguably that's better than mem corruption.
>
>> It looks like 5.1.0 is
On 3/5/19 5:51 AM, Segher Boessenkool wrote:
> On Mon, Mar 04, 2019 at 06:41:16PM -0600, Peter Bergner wrote:
>> Like this. This bootstraps and regtests with no regressions. Do you prefer
>> this instead? If so, we'll need Vlad or Jeff or ... to approve the LRA
>> changes.
>
> Either solution
On 04/03/19 13:57 -0500, Ed Smith-Rowland wrote:
This is actually PR libstdc++/86655.
Thank you for reminding me Andre.
I remove the throw for m > l and just return 0. This is also done for
sph_legendre.
This build and tests clean on x86_64-linux.
OK?
OK for trunk, thanks.
Hi Harald,
To the reviewer: I am not 100% sure that my solution is correct, but it
solves the issues reported and regtests cleanly on x86_64-pc-linux-gnu.
OK for trunk? Backports?
I don't see how adding the charlen to the current namespace can hurt,
so I think this is OK.
Regarding
This libgo patch by Cherry Zhang enables precise GC checks when using
stack maps. The runtime package has bad pointer checks that currently
don't work with the conservative collector used by gccgo. With stack
maps, the GC is precise and the checks should work. Enable them.
Bootstrapped and ran
This patch by Clément Chigot changes the go tool to pass -X64 to ar on
AIX. On aix/ppc64, ar tool must always have -X64 argument if it aims
to create 64 bits archives. Bootstrapped on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On Tue, Mar 05, 2019 at 05:33:45PM -0500, Jason Merrill wrote:
> The x86_64 psABI says that an empty class isn't passed or returned in memory
> or registers, so we shouldn't set %eax in this function. This seems like a
> missed case from the GCC 8 TYPE_EMPTY_P changes.
>
> Shall I apply this for
The x86_64 psABI says that an empty class isn't passed or returned in memory
or registers, so we shouldn't set %eax in this function. This seems like a
missed case from the GCC 8 TYPE_EMPTY_P changes.
Shall I apply this for GCC 9, or hold it for stage 1?
* function.c
Hi Jakub,
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Yes (also could be considered obvious, I guess).
Thanks for the patch!
Regards
Thomas
Hi!
The following patch fixes:
../../../../libgfortran/caf/single.c: In function
‘_gfortran_caf_sendget_by_ref’:
../../../../libgfortran/caf/single.c:2813:57: warning: passing argument 3 of
‘_gfortran_caf_get_by_ref’ from incompatible pointer type
[-Wincompatible-pointer-types]
2813 |
Hi!
In this PR, Jonathan argues that we should accept value initialization of
classes with flexible array member.
The following patch does that. Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?
2019-03-05 Jakub Jelinek
PR c++/87148
* init.c
Well, this sent me down rather a rabbit hole of empty class handling.
The main problem in this testcase is that the front end expects an rvalue
COND_EXPR to initialize a single temporary from one of the arms. But
because gimplify_cond_expr used MODIFY_EXPR, instead the arms would each
create
While looking at PR86485, I noticed that many uses of is_really_empty_class
were overlooking that it returned true for a class with only a vptr;
initialization of such a class is not trivial. Marek's P1064 patch fixed
one place in constexpr.c to also check for a vtable, but there are several
On Tue, Mar 05, 2019 at 03:50:30PM -0500, Jason Merrill wrote:
> On 3/4/19 7:17 PM, Marek Polacek wrote:
> > This patch fixes a bogus -Wredundant-move warning. In the test in the PR
> > the std::move call isn't redundant; the testcase won't actually compile
> > without that call, as per the
On 3/5/19 7:44 AM, Richard Biener wrote:
> So fixing it properly with also re-optimize_stmt those stmts so we'd CSE
> the MAX_EXPR introduced by folding makes it somewhat ugly.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Any ideas how to make it less so? I can split
On 3/4/19 4:45 AM, Richard Biener wrote:
> On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote:
>>
>>
>> On Mar 1, 2019, at 1:25 PM, Richard Biener
>> wrote:
>>
>> On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao
>> wrote:
>>
>> Jeff,
>>
>> thanks a lot for the reply.
>>
>> this is really
On Mon, 4 Mar 2019 at 01:43, Ville Voutilainen
wrote:
>
> On Mon, 4 Mar 2019 at 01:26, Ville Voutilainen
> wrote:
> > I consider variant to no longer be in the state of sin after this.
>
> Sigh, except for the places where it self-destructs or placement-news
> over things that it shouldn't.
On 3/1/19 10:49 AM, Qing Zhao wrote:
> Jeff,
>
> thanks a lot for the reply.
>
> this is really helpful.
>
> I double checked the dumped intermediate file for pass “dom3", and
> located the following for _152:
>
> BEFORE the pass “dom3”, there is no _152, the corresponding Block
> looks
On 3/4/19 5:35 PM, Jakub Jelinek wrote:
Hi!
output_view_list_offset does:
if (dwarf_split_debug_info)
dw2_asm_output_delta (DWARF_OFFSET_SIZE, sym, loc_section_label,
"%s", dwarf_attr_name (a->dw_attr));
else
dw2_asm_output_offset (DWARF_OFFSET_SIZE,
On 3/5/19 4:03 PM, Jason Merrill wrote:
On 3/5/19 3:14 PM, Jakub Jelinek wrote:
On Thu, Jan 10, 2019 at 11:07:37AM +0100, Jakub Jelinek wrote:
2019-01-10 Jakub Jelinek
PR c/88568
* attribs.c (handle_dll_attribute): Clear TREE_STATIC after setting
DECL_EXTERNAL.
*
On 3/5/19 3:14 PM, Jakub Jelinek wrote:
On Thu, Jan 10, 2019 at 11:07:37AM +0100, Jakub Jelinek wrote:
2019-01-10 Jakub Jelinek
PR c/88568
* attribs.c (handle_dll_attribute): Clear TREE_STATIC after setting
DECL_EXTERNAL.
* gcc.dg/pr88568.c: New test.
---
On 3/4/19 7:17 PM, Marek Polacek wrote:
This patch fixes a bogus -Wredundant-move warning. In the test in the PR
the std::move call isn't redundant; the testcase won't actually compile
without that call, as per the resolution of bug 87150.
Before this patch, we'd issue the redundant-move
On Tue, Mar 5, 2019 at 1:02 AM Uros Bizjak wrote:
>
> > I've committed this patch to update to the final Go 1.12 release.
> > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
> > to mainline.
>
> This patch introduced following failure in CentOS 5.11:
>
>
The attached patch addresses ICEs on several situations with zero-length
arrays of strings or zero-length substrings, which were caused by a NULL
pointer dereference in those particular situations.
To the reviewer: I am not 100% sure that my solution is correct, but it
solves the issues reported
Arno,
OK.
--S
> On 5 Mar 2019, at 20:38, Arnaud Charlet wrote:
>
> Simon,
>
> Thanks for the patch.
> We already have a fix pending for that in our tree that we will merge.
>
> Arno
>
>> On 4 Mar 2019, at 20:48, Simon Wright wrote:
>>
>> With GCC9, GNAT.Sockets includes support for IPv6.
Simon,
Thanks for the patch.
We already have a fix pending for that in our tree that we will merge.
Arno
> On 4 Mar 2019, at 20:48, Simon Wright wrote:
>
> With GCC9, GNAT.Sockets includes support for IPv6. Sockaddr is an
> Unchecked_Union, which now includes IPv6 fields, bringing the total
On Thu, Jan 10, 2019 at 11:07:37AM +0100, Jakub Jelinek wrote:
> 2019-01-10 Jakub Jelinek
>
> PR c/88568
> * attribs.c (handle_dll_attribute): Clear TREE_STATIC after setting
> DECL_EXTERNAL.
>
> * gcc.dg/pr88568.c: New test.
>
> --- gcc/attribs.c.jj 2019-01-05
This patch to the Go frontend changes from using MPFR_RNDN to using
GMP_RNDN. This should fix the build when using MPFR 2.4.2, fixing PR
89598. Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
The implementation of midpoint used for integral types is due to Howard
Hinnant and avoids a branch for int and larger types (but not for chars
and shorts).
The midpoint and lerp functions for floating point types come straight
from the P0811R3 proposal, with no attempt at optimization.
On Tue, Mar 05, 2019 at 11:10:20AM -0600, Segher Boessenkool wrote:
> On Tue, Mar 05, 2019 at 04:22:17PM +0100, Jakub Jelinek wrote:
> > powerpc-linux-gnu is apparently the only target that provides
> > MULTIARCH_DIRNAME unconditionally,
>
> (Unless building with default CPU a 4xx or 8xx or
> On Mar 5, 2019, at 8:44 AM, Richard Biener wrote:
>
will you commit this fix to gcc9 and gcc8 (we need it in gcc8)?
>>>
>>> I'll see to carve out some cycles trying to find a testcase and amend
>>> the fix a bit
>>> and will take care of testing/submitting the fix. Thanks
Hi,
On Tue, Mar 05, 2019 at 04:22:17PM +0100, Jakub Jelinek wrote:
> powerpc-linux-gnu is apparently the only target that provides
> MULTIARCH_DIRNAME unconditionally,
(Unless building with default CPU a 4xx or 8xx or similar embedded. Which
doesn't seem right, oh well).
> all others properly
> On Mar 5, 2019, at 4:44 AM, Richard Biener wrote:
>
>>>
>>> will you commit this fix to gcc9 and gcc8 (we need it in gcc8)?
>>
>> I'll see to carve out some cycles trying to find a testcase and amend
>> the fix a bit
>> and will take care of testing/submitting the fix. Thanks for testing
On 04/03/19 01:26 +0200, Ville Voutilainen wrote:
On Wed, 6 Feb 2019 at 15:12, Ville Voutilainen
wrote:
And, to emphasize, the most important reason for this was to be able
to write straightforward
code for the special member functions, with the hope that it wouldn't
have a negative codegen
On March 5, 2019 4:18:13 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>When adding this warning years ago, I forgot to verify number of
>arguments.
>
>Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for
>trunk?
OK.
Richard.
>2019-03-05 Jakub Jelinek
>
> PR
On Tue, 5 Mar 2019 at 16:17, Rainer Orth wrote:
>
> Hi Christophe,
>
> I know I'm coming quite late to this, but I've got quite a number of
> problems with your approach.
Thanks for your feedback
> > dg-extract-results currently moves lines like
> > WARNING: program timed out
> > at the end of
On 3/5/19 7:14 AM, Martin Liška wrote:
Hi.
The patch extends option suggestion for both -Werror and corresponding
pragram.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed after stage1 opens?
Thanks,
Martin
gcc/ChangeLog:
2019-03-05 Martin Liska
On 05.03.19 16:22, Jakub Jelinek wrote:
> Hi!
>
> powerpc-linux-gnu is apparently the only target that provides
> MULTIARCH_DIRNAME unconditionally, all others properly wrap that with
> if_multiarch, which decides if it should be used (--enable-multiarch,
> or if the test for automatic multiarch
On Tue, Mar 05, 2019 at 04:53:54PM +0100, Martin Liška wrote:
> Hi.
>
> The param was added by Jakub. Should I mention it in invoke.texi?
It is meant solely for the testsuite, so I wouldn't document it.
But if others disagree, I'm not strongly opposed to that, but we then should
say so in the
On Mon, Mar 04, 2019 at 11:19:34PM -0600, Xiong Hu Luo wrote:
> Backport r268834 of "Add support for the vec_sbox_be, vec_cipher_be etc."
> from mainline to gcc-8-branch.
>
> Regression-tested on Linux POWER8 LE. OK for gcc-8-branch?
Yes, okay for 8. Thanks!
> PS: Is backport to gcc-7-branch
Hi.
The param was added by Jakub. Should I mention it in invoke.texi?
Thanks,
Martin
gcc/ChangeLog:
2019-03-05 Martin Liska
* doc/invoke.texi: Mention logical-op-non-short-circuit
param.
---
gcc/doc/invoke.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi!
powerpc-linux-gnu is apparently the only target that provides
MULTIARCH_DIRNAME unconditionally, all others properly wrap that with
if_multiarch, which decides if it should be used (--enable-multiarch,
or if the test for automatic multiarch succeeds), or should be empty
(--disable-multiarch,
Hi!
When adding this warning years ago, I forgot to verify number of arguments.
Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
2019-03-05 Jakub Jelinek
PR middle-end/89590
* builtins.c (maybe_emit_free_warning): Punt if free doesn't have
Hi Christophe,
I know I'm coming quite late to this, but I've got quite a number of
problems with your approach.
> dg-extract-results currently moves lines like
> WARNING: program timed out
> at the end of each .exp section when it generates .sum files.
This is only true when
On Mon, Mar 04, 2019 at 06:41:16PM -0600, Peter Bergner wrote:
> Like this. This bootstraps and regtests with no regressions. Do you prefer
> this instead? If so, we'll need Vlad or Jeff or ... to approve the LRA
> changes.
Either solution is fine with me, whatever the LRA experts prefer.
Hi Christophe,
> On Tue, 19 Feb 2019 at 10:28, Christophe Lyon
> wrote:
>>
>> On Mon, 18 Feb 2019 at 21:12, Rainer Orth
>> wrote:
>> >
>> > Hi Christophe,
>> >
>> > > dg-extract-results currently moves lines like
>> > > WARNING: program timed out
>> > > at the end of each .exp section when it
On Tue, 2019-03-05 at 15:42 +0100, Martin Liška wrote:
> On 3/5/19 3:21 PM, David Malcolm wrote:
> > On Tue, 2019-03-05 at 15:14 +0100, Martin Liška wrote:
> > > Hi.
> > >
> > > The patch extends option suggestion for both -Werror and
> > > corresponding
> > > pragram.
> > >
> > > Patch can
On Tue, 5 Mar 2019, Richard Biener wrote:
> On Tue, 5 Mar 2019, Martin Jambor wrote:
>
> > Hi,
> >
> > after looking into the three PRs I found that the problem is the same in
> > all of them, introduced in revision 255510, with SRA treating completely
> > non type-punning MEM_REFs to a filed
On 3/5/19 3:47 PM, David Malcolm wrote:
> On Tue, 2019-03-05 at 15:14 +0100, Martin Liška wrote:
>> Hi.
>>
>> The patch extends option suggestion for both -Werror and
>> corresponding
>> pragram.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests.
>>
>> Ready to be
On Tue, 5 Mar 2019, Martin Jambor wrote:
> Hi,
>
> after looking into the three PRs I found that the problem is the same in
> all of them, introduced in revision 255510, with SRA treating completely
> non type-punning MEM_REFs to a filed of a structure as a V_C_E (these
> are typically
On Tue, 2019-03-05 at 15:14 +0100, Martin Liška wrote:
> Hi.
>
> The patch extends option suggestion for both -Werror and
> corresponding
> pragram.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
>
> Ready to be installed after stage1 opens?
> Thanks,
> Martin
>
>
On Tue, Mar 5, 2019 at 11:44 AM Richard Biener
wrote:
>
> On Tue, Mar 5, 2019 at 10:48 AM Richard Biener
> wrote:
> >
> > On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote:
> > >
> > > Hi, Richard,
> > >
> > > > On Mar 4, 2019, at 5:45 AM, Richard Biener
> > > > wrote:
> > > >>
> > > >> It
On 3/5/19 3:21 PM, David Malcolm wrote:
> On Tue, 2019-03-05 at 15:14 +0100, Martin Liška wrote:
>> Hi.
>>
>> The patch extends option suggestion for both -Werror and
>> corresponding
>> pragram.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression
>> tests.
>>
>> Ready to be
Hi,
after looking into the three PRs I found that the problem is the same in
all of them, introduced in revision 255510, with SRA treating completely
non type-punning MEM_REFs to a filed of a structure as a V_C_E (these
are typically introduced by inlining tiny C++ getters/setters and other
On Tue, 2019-03-05 at 15:14 +0100, Martin Liška wrote:
> Hi.
>
> The patch extends option suggestion for both -Werror and
> corresponding
> pragram.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
>
> Ready to be installed after stage1 opens?
> Thanks,
> Martin
Hi.
The patch basically simplifies documentation as pointed in the PR.
I'll install the patch if there's no objection.
Thanks,
Martin
gcc/ChangeLog:
2019-03-05 Martin Liska
PR gcov-profile/89577
* doc/gcov.texi: Prefer to use --coverage.
* doc/sourcebuild.texi:
Hi.
The patch extends option suggestion for both -Werror and corresponding
pragram.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed after stage1 opens?
Thanks,
Martin
gcc/ChangeLog:
2019-03-05 Martin Liska
* opts.c
On 3/5/19 5:25 AM, Segher Boessenkool wrote:
> But, it seems you need to keep track of other things on the side for LRA?
The extra LRA info is to keep track of scratches that are not needed.
In our case, only the one alternative in movsf_from_si requires a
scratch register. The rest use an X
On Mon, Mar 04, 2019 at 02:41:32PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 04, 2019 at 05:33:41AM -0800, H.J. Lu wrote:
> > > > PR tree-optimization/89487
> > > > * gcc/testsuite/gcc.dg/tree-ssa/pr89487.c: New test.
> >
> > gcc.dg/tree-ssa/pr89487.c:
> >
> > /* { dg-do compile
I am testing the following for PR89594.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-03-05 Richard Biener
PR tree-optimization/89594
* tree-if-conv.c (pass_if_conversion::execute): Handle
case where .LOOP_VECTORIZED_FUNCTION was removed.
On 05/03/2019 12:33, Wilco Dijkstra wrote:
ping
From: Wilco Dijkstra
Sent: 13 February 2019 12:23
To: Ramana Radhakrishnan
Cc: GCC Patches; nd; Olivier Hainque
Subject: Re: [PATCH][ARM] Fix PR89222
Hi Ramana,
ARMv5te bootstrap OK, regression tests pass. OK for commit?
Interesting
ping
From: Wilco Dijkstra
Sent: 13 February 2019 12:23
To: Ramana Radhakrishnan
Cc: GCC Patches; nd; Olivier Hainque
Subject: Re: [PATCH][ARM] Fix PR89222
Hi Ramana,
>> ARMv5te bootstrap OK, regression tests pass. OK for commit?
>
> Interesting bug. armv5te-linux bootstrap ? Can you
Jakub Jelinek writes:
> On Tue, Mar 05, 2019 at 09:26:19AM +, Richard Sandiford wrote:
>> LGTM, thanks. Given the discussion, I think it would also be worth having
>> a comment explaining why we're doing this, something like:
>>
>> /* Avoid speculatively generating a stand-alone vector
On 4 Mar 2019, at 19:48, Simon Wright wrote:
> With GCC9, GNAT.Sockets includes support for IPv6. Sockaddr is an
> Unchecked_Union, which now includes IPv6 fields, bringing the total possible
> size to 28 bytes. The code in Bind_Socket currently calculates the length of
> the struct sockaddr
Hi Peter,
On Mon, Mar 04, 2019 at 04:16:23PM -0600, Peter Bergner wrote:
> On 3/4/19 1:27 PM, Segher Boessenkool wrote:
> >> + /* If LRA is generating a direct move from a GPR to a FPR,
> >> + then the splitter is going to need a scratch register. */
> >> + rtx insn =
On Tue, Mar 5, 2019 at 10:48 AM Richard Biener
wrote:
>
> On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote:
> >
> > Hi, Richard,
> >
> > > On Mar 4, 2019, at 5:45 AM, Richard Biener
> > > wrote:
> > >>
> > >> It looks like DOM fails to visit stmts generated by simplification. Can
> > >> you
On Mon, Mar 4, 2019 at 11:01 PM Qing Zhao wrote:
>
> Hi, Richard,
>
> > On Mar 4, 2019, at 5:45 AM, Richard Biener
> > wrote:
> >>
> >> It looks like DOM fails to visit stmts generated by simplification. Can
> >> you open a bug report with a testcase?
> >>
> >>
> >> The problem is, It took me
On Tue, Mar 05, 2019 at 09:26:19AM +, Richard Sandiford wrote:
> LGTM, thanks. Given the discussion, I think it would also be worth having
> a comment explaining why we're doing this, something like:
>
> /* Avoid speculatively generating a stand-alone vector comparison
> on targets
Jakub Jelinek writes:
> On Tue, Mar 05, 2019 at 08:53:00AM +, Richard Sandiford wrote:
>> Sorry, commented on the bug before seeing this patch.
>
> Sorry, I've committed before seeing your comment in the PR
> (and responded there after seeing it).
>
>> I don't think this is the way to go
On Tue, 5 Mar 2019, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > Hi!
> >
> > As the following testcase shows, these match.pd patterns create temporary
> > GIMPLE stmts even when they aren't going to result in anything useful
> > (all targets except aarch64 right now), besides compile
On Tue, Mar 05, 2019 at 08:53:00AM +, Richard Sandiford wrote:
> Sorry, commented on the bug before seeing this patch.
Sorry, I've committed before seeing your comment in the PR
(and responded there after seeing it).
> I don't think this is the way to go though. If we want match.pd
> rules
Hello!
> I've committed this patch to update to the final Go 1.12 release.
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
> to mainline.
This patch introduced following failure in CentOS 5.11:
syscall_linux_test.go:381:11: error: reference to undefined field or
method
Jakub Jelinek writes:
> Hi!
>
> As the following testcase shows, these match.pd patterns create temporary
> GIMPLE stmts even when they aren't going to result in anything useful
> (all targets except aarch64 right now), besides compile time memory
> this is bad with -fno-tree-dce because those
On Tue, 5 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> My earlier change to fold_checksum_tree unfortunately can result in buffer
> overflow for CALL_EXPRs with TREE_NO_WARNING bit set and more than 21
> arguments, because the code used fixed size 216 byte (on x86_64) buffer
> and CALL_EXPR is
On Mon, 4 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> Before PR87041 changes sprintf_dom_walker::handle_gimple_call
> would punt if gimple_call_builtin_p (which did all the needed call argument
> checking) failed, but it doesn't fail anymore because it wants to handle
> format attribute. That is
On Mon, 4 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows, these match.pd patterns create temporary
> GIMPLE stmts even when they aren't going to result in anything useful
> (all targets except aarch64 right now), besides compile time memory
> this is bad with
Hi!
My earlier change to fold_checksum_tree unfortunately can result in buffer
overflow for CALL_EXPRs with TREE_NO_WARNING bit set and more than 21
arguments, because the code used fixed size 216 byte (on x86_64) buffer
and CALL_EXPR is variable length size 48 + nargs*8.
Which means at least
81 matches
Mail list logo
