Am Montag, den 17.12.2018, 10:28 -0700 schrieb Jeff Law:
> > But the alignment increase itself on 'i386' and 'aarch64'
> > might be unacceptable. In this case, the only safe change
> > is to make the higher alignment also depend on
> > "-fno-trampolines". Would this be acceptable?
>
> Unclear
On Thu, Dec 20, 2018 at 01:47:39PM -0800, Steve Kargl wrote:
> The attached patch has been tested on x86_64-*-freebsd.
>
> OK to commit?
>
> 2018-12-20 Steven G. Kargl
>
> PR fortran/69121
> * libgfortran/ieee/ieee_arithmetic.F90: Provide missing functions
> in interface
On Dec 7, 2018, Alexandre Oliva wrote:
> Any objections, further requests or advice, before I put it in and
FTR, I've just checked it in.
--
Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain Engineer
The enhancement to detect mismatched attributes between function
aliases and their targets triggers (expected) warnings in GCC
builds due to aliases being declared with fewer attributes than
their targets.
Using attribute copy as recommended to copy the attributes from
the target to the alias
On Tue, 25 Sep 2018 14:59:18 +0200
Martin Jambor wrote:
> Hi,
>
> I have noticed a few things...
>
> On Thu, Sep 20 2018, Cesar Philippidis wrote:
> > This is another old gomp4 patch that demotes an ICE in PR71959 to a
> > linker warning. One problem here is that it is not clear if OpenACC
> >
Jeff, did this and the rest of the discussion answer your question
and if so, is the patch okay to commit?
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00337.html
Martin
On 12/13/18 12:48 PM, Martin Sebor wrote:
On 12/13/18 12:20 PM, Martin Sebor wrote:
On 12/13/18 11:59 AM, Jeff Law
On 12/20/18 4:54 PM, Marek Polacek wrote:
This testcase breaks in C++20 because convert_nontype_argument gets a PTRMEM_CST
as the expression, and we're trying to convert it to a class type, which
doesn't work, but because of the PTRMEM_CST check below we never diagnosed it.
The comment says a
On 12/20/18 5:27 PM, Jakub Jelinek wrote:
On Thu, Dec 20, 2018 at 04:47:29PM -0500, Jason Merrill wrote:
So are you ok with what is in the patch below, i.e.
{
bool non_cst_p = false, ovf_p = false;
tree a = cxx_eval_constant_expression (_ctx, args[i], false,
On 12/20/18 2:07 PM, Bernd Edlinger wrote:
On 12/20/18 6:50 PM, Martin Sebor wrote:
On 12/20/18 10:46 AM, Martin Sebor wrote:
On 12/17/18 7:58 AM, Jason Merrill wrote:
On 12/15/18 3:36 AM, Bernd Edlinger wrote:
this patch implements an error message, for non-static initialization of a
On Fri, Dec 21, 2018 at 12:46:41AM +0100, Jakub Jelinek wrote:
> The following patch makes it build again, will commit as obvious if it
> passes bootstrap/regtest:
>
> 2018-12-21 Jakub Jelinek
>
> * tree-vect-data-refs.c (vect_enhance_data_refs_alignment): Use
>
On Sun, Dec 16, 2018 at 11:04:44AM -0800, Steve Kargl wrote:
> The attached patch has been tested on i586-*-freebsd and x86_64-*-freebsd.
> If a data-statement-object is a component of a derived type, it checks if
> that component is allocatable.
>
> 2018-12-16 Steven G . Kargl
>
> PR
On 12/20/18 5:44 PM, Segher Boessenkool wrote:
> On Thu, Dec 20, 2018 at 05:34:54PM -0600, Aaron Sawdey wrote:
>> On 12/20/18 3:51 AM, Segher Boessenkool wrote:
>>> On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
Because of POWER9 dd2.1 issues with certain unaligned vsx
On Thu, Dec 20, 2018 at 07:46:31PM +, Richard Sandiford wrote:
> > vect_compute_data_ref_alignment uses DR_TARGET_ALIGNMENT
> > and DR_STEP_ALIGNMENT () % dr_target-alignment == 0 as check.
> >
> > I think it's preferable to use the same or similar values for the desired
> > alignment.
>
>
On Thu, Dec 20, 2018 at 05:34:54PM -0600, Aaron Sawdey wrote:
> On 12/20/18 3:51 AM, Segher Boessenkool wrote:
> > On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
> >> Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
> >> to cache inhibited memory, here is a
On 12/20/18 3:51 AM, Segher Boessenkool wrote:
> On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
>> Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
>> to cache inhibited memory, here is a patch that keeps memmove (and memcpy)
>> inline expansion from doing
On 12/20/18 8:25 AM, David Malcolm wrote:
> According to comments within PR c++/87504, the patch fixes the
> bootstrap on aarch64, and fixes a similar issue on Solaris/SPARC.
>
> It also passed bootstrap on x86_64-pc-linux-gnu.
>
> Given that, I've committed it to trunk as r267299.
>
> Aaron,
Sorry, fatfingered the address for this patch. Thanks to everyone who
let me know off list, it's been sent to the right list now. :)
Dave
On Thu, Dec 20, 2018 at 4:43 PM Dave Murphy wrote:
>
> Cross compiling for macOS using osxcross gives errors of the form
> "error: default initialization of
On 12/20/18 4:41 PM, Jeff Law wrote:
> On 12/20/18 2:30 PM, Peter Bergner wrote:
>> For stage1, I'd like to fix that conflict wart if I can. I have also
>> wondered about adding a copy coalesce phase just before we enter RA,
>> which would ensure the copies are removed, instead of hoping RA
Hi Honza,
the patch below avoids keeping jump functions that do not hold any
interesting value. For all users such dropped jump function vectors
will then appear as empty ones, which they should handle gracefully
because they already can deal with parameter count mismatches
(especially during
On 12/20/18 2:30 PM, Peter Bergner wrote:
> On 12/20/18 2:26 PM, Segher Boessenkool wrote:
>> On Thu, Dec 20, 2018 at 09:07:41PM +0100, Eric Botcazou wrote:
It's not a terrible workaround, no. It looks like it will make some asm
once again fail though? If argument registers are
On Thu, Dec 20, 2018 at 04:47:29PM -0500, Jason Merrill wrote:
> > So are you ok with what is in the patch below, i.e.
> > {
> > bool non_cst_p = false, ovf_p = false;
> > tree a = cxx_eval_constant_expression (_ctx, args[i], false,
> >
This fixes the bug id, 71176 to use the proper known
code print formatter type, %lu for size_t rather than
%d which is considered best pratice for print statements.
Signed-off-by: Nicholas Krause
---
fixincludes/fixincl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 2018-12-20 4:02 p.m., Joseph Myers wrote:
> This is still changing the wrong format specifier (the one corresponding
> to apply_ct, which is an int).
>
Sorry for the dumb mistakes as I seem to have miscounted the variables over
in my understanding of the code.
I will resend again and
On Thu, 20 Dec 2018 at 23:53, François Dumont wrote:
> >> This is why I am partially specializing __move_if_noexcept_cond. As
> >> there doesn't seem to exist any Standard meta function to find out if
> >> move will take place I resort using std::is_const as in this case for
> >> sure the
This testcase breaks in C++20 because convert_nontype_argument gets a PTRMEM_CST
as the expression, and we're trying to convert it to a class type, which
doesn't work, but because of the PTRMEM_CST check below we never diagnosed it.
The comment says a PTRMEM_CST is a valid template argument for a
On 12/20/18 9:04 AM, Ville Voutilainen wrote:
On Thu, 20 Dec 2018 at 08:29, François Dumont wrote:
Hi
I eventually find out what was the problem with the
std::move_if_noexcept within associative containers.
The std::pair move default constructor might not move both first
and
The attached patch has been tested on x86_64-*-freebsd.
It provides the missing pieces for IEEE_SCALB to allow
it to be generic function. Briefly, when FX contributed
IEEE_SCALB, he implemented a casting of the integer
argument to the default integer kind. For integer(1)
and integer(2), this is
On 12/20/18 4:40 PM, Jakub Jelinek wrote:
On Thu, Dec 20, 2018 at 04:26:21PM -0500, Jason Merrill wrote:
Right, but they either are or they aren't. Doing this isn't likely to help
anything, and can lead to paradoxical results in contrived testcases.
But if you think this is a bad idea, I can
On Thu, Dec 20, 2018 at 1:28 PM Jason Merrill wrote:
>
> On 12/20/18 2:52 PM, H.J. Lu wrote:
> > On Thu, Dec 20, 2018 at 11:28 AM Jason Merrill wrote:
> >>
> >> On 12/19/18 12:35 PM, H.J. Lu wrote:
> >>> + while (handled_component_p (rhs))
> >>> +{
> >>> + if (TREE_CODE (rhs) ==
On Thu, Dec 20, 2018 at 04:26:21PM -0500, Jason Merrill wrote:
> Right, but they either are or they aren't. Doing this isn't likely to help
> anything, and can lead to paradoxical results in contrived testcases.
>
> > But if you think this is a bad idea, I can remove it, I haven't been
> >
On 12/20/18 2:26 PM, Segher Boessenkool wrote:
> On Thu, Dec 20, 2018 at 09:07:41PM +0100, Eric Botcazou wrote:
>>> It's not a terrible workaround, no. It looks like it will make some asm
>>> once again fail though? If argument registers are forwarded to in the asm.
>>
>> The combiner change
On 12/20/18 2:52 PM, H.J. Lu wrote:
On Thu, Dec 20, 2018 at 11:28 AM Jason Merrill wrote:
On 12/19/18 12:35 PM, H.J. Lu wrote:
+ while (handled_component_p (rhs))
+{
+ if (TREE_CODE (rhs) == COMPONENT_REF)
+ break;
+ rhs = TREE_OPERAND (rhs, 0);
+}
+
+ if (TREE_CODE
On 12/20/18 4:08 PM, Jakub Jelinek wrote:
On Thu, Dec 20, 2018 at 02:47:01PM -0500, Jason Merrill wrote:
--- gcc/cp/constexpr.c.jj 2018-12-12 09:34:17.531736075 +0100
+++ gcc/cp/constexpr.c 2018-12-12 11:30:33.986756914 +0100
@@ -1198,6 +1198,7 @@ cxx_eval_builtin_function_call (const co
On Thu, Dec 20, 2018 at 02:47:01PM -0500, Jason Merrill wrote:
> > --- gcc/cp/constexpr.c.jj 2018-12-12 09:34:17.531736075 +0100
> > +++ gcc/cp/constexpr.c 2018-12-12 11:30:33.986756914 +0100
> > @@ -1198,6 +1198,7 @@ cxx_eval_builtin_function_call (const co
> >in a constexpr
On 12/20/18 6:50 PM, Martin Sebor wrote:
> On 12/20/18 10:46 AM, Martin Sebor wrote:
>> On 12/17/18 7:58 AM, Jason Merrill wrote:
>>> On 12/15/18 3:36 AM, Bernd Edlinger wrote:
this patch implements an error message, for non-static initialization of a
flexible array member.
This
This is still changing the wrong format specifier (the one corresponding
to apply_ct, which is an int).
--
Joseph S. Myers
jos...@codesourcery.com
On 1/19/18 12:28 AM, Jakub Jelinek wrote:
+#ifndef DEFAULT_INCOMING_FRAME_SP_OFFSET
+#define DEFAULT_INCOMING_FRAME_SP_OFFSET INCOMING_FRAME_SP_OFFSET
+#endif
...
+ /* If the current function starts with a non-standard incoming frame
+ sp offset, emit a note before the first instruction. */
On Thu, Dec 20, 2018 at 09:07:41PM +0100, Eric Botcazou wrote:
> > It's not a terrible workaround, no. It looks like it will make some asm
> > once again fail though? If argument registers are forwarded to in the asm.
>
> The combiner change looks like a big hammer for such a corner case
> It's not a terrible workaround, no. It looks like it will make some asm
> once again fail though? If argument registers are forwarded to in the asm.
The combiner change looks like a big hammer for such a corner case though.
--
Eric Botcazou
On Thu, Dec 20, 2018 at 11:28 AM Jason Merrill wrote:
>
> On 12/19/18 12:35 PM, H.J. Lu wrote:
> > + while (handled_component_p (rhs))
> > +{
> > + if (TREE_CODE (rhs) == COMPONENT_REF)
> > + break;
> > + rhs = TREE_OPERAND (rhs, 0);
> > +}
> > +
> > + if (TREE_CODE (rhs)
On Thu, Dec 20, 2018 at 01:23:57PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 20, 2018 at 01:15:53PM +0100, Richard Biener wrote:
> > On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou
> > wrote:
> > > this is a regression introduced on the SPARC by the somewhat controversial
> > > combiner change
On 12/12/18 5:30 PM, Jakub Jelinek wrote:
Hi!
The following patch fixes __builtin_is_constant_evaluated and
__builtin_constant_p handling during static_assert evaluation.
finish_static_assert calls fold_non_dependent_expr and complains if the
result is not a constant expression, instead of
Richard Biener writes:
> On Thu, Dec 20, 2018 at 2:43 PM Joern Wolfgang Rennecke
> wrote:
>>
>> eSi-RISC has vector permute functionality, but no unaligned loads. We
>> see execution failures on gcc.dg/vect/slp-perm-12.c because loop
>> versioning is used to make the tptr aligned for the first
> Does this solve most of the pessimizations?
Yes, it does.
> Please add a testcase if it doesn't solve existing FAILs.
It fixes gcc.target/sparc/overflow-2.c.
--
Eric Botcazou
On Thu, Dec 20, 2018 at 02:29:40PM +0100, Thomas Koenig wrote:
> Hi Steve,
>
> > The attach patch shuffles lines around to eliminate 80
> > lines of #ifdef...#endif; thereby making the file more
> > readable. Tested on i586-*-freebsd and x86_64-*-freebsd.
> > Patch is a pre-requisite to fixing
On 12/19/18 12:35 PM, H.J. Lu wrote:
+ while (handled_component_p (rhs))
+{
+ if (TREE_CODE (rhs) == COMPONENT_REF)
+ break;
+ rhs = TREE_OPERAND (rhs, 0);
+}
+
+ if (TREE_CODE (rhs) != COMPONENT_REF)
+return NULL_TREE;
+
+ object = TREE_OPERAND (rhs, 0);
+ field
* testsuite/27_io/filesystem/operations/proximate.cc: Fix test for
MinGW.
* testsuite/27_io/filesystem/path/append/source.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.
Tested x86_64-linux and mingw-w64, committed to trunk.
commit
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88457
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 267307
Index: ChangeLog
===
--- ChangeLog (revision
On 12/20/18 10:46 AM, Martin Sebor wrote:
On 12/17/18 7:58 AM, Jason Merrill wrote:
On 12/15/18 3:36 AM, Bernd Edlinger wrote:
this patch implements an error message, for non-static initialization
of a flexible array member.
This duplicates the existing error message from the C-FE, to avoid
On 12/17/18 7:58 AM, Jason Merrill wrote:
On 12/15/18 3:36 AM, Bernd Edlinger wrote:
this patch implements an error message, for non-static initialization
of a flexible array member.
This duplicates the existing error message from the C-FE, to avoid ICE
and wrong code generation
issues, as
On Thu, Dec 20, 2018 at 02:29:40PM +0100, Thomas Koenig wrote:
>
> > The attach patch shuffles lines around to eliminate 80
> > lines of #ifdef...#endif; thereby making the file more
> > readable. Tested on i586-*-freebsd and x86_64-*-freebsd.
> > Patch is a pre-requisite to fixing issues and
PR84053 - [7/8/9 Regression] missing -Warray-bounds accessing
a local array across inlined function boundaries, started to
pass with r262893 (a fix for a couple of different -Warray-bounds
bugs) but a test case for it was never added. After putting one
together I noticed that although it passes
Cross compiling for macOS using osxcross gives errors of the form
"error: default initialization of an object of ... without a
user-provided default constructor"
Fixed by attached patch, tested compile with mingw-w64, osxcross and
linux native builds.
2018-12-20 Dave Murphy
*
Hi James
On 19/12/18 3:40 PM, James Greenhalgh wrote:
> On Fri, Dec 14, 2018 at 10:09:03AM -0600, Sudakshina Das wrote:
>
>
>
>> I have updated the patch according to our discussions offline.
>> The md pattern is now split into 4 patterns and i have added a new
>> test for the setjmp case
On 11/22/18 4:54 PM, Sam Tebbs wrote:
> On 11/12/18 6:24 PM, Sudakshina Das wrote:
>> Hi Sam
>>
>> On 02/11/18 17:31, Sam Tebbs wrote:
>>> Hi all,
>>>
>>> The -mbranch-protection option combines the functionality of
>>> -msign-return-address and the BTI features new in Armv8.5 to better reflect
For some reason we missed ABS out of the list of supported integer
operations when adding the SVE port initially.
Applied after testing on aarch64-linux-gnu and aarch64_be-elf.
Richard
2018-12-20 Richard Sandiford
gcc/
* config/aarch64/iterators.md (SVE_INT_UNARY, fp_int_op): Add
This patch fixes a cut-&-pasto in the (match_dup 4) version of
"cond_". (It's a shame
that there's so much cut-&-paste in these patterns, but it's hard
to avoid without more infrastructure.)
Applied after testing on aarch64-linux-gnu and aarch64_be-elf.
Richard
2018-12-20 Richard Sandiford
On Thu, Dec 20, 2018 at 2:43 PM Joern Wolfgang Rennecke wrote:
>
> eSi-RISC has vector permute functionality, but no unaligned loads. We
> see execution failures on gcc.dg/vect/slp-perm-12.c because loop
> versioning is used to make the tptr aligned for the first loop
> iteration, and then with a
On 12/19/18 7:04 PM, Alexandre Oliva wrote:
Christophe,
Thanks again for the report. This was quite an adventure to figure
out ;-) See below.
[PR88146] avoid diagnostics diffs if cdtor_returns_this
Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms. Specifically,
On 12/19/18 6:12 PM, Jakub Jelinek wrote:
Hi!
On Tue, Dec 18, 2018 at 05:29:41PM -0500, Jason Merrill wrote:
So, we end up calling ggc_collect because we're processing a member function
in a context where defining a type is not allowed. One solution would be to
not do late parsing of members
On 12/19/18 6:14 PM, Jakub Jelinek wrote:
On Tue, Dec 18, 2018 at 10:27:56PM -0500, Jason Merrill wrote:
On 12/18/18 6:19 PM, Jakub Jelinek wrote:
On Tue, Dec 18, 2018 at 05:40:03PM -0500, Jason Merrill wrote:
On 12/18/18 3:45 PM, Jakub Jelinek wrote:
The following testcase FAILs, because
On Thu, 20 Dec 2018 at 01:04, Alexandre Oliva wrote:
>
> Christophe,
>
> Thanks again for the report. This was quite an adventure to figure
> out ;-) See below.
>
Glad I've helped. I wouldn't have been able to do the analysis :)
>
> [PR88146] avoid diagnostics diffs if cdtor_returns_this
>
>
Dne 2018-12-20 15:36, Martin Jambor napsal:
Hi,
Ping:
On Fri, Dec 07 2018, Martin Jambor wrote:
Hi,
the patch below adds alias analysis (AA) walk limiting to all
walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summary
generation. Eventually the two should be unified into just one
Hi,
Ping:
On Fri, Dec 07 2018, Martin Jambor wrote:
Hi,
the patch below adds alias analysis (AA) walk limiting to all
walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summary
generation. Eventually the two should be unified into just one phase
but that is something for stage1. This
On Wed, 19 Dec 2018, Maciej W. Rozycki wrote:
> This has passed regression-testing with the `x86_64-linux-gnu' target and
> the `nvptx-none' offload target, across the `gcc', `g++', `gfortran' and
> `libgomp' test suites. I will appreciate feedback and if none has been
> given shortly, then I
Hi Chung-Lin,
> My only issue is should "serial" really be promoted to such a visible
> construct
> in the middle-end? It's just a special case of parallel, and user debug errors
> can be dealt with specifically. I don't see much value of it being preserved
> past the front-ends into
Hi!
On behalf of Gergő (who doesn't have write access yet) I've pushed the
attached to openacc-gcc-8-branch.
Grüße
Thomas
From a9e48066198ffb1e7bc2b137167a61a6cb47748c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerg=C3=B6=20Barany?=
Date: Thu, 20 Dec 2018 15:07:34 +0100
Subject: [PATCH]
On Wed, 2018-12-19 at 22:01 -0500, David Malcolm wrote:
> On Wed, 2018-12-19 at 17:27 -0600, Aaron Sawdey wrote:
> > Assuming you applied this as svn 267273, it causes bootstrap
> > failure
> > on powerpc64le-unknown-linux-gnu. Stage 2 fails with multiple
> > instances
> > of this error:
> >
> >
Hi,
On Mon, Dec 10 2018, Richard Biener wrote:
> On Fri, Dec 7, 2018 at 3:59 PM Martin Jambor wrote:
>>
...
>>
>> On a related note, would people object to adding the following assert,
>> which would have made this bug much more straightforward to find?
>
> That's fine with me.
Thanks, I have
On Mon, 10 Dec 2018, Chung-Lin Tang wrote:
> I think the patch is okay, although still needs approval from Thomas and Tom
> to commit.
I have committed this change now, thank you for your review.
Maciej
Disable AC_PROG_CXX and consequently a libstdc++ dependency for libffi,
introduced with upstream libffi commit 7d698125b1f0 ("Use the proper C++
compiler to run C++ tests"). This is only needed for the libffi test
suite, which we don't have to support in the GCC tree, as libffi is
maintained
eSi-RISC has vector permute functionality, but no unaligned loads. We
see execution failures on gcc.dg/vect/slp-perm-12.c because loop
versioning is used to make the tptr aligned for the first loop
iteration, and then with a step of originally 11, 22 after
vectorization, and a vector alignment
Hi Steve,
The attach patch shuffles lines around to eliminate 80
lines of #ifdef...#endif; thereby making the file more
readable. Tested on i586-*-freebsd and x86_64-*-freebsd.
Patch is a pre-requisite to fixing issues and adding
missing functionality. OK to commit?
2018-12-18 Steven G.
Hi Martin,
> There is a similar mechanism for pointer-to-member-functions
> used by C++. Is this correct on aarch64?
/* By default, the C++ compiler will use the lowest bit of the pointer
to function to indicate a pointer-to-member-function points to a
virtual member function. However, if
On 20/12/18 04:08 -0500, Tim Song wrote:
On Tue, Dec 18, 2018 at 10:57 AM Jonathan Wakely wrote:
* include/bits/fs_dir.h (operator<<): Overload for directory_entry,
as per LWG 3171.
* testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test.
Tested
On Thu, Dec 20, 2018 at 01:15:53PM +0100, Richard Biener wrote:
> On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou wrote:
> > this is a regression introduced on the SPARC by the somewhat controversial
> > combiner change for hard registers: the compiler can no longer apply the
> > leaf
> >
On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression introduced on the SPARC by the somewhat controversial
> combiner change for hard registers: the compiler can no longer apply the leaf
> registers optimization to a small function so a register window is now
On Thu, Dec 20, 2018 at 01:42:15PM +0530, Lokesh Janghel wrote:
> Hi Mateuszb,
>
> I tested with your proposition patch and it is working right.
> I also added the patch with test case.
> Please let me know your thoughts/suggestions.
ChangeLog entry is missing, please write it (and mention there
Hi,
this is a regression introduced on the SPARC by the somewhat controversial
combiner change for hard registers: the compiler can no longer apply the leaf
registers optimization to a small function so a register window is now used.
The combiner change might be an overall win, but my
There's a long-standing issue with LIM which isn't very good at
recognizing same memory references esp. when they are in MEM vs.
traditional form. The following rectifies this for the class
of refs we can compute get_addr_base_and_unit_offset on (that
makes it easy to create a canonical ref).
On 12/20/18 10:38 AM, Sam Tebbs wrote:
> On 11/24/18 11:29 AM, Christophe Lyon wrote:
>
>> On Thu, 22 Nov 2018 at 18:30, Vladimir Makarov
>> wrote:
>>> The following patch fixes
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
>>>
>>> The patch adds a special treatment for moves with a
On 11/24/18 11:29 AM, Christophe Lyon wrote:
> On Thu, 22 Nov 2018 at 18:30, Vladimir Makarov
> wrote:
>> The following patch fixes
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
>>
>> The patch adds a special treatment for moves with a hard register in
>> register cost and class
On 14/12/2018 23:28, Thomas Preudhomme wrote:
> Hi,
>
> Commit r242693 forced fp to be saved/restored when needed due to an
> instance of GCC using fp as a scratch register to save sp while it's
> being clobbered by an inline asm. The normal path in
> thumb1_compute_save_reg_mask saving
On Thu, Dec 20, 2018 at 11:08 AM Uros Bizjak wrote:
>
> Attached patch inlines calls to asinh{,f,l}, acosh{,f,l} and
> atanh{,f,l} using x87 XFmode arithmetic. The expanders are modelled
> after the removed inlines in glibc [1].
>
> 2018-12-20 Uros Bizjak
>
> PR target/88556
> *
On 12/12/2018 21:32, Andreas Tobler wrote:
> Hi all,
>
> I have this patch since a longer time in my tree. No obvious fallout
> visible.
>
> I'm going to commit this patch in the next days if no one objects.
>
> TIA,
> Andreas
>
> 2018-12-12 Andreas Tobler
>
> * config.gcc: Enable
Attached patch inlines calls to asinh{,f,l}, acosh{,f,l} and
atanh{,f,l} using x87 XFmode arithmetic. The expanders are modelled
after the removed inlines in glibc [1].
2018-12-20 Uros Bizjak
PR target/88556
* internal-fn.def (COSH): New.
(SINH): Ditto.
(TANH): Ditto.
*
[ add gcc-patches ]
Forwarded Message
Subject: [RFC, openacc] Ensure oacc_replace_fn_attrib replaces
Date: Thu, 20 Dec 2018 00:40:56 +0100
From: Tom de Vries
To: Thomas Schwinge
Hi,
this looks like a good cleanup.
WDYT?
Thanks,
- Tom
[openacc] Ensure oacc_replace_fn_attrib
On Wed, Dec 19, 2018 at 01:53:05PM -0600, Aaron Sawdey wrote:
> Because of POWER9 dd2.1 issues with certain unaligned vsx instructions
> to cache inhibited memory, here is a patch that keeps memmove (and memcpy)
> inline expansion from doing unaligned vector or using vector load/store
> other than
On Tue, Dec 18, 2018 at 10:57 AM Jonathan Wakely wrote:
> * include/bits/fs_dir.h (operator<<): Overload for directory_entry,
> as per LWG 3171.
> * testsuite/27_io/filesystem/directory_entry/lwg3171.cc: New test.
>
> Tested x86_64-linux, committed to trunk.
>
>
>
The
W dniu 20.12.2018 o 09:12, Lokesh Janghel pisze:
> Hi Mateuszb,
>
> I tested with your proposition patch and it is working right.
> I also added the patch with test case.
> Please let me know your thoughts/suggestions.
>
>
> Thanks
> Lokesh
Patch looks good to me, thanks!
On 64-bit target we
Hi Mateuszb,
I tested with your proposition patch and it is working right.
I also added the patch with test case.
Please let me know your thoughts/suggestions.
Thanks
Lokesh
88521.patch
Description: Binary data
On Thu, 20 Dec 2018 at 08:29, François Dumont wrote:
>
> Hi
>
> I eventually find out what was the problem with the
> std::move_if_noexcept within associative containers.
>
> The std::pair move default constructor might not move both first
> and second member. If any is not moveable it
92 matches
Mail list logo
