Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist
:
>> There is already quite some discussion in the PRs, especially 85599,
>> where not all people were of the same opinion. Let us see where the
>> discussion here leads us.
>
>IMHO it's a mistake that the standard refuses to specify the
Am 14. Juni 2018 11:41:03 MESZ schrieb Janne Blomqvist
:
>On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil
>wrote:
>
>>
>> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
>> blomqvist.ja...@gmail.com>:
>>
>> >Either
>> >
>> >a) short-circuiting in left-to-right order
>> >
>> >or
>> >
>>
On Thu, 14 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> #pragma omp atomic is now allowed inside of simd regions.
> Tested on x86_64-linux, committed to gomp-5_0-branch.
>
> We will actually not vectorize it then though, so some further work will be
> needed in the vectorizer to handle it. Either,
Since param_type's constructors are defined by reference to the
constructors of the distribution, P0935's changes to the distribution's
constructors apply to their param_type as well.
On Thu, 14 Jun 2018, Jakub Jelinek wrote:
> On Thu, Jun 14, 2018 at 12:34:11PM +0200, Richard Biener wrote:
> > > #pragma omp atomic is now allowed inside of simd regions.
> > > Tested on x86_64-linux, committed to gomp-5_0-branch.
> > >
> > > We will actually not vectorize it then though, so
Hi Rasmus,
> On 13 Jun 2018, at 08:46, Rasmus Villemoes wrote:
>
>> This include path part alone looks sensible. I'd still like to
>> evaluate how it fares in a environment where many of there variations
>> are exercised, and I'm not quite done with this yet.
>
> Thanks, I do hope for careful
On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil wrote:
>
> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
> blomqvist.ja...@gmail.com>:
>
> >Either
> >
> >a) short-circuiting in left-to-right order
> >
> >or
> >
> >b) must evaluate all the arguments in left-to-right order
> >
> >My
On 14/06/18 06:43 -0400, Tim Song wrote:
Since param_type's constructors are defined by reference to the
constructors of the distribution, P0935's changes to the distribution's
constructors apply to their param_type as well.
Back to the patch mines I go ...
Andre Simoes Dias Vieira writes:
> @@ -5716,10 +5717,17 @@ aarch64_classify_address (struct aarch64_address_info
> *info,
>unsigned int vec_flags = aarch64_classify_vector_mode (mode);
>bool advsimd_struct_p = (vec_flags == (VEC_ADVSIMD | VEC_STRUCT));
>bool load_store_pair_p = (type
On Thu, 14 Jun 2018, Jan Hubicka wrote:
> Hi,
> this patch removes TYPE_DECLs and CONST_DECLs from block trees for LTO.
> With early debug we have no good use for it anymore.
>
> ltobootstrapped/regtested x86-64-linux, OK?
>
> Honza
>
> * tree.c (find_decls_types_r): Remove all
On Thu, Jun 14, 2018 at 12:34:11PM +0200, Richard Biener wrote:
> > #pragma omp atomic is now allowed inside of simd regions.
> > Tested on x86_64-linux, committed to gomp-5_0-branch.
> >
> > We will actually not vectorize it then though, so some further work will be
> > needed in the vectorizer
Sending to list as well.
> -Original Message-
> From: Tamar Christina
> Sent: Thursday, June 14, 2018 11:54
> To: 'Eric Botcazou' ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Use response files from the driver in more cases
>
> This also fixes PR86030,
>
> Thanks Eric!
>
> Regards,
Kyrill Tkachov writes:
> Hi Andre,
> On 07/06/18 18:02, Andre Simoes Dias Vieira wrote:
>> Hi,
>>
>> See below a patch to address PR 83009.
>>
>> Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran.
>> Ran the adjusted testcase for -mabi=ilp32.
>>
>> Is this OK for trunk?
Forwarding to gcc-patches ...
On 14/06/18 10:26 +0100, Jonathan Wakely wrote:
On 14/06/18 07:45 +0200, François Dumont wrote:
> You're still using __gnu_cxx::__alloc_traits for
> _Fwd_list_base::_Node_alloc_traits to get the _S_always_equal().
>
> So you might perhaps cleanup this part of
Hi!
#pragma omp atomic is now allowed inside of simd regions.
Tested on x86_64-linux, committed to gomp-5_0-branch.
We will actually not vectorize it then though, so some further work will be
needed in the vectorizer to handle it. Either, if we have hw atomics for both
the size of the scalar
On Thu, Jun 14, 2018 at 1:14 PM, Janus Weil wrote:
>
>
> Am 14. Juni 2018 11:41:03 MESZ schrieb Janne Blomqvist <
> blomqvist.ja...@gmail.com>:
> >On Thu, Jun 14, 2018 at 11:38 AM, Janus Weil
> >wrote:
> >
> >>
> >> Am 14. Juni 2018 10:05:24 MESZ schrieb Janne Blomqvist <
> >>
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to
trunk and gcc 8 branch for now.
Richard.
2018-06-14 Richard Biener
PR middle-end/86139
* tree-vect-generic.c (build_word_mode_vector_type): Remove
duplicate and harmful type_hash_canon.
* tree.c
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
>From ea6f08c8ce3de4d517d37faed5e2c9e4bf48f8bb Mon Sep 17 00:00:00 2001
From: Richard Guenther
Date: Thu, 14 Jun 2018 10:20:06 +0200
Subject: [PATCH] fix-pr86124
2018-06-14 Richard Biener
PR ipa/86124
Hi!
The following patch implements P0624R2, where stateless lambdas don't have
deleted default ctor and copy assignment operator anymore.
Tested on x86_64-linux with check-c++-all and libstdc++ testsuite, ok for
trunk?
2018-06-14 Jakub Jelinek
P0624R2 - Default constructible and
Am 13. Juni 2018 22:39:38 MESZ schrieb Thomas Koenig :
>>> If a logical .and. or .or. expression contains a reference to a
>>> function
>>> which is impure and which also does not behave like a pure function
>>> (i.e. does not have the implicit_pure attribute set), it emits a
>>> warning with
Hello,
We have a somewhat long-recognized problem with LTO vs. symbols referenced
in inline asm statements. For extended asms, the solution is easy: just
mention the symbol in constraints. For toplevel asms, this is trickier, as
they cannot have constraints.
I think a good solution for toplevel
Hi,
This patch should fix the issue. Ok for trunk?
gcc/testsuite/
* gcc.target/i386/avx512vl-vpclmulqdq-2.c: Remove 128bit version.
Thanks,
Julia
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, June 12, 2018 1:27 PM
> To: Koval, Julia
> Cc:
On Wed, Jun 13, 2018 at 10:39:38PM +0200, Thomas Koenig wrote:
> Am 13.06.2018 um 14:20 schrieb Janus Weil:
> > Hi Thomas,
> >
> >
> > > the attached patch introduces the following changes:
> >
> > thanks a lot for working on this!
> >
> >
> > > If a logical .and. or .or. expression contains
Hi Eric
On 07/06/18 16:33, Eric Botcazou wrote:
Sorry this fell off my radar. I have reg-tested it on x86 and tried it
on the sparc machine from the gcc farm but I think I couldn't finished
the run and now its showing to he unreachable.
The patch is a no-op for SPARC because it defines the
> This also fixes PR86030,
Glad to see we're not alone on the Windows ship. :-)
> Thanks Eric!
You're welcome.
--
Eric Botcazou
Hi,
this patch removes TYPE_DECLs and CONST_DECLs from block trees for LTO.
With early debug we have no good use for it anymore.
ltobootstrapped/regtested x86-64-linux, OK?
Honza
* tree.c (find_decls_types_r): Remove all non-VAR_DECLs from
blocks.
*
On 14/06/18 20:27 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 20:21, Ville Voutilainen wrote:
On 14 June 2018 at 20:08, Jonathan Wakely wrote:
Oops, indeed. But for gnu-attributes, surely we can decide whatever we
want about what's
valid and what's not?
We could say that #defining
On 14 June 2018 at 20:40, Jonathan Wakely wrote:
>> Namely "For an attribute-token (including an attribute-scoped-token)
>> not specified in this document, the behavior is
>> implementation-defined.", aka [dcl.attr.grammar]/6.
>
>
> As I said on IRC, if the user does
>
> #define gnu R"(
> ,=
On Wed, Jun 13, 2018 at 9:57 PM, Sebastian Huber
wrote:
> gcc/
> * config.gcc (riscv*-*-elf* | riscv*-*-rtems*): Use custom
> multilibs for *-*-rtems*.
> * config/riscv/t-rtems: New file.
Looks OK to me. Though I think you can probably self approve patches
like this that
On Thu, 14 Jun 2018, Richard Biener wrote:
> Can you make sure to add a testcase?
Apologies, I got a bit too excited and forgot that my local testcase had
void *unused_ref =
which masked another issue: unreferenced declarations won't even appear
in the symtab, even if they have
On 14 June 2018 at 19:51, Jonathan Wakely wrote:
> On 14/06/18 10:46 -0600, Martin Sebor wrote:
>>
>> On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
>>>
>>> The C++ committee has confirmed that passing a null pointer to the
>>> unary basic_string_view constructor is undefined. This removes the
On 14/06/18 19:54 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 19:51, Jonathan Wakely wrote:
On 14/06/18 10:46 -0600, Martin Sebor wrote:
On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
The C++ committee has confirmed that passing a null pointer to the
unary basic_string_view
On 14 June 2018 at 20:08, Jonathan Wakely wrote:
>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>> want about what's
>> valid and what's not?
>
>
> We could say that #defining 'nonnull' and/or 'gnu' as a macro is
> undefined, but then programs that the standard says are
On 14/06/18 10:46 -0600, Martin Sebor wrote:
On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
The C++ committee has confirmed that passing a null pointer to the
unary basic_string_view constructor is undefined. This removes the check
from our implementation, and adds the nonnull attribute to warn
On Mon, Jun 11, 2018 at 03:00:04PM -0400, Jason Merrill wrote:
> On Wed, Jun 6, 2018 at 5:18 PM, Marek Polacek wrote:
> > We crash on this testcase containing a bogus attribute, because
> > cp_check_const_attributes accessed TREE_VALUE of a tree that happened to be
> > expr_pack_expansion. Since
On Thu, Jun 14, 2018 at 12:51 PM, Marek Polacek wrote:
> On Mon, Jun 11, 2018 at 03:00:04PM -0400, Jason Merrill wrote:
>> On Wed, Jun 6, 2018 at 5:18 PM, Marek Polacek wrote:
>> > We crash on this testcase containing a bogus attribute, because
>> > cp_check_const_attributes accessed TREE_VALUE
On 14 June 2018 at 19:57, Jonathan Wakely wrote:
>> [macro.names]/2 forbids #defining macros with the same names as the
>> standard attributes.
>> The programs Martin shows as examples are not valid.
>
>
> But nonnull isn't a standard attribute though. So we can't use
> [[gnu::xxx]] attributes in
On 14/06/18 20:02 +0300, Ville Voutilainen wrote:
On 14 June 2018 at 19:57, Jonathan Wakely wrote:
[macro.names]/2 forbids #defining macros with the same names as the
standard attributes.
The programs Martin shows as examples are not valid.
But nonnull isn't a standard attribute though. So
On 14 June 2018 at 20:21, Ville Voutilainen wrote:
> On 14 June 2018 at 20:08, Jonathan Wakely wrote:
>>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>>> want about what's
>>> valid and what's not?
>>
>>
>> We could say that #defining 'nonnull' and/or 'gnu' as a macro
On 06/14/18 15:43, Richard Biener wrote:
> On Fri, 8 Jun 2018, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This patch converts the splay-tree internals into a template, and makes
>> the typed_splay_tree template really type-safe. Previously everything
>> would break apart if KEY_TYPE or VALUE_TYPE
On Fri, 8 Jun 2018, Bernd Edlinger wrote:
> Hi!
>
>
> This patch converts the splay-tree internals into a template, and makes
> the typed_splay_tree template really type-safe. Previously everything
> would break apart if KEY_TYPE or VALUE_TYPE would not be pointer types.
> This limitation is
On Thu, Jun 14, 2018 at 1:19 PM Alexander Monakov wrote:
>
> Hello,
>
> We have a somewhat long-recognized problem with LTO vs. symbols referenced
> in inline asm statements. For extended asms, the solution is easy: just
> mention the symbol in constraints. For toplevel asms, this is trickier, as
On Wed, Jun 13, 2018 at 3:44 AM, Jan Hubicka wrote:
> Hi,
> this patch adds lto-streamer-out dump file which journal what is streamed
> into the output file and why. For example compiling:
>
> #include
> main()
> {
> fprintf (stderr, "Error\n");
> }
>
> We get
>
> Creating compressed section
GCC Maintainers:
The following patch fixes the instruction count tests for various
builtin testcases that fail on AIX. The expected instruction counts
differ in a few cases between Linux and AIX. An AIX instruction target
was added to the instruction count tests that differ on AIX and Linux.
On Thu, Jun 14, 2018 at 09:29:42AM -0500, Aaron Sawdey wrote:
> 2018-06-14 Aaron Sawdey
>
> * config/rs6000/rs6000-string.c (select_block_compare_mode): Check
> TARGET_EFFICIENT_OVERLAPPING_UNALIGNED here instead of in caller.
> (do_and3, do_and3_mask, do_compb3, do_rotl3):
On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
The C++ committee has confirmed that passing a null pointer to the
unary basic_string_view constructor is undefined. This removes the check
from our implementation, and adds the nonnull attribute to warn when the
compiler can detect undefined input.
During the review of P0941R2 in Rapperswil we noticed that SD-6 puts
the macro __cpp_lib_tuple_element_t in , but it should be in
.
* include/std/tuple (__cpp_lib_tuple_element_t): Move feature test
macro from and change type to long.
* include/std/utility
Another piece of P0935, this time for , and
.
The only piece left is .
Tested powerpc64le-linux, committed to trunk.
commit 0752b4dfd8dba7bae234f6210eea74dc337ade15
Author: Jonathan Wakely
Date: Thu Jun 14 14:58:16 2018 +0100
P0935R0 Eradicating unnecessarily explicit default
OK.
On Thu, Jun 14, 2018 at 9:00 AM, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements P0624R2, where stateless lambdas don't have
> deleted default ctor and copy assignment operator anymore.
>
> Tested on x86_64-linux with check-c++-all and libstdc++ testsuite, ok for
> trunk?
>
>
On Thu, Jun 14, 2018 at 12:35 AM Martin Sebor wrote:
>
> The C implementation of the -Wbuiltin-declaration-mismatch
> warning relies on TYPE_MODE to detect incompatibilities
> between return and argument types in user declarations of
> built-in functions. That prevents mistakes like
>
>char*
On Thu, Jun 14, 2018 at 11:55:45AM +0200, Jakub Jelinek wrote:
>
> I bet gfortran evaluates the side-effects left-to-right and evaluates both
> arguments always, right?
>
Currently, gfortran evaluates a logical expression left-to-right
due to its use of the middle-end's TRUTH_AND_EXPR. The
On 06/14/2018 07:36 AM, Richard Biener wrote:
On Thu, Jun 14, 2018 at 12:35 AM Martin Sebor wrote:
The C implementation of the -Wbuiltin-declaration-mismatch
warning relies on TYPE_MODE to detect incompatibilities
between return and argument types in user declarations of
built-in functions.
OK.
On Thu, Jun 14, 2018 at 10:48 AM, Paolo Carlini
wrote:
> Hi,
>
> tested x86_64 linux.
>
> Thanks, Paolo.
>
> ///
>
This patch cleans up and refactors some stuff in rs6000-string.c
before I start working on adding vec/vsx support to str[n]cmp inline
expansion. Also removes the * from vsx_mov_64bit in vsx.md
because I'll be using that pattern to generate lxvd2x.
Bootstrap/regtest passes on ppc64le power8 -- ok
Hi,
tested x86_64 linux.
Thanks, Paolo.
///
/cp
2018-06-14 Paolo Carlini
* decl.c (duplicate_decls): Use DECL_SOURCE_LOCATION in
OPT_Wshadow warning_at.
(grokfndecl): Consistently use the location_t argument in
literal operator
On 14/06/18 11:46 +0100, Jonathan Wakely wrote:
On 14/06/18 06:43 -0400, Tim Song wrote:
Since param_type's constructors are defined by reference to the
constructors of the distribution, P0935's changes to the distribution's
constructors apply to their param_type as well.
Back to the patch
On Thu, 14 Jun 2018, Martin Sebor wrote:
> There's a comment in the code about the weak checking being
> deliberate (the word harmless here suggests the author may
> not have fully appreciated all the conversions it allows):
>
> /* Accept harmless mismatch in function types.
>
On Mon, 2018-06-04 at 15:20 +0200, Richard Biener wrote:
> On Sat, Jun 2, 2018 at 12:22 AM David Malcolm
> wrote:
> >
> > On Fri, 2018-06-01 at 17:31 +0200, Richard Biener wrote:
> > > On June 1, 2018 3:40:15 PM GMT+02:00, David Malcolm > > hat.
> > > com> wrote:
> > > > On Fri, 2018-06-01 at
The vectorizer code has numerous instances of:
if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
"=== some message ===\n");
In each case, the dump_printf_loc is a MSG_NODE at vect_location.
In almost all cases the message is of the form
"=== foo
The idea is to later use these macros to mark the
if (dump_enabled_p ())
parts of the compiler as cold, in the hope of helping non-PGO builds
of gcc.
I haven't measured it yet, though.
gcc/ChangeLog:
* system.h (GCC_LIKELY, GCC_UNLIKELY): New macros, adapted from
libgfortran.h.
These are mostly pre-approved, but there are some slightly non-trivial
cases in frv.c and mips.c.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successfully built "cc1" binaries on all 197 configurations in
contrib/config-list.mk.
OK for trunk?
gcc/ChangeLog:
*
On 14/06/18 15:00 +0100, Jonathan Wakely wrote:
During the review of P0941R2 in Rapperswil we noticed that SD-6 puts
the macro __cpp_lib_tuple_element_t in , but it should be in
.
* include/std/tuple (__cpp_lib_tuple_element_t): Move feature test
macro from and change type to
On Thu, Jun 14, 2018 at 12:59:00PM -0400, Jason Merrill wrote:
> On Thu, Jun 14, 2018 at 12:51 PM, Marek Polacek wrote:
> > On Mon, Jun 11, 2018 at 03:00:04PM -0400, Jason Merrill wrote:
> >> On Wed, Jun 6, 2018 at 5:18 PM, Marek Polacek wrote:
> >> > We crash on this testcase containing a bogus
* testsuite/21_strings/basic_string/cons/char/deduction.cc: Test
deduction from string views.
* testsuite/21_strings/basic_string/cons/wchar_t/deduction.cc:
Likewise.
Tested powerpc64le-linux, committed to trunk. This is probably worth
backporting to gcc-8-branch
On 06/14/2018 01:33 PM, Joseph Myers wrote:
On Thu, 14 Jun 2018, Martin Sebor wrote:
There's a comment in the code about the weak checking being
deliberate (the word harmless here suggests the author may
not have fully appreciated all the conversions it allows):
/* Accept harmless
On Thu, Jun 14, 2018 at 11:59 AM, Sebastian Huber
wrote:
> The change in config.gcc could break all RISC-V ports, e.g. some typo leading
> to a syntax error. I would like to back port this to GCC 7 and 8.
The backports are OK with me. Though I think you will need permission
from the branch
On 06/14/2018 02:37 PM, Joseph Myers wrote:
On Thu, 14 Jun 2018, Martin Sebor wrote:
Hmm, I thought fileptr_type_node was a node for FILE*, but it's
actually the same as ptr_type_node, i.e., void*, so the built-in
fprintf expects a void* argument (and declaring it to take a FILE*
triggers the
This patch ports from fprintf to using the dump API in a few places
Doing so makes this information appear in -fopt-info, remarks,
and optimization records, rather than just in the dump_file.
In early_inline_small_functions I experimented with two approaches:
simply porting from fprintf to
Changed in v2:
* The patch now reuses the existing dump API (the "dump_*" functions
in dumpfile.h), rather than inventing its own.
* I've eliminated the streaming "operator<<" API; instead the
optimization records and remarks are constructed from "dump_*" calls.
* This patch gets rid of the
Doing so makes this information appear in -fopt-info, remarks,
and optimization records, rather than just in the dump_file.
gcc/ChangeLog:
* gimple-loop-interchange.cc (tree_loop_interchange::interchange):
Convert fprintf calls to dump_printf calls.
I noticed when reviewing an HTML report generated from optimization
records generated in turn from the existing API calls that we
sometimes use MSG_NOTE when MSG_OPTIMIZED_LOCATIONS would be more
appropriate (to denote a successful optimization).
gcc/ChangeLog:
* tree-vect-loop.c
More porting from fprintf to using the dump API, so that
the messages appear in -fopt-info etc.
Note how these messages aren't consolidated into one
optimization record by the v2 patch kit.
gcc/ChangeLog:
* tree-ssa-loop-im.c (move_computations_worker): Port from
fprintf to the
Hi!
Many thanks for all your work on this.
On Mon, Jun 11, 2018 at 07:31:44PM -0400, Michael Meissner wrote:
> This patch is a complete rework of the previous patch. Previously I used new
> target hooks to provide IFmode (__ibm128) from being widened by default to
> TFmode (long double) on
On Wed, Jun 13, 2018 at 01:23:41PM +0200, Eric Botcazou wrote:
> 2018-06-13 Eric Botcazou
>
> PR target/86048
> * config/i386/winnt.c (i386_pe_seh_cold_init): Do not emit negative
> offsets for register save directives. Emit a second batch of save
> directives, if need
On Thu, Jun 14, 2018 at 04:27:26PM -0500, Segher Boessenkool wrote:
> Hi!
>
> Many thanks for all your work on this.
>
> On Mon, Jun 11, 2018 at 07:31:44PM -0400, Michael Meissner wrote:
> > This patch is a complete rework of the previous patch. Previously I used
> > new
> > target hooks to
- Am 14. Jun 2018 um 20:23 schrieb Jim Wilson j...@sifive.com:
> On Wed, Jun 13, 2018 at 9:57 PM, Sebastian Huber
> wrote:
>> gcc/
>> * config.gcc (riscv*-*-elf* | riscv*-*-rtems*): Use custom
>> multilibs for *-*-rtems*.
>> * config/riscv/t-rtems: New file.
>
>
Hi!
unsigned_type_for doesn't handle complex types, so will return NULL for
them, which this optimization wasn't prepared to handle.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
pre-approved in the PR by Richard, committed to trunk and will commit to
8.2.
This doesn't
The committee approved this change last week, so that
operations combining scalars and valarrays work as long as the scalar
is convertible to the valarray's value_type, instead of failing
argument deduction when the types differ.
While testing this I discovered we didn't have any tests for
On Thu, 14 Jun 2018, Martin Sebor wrote:
> Hmm, I thought fileptr_type_node was a node for FILE*, but it's
> actually the same as ptr_type_node, i.e., void*, so the built-in
> fprintf expects a void* argument (and declaring it to take a FILE*
> triggers the new warning). That seems odd. What
On Thu, Jun 14, 2018 at 3:40 PM, Marek Polacek wrote:
> On Thu, Jun 14, 2018 at 12:59:00PM -0400, Jason Merrill wrote:
>> On Thu, Jun 14, 2018 at 12:51 PM, Marek Polacek wrote:
>> > On Mon, Jun 11, 2018 at 03:00:04PM -0400, Jason Merrill wrote:
>> >> On Wed, Jun 6, 2018 at 5:18 PM, Marek Polacek
On Thu, Jun 14, 2018 at 06:25:49PM -0500, Segher Boessenkool wrote:
> On Wed, Jun 13, 2018 at 05:10:15PM -0400, Michael Meissner wrote:
> > In addition to the previous patch to aid in transitioning the PowerPC long
> > double format to IEEE 128-bit, I have some additional patches that are
> >
On Wed, Jun 13, 2018 at 05:10:15PM -0400, Michael Meissner wrote:
> In addition to the previous patch to aid in transitioning the PowerPC long
> double format to IEEE 128-bit, I have some additional patches that are needed.
> The previous patch is:
>
On Mon, Jun 11, 2018 at 07:59:42PM +0200, Thomas Koenig wrote:
> Hi Steve,
>
> > The attach patch fixes an ICE that occurs when a user
> > uses a derived type as an actual argument to subprogram.
> > Regression tested on x86_64-*-freebsd and i586-*-freebsd.
> > OK to commit?
>
> OK. Thanks!
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 wrote:
> > This fixes some of the PowerPC tests that had implicit assumptions about the
> > long double format. The fixes involved:
> >
> > 1)
On Thu, 14 Jun 2018, Martin Sebor wrote:
> The standard says FILE is a type so I don't think it can
> be a macro that expands to something other than a type
> named FILE. The spec doesn't prevent programs from
> #undef-ing FILE so implementations cannot define it as
> one and rely on it staying
Hi Mike,
On Wed, Jun 13, 2018 at 05:16:37PM -0400, Michael Meissner wrote:
> This fixes some of the PowerPC tests that had implicit assumptions about the
> long double format. The fixes involved:
>
> 1)Using long double __complex instead of using a KC attribute;
Why? Does KC not
LWG 3039 changed the spec to use remove_cvref_t instead of decay_t,
and this patch makes that change to our std::packaged_task. I'm not
sure why I created a custom type at namespace scope to constrain
packaged_task. This patch replaces it with an alias for enable_if.
std::thread already had the
> I've noticed this test fails on i686-linux
> gcc/gcc/testsuite/gcc.target/i386/pr86048.c:23:3: error: unknown register
> name '%xmm6' in 'asm'
>
> Fixed thusly, tested on x86_64-linux and i686-linux, committed to trunk and
> 8.2.
Thanks!
--
Eric Botcazou
On 06/14/2018 04:52 PM, Joseph Myers wrote:
On Thu, 14 Jun 2018, Martin Sebor wrote:
The standard says FILE is a type so I don't think it can
be a macro that expands to something other than a type
named FILE. The spec doesn't prevent programs from
#undef-ing FILE so implementations cannot
On 06/14/2018 10:54 AM, Ville Voutilainen wrote:
On 14 June 2018 at 19:51, Jonathan Wakely wrote:
On 14/06/18 10:46 -0600, Martin Sebor wrote:
On 06/13/2018 10:30 AM, Jonathan Wakely wrote:
The C++ committee has confirmed that passing a null pointer to the
unary basic_string_view
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 nice to have and hope you'll get an OK for both this and
the gimple.vim patch.
One nit-pick: unlike "GIMPLE",
Hi Shaokun,
On 14/06/18 02:09, Shaokun Zhang wrote:
This patch adds HiSilicon's an mcpu: tsv110, which supports v8_4A.
---
gcc/ChangeLog| 8 +++
gcc/config/aarch64/aarch64-cores.def | 3 +
gcc/config/aarch64/aarch64-cost-tables.h | 103
On Mon, Jun 11, 2018 at 10:22 PM, Thomas Koenig
wrote:
> Hello world,
>
> the attached patch introduces the following changes:
>
> If a logical .and. or .or. expression contains a reference to a function
> which is impure and which also does not behave like a pure function
> (i.e. does not have
Hi!
On Tue, Jun 12, 2018 at 03:25:20PM -0500, Will Schmidt wrote:
> --- a/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-int.c
> +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-neg-int.c
> @@ -1,11 +1,11 @@
> /* Verify that overloaded built-ins for vec_neg with int
> inputs produce the right
94 matches
Mail list logo
