Pattern recognition can leave stale STMT_VINFO_RELATED_STMT entries
around which confuses the correctness asserting I put into
get_{earlier,later}_stmt. The following makes sure to clear
those again. To make things more complicated pattern recognition
sometimes scans forward ... which runs into
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
On 06/11/2018 11:34 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
On 06/04/2018 05:45 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html
On 05/29/2018 10
OK.
On Mon, Jun 18, 2018 at 5:35 AM, Nick Clifton wrote:
> Hi Guys,
>
> The patch below allows the zlib library to be built when the build
> directory is the same as the source directory. This patch has been in
> the binutils/gdb sources for a while now, but unfortunately was never
> cop
As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch. The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.
I'm send
On Mon, Jun 18, 2018 at 6:12 PM Ville Voutilainen wrote:
> On 16 June 2018 at 18:05, Marc Glisse wrote:
> > On Sat, 16 Jun 2018, Glen Fernandes wrote:
> >
> >> Use __builtin_memmove for trivially copy assignable types
> >>
> >> 2018-06-14 Glen Joseph Fernandes
> >>
> >>* include/bits/stl
Now that we allow unexpanded packs in a lambda, since they can be part
of the pattern of a pack expansion, we need to look at the argument
types when we scan the full-expression later.
But fixing this added an unexpected error to the test for 81060, where
we weren't properly diagnosing the unexpan
On 05/31/2018 11:43 AM, Jakub Jelinek wrote:
On Thu, May 31, 2018 at 01:34:19PM -0400, Jason Merrill wrote:
Where is the error_mark_node coming from in the first place?
remap_type invoked during omp-low.c (scan_omp).
omp_copy_decl returns error_mark_node for decls that tree-inline.c wants
to r
Attached is an updated patch with the additional text as
discussed below.
Martin
On 06/11/2018 03:05 PM, Martin Sebor wrote:
On 06/11/2018 02:03 PM, Richard Sandiford wrote:
Martin Sebor writes:
On 06/11/2018 12:08 PM, Richard Sandiford wrote:
Martin Sebor writes:
@@ -1553,12 +1553,28 @@
As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch. The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.
I'm send
Richard & Jakub,
I would like to backport the fix for pr85602 to gcc-8-branch.
Can you please review the original patch below and let me know
if you have any concerns with the backport?
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00869.html
Thanks
Martin
As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch. The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.
I'm send
As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch. The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.
I'm send
On 06/12/2018 03:37 PM, Jeff Law wrote:
On 06/12/2018 03:29 PM, Martin Sebor wrote:
Declaring strlen() to return a pointer instead of size_t
and then calling the function can result in an ICE due to
both gimple-fold and tree-ssa-strlen assuming the function
necessarily returns an integer.
As lu
On 16 June 2018 at 18:05, Marc Glisse wrote:
> On Sat, 16 Jun 2018, Glen Fernandes wrote:
>
>> Use __builtin_memmove for trivially copy assignable types
>>
>> 2018-06-14 Glen Joseph Fernandes
>>
>>* include/bits/stl_algobase.h
>>(__is_simple_copy_move): Defined helper.
>>
The issue is caused by reordering of stack pointer update after stack
space allocation with instructions that write to the allocated stack
space. In windowed ABI register spill area for the previous call frame
is located just below the stack pointer and may be reloaded back into
the register file o
Last month I sent a patch for a bug in the rope template. I want to
make sure it is not forgotten:
https://gcc.gnu.org/ml/libstdc++/2018-05/msg00115.html
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01006.html
When an iterator is copied or assigned, the copy can retain pointers to
an interna
Hi
I abandon the idea of providing Debug algos, it would be too much
code to add and maintain. However I haven't quit on reducing Debug mode
performance impact.
So this patch make use of the existing std::__niter_base to get rid
of the debug layer around __gnu_debug::vector<>::iterat
Segher:
Per our discussions, the previous patch had issues with the target
!powerpc*-*-aix* not working correctly and thus the instruction count
test was not being done. I have addressed those issues and verified by
inspecting the gcc/testsuite/gcc/gcc.log file to make sure the test was
actually
This patch improves the checks in size_must_be_zero_p so that we don't
call get_range_info with SIZE of a pointer type.
Bootstrapped/regtested on x86_64-linux, ok for trunk and 8?
2018-06-18 Marek Polacek
PR middle-end/86202
* gimple-fold.c (size_must_be_zero_p): Check the typ
On Mon, 18 Jun 2018 at 18:01, Jonathan Wakely wrote:
>
> On 16/06/18 20:56 -0600, Sandra Loosemore wrote:
> >On 06/16/2018 05:05 PM, Jonathan Wakely wrote:
> >>Oops, that message got bounced from the lists and was the wrong
> >>version of the patch anyway - this is the one I meant to attach.
> >>
* include/std/scoped_allocator (__not_pair): Define SFINAE helper.
(construct(_Tp*, _Args&&...)): Remove from overload set when _Tp is
a specialization of std::pair.
* testsuite/20_util/scoped_allocator/construct_pair.cc: Ensure
pair elements are constructed
On Mon, 18 Jun 2018, Michael Meissner wrote:
> In terms of the tests, the following tests fail if you switch the default long
> double format.
Also, having done a test build: various *tf* and *tc* libgcc functions end
up getting built incorrectly (to use IEEE long double when the ABIs for
those
On Mon, Jun 18, 2018 at 07:40:46PM +, Joseph Myers wrote:
> On Mon, 18 Jun 2018, Michael Meissner wrote:
>
> > gcc.target/powerpc/pr70117.c(bug in isnormal on
> > IEEE 128)
>
> Doesn't look like a bug in isnormal to me. That test is explicitly using
> an IBM long do
On Mon, 18 Jun 2018, Michael Meissner wrote:
> gcc.target/powerpc/pr70117.c (bug in isnormal on IEEE 128)
Doesn't look like a bug in isnormal to me. That test is explicitly using
an IBM long double representation and can't possibly be expected to work
with IEEE long double - e
This is just the combined patch of the last three patches that have been
approved for trunk. I expanded the description in rs6000-modes.def of what the
3 128-bit floating point types are and why IFmode needs to be ordered above
KFmode and TFmode.
These patches were individually proposed in:
https
On Mon, 18 Jun 2018, Jason Merrill wrote:
> On Mon, Jun 18, 2018 at 11:59 AM, Joseph Myers
> wrote:
> > On Mon, 18 Jun 2018, Jason Merrill wrote:
> >
> >> > + if (TREE_CODE (rhs) == COND_EXPR)
> >> > +{
> >> > + /* Check the THEN path first. */
> >> > + tree op1 = TREE_OPERAND (r
While looking into opportunities to detect strnlen/strlen coding
mistakes (pr86199) I noticed a bug in the strnlen implementation
I committed earlier today that lets a strnlen() result be saved
and used in subsequent calls to strlen() with the same argument.
The attached patch changes the handle_b
On Fri, 2018-06-15 at 14:11 -0600, Jeff Law wrote:
> On 06/14/2018 02:32 PM, David Malcolm wrote:
> > The vectorizer code has numerous instances of:
> >
> > if (dump_enabled_p ())
> > dump_printf_loc (MSG_NOTE, vect_location,
> > "=== some message ===\n");
> >
> > In ea
On Fri, Jun 15, 2018 at 04:00:42PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 14, 2018 at 08:15:51PM -0400, Michael Meissner wrote:
> > On Thu, Jun 14, 2018 at 07:00:52PM -0500, Segher Boessenkool wrote:
> > > Hi Mike,
> > >
> > > On Wed, Jun 13, 2018 at 05:16:37PM -0400, Michael Meissner wrot
By only defining these operators as friends (with no namespace-scope
declaration) they can only be found by ADL and do not participate in
overload resolution for arguments of types other than path.
LWG 2989 hide path iostream operators from normal lookup
* include/bits/fs_path.h (
On сряда, 13 юни 2018 г. 19:44:16 EEST Joseph Myers wrote:
> On Wed, 13 Jun 2018, Dimitar Dimitrov wrote:
> > + error ("__delay_cycles() only takes constant arguments");
>
> As in documentation, diagnostics should not use () to indicate that a name
> refers to a function (as opposed to referr
Hello,
this is a patch for PR other/86198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Thanks.
From: Denis Khalikov
Date: Mon, 18 Jun 2018 20:46:39 +0300
Subject: [PATCH] PR other/86198
* elf.c (elf_add): Increase ".note.gnu.build-id" section size
checking up to 36 bytes.
---
libbacktrace/
Here, instantiating B requires instantiating A, which
requires instantiating B. Previously, that resulted in
creating two separate TYPE_DECLS for B and trying to combine
them in register_specialization. Better, I think, to check for this
situation sooner.
Tested x86_64-pc-linux-gnu, applying to
On Mon, Jun 18, 2018 at 11:59 AM, Joseph Myers wrote:
> On Mon, 18 Jun 2018, Jason Merrill wrote:
>
>> > + if (TREE_CODE (rhs) == COND_EXPR)
>> > +{
>> > + /* Check the THEN path first. */
>> > + tree op1 = TREE_OPERAND (rhs, 1);
>> > + context = check_address_of_packed_member
This issue hasn't been voted into the working draft yet, but it's been
approved by LWG and is obviously correct.
* include/std/chrono (duration, operator*, operator/, operator%): Use
const-qualified type as source type in is_convertible constraints.
* testsuite/20_util/dur
On Mon, Jun 18, 2018 at 1:51 PM, Jakub Jelinek wrote:
> On Mon, Jun 18, 2018 at 01:48:05PM -0400, Jason Merrill wrote:
>> On Mon, Jun 18, 2018 at 12:41 PM, Jakub Jelinek wrote:
>> > On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
>> >> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
On 06/18/2018 11:37 AM, Jan Hubicka wrote:
It is exactly the warning newly added by this patch.
/scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld:
warning: incremental linking of LTO and non-LTO objects; using
-flinker-output=nolto-rel which
On Fri, Feb 16, 2018 at 11:19 AM, Martin Sebor wrote:
> On 02/16/2018 05:43 AM, Nick Clifton wrote:
>>
>> Hi David,
>>
>> Attached is a revised version of the patch which I hope addresses all
>> of your (very helpful) comments on the v3 patch.
>>
>> OK to apply once the sources are back on s
On Mon, Jun 18, 2018 at 01:48:05PM -0400, Jason Merrill wrote:
> On Mon, Jun 18, 2018 at 12:41 PM, Jakub Jelinek wrote:
> > On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
> >> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
> >> > On 18 June 2018 at 19:28, Nick Clifton wrote:
> >> >
On Mon, Jun 18, 2018 at 12:41 PM, Jakub Jelinek wrote:
> On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
>> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
>> > On 18 June 2018 at 19:28, Nick Clifton wrote:
>> >> Hi Prathamesh,
>> >>
>> >>> I am getting the following build error with
>
> It is exactly the warning newly added by this patch.
>
> /scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld:
> warning: incremental linking of LTO and non-LTO objects; using
> -flinker-output=nolto-rel which will bypass whole program optimiz
On 05/24/2018 04:34 PM, co...@sdf.org wrote:
> On Thu, May 24, 2018 at 01:32:17PM -0600, Jeff Law wrote:
>> On 05/24/2018 01:17 PM, co...@sdf.org wrote:
>>> On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
On 05/24/2018 07:54 AM, Maya Rashish wrote:
> Move linux-specific specfile
On Mon, 18 Jun 2018, Jeff Law wrote:
> So do we need to set or check math_errhandling & MATH_ERRNO at all? Or
That's a matter for libc (glibc currently sets it based on __FAST_MATH__ /
__NO_MATH_ERRNO__, but fails to avoid including MATH_ERREXCEPT in the
definition for configurations not suppo
On 18/06/18 15:12 +0300, Ville Voutilainen wrote:
On 17 June 2018 at 19:49, Ed Smith-Rowland <3dw...@verizon.net> wrote:
On 06/15/2018 11:52 AM, Jonathan Wakely wrote:
C++20 adds a header, which should define all the library
feature test macros, as well as implementation-specific macros like
On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
> > On 18 June 2018 at 19:28, Nick Clifton wrote:
> >> Hi Prathamesh,
> >>
> >>> I am getting the following build error with trunk:
> >>> ../../gcc/gcc/tree.c: In member function ‘void
>
On 06/12/2018 03:11 PM, Jeff Law wrote:
On 06/05/2018 03:43 PM, Martin Sebor wrote:
The attached patch adds basic support for handling strnlen
as a built-in function. It touches the strlen pass where
it folds constant results of the function, and builtins.c
to add simple support for expanding s
This patch fixes an error in the code generation for vec_packsu (vector
unsigned long long, vector unsigned long long). As previously implemented,
this built-in function translates to the vpksdus instruction.
This patch causes vec_packsu (vector unsigned long long, vector unsigned long
long)
Hi Martin,
> I'm getting a bootstrap failure:
*sigh* yes - my bad. Fortunately a patch has already been posted:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01039.html
And I think that it has now been approved.
Cheers
Nick
On 06/18/2018 08:01 AM, Wilco Dijkstra wrote:
> GCC currently defaults to -fmath-errno. This generates code assuming math
> functions set errno and the application checks errno. Few applications
> test errno and various systems and math libraries no longer set errno since it
> is optional. GCC g
On 06/14/2018 05:44 AM, Koval, Julia wrote:
> Hi,
>
> This patch should fix the issue. Ok for trunk?
>
> gcc/testsuite/
> * gcc.target/i386/avx512vl-vpclmulqdq-2.c: Remove 128bit version.
OK.
jeff
On 16/06/18 20:56 -0600, Sandra Loosemore wrote:
On 06/16/2018 05:05 PM, Jonathan Wakely wrote:
Oops, that message got bounced from the lists and was the wrong
version of the patch anyway - this is the one I meant to attach.
On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely wrote:
Here's what I
On Mon, 18 Jun 2018, Jason Merrill wrote:
> > + if (TREE_CODE (rhs) == COND_EXPR)
> > +{
> > + /* Check the THEN path first. */
> > + tree op1 = TREE_OPERAND (rhs, 1);
> > + context = check_address_of_packed_member (type, op1);
>
> This should handle the GNU extension of re-u
On 06/18/2018 02:00 AM, Eric Botcazou wrote:
> Hi,
>
> that's already done for C++ so it seems consistent to do it for Fortran too.
>
> Tested on x86-64/Linux, OK for the mainline?
>
>
> 2018-06-18 Eric Botcazou
>
> * Makefile.def (fortran): Add check-target-libgomp-fortran.
> *
On 06/15/2018 08:28 AM, Martin Liška wrote:
> On 06/15/2018 07:08 AM, Alexander Monakov wrote:
>> On Tue, 12 Jun 2018, Martin Liška wrote:
>>
>>> This is equivalent of gimple.vim file. I'm aware of not full coverage of RTL
>>> instructions, but hope it's a good start point.
>>
>> I think this is ni
On 06/14/2018 02:10 PM, David Malcolm wrote:
> These are mostly pre-approved, but there are some slightly non-trivial
> cases in frv.c and mips.c.
They looked pretty trivial to me :-)
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> Successfully built "cc1" binaries on all
* include/bits/allocator.h (allocator): Add constexpr to constructors
for C++2a. Replace dynamic exception specifications with NOTHROW
macro.
(allocator, operator==, operator!=): Replace USE_NOEXCEPT macro with
NOTHROW.
* include/bits/c++config (_GLI
Hi,
this is the 3rd (and the last) patch for PR78809:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Inline strcmp with small constant strings
The design doc for PR78809 is at:
https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html
this patch is for the third part of change of PR78809.
On 06/18/2018 02:45 AM, Jan Hubicka wrote:
On 05/08/2018 09:14 AM, Jan Hubicka wrote:
Hi,
with lto, incremental linking can be meaninfuly done in three ways:
1) read LTO file and produce non-LTO .o file
this is current behaviour of gcc -r or ld -r with plugin
2) read LTO files and merge
This patch adds an overload of vect_reassociating_reduction_p
that checks for a vectorizable associative reduction,
since the check was duplicated in three functions.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2018-06-18 Richard Sandiford
gcc/
* tree-v
When following the definitions of SSA names, some recognisers
already cope with statements that have been replaced by patterns.
This patch makes that happen automatically for users of
type_conversion_p and vect_get_internal_def. It also adds
a vect_look_through_pattern helper that can be used dire
This patch makes pattern recognisers do their own checking for vector
types and target support. Previously some recognisers did this
themselves and some left it to vect_pattern_recog_1.
Doing this means we can get rid of the type_in argument, which was
ignored if the recogniser did its own checki
This message is a long write-up for a patch that simply adds a common
routine for printing the "vector_foo_pattern: detected:" messages.
The reason for doing this is that some routines check for target support
themselves and some leave it to vect_pattern_recog_1. Those that leave
it to vect_patte
This patch adds a helper for pattern code that wants to find an
internal (vectorisable) definition of an SSA name.
A later patch will make more use of this, and alter the definition.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2018-06-18 Richard Sandiford
gcc/
vect_recog_dot_prod_pattern and vect_recog_sad_pattern both checked
whether the statement passed in had already been recognised as a
WIDEN_SUM_EXPR pattern. That isn't possible (any more?), since the
first recognised pattern wins, and since vect_recog_widen_sum_pattern
never matches a later statem
tree-vect-patterns.c checked that operands to primitive arithmetic ops
are compatible with each other and with the result. The checks date
back years and have long been redundant with verify_gimple_stmt.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2018-06-18 Rich
vectorizable_call stubs out the original scalar statement with
a dummy assignment to the same lhs, so that we don't leave any bogus
scalar calls around. If the call is actually a pattern statement,
the code rightly took the lhs of the original bb statement:
if (is_pattern_stmt_p (stmt_info))
A pattern's PATTERN_DEF_SEQ was attached to both the original statement
and the main pattern statement, which made it harder to update later.
This patch attaches it to just the original statement. In practice,
anything that cared had ready access to both.
Tested on aarch64-linux-gnu and x86_64-li
This patch is the first part of a series to fix to PR85694.
Later patches can make the pattern for a statement S2 reuse the
results of a PATTERN_DEF_SEQ statement attached to an earlier
statement S1. Although vect_mark_stmts_to_be_vectorized handled
this fine, vect_analyze_stmt and vect_transform_
On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
> On 18 June 2018 at 19:28, Nick Clifton wrote:
>> Hi Prathamesh,
>>
>>> I am getting the following build error with trunk:
>>> ../../gcc/gcc/tree.c: In member function ‘void
>>> escaped_string::escape(const char*)’:
>>> ../../gcc/gcc/tree.c:12457
On Fri, May 18, 2018 at 7:36 AM, H.J. Lu wrote:
> On Thu, May 17, 2018 at 10:32:56AM -0700, H.J. Lu wrote:
>> On Mon, May 14, 2018 at 8:00 PM, Martin Sebor wrote:
>> > On 05/14/2018 01:10 PM, H.J. Lu wrote:
>> >>
>> >> On Mon, May 14, 2018 at 10:40 AM, H.J. Lu wrote:
>> >>
>> >> $ cat c.i
>>
On 18 June 2018 at 19:28, Nick Clifton wrote:
> Hi Prathamesh,
>
>> I am getting the following build error with trunk:
>> ../../gcc/gcc/tree.c: In member function ‘void
>> escaped_string::escape(const char*)’:
>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
>> type ‘char*’
Hi Nick,
On Fri, Feb 16 2018, Nick Clifton wrote:
> Hi David,
>
> Attached is a revised version of the patch which I hope addresses all
> of your (very helpful) comments on the v3 patch.
>
> OK to apply once the sources are back on stage 1 ?
>
> Cheers
> Nick
>
> gcc/ChangeLog
> 2018-02-0
GCC currently defaults to -fmath-errno. This generates code assuming math
functions set errno and the application checks errno. Few applications
test errno and various systems and math libraries no longer set errno since it
is optional. GCC generates much faster code for simple math functions wi
Hi Prathamesh,
> I am getting the following build error with trunk:
> ../../gcc/gcc/tree.c: In member function ‘void
> escaped_string::escape(const char*)’:
> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
>m_str =
Hi,
I am getting the following build error with trunk:
../../gcc/gcc/tree.c: In member function ‘void
escaped_string::escape(const char*)’:
../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
type ‘char*’ casts away qualifiers [-Werror=cast-qual]
m_str = (char *) unescaped;
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Siddhesh
* config/aarch64/aarch64.h: Remove obsolete comment.
---
gcc/config/aarch64/aarch64.h | 9 -
1 file changed, 9 dele
OK.
On Fri, Jun 15, 2018 at 10:16 AM, Paolo Carlini
wrote:
> Hi,
>
> these bits started when I realized that in the error messages about
> redefined default arguments we were using DECL_SOURCE_LOCATION for the
> olddecl and just input_location for newdecl: in the future we'll able to
> point at t
Hi Nicolas,
> Here is the next version of the async I/O patch. It adds the documentation,
> renames the testcases, uses "gthr.h", follows the style guidelines and has
> been regression tested cleanly.
>
> As for adding additional flags, I think it would be better to follow ifort
> to minimize comp
Add missing target pthread to ensure test doesn't fail on bare-metal
targets. Committed as obvious.
ChangeLog:
2018-06-18 Wilco Dijkstra
PR tree-optimization/86076
* gcc.dg/pr86076.c: Add target pthread for bare-metal targets.
--
diff --git a/gcc/testsuite/gcc.dg/pr86076.c b/g
On 17 June 2018 at 19:49, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 06/15/2018 11:52 AM, Jonathan Wakely wrote:
>>
>> C++20 adds a header, which should define all the library
>> feature test macros, as well as implementation-specific macros like
>> _GLIBCXX_RELEASE and __GLIBCXX__.
>>
>> W
On Sun, 17 Jun 2018 at 17:49, Ed Smith-Rowland wrote:
>
> On 06/15/2018 11:52 AM, Jonathan Wakely wrote:
> > My preference is implemented by the attached patch.
> >
> This is pretty much what I was looking at doing. I say go!
Thanks for the feedback, I'll add later today.
> > While on the subje
Since PR64946 has been fixed, we can remove the xfail from this test.
Committed as obvious.
ChangeLog:
2018-06-18 Wilco Dijkstra
PR tree-optimization/64946
* gcc.target/aarch64/vect-abs-compile.c: Remove xfail.
--
diff --git a/gcc/testsuite/gcc.target/aarch64/vect-abs-compile.
Hi,
This patch teaches the AArch64 backend that AES instructions with a XOR and
zero operands can be simplified by replacing the operands of the AES with XOR's
thus eliminating the XOR. This is OK because the AES instruction XORs the input
operands.
This will improve code-generation when deali
Hi,
This patch teaches the AArch64 backend that the AESE and AESD unspecs are
commutative (which correspond to the vaeseq_u8 and vaesdq_u8 intrinsics). This
improves register allocation around their corresponding instructions avoiding
unnecessary moves.
For instance, with the old patterns code
Hi,
This patch series aims to improve codegen for the AArch64 AES instructions by
doing two things.
The first is to make the AES unspecs commutative and by consequence make the
corresponding intrinsics commutative, since the instructions themselves are
commutative in the input.
This will impro
Hi Guys,
The patch below allows the zlib library to be built when the build
directory is the same as the source directory. This patch has been in
the binutils/gdb sources for a while now, but unfortunately was never
copied to gcc. So I am trying to right that mistake now.
OK to apply
On Fri, Jun 15, 2018 at 10:11 PM Jeff Law wrote:
>
> On 06/14/2018 02:32 PM, David Malcolm wrote:
> > The vectorizer code has numerous instances of:
> >
> > if (dump_enabled_p ())
> > dump_printf_loc (MSG_NOTE, vect_location,
> > "=== some message ===\n");
> >
> > In eac
On Fri, Jun 15, 2018 at 2:59 PM H.J. Lu wrote:
>
> Currently GCC inserts ENDBR instruction at entries of all non-static
> functions, unless LTO compilation is used. Marking all functions,
> which are not called indirectly with nocf_check attribute, is not
> ideal since 99% of functions in a progr
> On 05/08/2018 09:14 AM, Jan Hubicka wrote:
> >Hi,
> >with lto, incremental linking can be meaninfuly done in three ways:
> > 1) read LTO file and produce non-LTO .o file
> > this is current behaviour of gcc -r or ld -r with plugin
> > 2) read LTO files and merge section for later LTO
> >
Hi Richard,
Sorry for the delay I have been on holidays. I had a look and I think you are
right. With these changes Umq and Uml seem to have the same functionality
though, so I would suggest using only one. Maybe use a different name for
both, removing both Umq and Uml in favour of Umn, wher
Hi,
that's already done for C++ so it seems consistent to do it for Fortran too.
Tested on x86-64/Linux, OK for the mainline?
2018-06-18 Eric Botcazou
* Makefile.def (fortran): Add check-target-libgomp-fortran.
* Makefile.tpl (check-target-libgomp-fortran): New phony target.
> Looks good to me. Rather than removing dwarf2/pr37726.c can you try
> turning that into a guality test that verifies the debug experience is the
> same (or better) than before? I realize guality stuff is fragile but you
> can restrict it to -O0 if you like (not sure if dg-skip-if supports that)
92 matches
Mail list logo
