> IMO you ought not to duplicate most of function_value_32 here.
I modified the patch.
Please let me know your thoughts.
--
Lokesh
On Sat, Mar 23, 2019 at 5:59 PM Eric Botcazou wrote:
>
> > The attached patch (pr85667.patch) fixes the subjected issue for 32-bit.
> > Please let me know your tho
On Tue, Mar 26, 2019 at 03:42:09PM -0700, Kevin Buettner wrote:
> libgomp/ChangeLog:
>
> * team.c (gomp_team_start): Initialize pool->threads[0].
>
> diff --git a/libgomp/team.c b/libgomp/team.c
> index 2b2e9750da5..c422da3701d 100644
> --- a/libgomp/team.c
> +++ b/libgomp/team.c
> @@ -482,
Hi Jakub,
> On Mon, Mar 25, 2019 at 11:41:35AM -0600, Jeff Law wrote:
>> > PR c/89812 - incorrect maximum in error: requested alignment
>> > ‘536870912’ exceeds maximum 2147483648
>> >
>> > gcc/c-family/ChangeLog:
>> >
>> >PR c/89812
>> >* c-common.c (check_user_alignment): Rename lo
On Mon, 25 Mar 2019 19:30:57 +0100
Jakub Jelinek wrote:
> On Fri, Feb 22, 2019 at 06:11:44PM -0700, Kevin Buettner wrote:
> > For debugging purposes, I need to be able to find the master thread
> > in the thread pool.
> >
> > Without this patch, I see over 20 failures in the tests that I've
> >
Hi!
As the testcase shows, the SWITCH_STMT handling in
potential_constant_expression_1
is quite conservative, it doesn't recurse on the body of the switch stmt,
because at least for the case where the switch condition isn't some easily
determinable constant, we'd need to try all possible values o
Hi Paul,
Bootstraps and regtests on FC29/x86_64 - OK for 8- and 9-branches?
OK. Thanks for the patch!
Regards
Thomas
This adds a pipeline description for the SiFive 7 Series parts, and all
of the supporting patches to make this work. There is quite a bit of
infrastructure to add, as this is the first non-rocket-chip core that
we are adding to the RISC-V backend. This also adds options for the existing
sifive 3
Attached patch fixes a corner case in STV pass where the shift operand
register equals shift count register. The specialization for shift
insns marked register as processed, but didn't process shift input
operand, leaving an unprocessed DImode register.
2019-03-26 Uroš Bizjak
PR target/898
On Tue, Mar 26, 2019 at 12:15:26PM -0600, Jeff Law wrote:
> On 3/26/19 11:52 AM, Segher Boessenkool wrote:
> > On Mon, Mar 25, 2019 at 05:12:05PM -0600, Jeff Law wrote:
> >> To touch on one of the issues I raised. AFAICT the schedulers don't use
> >> SCHED_GROUP_P for dealing with tablejumps. The
On 3/26/19 11:52 AM, Segher Boessenkool wrote:
> On Mon, Mar 25, 2019 at 05:12:05PM -0600, Jeff Law wrote:
>> To touch on one of the issues I raised. AFAICT the schedulers don't use
>> SCHED_GROUP_P for dealing with tablejumps. They're used for
>> cc0-user/setter, fused insns and the like. That'
On Tue, Mar 26, 2019 at 04:14:07PM +1030, Alan Modra wrote:
> This just chooses a more descriptive name for this register class.
> Bootstrapped etc. powerpc64le-linux. OK for next stage1?
It's okay now, even. Thanks!
Segher
On Tue, Mar 26, 2019 at 03:40:05PM +1030, Alan Modra wrote:
> rs6000_hard_regno_mode_ok_uncached result depends on target flags,
> and nowadays it is possible that TARGET_OPTION_OVERRIDE be called not
> just at the start of compilation but per-function by the action of
> function attributes or "#pr
On Mon, Mar 25, 2019 at 05:12:05PM -0600, Jeff Law wrote:
> To touch on one of the issues I raised. AFAICT the schedulers don't use
> SCHED_GROUP_P for dealing with tablejumps. They're used for
> cc0-user/setter, fused insns and the like. That's a bit of a surprise.
>
> Given that the table isn
Hi, Richard,
thanks for the suggestion.
I tried it yesterday, but it did not work.
the reason is:
inside “can_inline_edge_by_limits_p”, the “allowance for always_inline” is
guarded by the following condition:
else if “caller_tree != callee_tree”
this condition is ONLY true when when callee
When we refer to a captured variable from a constant-expression context
inside a lambda, the closure (like any function parameter) is not constant
because we aren't in a call, so we don't have an argument. So the capture
is non-constant. But if the captured variable is constant, we might be able
On 3/26/19 10:45 AM, Rainer Orth wrote:
Hi Nathan,
This patch addresses a compiler incompatibility with non-capturing lambdas.
Specifically, when a lambda's functions are comdat, we place the static
_FUN function in the same comdat group as the operator() function.
the new test FAILs on Sola
On Mon, Mar 25, 2019 at 11:41:35AM -0600, Jeff Law wrote:
> > PR c/89812 - incorrect maximum in error: requested alignment
> > ‘536870912’ exceeds maximum 2147483648
> >
> > gcc/c-family/ChangeLog:
> >
> > PR c/89812
> > * c-common.c (check_user_alignment): Rename local. Correct max
The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the arg
On Tue, Mar 26, 2019 at 12:34:03PM +0100, Andreas Schwab wrote:
> I don't see any of the warnings in the tests on ia64.
>
> FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnings, line 33)
> FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnings, line 34)
> FAIL: g++.dg/cpp1z/agg
On 26/03/19 16:48 +0200, Ville Voutilainen wrote:
Slight tweak, the condition for _M_valid and _Extra_visit_slot_needed
is now in sync.
OK, thanks.
PR libstdc++/89825
Fix based on a suggestion by Antony Polukhin.
* include/std/variant (__never_valueless): New.
(_M_valid): Use it.
Slight tweak, the condition for _M_valid and _Extra_visit_slot_needed
is now in sync.
2019-03-26 Ville Voutilainen
PR libstdc++/89825
Fix based on a suggestion by Antony Polukhin.
* include/std/variant (__never_valueless): New.
(_M_valid): Use it.
(_Extra_visit_slot_needed)
On 3/26/19 8:35 AM, Maxim Kuvyrkov wrote:
I don't follow. Do you mean that in the below testcase it's not guaranteed
that casp will get its first two arguments in x0 and x1? (If so, why?)
Sorry for not to be clear. With my first patch only, it was not
guaranteed for some complicated code ca
Hi Nathan,
> This patch addresses a compiler incompatibility with non-capturing lambdas.
> Specifically, when a lambda's functions are comdat, we place the static
> _FUN function in the same comdat group as the operator() function.
>
> This breaks link compatibility with clang, where the static fu
Hi,
This patch merges the D front-end implementation with dmd upstream ab702e73e.
Backports memory leak fix in the mangler, and introduces recognition
and rejection of more C types and directives.
Bootstrapped and regression tested on x86_64-linux-gnu.
Committed to trunk as r269945.
--
Iain
-
I ported linux kernel to Renesas RX.
rx-*-elf target output a binary different from the standard ELF.
It has the same format as the Renesas compiler.
But the linux kernel requires the standard ELF format.
I want to define a rx-*-linux target so that I can generate
a standard ELF binary.
diff --g
2019-03-26 Ville Voutilainen
PR libstdc++/89825
Fix based on a suggestion by Antony Polukhin.
* include/std/variant (_Extra_visit_slot_needed): New.
(_Multi_array): Use it.
(_S_apply_all_alts): Likewise.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/st
On Tue, Mar 26, 2019 at 02:34:40PM +0100, Richard Biener wrote:
> Just found this in one of my dev trees and think it's suitable at
> this stage as a general speedup.
>
> gimple_block involves querying an on-the-side map in libcpp
> since it is encoded in the location_t location. This means
> cac
Just found this in one of my dev trees and think it's suitable at
this stage as a general speedup.
gimple_block involves querying an on-the-side map in libcpp
since it is encoded in the location_t location. This means
caching is beneficial. It's also pointless to copy
gimple_block once you've
On Tue, 26 Mar 2019, Martin Liška wrote:
> On 3/26/19 12:21 AM, Jakub Jelinek wrote:
> > I know it isn't that much, but 74KB savings on .text seems to be worth to
> > me with such a small patch. Ok for trunk?
>
> Hi.
>
> I like the suggested trick with const static field in case
> of memory rep
On Tue, 26 Mar 2019, Martin Liška wrote:
> On 3/26/19 10:56 AM, Jakub Jelinek wrote:
> > On Mon, Mar 25, 2019 at 09:42:01PM +0100, Jakub Jelinek wrote:
> >> On Mon, Mar 25, 2019 at 03:10:04PM -0400, Jason Merrill wrote:
> 2) has the false -> true fixed
> 3) ditto, but furthermore is move
On 26/03/19 14:14 +0200, Ville Voutilainen wrote:
A minor thinko, very easy to fix.
OK, thanks.
> On Mar 26, 2019, at 3:20 PM, Vladimir Makarov wrote:
>
> On 3/26/19 4:25 AM, Maxim Kuvyrkov wrote:
>>> On Mar 26, 2019, at 12:22 AM, Vladimir Makarov wrote:
>>>
>>> Jeff Law recently found that my latest patch break some existing code
>>> compilation (the code is big to make test out of
On 3/26/19 4:25 AM, Maxim Kuvyrkov wrote:
On Mar 26, 2019, at 12:22 AM, Vladimir Makarov wrote:
Jeff Law recently found that my latest patch break some existing code
compilation (the code is big to make test out of it).
Here is the patch to fix it. The patch was successfully bootstrapped
A minor thinko, very easy to fix.
2019-03-26 Ville Voutilainen
PR libstdc++/89824
Fix based on a suggestion by Antony Polukhin.
* include/std/variant (__gen_vtable): Don't reserve an
additional table slot, _Multi_array already does that.
diff --git a/libstdc++-v3/include/std/va
On 22.03.19 23:00, David Malcolm wrote:
> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote:
>> Fix PR jit/87808, the embedded driver still needing the external gcc
>> driver to
>> find the gcc_lib_dir. This can happen in a packaging context when
>> libgccjit
>> doesn't depend on the gcc pack
Hi
According to gnu document of function attributes, neither weakref nor alias
could be attached to a function defined in current translation unit.
Although GCC checks the attributes under some circumstances, it still fails
on some cases and even causes ICE.
This patch checks whether alias/weakr
I don't see any of the warnings in the tests on ia64.
FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnings, line 33)
FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnings, line 34)
FAIL: g++.dg/cpp1z/aggr-base8.C -std=c++17 (test for warnings, line 35)
FAIL: g++.dg/cpp1z/agg
On 3/26/19 10:56 AM, Jakub Jelinek wrote:
> On Mon, Mar 25, 2019 at 09:42:01PM +0100, Jakub Jelinek wrote:
>> On Mon, Mar 25, 2019 at 03:10:04PM -0400, Jason Merrill wrote:
2) has the false -> true fixed
3) ditto, but furthermore is moved out of add_capture into the lambda
introducer
On 3/26/19 12:21 AM, Jakub Jelinek wrote:
> I know it isn't that much, but 74KB savings on .text seems to be worth to
> me with such a small patch. Ok for trunk?
Hi.
I like the suggested trick with const static field in case
of memory reporting is disabled.
Martin
Hi,
Some of the dmd-style options converted in gdc-convert-args are mapped
to two separate options, notably those that control warning and
deprecation messages (-w, -de, -dw). When given as arguments to
PERMUTE_ARGS, there is no need to test with the same gdc-style option
given twice.
Ran the D
On 3/22/19 11:02 PM, Joseph Myers wrote:
> This one seems wrong:
>
>> - "-fno-strict-aliasing is used");
>> + "%<-fno-strict-aliasing is used%>");
>
> (only the option name should be quoted, not "is used").
>
Hi.
It's fixed now.
Thanks,
Martin
On Mon, Mar 25, 2019 at 09:42:01PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 25, 2019 at 03:10:04PM -0400, Jason Merrill wrote:
> > > 2) has the false -> true fixed
> > > 3) ditto, but furthermore is moved out of add_capture into the lambda
> > > introducer parsing routine only, tests for [this, th
Hi.
This is a fix for wrong option name wrapping.
It was seen by Joseph.
I'm going to install that as obvious.
Thanks,
Martin
gcc/lto/ChangeLog:
2019-03-26 Martin Liska
* lto-symtab.c (lto_symtab_merge_decls_2): Fix option name
wrapping
---
gcc/lto/lto-symtab.c | 2 +-
1 f
On Mon, 18 Mar 2019, Richard Biener wrote:
> On Fri, 15 Mar 2019, Jason Merrill wrote:
>
> > On 3/15/19 9:33 AM, Richard Biener wrote:
> > >
> > > The following is an attempt to fix PR71598 where C (and C++?) have
> > > an implementation-defined compatible integer type for each enum
> > > and th
On Tue, Mar 26, 2019 at 1:56 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Mar 22, 2019 at 7:12 AM Bin.Cheng wrote:
> >>
> >> On Thu, Mar 21, 2019 at 8:24 PM Richard Biener
> >> wrote:
> >> >
> >> > On Mon, Dec 18, 2017 at 1:37 PM Richard Biener
> >> > wrote:
> >> > >
> >>
> On Mar 26, 2019, at 12:22 AM, Vladimir Makarov wrote:
>
> Jeff Law recently found that my latest patch break some existing code
> compilation (the code is big to make test out of it).
>
> Here is the patch to fix it. The patch was successfully bootstrapped on
> x86-64. The patch actually
On Mon, Mar 25, 2019 at 6:48 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Mar 12, 2019 at 10:50 AM Richard Sandiford
> > wrote:
> >>
> >> Steve Ellcey writes:
> >> > Richard,
> >> >
> >> > I don't necessarily disagree with anything in your comments and long
> >> > term I t
Hi!
c-omp.c calls omit_one_operand which in several cases can wrap a MODIFY_EXPR
into NON_LVALUE_EXPR and similar. An atomic is always a whole
statement that has its side-effect(s), so -Wunused-value for that is not
really useful.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-lin
48 matches
Mail list logo
