PING^1
On 2/10/19 6:21 PM, Jan Hubicka wrote:
> Hi,
> build_qualified_type adjusts alignment of atomic types to one of minimal
> alignment needed for atomic operations (I think it does so). For packed
> structures this leads to type variant to be created and alignment to be
> updated later.
>
> I
This Go frontend patch by Ben Shi checks for duplicate numeric keys in
map literals. This is for https://golang.org/issue/28104.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
On 2/26/19 5:18 PM, Segher Boessenkool wrote:
> On Tue, Feb 26, 2019 at 04:58:17PM -0700, Jeff Law wrote:
>> On 2/26/19 4:19 PM, Segher Boessenkool wrote:
>>> On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
>> For gcc-10 we should:
>>
>> 1. Avoid really stupid stuff in init-regs.
>>
>>
From: Kito Cheng
Kito Cheng
Monk Chiang
ChangeLog:
gcc:
* common/config/riscv/riscv-common.c:
Include config/riscv/riscv-protos.h.
(INCLUDE_STRING): Defined.
(RISCV_DONT_CARE_VERSION): Defined.
(riscv_subset_t): Declare.
(riscv_subset_t::riscv_
This version 2 of patch series for of RISC-V ELF attribute[1], first version
can be found in[2-4].
Most changes between last version is typo fixing and coding sytle fix, and a
missing re-generated
configure file.
[1] https://github.com/riscv/riscv-elf-psabi-doc/pull/71
[2] [PATCH 0/2] RISC-V: Su
From: Kito Cheng
This patch added a configure time option,
--with-riscv-attribute=[yes|no|default],
run time option, -mriscv-attribute to control the output of ELF attribute.
This feature is only enabled by default for ELF/Bare mental target
configuration.
Kito Cheng
Monk Chiang
ChangeLog
This patch by Ben Shi fixes the Go frontend to check for recursive
inherited interface aliases. This avoids a compiler crash as
described at https://golang.org/issue/25302. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
Please disregard the original patch and consider the attached
version instead.
On 2/26/19 5:03 PM, Martin Sebor wrote:
The false positive in PR89350 is due to -Wstringop-overflow
trusting that the sizetype offset in POINTER_PLUS_EXPR means
the offset is, in fact, unsigned. Avoiding the false po
This libgo patch fixes the cmd/g TestScript test to preserve the CC
environment variable for TestScript child processes, so that tests
that use cgo will act as expected. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
On 02/26/2019 05:50 AM, Jonathan Wakely wrote:
> On 23/02/19 02:04 +, Pádraig Brady wrote:
>> Attached is a simple patch which has been extensively tested within
>> Facebook,
>> and is enabled by default in our code base.
>>
>> Passing the size to the allocator allows it to optimize deallocat
On Tue, Feb 26, 2019 at 04:58:17PM -0700, Jeff Law wrote:
> On 2/26/19 4:19 PM, Segher Boessenkool wrote:
> > On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
> For gcc-10 we should:
>
> 1. Avoid really stupid stuff in init-regs.
>
> 2. Avoid really stupid stuff in the splitters.
>
The false positive in PR89350 is due to -Wstringop-overflow
trusting that the sizetype offset in POINTER_PLUS_EXPR means
the offset is, in fact, unsigned. Avoiding the false positive
in the cases when this isn't so is trivial but comes at a cost
of false negatives. Avoiding those will, I expect,
Hi Harald,
On Tue, Feb 26, 2019 at 09:09:53PM +0100, Harald Anlauf wrote:
> @Dominique: I am unable to close PRs in bugzilla that I do not own
> due to insufficient privileges.
You need to log in to bugzilla as anl...@gcc.gnu.org, then everything
should work.
Segher
On 2/26/19 4:19 PM, Segher Boessenkool wrote:
> On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
>> As we enter regcprop we have the following horrific RTL:
(insn 35 7 36 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
(const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
(
On Tue, Feb 26, 2019 at 10:07:54AM -0700, Jeff Law wrote:
> As we enter regcprop we have the following horrific RTL:
> >> (insn 35 7 36 2 (set (reg:DI 2 $2 [orig:200 x ] [200])
> >> (const_int 0 [0])) "j.c":8:49 313 {*movdi_64bit}
> >> (nil))
> >> (insn 36 35 10 2 (set (reg:DI 3 $3 [ x
The Compare, Hash, and Pred template parameters should be constrained in
the C++17 deduction guides for associative and unordered containers.
The deduction guides for stack, queue and priority_queue are already
constrained, but this patch makes them use the _RequireNotAllocator
helper instead of
Here we ICE because the unscoped enum's context is a FUNCTION_DECL, which
push_using_decl can't handle.
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1742
says this is well-formed (but the scoped enum case is ill-formed).
Nevertheless, the DR hasn't been resolved either way yet, and
On 2/26/19 3:44 PM, Jakub Jelinek wrote:
Hi!
Seems valid_constant_size_p has been written with the expectation that only
sizetype/ssizetype constants will be passed to it, otherwise it couldn't
ever just blindly test tree_int_cst_sign_bit (size) for unsigned
INTEGER_CSTs and complain cst_size_to
On 2/26/19 11:02 AM, Paolo Carlini wrote:
Hi,
On 26/02/19 15:28, Jason Merrill wrote:
On 2/25/19 10:27 AM, Paolo Carlini wrote:
Hi,
this error recovery regression has to do with the recent changes
committed by Jason for c++/88368. What happens is that
maybe_instantiate_noexcept fails the ha
On 2/26/19 10:22 AM, Paolo Carlini wrote:
Hi,
On 26/02/19 15:33, Jason Merrill wrote:
On 2/26/19 5:42 AM, Paolo Carlini wrote:
Hi,
the issue is rather easy to explain: after Alexandre' change in
r266874, which simplified the condition at the beginning of
build_noexcept_spec to evaluate ear
--help=target -Q currently outputs the memory model but not the code model,
because the former is entirely handled by the option machinery while the
latter is partially handled manually; this patch fixes this discrepancy.
Tested on SPARC/Solaris and SPARC64/Linux, applied on the mainline.
2019
On Tue, Feb 26, 2019 at 05:18:17PM +0100, Jakub Jelinek wrote:
> > > Shall I modify the patch for that?
> >
> > Might it even simplify the patch? If not the only comment on the
> > original patch is that it would be nice to test it on a SJLJ EH
> > target ...
>
> 1 file changed, 29 insertions(+
On Tue, 26 Feb 2019, Tom de Vries wrote:
>>> Specifically I am now seeing
>>>
>>> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
>>> needed by 'b3test_dwz_buildid.log'.
> The only way of reproducing it was to deinstall dwz.
:
> Fixed in patch below, committed as trivial.
Great, th
Hi!
Seems valid_constant_size_p has been written with the expectation that only
sizetype/ssizetype constants will be passed to it, otherwise it couldn't
ever just blindly test tree_int_cst_sign_bit (size) for unsigned
INTEGER_CSTs and complain cst_size_too_big.
Unfortunately a recent patch started
On 24/02/19 15:46 +, Jonathan Wakely wrote:
On 21/02/19 20:47 +, Jonathan Wakely wrote:
On 05/02/19 14:45 +, Jonathan Wakely wrote:
This fixes two PRs, one trivial (don't use C++17 features in C++11
mode) and one more serious (don't require MoveInsertable when we
should only need Co
Committed as rev. 269227 after confirmation by Dominique:
https://gcc.gnu.org/ml/fortran/2019-02/msg00229.html
Thanks for the quick review.
Harald
@Dominique: I am unable to close PRs in bugzilla that I do not own
due to insufficient privileges.
On 02/25/19 22:49, Harald Anlauf wrote:
> Rev. 2
Gerald,
now modules and coroutines are slated to be in C++20, here's a doc patch
for them, pointing at their respective wiki pages.
ok?
nathan
--
Nathan Sidwell
? stat.diff
Index: htdocs/projects/cxx-status.html
===
RCS file: /cvs
On February 26, 2019 6:50:13 PM GMT+01:00, "Martin Liška"
wrote:
>On 2/26/19 4:02 PM, Richard Biener wrote:
>> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
>>>
>>> Hi.
>>>
>>> I've rewritten bitmap memory statistics which abused unsigned
>>> type via register_overhead (map, -((int)sizeof
On Tue, Feb 26, 2019 at 07:16:21PM +0100, Uros Bizjak wrote:
> Attached patch removes following warning:
>
> libgfortran/io/transfer.c: In function ‘transfer_array_inner’:
> libgfortran/io/transfer.c:2499:35: warning: operand of ?: changes
> signedness from ‘long int’ to ‘size_t’ {aka ‘long unsign
Attached patch removes following warning:
libgfortran/io/transfer.c: In function ‘transfer_array_inner’:
libgfortran/io/transfer.c:2499:35: warning: operand of ?: changes
signedness from ‘long int’ to ‘size_t’ {aka ‘long unsigned int’} due
to unsignedness of other operand [-Wsign-compare]
There i
On 2/26/19 4:02 PM, Richard Biener wrote:
> On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
>>
>> Hi.
>>
>> I've rewritten bitmap memory statistics which abused unsigned
>> type via register_overhead (map, -((int)sizeof (bitmap_head))).
>> I come up with a concept that each bitmap has assigned
2019-02-26 Uroš Bizjak
* doc/extend.texi (__builtin_object_size):
Use @pxref instead of @xref inside parenthesis.
(__builtin_has_attribute): Add missing comma after @xref.
(__builtin_object_size): Ditto.
* doc/md.texi (cond_*{mode}): Use @samp instead of @var around op1[i].
This is the first of either 2 (possibly 3) patches to address the
fix-r4000-10 regression in BZ87761.
There's a bit of winding path to get to the code quality regression and
some things we can and should do for gcc-10 (smarter splitters, avoid
stupid code from init-regs).
Even if those issues ear
Steve Ellcey writes:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 91e79d3..b8125d5 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -18722,6 +18722,17 @@ aarch64_comp_type_attributes (const_tree type1,
> const_tree type2)
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> On Tue, Feb 26, 2019 at 04:08:21PM +0100, Richard Biener wrote:
> > I think we can have multiple .ABNORMAL_DISPATCHERs - at least in theory
> > via inlining, though I see code in the inliner avoiding multiple ones
> > at least for nonlocal goto, not sure
Alejandro Martinez Vicente writes:
> Hi,
>
> Some of the narrowing/widening FP converts were missing from SVE. I fixed most
> of them, so they can be vectorized. The ones missing are int64->fp16 and
> fp16->int64.
>
> I extended the tests to cover the cases that were missing.
>
> I validated the p
Ping.
Steve Ellcey
sell...@marvell.com
On Mon, 2019-02-11 at 10:46 -0800, Steve Ellcey wrote:
> On Thu, 2019-02-07 at 18:13 +, Wilco Dijkstra wrote
> >
> > Hi Steve,
> >
> > > > After special cases you could do something like t = mask2 +
> > > > (HWI_1U << shift);
> > > > return t == (t &
On Tue, 2019-02-26 at 10:17 +, Richard Sandiford wrote:
>
> I'm torn about about whether we should proactively add the ILP32 and
> big-endian conditions now or wait until there's a specific need.
> Unless anyone strongly objects, let's keep them for now.
>
> Thanks,
> Richard
OK, here is a n
On Tue, Feb 26, 2019 at 04:08:21PM +0100, Richard Biener wrote:
> I think we can have multiple .ABNORMAL_DISPATCHERs - at least in theory
> via inlining, though I see code in the inliner avoiding multiple ones
> at least for nonlocal goto, not sure if that covers all cases.
Ok.
> > Shall I modify
Hi,
On 26/02/19 15:28, Jason Merrill wrote:
On 2/25/19 10:27 AM, Paolo Carlini wrote:
Hi,
this error recovery regression has to do with the recent changes
committed by Jason for c++/88368. What happens is that
maybe_instantiate_noexcept fails the hard way, thus, toward the end
of the functi
Hi,
Some of the narrowing/widening FP converts were missing from SVE. I fixed most
of them, so they can be vectorized. The ones missing are int64->fp16 and
fp16->int64.
I extended the tests to cover the cases that were missing.
I validated the patch with self-checking and running the new SVE tes
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.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 26921
Hi,
On 26/02/19 15:33, Jason Merrill wrote:
On 2/26/19 5:42 AM, Paolo Carlini wrote:
Hi,
the issue is rather easy to explain: after Alexandre' change in
r266874, which simplified the condition at the beginning of
build_noexcept_spec to evaluate early all the expressions which
aren't deferr
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> On Sat, Feb 23, 2019 at 10:05:40AM +0100, Jakub Jelinek wrote:
> > And finally, for 1) the patch has a case for a dead .ABNORMAL_DISPATCHER,
> > one that has only incoming edges but no successors. I didn't want to
> > complicate or slow down the process
On Tue, Feb 26, 2019 at 3:30 PM Martin Liška wrote:
>
> Hi.
>
> I've rewritten bitmap memory statistics which abused unsigned
> type via register_overhead (map, -((int)sizeof (bitmap_head))).
> I come up with a concept that each bitmap has assigned a unique ID
> which is used for stats tracking. I
> On Tue, Feb 26, 2019 at 3:25 PM Martin Liška wrote:
> >
> > Hi.
> >
> > It's a legacy file that is out of current build system. I tried
> > to fix compilation errors, but it crashes early after start.
> >
> > May I remove the file?
>
> yeah, it's probably just left over by accident.
I think it
On Tue, Feb 26, 2019 at 6:27 AM Tom de Vries wrote:
>
> On 26-02-19 13:00, Thomas Schwinge wrote:
> > Hi Tom!
> >
> > On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries wrote:
> >> On 26-02-19 10:40, Thomas Schwinge wrote:
> >>> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries wrote:
> On 25-
On Tue, Feb 26, 2019 at 3:27 PM Martin Liška wrote:
>
> Hi.
>
> The patch is fixing an error in vec_safe_grow_cleared function.
> Apart from that I improved readability of the report.
>
> Patch bootstrap with --enable-gather-detailed-mem-stats.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
On Tue, Feb 26, 2019 at 3:25 PM Martin Liška wrote:
>
> Hi.
>
> It's a legacy file that is out of current build system. I tried
> to fix compilation errors, but it crashes early after start.
>
> May I remove the file?
yeah, it's probably just left over by accident.
Richard.
> Thanks,
> Martin
>
Hi all,
This fixes a typo and removes the "with cases" from "as a switch
statement with cases" as that's redundant.
Checked output on Firefox.
Committing as obvious.
Thanks,
Kyrill
Index: htdocs/gcc-9/changes.html
===
RCS file:
For the libgo implementation nanotime is always defined in C, so
remove build tags so that it is always declared in Go. This is for PR
86535. Bootstrapped and tested on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
On Sat, Feb 23, 2019 at 10:05:40AM +0100, Jakub Jelinek wrote:
> And finally, for 1) the patch has a case for a dead .ABNORMAL_DISPATCHER,
> one that has only incoming edges but no successors. I didn't want to
> complicate or slow down the processing too much, so it is actually done
> only if .ABN
On 2/26/19 5:42 AM, Paolo Carlini wrote:
Hi,
the issue is rather easy to explain: after Alexandre' change in
r266874, which simplified the condition at the beginning of
build_noexcept_spec to evaluate early all the expressions which aren't
deferred or value-dependent, we obviously ICE during
Hi.
I've rewritten bitmap memory statistics which abused unsigned
type via register_overhead (map, -((int)sizeof (bitmap_head))).
I come up with a concept that each bitmap has assigned a unique ID
which is used for stats tracking. It's caused by fact that e.g. DF is
heavily reallocating bitmaps th
On 2/25/19 5:45 PM, Jakub Jelinek wrote:
Hi!
cxx_eval_store_expression has code to propagate no_zero_init from outer
ctors to inner ctors, if the outer ctor is known to be zero initialized, the
inner one should be as well.
As the following patch shows, when changing active union member there ne
On 2/25/19 10:27 AM, Paolo Carlini wrote:
Hi,
this error recovery regression has to do with the recent changes
committed by Jason for c++/88368. What happens is that
maybe_instantiate_noexcept fails the hard way, thus, toward the end of
the function, doesn't update TREE_TYPE (fn) and just ret
On 26-02-19 13:00, Thomas Schwinge wrote:
> Hi Tom!
>
> On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries wrote:
>> On 26-02-19 10:40, Thomas Schwinge wrote:
>>> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries wrote:
On 25-02-19 11:48, Thomas Schwinge wrote:
> On Fri, 8 Feb 2019 10:42:2
Hi.
The patch is fixing an error in vec_safe_grow_cleared function.
Apart from that I improved readability of the report.
Patch bootstrap with --enable-gather-detailed-mem-stats.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2019-02-26 Martin Liska
* alloc-pool.h (struct poo
Hi.
It's a legacy file that is out of current build system. I tried
to fix compilation errors, but it crashes early after start.
May I remove the file?
Thanks,
Martin
lto-plugin/ChangeLog:
2019-02-26 Martin Liska
* lto-symtab.c: Remove.
---
lto-plugin/lto-symtab.c | 359 ---
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.
Richard.
2019-02-26 Richard Biener
PR tree-optimization/89505
* tree-ssa-structalias.c (compute_dependence_clique): Make sure
to handle restrict pointed-to vars with multiple subvars
On Tue, 26 Feb 2019, Jakub Jelinek wrote:
> On Mon, Feb 25, 2019 at 04:55:56PM -0700, Martin Sebor wrote:
> > Storing the strnlen result is intentional when it equals strlen.
>
> For the *si update, you never want to do that for strnlen.
> And for the strlen_to_stridx, while I don't think it is t
Hi Chung-Lin!
On Tue, 26 Feb 2019 01:49:09 +0800, Chung-Lin Tang
wrote:
> I have incorporated all your patches you've included in the last mail (with
> some modifications, though pretty minor I think).
OK, thanks, that's good for next GCC development stage 1 as far as I'm
concerned, and Tom has
On 23/02/19 02:04 +, Pádraig Brady wrote:
Attached is a simple patch which has been extensively tested within
Facebook,
and is enabled by default in our code base.
Passing the size to the allocator allows it to optimize deallocation,
and this was seen to significantly reduce the work require
Hi,
On Wed, Feb 13 2019, Martin Jambor wrote:
> Hi Gerald and Martin,
>
> On Mon, Jan 28 2019, Gerald Pfeifer wrote:
>> Hi Martin,
>>
>> On Sat, 26 Jan 2019, Martin Jambor wrote:
What is a "wrong absolute value function"? That might be good to
show by means of an example? (Also in invo
On Mon, Feb 25, 2019 at 04:55:56PM -0700, Martin Sebor wrote:
> Storing the strnlen result is intentional when it equals strlen.
For the *si update, you never want to do that for strnlen.
And for the strlen_to_stridx, while I don't think it is that important,
here is an updated patch that handles
Hi Tom!
On Tue, 26 Feb 2019 12:28:34 +0100, Tom de Vries wrote:
> On 26-02-19 10:40, Thomas Schwinge wrote:
> > On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries wrote:
> >> On 25-02-19 11:48, Thomas Schwinge wrote:
> >>> On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries wrote:
> Add libbackt
On 26-02-19 10:40, Thomas Schwinge wrote:
> Hi Tom!
>
> On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries wrote:
>> On 25-02-19 11:48, Thomas Schwinge wrote:
>>> On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries wrote:
Add libbacktrace test-case using -flto.
>>>
>>> I'm seeing this one fail is
> * rtlanal.c (get_initial_register_offset): Fall back to the raw estimate
> as long as the epilogue isn't completed.
I have backported it onto the 8 branch, where it fixes the failure (timeout)
of gnat.dg/opt73.adb for PowerPC/Linux, after testing it on this platform.
--
Eric Botca
Boostrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-02-26 Richard Biener
PR tree-optimization/89489
* tree-parloops.c (create_loop_fn): Copy over last_clique.
Index: gcc/tree-parloops.c
===
On Mon, 25 Feb 2019, Kyrill Tkachov wrote:
> Here's a wwwdocs patch mentioning the recently-added support for the Arm
> Neoverse N1 and Neoverse E1 processors. Checked the output on Firefox.
>
> Ok to commit (from an aarch64 perspective)?
Looks good to me, just...
> +Support has been added
Hi,
the issue is rather easy to explain: after Alexandre' change in
r266874, which simplified the condition at the beginning of
build_noexcept_spec to evaluate early all the expressions which aren't
deferred or value-dependent, we obviously ICE during error-recovery on
the new testcase becau
On Tue, Feb 26, 2019 at 08:37:28AM +, Paul Richard Thomas wrote:
> Your timing is astonishing. This was next on my list of TODOs - not
> for this particular PR but to deal with the rodata bloat eg. 84487. I
> presume that this patch will make the latter go away?
>
> Yes, this is good for trunk
Steve Ellcey writes:
> On Wed, 2019-02-20 at 10:04 +, Richard Sandiford wrote:
>> (E.g. __attribute__((vector_size)) never creates an ABI-level SVE vector,
>> even with -msve-vector-bits=N, but it can create an ABI-level Advanced
>> SIMD vector.)
>>
>> I think we should leave the SVE stuff ou
On Mon, Feb 25, 2019 at 11:53 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch fixes two issues in the new rpad pass.
> One is that the insertion at the start of a basic block didn't work properly
> if the basic block didn't contain any non-NOTE/non-DEBUG_INSN instructions.
> next_nonnote_n
On Mon, Feb 25, 2019 at 10:09 AM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present on the mainline and 8 branch, introduced by the
> new code in edge_info::derive_equivalences dealing with BIT_AND_EXPR for SSA
> names with boolean range:
>
> /* If either operand has a boo
On 2/22/19 3:40 PM, John David Anglin wrote:
> Hi Martin,
>
> On 2019-02-22 5:21 a.m., Martin Liška wrote:
>> Hi.
>>
>> This patch makes main not hidden (as reported in the PR).
>> John: Can you verify it fixes your problem on hppa64-hp-hpux11.11 target?
> Your patch fixed the problem on the hppa6
Hi Tom!
On Mon, 25 Feb 2019 18:11:23 +0100, Tom de Vries wrote:
> On 25-02-19 11:48, Thomas Schwinge wrote:
> > On Fri, 8 Feb 2019 10:42:24 +0100, Tom de Vries wrote:
> >> Add libbacktrace test-case using -flto.
> >
> > I'm seeing this one fail is some configurations, but only in the
> > 'build
Hi Harald,
> Rev. 269177 uncovered a latent issue in TRANSFER when the MOLD argument
> had storage size 0, resulting in an infinite loop. The attached patch
> rejects illegal cases and handles the case where storage size of both
> SOURCE and MOLD are 0. It also verifies proper simplification for
Hi!
Honza, you've reviewed H.J.'s patch, could you please review this follow-up
as well? Thanks.
On Mon, Feb 25, 2019 at 02:57:39PM -0800, H.J. Lu wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > 2019-02-25 Jakub Jelinek
> >
> > PR target/89474
>
Hi Jakub,
Your timing is astonishing. This was next on my list of TODOs - not
for this particular PR but to deal with the rodata bloat eg. 84487. I
presume that this patch will make the latter go away?
Yes, this is good for trunk and, if it fixes 84487, 8-branch as well.
Thanks
Paul
On Mon, 25
On Tue, Feb 26, 2019 at 9:19 AM Thomas Koenig wrote:
>
> Hi Dominique,
>
>
> > AFAICT there is no patch attached.
>
> I guess that would have helped :-)
>
> Here it is.
Ok, thanks.
--
Janne Blomqvist
On 25-02-19 21:03, Tom de Vries wrote:
> On 25-02-19 15:12, Gerald Pfeifer wrote:
>> Specifically I am now seeing
>>
>> gmake[4]: *** No rule to make target 'b3test_dwz_buildid',
>> needed by 'b3test_dwz_buildid.log'.
>>
>> in my build/test logs. (Note, this is GNU make 4.2.1, so might reprod
82 matches
Mail list logo
