On Tue, Jan 17, 2017 at 10:59:43PM -0700, Jeff Law wrote:
> > I agree that breaking those applications would be bad. It could
> > be dealt with by adding an option to let them disable the insertion
> > of the trap. With the warning, programmers would get a heads up
> > that their (already dubious
On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
> On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
> wrote:
> > On 2017.01.11 at 13:03 +0100, Jakub Jelinek wrote:
> >> On Wed, Jan 11, 2017 at 12:48:29PM +0100, Markus Trippelsdorf wrote:
> >> > @@ -1965,7 +1966,11 @@ write_discriminator (con
Ping.
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00381.html
Thanks,
Kyrill
On 06/01/17 11:54, Kyrill Tkachov wrote:
Hi all,
In this wrong-code issue the RTL tries to load a const_vector:
(const_vector:V8QI [
(const_int 1 [0x1])
(const_int 0 [0])
(const_int 1 [0x1])
By default, wildcard support on Windows for programs compiled with mingw depends
on how the mingw runtime was configured. This means if one wants to build GCC
for Windows with a consistent behavior with Wildcard (enabled or disabled) the
mingw runtime must be built as well. This patch adds an op
On 19/12/16 14:53, Jakub Jelinek wrote:
On Thu, Dec 15, 2016 at 10:00:14AM +, Richard Earnshaw (lists) wrote:
sorry, pasted the wrong bit of code.
That should read when we generate:
(insn 55 19 67 3 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 147) [2
Toma Tabacu writes:
> Matthew Fortune writes:
> >
> > Sounds good. I'd prefer to get the testsuite clean first then improve the
> > code quality as a later step since it is not a regression and we are
> > a few days off stage 4.
> >
> > In terms of the patch then the ISA_HAS_DIV3 macro is not curr
On 01/18/2017 01:35 AM, Dominik Vogt wrote:
> On Tue, Jan 10, 2017 at 03:40:00PM +0100, Martin Liška wrote:
>> On 01/10/2017 02:56 PM, Richard Biener wrote:
>>> On Mon, Jan 9, 2017 at 4:05 PM, Martin Liška wrote:
Second part of the patch does sorting of final congruence classes, it's
gr
On 2017.01.18 at 09:55 +0100, Markus Trippelsdorf wrote:
> index cac3d8bc65e9..767c8f42fee9 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -2252,7 +2252,9 @@ attributes that affect type identity, such as ia32
> calling convention
> attributes (e.g. @samp{stdcall}).
>
> Ver
Hello.
After basic understanding of loop predictive commoning, the problematic
combined chain is:
Loads-only chain 0x38b6730 (combined)
max distance 0
references:
MEM[(real(kind=8) *)vectp_a.29_81] (id 1)
offset 20
distance 0
MEM[(real(kind=8) *)vectp_a.38_141] (id 3)
On Wed, Jan 18, 2017 at 10:53:59AM +0100, Martin Liška wrote:
> As I've been reading when the warning is emitted (rtl expansion), I guess a
> pair of function was merged
> by IPA ICF and thus the location points to a different function.
>
> I can't reproduce the test-case due to missing __HTM__.
On 01/18/2017 11:21 AM, Jakub Jelinek wrote:
> So my preference is to add -fno-ipa-icf to dg-options and
> add the missing dg-error line on line 42.
>
> Like below, ok for trunk?
I like the idea of adding -fno-ipa-icf to the test-case.
Martin
On Wed, Jan 18, 2017 at 10:10 AM, Martin Liška wrote:
> Hello.
>
> After basic understanding of loop predictive commoning, the problematic
> combined chain is:
>
> Loads-only chain 0x38b6730 (combined)
> max distance 0
> references:
> MEM[(real(kind=8) *)vectp_a.29_81] (id 1)
> offs
> From: Matthew Fortune
>
> Apart from those changes this looks OK to me.
>
> Matthew
Thanks.
Committed as r244570.
Regards,
Toma
On 01/18/2017 11:21 AM, Jakub Jelinek wrote:
> 2017-01-18 Jakub Jelinek
>
> * gcc.target/s390/target-attribute/tattr-2.c: Add -fno-ipa-icf
> to dg-options.
> (p0): Add missing dg-error.
Ok. Thanks!
-Andreas-
On Wed, Jan 18, 2017 at 11:21:50AM +0100, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 10:53:59AM +0100, Martin Liška wrote:
> > As I've been reading when the warning is emitted (rtl expansion), I guess a
> > pair of function was merged
> > by IPA ICF and thus the location points to a different
Hi!
On Wed, Jan 18, 2017 at 12:49:19PM +0100, Dominik Vogt wrote:
> > I think the testcase as written just assumes ICF happens but in a certain
> > way and what broke is that the same functions are ICFed in a different order
> > now, because with -fno-ipa-icf it reports:
> > tattr-2.c: In function
On 12/09/2016 12:49 PM, Bernd Schmidt wrote:
On 12/03/2016 10:49 AM, Uros Bizjak wrote:
Based on the above explanation, the patch is OK.
I'll be treating the ifcvt part of it as obvious. However, testing
showed an issue with the i386 funcspec-11 test:
/* PR target/36936 */
/* { dg-do compile
honza,
this is the fix for the partitioned WPA bug I was tracking down.
We have base and complete dtors sharing a comdat group (one's an alias
for the other). The linker tells us the complete dtor is
PREVAILING_DEF, as it's referenced from some other library. The base
dtor is UNKNOWN.
We t
On Wed, Jan 18, 2017 at 1:10 PM, Bernd Schmidt wrote:
> On 12/09/2016 12:49 PM, Bernd Schmidt wrote:
>>
>> On 12/03/2016 10:49 AM, Uros Bizjak wrote:
>>
>>> Based on the above explanation, the patch is OK.
>>
>>
>> I'll be treating the ifcvt part of it as obvious. However, testing
>> showed an iss
Hi all,
the patch I proposed for this pr unfortunately did not catch all errors.
Dominique figured, that the original testcase was not resolved (thanks for
that).
This patch resolves the linker problem by putting the static token into the
parent function's decl list. Furthermore does the patch be
Hi!
The following patch fixes ICE with -fdebug-types-section on the following
testcase. We prune DIEs in the main CU for methods in a class that is
moved into .debug_types section, because we don't see any uses of those
in the debug info. But those uses are only added later when adding
DW_TAG_ca
On Tue, Jan 17, 2017 at 3:42 PM, Jeff Law wrote:
> On 01/17/2017 02:15 AM, Richard Biener wrote:
>>
>> On Mon, Jan 16, 2017 at 11:36 PM, Richard Biener
>> wrote:
>>>
>>> On January 16, 2017 7:27:53 PM GMT+01:00, Jeff Law
>>> wrote:
On 01/16/2017 01:51 AM, Richard Biener wrote:
>
>>
On Tue, Jan 17, 2017 at 9:07 PM, Alexander Monakov wrote:
> Hello,
>
> This patch series addresses a correctness issue in how OpenMP SIMD regions are
> transformed for SIMT execution. On NVPTX, OpenMP target code runs with
> per-warp stacks outside of SIMD regions, and needs to transition to per-
2017-01-17 16:51 GMT+03:00 Jakub Jelinek :
> On Tue, Jan 17, 2017 at 04:03:08PM +0300, Andrew Senkevich wrote:
>> > I've played a bit w/ SDE. And looks like operands are not early clobber:
>> > TID0: INS 0x004003ee AVX512VEX kmovd k0, eax
>> > TID0: k0 := _
>>
>
> They're added to the cgraph by this call:
>
> /* Add to cgraph. */
> cgraph_node::finalize_function (fndecl, false);
>
> within function_reader::create_function (in r244110, though that code
> isn't called yet; it's called by the stuff in patch 9).
>
> If I hack out that call, so that
Hi!
On Wed, Jan 11, 2017 at 08:41:02PM +0100, Jakub Jelinek wrote:
> The pr77416.c test fails in some configurations, where the -m32 option
> is not supported. The following patch fixes that by guarding the test
> with ilp32 effective target and removing the -m32 and adjusts a couple of
> tests t
On 01/17/2017 03:17 PM, Jason Merrill wrote:
Hmm, what if write_exception_spec checks for a dependent
noexcept-specifier first, and noexcept_spec_p second? That seems like
it would avoid needing any change to nothrow_spec_p.
that's a better solution. However it was easier for it to check for
On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
> Hi,
>
> as was figured out in PR LTO + ASan raises false initialization order fiasco
> alarm due to in LTO case main_input_filename doesn't match module name passed
> to __asan_before_dynamic_init.
> Following Jakub's suggestion I used TRANSLATION_UNI
On 01/18/2017 01:05 PM, Jakub Jelinek wrote:
...
> Two more things:
> 1)
> 823 error ("Builtin %qF is not supported without -mhtm "
> 824"(default with -march=zEC12 and higher).", fndecl);
>is a bug, diagnostics (I think Fortran FE is a big exception here) should
On Wed, 18 Jan 2017, Richard Biener wrote:
> > After OpenMP lowering, inlining might break this by inlining functions with
> > address-taken locals into SIMD regions. For now, such inlining is
> > disallowed
> > (this penalizes only SIMT code), but eventually that can be handled by
> > collecting
On Wed, Jan 18, 2017 at 3:55 AM, Markus Trippelsdorf
wrote:
> On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
>> On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
>> wrote:
> + if (abi_version_at_least (11) && discriminator - 1 >= 10)
> + {
> + write_char ('_');
> +
On Wed, Jan 18, 2017 at 3:11 PM, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Richard Biener wrote:
>> > After OpenMP lowering, inlining might break this by inlining functions with
>> > address-taken locals into SIMD regions. For now, such inlining is
>> > disallowed
>> > (this penalizes only
On 2017.01.18 at 09:11 -0500, Jason Merrill wrote:
> On Wed, Jan 18, 2017 at 3:55 AM, Markus Trippelsdorf
> wrote:
> > On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
> >> On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
> >> wrote:
> > + if (abi_version_at_least (11) && discriminator
On Wed, Jan 18, 2017 at 03:22:15PM +0100, Richard Biener wrote:
> > So I guess a way to keep allocation layout implicit until after inlining is
> > this: instead of exposing the helper struct in the IR immediately, somehow
> > keep
> > it on the side, associated only with the SIMT region, and not
On Wed, 18 Jan 2017, Richard Biener wrote:
> But I guess I was asking whether you could initially emit
>
> void *omp_simt = IFN_GOMP_SIMT_ENTER (0);
>
> for (int i = n1; i < n2; i++)
> foo (&tmp);
>
> IFN_GOMP_SIMT_EXIT (omp_simt);
>
> and only after inlining do liveness / use analysi
Jason,
What is the scope of a lambda capture? AFAICT it depends on whether the
capture is simple or initialized.
the attached program prints:
[x] is i
[x=x] is i
[x=x] {short x;} is s
I'm not sure that's right.
The clearest one is an initialized capture. [5.1.6]/12 says this is
equivalent t
Hi all,
this patch adds undocumented parameters to caf-API functions and fixes the
documentation style in many parts of the caf-API functions. It intentionally
does not fix the last paragraph in the caf-API function's section (co_reduce),
because I do not understand what is intended by the last se
On Tue, Jan 17, 2017 at 11:07:41PM +0300, Alexander Monakov wrote:
> In preparation to handle new SIMT privatization in
> lower_rec_simd_input_clauses
> this patch factors out variables common to this and lower_rec_input_clauses to
> a new structure. No functional change intended.
>
> * om
On Wed, Jan 18, 2017 at 03:32:56PM +0100, Jakub Jelinek wrote:
> > It probably is.
> >
> > But I guess I was asking whether you could initially emit
> >
> > void *omp_simt = IFN_GOMP_SIMT_ENTER (0);
> >
> > for (int i = n1; i < n2; i++)
> > foo (&tmp);
> >
> > IFN_GOMP_SIMT_EXIT (omp_
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic attributes
> on them during omplower time and then only finalized into the magic .local
> alloca in the pass_omp_device_lower pass?
No (see my adjacent response): it can't be a variable fl
On Wed, Jan 18, 2017 at 11:10 AM, Martin Liška wrote:
> Hello.
>
> After basic understanding of loop predictive commoning, the problematic
> combined chain is:
>
> Loads-only chain 0x38b6730 (combined)
> max distance 0
> references:
> MEM[(real(kind=8) *)vectp_a.29_81] (id 1)
> offs
On Wed, Jan 18, 2017 at 11:10:32AM +0100, Martin Liška wrote:
> Hello.
>
> After basic understanding of loop predictive commoning, the problematic
> combined chain is:
>
> Loads-only chain 0x38b6730 (combined)
> max distance 0
> references:
> MEM[(real(kind=8) *)vectp_a.29_81] (id 1)
>
On Tue, Jan 17, 2017 at 11:07:43PM +0300, Alexander Monakov wrote:
> This patch implements propagation of PROP_gimple_lomp_dev during inlining to
> allow using it to decide whether pass_omp_device_lower needs to run.
>
> We need to clear this property in expand_omp_simd when the _simt_ clause is
>
On Wed, Jan 18, 2017 at 9:23 AM, Markus Trippelsdorf
wrote:
> On 2017.01.18 at 09:11 -0500, Jason Merrill wrote:
>> On Wed, Jan 18, 2017 at 3:55 AM, Markus Trippelsdorf
>> wrote:
>> > On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
>> >> On Thu, Jan 12, 2017 at 2:36 AM, Markus Trippelsdorf
>>
On Wed, Jan 18, 2017 at 06:02:06PM +0300, Alexander Monakov wrote:
> > > +struct omplow_simd_context {
> > > + tree idx;
> > > + tree lane;
> > > + int max_vf;
> > > + bool is_simt;
> >
> > Any reason ivar and lvar weren't added there too?
>
> Yes, they are not part of 'persistently live cont
On Wed, Jan 18, 2017 at 05:52:49PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic attributes
> > on them during omplower time and then only finalized into the magic .local
> > alloca in the pass_omp_d
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > +/* This structure is part of the interface between
> > lower_rec_simd_input_clauses
> > + and lower_rec_input_clauses. */
> > +
> > +struct omplow_simd_context {
> > + tree idx;
> > + tree lane;
> > + int max_vf;
> > + bool is_simt;
>
> Any re
On Fri, Jan 13, 2017 at 7:48 PM, Aldy Hernandez wrote:
> [Sorry for the delay, I was sick.]
>
>
> On 01/09/2017 04:30 AM, Richard Biener wrote:
>>
>> On Sat, Jan 7, 2017 at 1:54 PM, Aldy Hernandez wrote:
>>>
>>> On 01/04/2017 07:11 AM, Richard Biener wrote:
On Tue, Jan 3, 2017 at 6
On 2017.01.18 at 10:03 -0500, Jason Merrill wrote:
> On Wed, Jan 18, 2017 at 9:23 AM, Markus Trippelsdorf
> wrote:
> > On 2017.01.18 at 09:11 -0500, Jason Merrill wrote:
> >> On Wed, Jan 18, 2017 at 3:55 AM, Markus Trippelsdorf
> >> wrote:
> >> > On 2017.01.17 at 13:26 -0500, Jason Merrill wrote:
On Wed, Jan 18, 2017 at 04:16:44PM +0100, Markus Trippelsdorf wrote:
> No. It appears to work even without the additional condition:
>
> % g++ -fabi-version=10 -Wabi=11 -Wall -c gcc/testsuite/g++.dg/abi/pr77489.C
> gcc/testsuite/g++.dg/abi/pr77489.C:56:16: warning: the mangled name of
> ‘localVa
On Wed, Jan 18, 2017 at 01:51:12PM +0100, Jakub Jelinek wrote:
> > The pr77416.c test fails in some configurations, where the -m32 option
> > is not supported. The following patch fixes that by guarding the test
> > with ilp32 effective target and removing the -m32 and adjusts a couple of
> > test
On 2017.01.18 at 16:25 +0100, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 04:16:44PM +0100, Markus Trippelsdorf wrote:
> > No. It appears to work even without the additional condition:
> >
> > % g++ -fabi-version=10 -Wabi=11 -Wall -c gcc/testsuite/g++.dg/abi/pr77489.C
> > gcc/testsuite/g++.dg/
On Wed, Jan 18, 2017 at 2:54 PM, Richard Biener
wrote:
> On Wed, Jan 18, 2017 at 11:10 AM, Martin Liška wrote:
>> Hello.
>>
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>
> I'm not sure. If we have such zero distance refs in the IL
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 05:52:49PM +0300, Alexander Monakov wrote:
> > On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic
> > > attributes
> > > on them during omplower time and then only fi
Hello.
During bootstrap, I came to following test-case:
struct A
{
int regno;
};
struct
{
A base;
} typedef *df_ref;
int *a;
void
fn1 (int N)
{
for (int i = 0; i < N; i++)
{
df_ref b;
a[(b)->base.regno]++;
}
}
As we expand all usages of an LHS of a ASAN_POISON to all us
On 01/13/17 19:28, Bernd Edlinger wrote:
> On 01/13/17 17:10, Bernd Edlinger wrote:
>> On 01/13/17 14:50, Richard Earnshaw (lists) wrote:
>>> On 18/12/16 12:58, Bernd Edlinger wrote:
Hi,
this is related to PR77308, the follow-up patch will depend on this
one.
When tryi
On Wed, Jan 18, 2017 at 10:32 AM, Markus Trippelsdorf
wrote:
> On 2017.01.18 at 16:25 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 18, 2017 at 04:16:44PM +0100, Markus Trippelsdorf wrote:
>> > No. It appears to work even without the additional condition:
>> >
>> > % g++ -fabi-version=10 -Wabi=11 -W
On Wed, Jan 18, 2017 at 06:34:05PM +0300, Alexander Monakov wrote:
> My main concern is that nothing indicates to optimization passes that after
> SIMT_EXIT(), underlying storage is unavailable. What would prevent the
> compiler
> from transforming, say
>
> SIMT_ENTER();
> // originally omp
Hi Eric,
This patch adds a workaround to the Sparc backend for the LEON3FT
store-store errata. It is enabled using the -mfix-b2bst flag.
The workaround inserts NOP instructions to prevent the following two
instruction sequences from being generated:
std -> stb/sth/st/std
stb/sth/st -> any single
On 12/19/2016 10:18 AM, Tamar Christina wrote:
Hi All,
I've respun the patch with the feedback from Jeff and Joseph.
I think an integer mode should always exist - even in the case of TFmode
on 32-bit systems (32-bit sparc / s390, for example, use TFmode long
double for GNU/Linux, and it's supp
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> We are talking here about addressable vars, right (so if we turn it into
> non-addressable, in the SIMT region we just use the normal PTX pseudos),
> right? We could emit inner ={v} {CLOBBER}; before SIMT_EXIT() to make it
> clear it shouldn't be moved a
On 18/01/17 16:00, Richard Biener wrote:
On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
Hi,
as was figured out in PR LTO + ASan raises false initialization order fiasco
alarm due to in LTO case main_input_filename doesn't match module name passed
to __asan_before_dynamic_init.
Following Jakub's s
On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > We are talking here about addressable vars, right (so if we turn it into
> > non-addressable, in the SIMT region we just use the normal PTX pseudos),
> > right? We could emit inner ={
On 01/17/2017 04:57 PM, Christophe Lyon wrote:
Hi Vladimir,
On 17 January 2017 at 17:14, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 244535.
The new
On 01/17/2017 02:28 AM, Richard Biener wrote:
This feels somewhat different, but still a hack.
I don't have strong suggestions on how to approach this, but what we've got
here feels like a hack and one prone to bitrot.
All the above needs a bit of cleanup in the way we use (or not use) PROP_x
* Mike Stump [2017-01-17 10:49:30 -0800]:
> On Jan 17, 2017, at 3:30 AM, Andrew Burgess
> wrote:
> >
> >> This patch revamps the arc's header file by means of using separate
> >> headers for different tool targets. Each target header file holds the
> >> specific compiler backend macros definit
Since the patch adds new built-in functions __builtin_issubnormal and
__builtin_iszero, it also needs to update c-typeck.c:convert_arguments to
make those functions remove excess precision. This is mentioned in the
PRs 77925 and 77926 for addition of those functions (which as I noted in
Also, I don't think the call to perform_ibm_extended_fixups in
is_subnormal is correct. Subnormal for IBM long double is *not* the same
as subnormal double high part. Likewise it's incorrect in is_normal as
well.
Generally, I don't see tests added that these new functions are correct
for flo
We were aborting in tsubst_copy due to finding an AGGR_INIT_EXPR
because tsubst_decl thought we needed to instantiate the default
arguments of the deduction guide because PRIMARY_TEMPLATE_P was false.
Fixed by making a deduction guide its own primary template.
Tested x86_64-pc-linux-gnu, applying
Hi all,
during discussing some other functionality in the caf-library, it occurred to
me that gfortran is adding a caf_sync_all()-call when allocating only
allocatable or pointer components of derived typed coarrays. The attached patch
fixes the behavior.
Bootstrapped and regtests ok on x86_64-li
On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > It is, but I think my approach is compatible with inlining too (and has a
> > more
> > localized impact on the compiler).
>
> But your 2/5 patch disables inlining into the SIMT regions. Or do you mean
> the approach with some new IFN for the pointers
On Wed, 18 Jan 2017, Joseph Myers wrote:
> Generally, I don't see tests added that these new functions are correct
> for float, double and long double, which would detect such issues if run
> for a target with IBM long double.
Specifically, I think gcc.dg/tg-tests.h should have tests added for
On 12/01/17 18:10, Jiong Wang wrote:
On 06/01/17 11:47, Jiong Wang wrote:
This is the update on libgcc unwinder support according to new DWARF proposal.
As Joseph commented, duplication of unwind-dw2.c is not encouraged in libgcc,
But from this patch, you can see there are a few places we need
NOTE, this approach however requires DWARF change as the original LR is signed,
the binary needs new libgcc to make sure c++ eh works correctly. Given this
acceleration already needs the user specify -mstack-protector-dialect=pauth
which means the target platform largely should have install new l
On Wed, 2017-01-18 at 09:36 -0700, Jeff Law wrote:
> On 01/17/2017 02:28 AM, Richard Biener wrote:
> > >
> > > This feels somewhat different, but still a hack.
> > >
> > > I don't have strong suggestions on how to approach this, but what
> > > we've got
> > > here feels like a hack and one prone
PR libstdc++/68925
* include/experimental/random (randint): Use temporary instead of
thread_local static.
Tested powerpc64le-linux, committed to trunk.
commit 71544b3d1abd1c9a2d47ef664ce696b750232e0f
Author: Jonathan Wakely
Date: Wed Jan 18 17:16:10 2017 +
PR6
On Tue, Jan 17, 2017 at 08:50:08PM -0500, Michael Meissner wrote:
> I have checked this on a little endian power8 system (64-bit only), a big
> endian power8 system (64-bit only), and a big endian power7 system (both
> 32-bit
> and 64-bit), and there were no regressions. Can I check this into the
On Wed, Jan 18, 2017 at 08:02:14PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > It is, but I think my approach is compatible with inlining too (and has a
> > > more
> > > localized impact on the compiler).
> >
> > But your 2/5 patch disables inlining into the
On 01/18/2017 04:26 AM, Andre Vehreschild wrote:
Hi all,
the patch I proposed for this pr unfortunately did not catch all errors.
Dominique figured, that the original testcase was not resolved (thanks for
that).
This patch resolves the linker problem by putting the static token into the
parent
On January 18, 2017 5:17:12 PM GMT+01:00, Maxim Ostapenko
wrote:
>On 18/01/17 16:00, Richard Biener wrote:
>> On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
>>
>>> Hi,
>>>
>>> as was figured out in PR LTO + ASan raises false initialization
>order fiasco
>>> alarm due to in LTO case main_input_filena
On 01/18/2017 01:10 AM, Jakub Jelinek wrote:
On Tue, Jan 17, 2017 at 10:59:43PM -0700, Jeff Law wrote:
I agree that breaking those applications would be bad. It could
be dealt with by adding an option to let them disable the insertion
of the trap. With the warning, programmers would get a head
PR 79121 is a silent wrong code regression where, when generating a
shift from an extended value moving from one to two machine registers,
the type of the right shift is for the most significant word should be
determined by the signedness of the inner type, not the signedness of
the result type.
g
On 01/18/2017 06:46 AM, Andre Vehreschild wrote:
Hi all,
this patch adds undocumented parameters to caf-API functions and fixes the
documentation style in many parts of the caf-API functions. It intentionally
does not fix the last paragraph in the caf-API function's section (co_reduce),
because
On 01/18/2017 08:54 AM, Andre Vehreschild wrote:
Hi all,
during discussing some other functionality in the caf-library, it occurred to
me that gfortran is adding a caf_sync_all()-call when allocating only
allocatable or pointer components of derived typed coarrays. The attached patch
fixes the b
Jason,
I've figured out what's happening here. Just not sure of the most
prudent way to fix it.
struct no_destr {
no_destr() = default;
protected:
~no_destr() = default;
};
void *Foo ()
{
return new no_destr ();
}
no_destr is a type for which the default ctor is not DECL_ARTIFICIAL,
The following patch updates a few latencies in the Power9 machine description.
Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?
-Pat
2017-01-18 Pat Haugen
* config/rs6000/power9.md (power9-alu): Remove 'cmp' type and add
define_bypass for CR latency.
Hi Jerry,
thanks for the fast review. Committed as r244587.
Regards,
Andre
On Wed, 18 Jan 2017 09:38:40 -0800
Jerry DeLisle wrote:
> On 01/18/2017 04:26 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > the patch I proposed for this pr unfortunately did not catch all errors.
> > Dominiq
This fixes an invalid assumption that std::atomic can default
construct a T. It also fixes some variables called "tmp" with
non-uglified names.
PR libstdc++/69301
* include/std/atomic (atomic::load, atomic::exchange): Use
aligned buffer instead of default-initialized varia
Hi all,
I have the following issue here on aarch64-*-freebsd:
(sorry if the format is hardly readable)
..
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.c: In
function 'void aarch64_elf_asm_destructor(rtx, int)':
/export/devel/net/src/gcc/head/gcc/gcc/config/aarch64/aarch64.
Hi Jerry,
and also for this many thanks. Committed as r244590.
Regards,
Andre
PS: Hopefully this mail is not declared SPAM by the mail-host like the last one.
On Wed, 18 Jan 2017 10:13:10 -0800
Jerry DeLisle wrote:
> On 01/18/2017 08:54 AM, Andre Vehreschild wrote:
> > Hi all,
> >
>
On Wed, Jan 18, 2017 at 11:21:40AM -0600, Segher Boessenkool wrote:
> On Tue, Jan 17, 2017 at 08:50:08PM -0500, Michael Meissner wrote:
> > I have checked this on a little endian power8 system (64-bit only), a big
> > endian power8 system (64-bit only), and a big endian power7 system (both
> > 32-
On 17/08/2016 12:19, Joe Seymour wrote:
> fail to build with...
>
>> ../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc:274:3: error: static
>> assertion failed: Pointers must be 32 bits or 64 bits wide
>> static_assert(sizeof(uint64_t) == sizeof(void*)
>
> The assert fails because msp430 h
Joe Seymour writes:
>> the msp430 -mlarge multilib failing to build with...
>>> configure: error: Unknown underlying type for size_t
>>> make[1]: *** [configure-target-libstdc++-v3] Error 1
>
> This is still reproducible.
FYI the underlying type is uint20_t
I think I've complained that libstdc++
This patch fixes an ICE with inherited default ctor and a local decl.
In such a case we don't have any conv args (just the object expression,
handled differently). Thus 'num_convs-1' is -1 and we seg fault at:
cand->convs[cand->num_convs-1]->ellipsis_p
do just check it's non-zero first.
commi
As suggested by Segher, we have to use code iterator to iterate RTX
pattern through zero- and sign-extract for 8 bit inserts. In a similar
way, we can use any_shiftrt in a RTX pattern involving 8-bit inserts.
While it would be nice to have a middle-end perform relevant
simplifications, these two p
Hello Jakub,
Sorry for not noticing this earlier, but ...
> +#ifdef __LP64__
> +typedef unsigned long long CUdeviceptr;
> +#else
> +typedef unsigned CUdeviceptr;
> +#endif
I think this #ifdef doesn't do the right thing on MinGW.
Would it be fine to simplify it? In my code I have
typedef uint
This fix follows the same approach that glibc uses to disable TSX on
processors on which it is broken. TSX can also be disabled through a
microcode update on these processors, but glibc consensus is that it
cannot be detected reliably whether the microcode update has been
applied. Thus, we just l
This is a partial patch for PR78516. This patch fixes some broken constraints
in spe.md that were exposed by the rs6000 port's switch to using LRA.
In order to change some of the constraints to outputs from inout, I had
to change some of the instructions we emit to equivalent forms.
Joseph has sa
DejaGnu's provides decls of various inline functions,
of which the jit testsuite uses "pass", "fail" and "note".
The jit testcase test-threads.c jumps through some hoops to make
these functions threadsafe, using macros to rename the implementation
in dejagnu.h, giving them a "dejagnu_" prefix, th
The problem was that finish_class_member_access_expr got missed when
we added variable templates. 68666 is a report of how this affects
concepts; the patch adds both concepts and non-concepts testcases.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 40ab19fcedf621438a819dbdf08d9ee66e3143db
1 - 100 of 124 matches
Mail list logo