Dear Janus,
I woke up in the middle of the night realising that not only are you
right about the need for dynamic dispatch but that my dtio_20.f90 must
already work.
Thanks for putting me right!
Paul
On 13 December 2016 at 00:30, Janus Weil wrote:
> Hi Paul, hi all,
>
> 2016-12-12 21:04 GMT+01
On Mon, Dec 12, 2016 at 11:12 AM, Nathan Sidwell wrote:
> This patch fixes an ICE in a checking build where structural_comptypes
> disagrees with TYPE_CANONICAL.
>
> An (implicit) template alias has a different TYPE_TI_TEMPLATE to the thing
> its aliasing. That make structural comparison think it
Hi:
I get the copyright assignment, it's ok for commit.
but recently, The gcc mainline trunk are fail to building on
mips64el-unknown-linux,
the bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660 show the problem.
Thanks,
Paul
On Thu, Nov 17, 2016 at 7:14 PM, Matthew Fortune
wrote:
> Hi Jef
OK.
On Sat, Dec 10, 2016 at 6:04 AM, Jakub Jelinek wrote:
> Hi!
>
> Mangling of decltype(auto) has been added back in April 2013:
> https://gcc.gnu.org/ml/gcc-patches/2013-04/msg01273.html
> and matches the
> https://mentorembedded.github.io/cxx-abi/abi.html#mangling
> ::= Da # a
On 12/12/2016 11:51 AM, Martin Sebor wrote:
The attached patch removes the unsafe assumption behind the ICE.
Is this okay for both trunk and GCC 6?
+ && TREE_CODE (innertype) == REFERENCE_TYPE
+ && TREE_CODE (TREE_TYPE (innertype)) == FUNCTION_TYPE
+ && TR
On Mon, Dec 12, 2016 at 4:09 PM, Marek Polacek wrote:
> So I'm wondering how/if should we proceed with this. Seems that if we'll
> go with my patch, we might have to add a bunch of sentinels (it seemed that
> it's mostly warnings about GNU extensions that we want to silence for
> system headers),
On Mon, Dec 12, 2016 at 5:48 PM, Nathan Sidwell wrote:
> On 12/12/2016 04:44 PM, Jason Merrill wrote:
>>
>> On Mon, Dec 12, 2016 at 2:12 PM, Nathan Sidwell wrote:
>>>
>>> Solved by breaking TYPE_TEMPLATE_INFO into an underlying helper that
>>> doesn't deal with type aliases.
>>
>> I like this ide
The attached patch avoids infinite recursion when traversing phi
nodes in maybe_warn_alloc_args_overflow by using a bitmap to keep
track of those already visited and breaking out.
Thanks
Martin
PR tree-optimization/78775 - ICE in maybe_warn_alloc_args_overflow
gcc/ChangeLog:
PR tree-optimizati
This patch adds built-in function support for the new setb, cmprb, and
cmpeqb Power9 instructions. This third version of the patch differs
from the second in the following ways:
1. Changed the name of the *cmprb, *setb, *cmprb2, and *cmpeqb new
instructions to *cmprb_internal, *setb_internal, a
+/* The lower bound when precision isn't specified is 8 bytes
+ ("1.23456" since precision is taken to be 6). When precision
+ is zero, the lower bound is 1 byte (e.g., "1"). Otherwise,
+ when precision is greater than zero, then the lower bound
+ is 2 plus precision
On Mon, Dec 12, 2016 at 3:29 AM, Tamar Christina
wrote:
> Hi Andrew,
>
> These should be fixed now.
Yes they are fixed.
Thanks,
Andrew
>
> Thanks,
> Tamar
>
>
> From: Andrew Pinski
> Sent: Wednesday, December 7, 2016 4:33:51 AM
> To: Christophe Lyon
> C
Hi Paul, hi all,
2016-12-12 21:04 GMT+01:00 Janus Weil :
> As commented several times in bugzilla, my feeling is that the
> solution for this PR would be to utilize the vtable machinery, in
> order to generate a truly polymorphic call to the DTIO procedure.
in order to elaborate what I have in mi
On 12/12/2016 04:44 PM, Jason Merrill wrote:
On Mon, Dec 12, 2016 at 2:12 PM, Nathan Sidwell wrote:
Solved by breaking TYPE_TEMPLATE_INFO into an underlying helper that doesn't
deal with type aliases.
I like this idea, but I don't like the name. Since alias templates
are generally transparen
On 12/05/2016 08:56 PM, Martin Sebor wrote:
On 12/05/2016 11:21 AM, Jeff Law wrote:
On 12/04/2016 04:55 PM, Martin Sebor wrote:
Bug 78519 points out that while the -Wformat warning flags a small
subset of sprintf calls with a null pointer argument to a %s directive
(those where the pointer is a
On 12/11/16 7:24 AM, Gerald Pfeifer wrote:
On Thu, 8 Dec 2016, Josh Conner wrote:
This patch adds support to gcc for the Fuchsia OS
(https://fuchsia.googlesource.com/).
Once this is in, can you please suggest a news item for our
main page?
(You could cook a patch following https://gcc.gnu.org
On Mon, Dec 12, 2016 at 2:12 PM, Nathan Sidwell wrote:
> Solved by breaking TYPE_TEMPLATE_INFO into an underlying helper that doesn't
> deal with type aliases.
I like this idea, but I don't like the name. Since alias templates
are generally transparent in the language, I wonder about changing
TY
On 12/12/2016 12:20 PM, Jakub Jelinek wrote:
Hi!
The strength reduction has code to emit stuff before or after the last insn
in a bb, but uses a wrong predicate to decide where to put it, is_ctrl_stmt
covers only a subset of statements that must end a bb.
Fixed thusly, bootstrapped/regtested on
On 12/10/16 3:26 AM, Richard Earnshaw wrote:
On 08/12/16 22:55, Josh Conner wrote:
+ arm*-*-fuchsia*)
+ tm_file="${tm_file} fuchsia.h arm/fuchsia-elf.h glibc-stdint.h"
+ tmake_file="${tmake_file} arm/t-bpabi"
+ ;;
This will leave the default cpu as arm7tdmi. Is t
On 12/12/2016 04:16 AM, James Greenhalgh wrote:
On Wed, Nov 30, 2016 at 02:36:28PM +, James Greenhalgh wrote:
Hi,
As subject - update extend.texi to mention availability of _Float16 types
on ARM and AArch64.
OK?
*ping*
Thanks,
James
2016-11-30 James Greenhalgh
* doc/exten
On 12/12/2016 04:16 AM, James Greenhalgh wrote:
On Thu, Dec 01, 2016 at 11:09:07AM +, James Greenhalgh wrote:
On Wed, Nov 30, 2016 at 05:58:13PM +, Joseph Myers wrote:
On Wed, 30 Nov 2016, James Greenhalgh wrote:
+@code{_Float16} type defined by ISO/IEC TS18661:3-2005
Add a space a
On Mon, Dec 12, 2016 at 02:15:42PM -0700, Jeff Law wrote:
> On 12/12/2016 12:14 PM, Jakub Jelinek wrote:
> >{ is a special character in ERE, so gawk rightfully complains in
> >POSIXLY_CORRECT mode. The regex is meant to look for { at the beginning
> >of line. Neither "^\{" nor "^\\{" works though
Hi Thomas,
Thanks for working on this,
On 12 December 2016 at 18:52, Thomas Preudhomme
wrote:
> Hi,
>
> The logic to make -mthumb optional for Thumb-only devices is only executed
> when no -marm or -mthumb is given on the command-line. This includes
> configuring GCC with --with-mode= because t
On 12/12/2016 02:03 PM, Marek Polacek wrote:
At least these should be HOST_WIDE_INTs rather than ints. There might be
more opportunities than this.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-12-12 Marek Polacek
* tree-data-ref.c (compute_overlap_steps_for_affine_uni
On 12/12/2016 12:14 PM, Jakub Jelinek wrote:
Hi!
{ is a special character in ERE, so gawk rightfully complains in
POSIXLY_CORRECT mode. The regex is meant to look for { at the beginning
of line. Neither "^\{" nor "^\\{" works though, but "^[{]" does.
Bootstrapped/regtested on x86_64-linux and
On 12/09/2016 11:07 AM, Martin Sebor wrote:
Bug 78696 points out a bug in the handling of the %g directive in
the gimple-ssa-sprintf pass where precision wasn't being correctly
handled. In the process of developing and testing a fix for it
I noticed a few other subtle problems in the floating po
So I'm wondering how/if should we proceed with this. Seems that if we'll
go with my patch, we might have to add a bunch of sentinels (it seemed that
it's mostly warnings about GNU extensions that we want to silence for
system headers), but it's hard to gauge the overall effect.
On Thu, Nov 03, 20
At least these should be HOST_WIDE_INTs rather than ints. There might be
more opportunities than this.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-12-12 Marek Polacek
* tree-data-ref.c (compute_overlap_steps_for_affine_univar): Change
parameters' type from int
Hi Claudiu,
On 12/12/16 19:18, Claudiu Zissulescu wrote:
> It looks sane to me, please apply (ask Andrew to do it for you)
>
> //Claudiu
Many thanks for the quick review. I'll ask Andrew to do it once the
binutils patch is approved and applied.
Best regards,
Graham.
signature.asc
Descriptio
On 12/11/2016 05:21 PM, Martin Sebor wrote:
So I think the return value needs a bit of clarification here. Take
guidance from our discussion on this thread.
OK with that fixed.
jeff
The "strange test failures​" that I wrote about in a separate thread
late last week prompted me to re-review t
Hi Janne,
How about adding charlen_zero_node and one_node like the others have it to
prevent repeating ourselves?
- Andre
Am 12. Dezember 2016 20:39:38 MEZ, schrieb Janne Blomqvist
:
>On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild
>wrote:
>> Hi Janne,
>>
>> I found that you are favoring b
Hi Paul,
> The original testcase appears here as dtio_19.f90. I gather that some
> vendors accept this, while fort does not. IMHO ifort is correct here
> since there is no specific DTIO procedure present.
to be honest, I kind of disagree with ifort here (wouldn't be the
first time ;) ...
dtio_19
On Mon, Dec 12, 2016 at 7:39 PM, Andre Vehreschild wrote:
> Hi Janne,
>
> I found that you are favoring build_int_cst (size_type_node, 0) over
> size_zero_node. Is there a reason to this?
Yes. AFAIU size_zero_node is a zero constant for sizetype which is not
the same as size_type_node.
AFAIK the
Hi!
On the following testcase (where I've failed to reduce it without the
header, got to over 70KB with both delta and creduce) we end up with huge
RTL expressions in debug insns that just slow down combiner as well as
var-tracking etc. too much.
Generally, at GIMPLE level we try to keep the debug
Hi!
The strength reduction has code to emit stuff before or after the last insn
in a bb, but uses a wrong predicate to decide where to put it, is_ctrl_stmt
covers only a subset of statements that must end a bb.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
20
It looks sane to me, please apply (ask Andrew to do it for you)
//Claudiu
From: Graham Markall [graham.mark...@embecosm.com]
Sent: Monday, December 12, 2016 8:11 PM
To: gcc-patches@gcc.gnu.org
Cc: claudiu.zissule...@synopsys.com; andrew.burg...@embecosm.com
Hi!
The local pure const pass notices the static ctor is looping const,
so sets TREE_READONLY and DECL_LOOPING_CONST_OR_PURE_P and does not
clear DECL_STATIC_CONSTRUCTOR bit because it is looping.
Then the ipa pure const pass notices the static ctor is non-looping const,
clears DECL_LOOPING_CONST_
Hi!
{ is a special character in ERE, so gawk rightfully complains in
POSIXLY_CORRECT mode. The regex is meant to look for { at the beginning
of line. Neither "^\{" nor "^\\{" works though, but "^[{]" does.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-12-12 Jakub Je
This patch fixes an ICE in a checking build where structural_comptypes
disagrees with TYPE_CANONICAL.
An (implicit) template alias has a different TYPE_TI_TEMPLATE to the
thing its aliasing. That make structural comparison think it's
different. In the testcase we end up thinking 'Loc' refers
This proposed binutils patch adds an arclinux_nps linker emulation:
https://sourceware.org/ml/binutils/2016-12/msg00172.html
The arclinux_nps emulation provides some additional symbols in the
linker script, which are specific to the Mellanox NPS-400. The patch in
this message modifies the arc LIN
2016-12-12 18:37 GMT+01:00 Paul Richard Thomas :
> Hi Janus,
>
> The patch is good - OK for trunk.
Thanks, Paul. Committed as r243580.
Cheers,
Janus
> On 12 December 2016 at 16:52, Janus Weil wrote:
>> Hi all,
>>
>> I hate to ping this patch once more, but somehow we need to come to a
>> conc
Dear All,
The original testcase appears here as dtio_19.f90. I gather that some
vendors accept this, while fort does not. IMHO ifort is correct here
since there is no specific DTIO procedure present. However, it could
be that a more helpful error message to the effect that this is an
abstract type
> However, this will also affect people doing C->Fortran calls the
> old-fashioned way without ISO_C_BINDING, as they will have to change
> the string length argument from int to size_t in their prototypes.
> Then again, Intel Fortran did this some years ago so I guess at least
> people who care a
On 12/07/2016 12:17 PM, Martin Sebor wrote:
OK. So is the hangup really a problem in how the return type is
documented? I parsed the comment as essentially saying we return true
if the range gets adjusted in any way -- thus a sign change in the first
block would qualify, but we returned false w
On 12/12/16 14:09 +, Jonathan Wakely wrote:
This syncs the std::experimental::filesystem code on gcc-6-branch to
match what's on trunk, except that the C++17 std::string_view type
doesn't exist on the branch, so the filesystem::path type only
supports experimental::string_view.
I'm doing it
Hi,
The logic to make -mthumb optional for Thumb-only devices is only executed when
no -marm or -mthumb is given on the command-line. This includes configuring GCC
with --with-mode= because this makes the option to be passed before any others.
The optional_mthumb-* testcases are skipped when -
On Mon, Dec 12, 2016 at 06:44:19PM +0100, Marek Polacek wrote:
> Ping.
>
> On Mon, Dec 05, 2016 at 09:37:30PM +0100, Marek Polacek wrote:
> > We were crashing on this invalid test because
> > cp_parser_std_attribute_spec_seq
> > in cp_parser_statement returned error_mark_node, but the subsequent
Hi Janus,
all the sanitizer issues I fixed occur during compiling the testsuite. So I
would say, that when with the patch these errors do not occur anymore while
processing the testsuite, then those are tested for, right?
- Andre
On Mon, 12 Dec 2016 13:37:43 +0100
Janus Weil wrote:
> Hi Andre,
Ping.
On Mon, Dec 05, 2016 at 09:37:30PM +0100, Marek Polacek wrote:
> We were crashing on this invalid test because cp_parser_std_attribute_spec_seq
> in cp_parser_statement returned error_mark_node, but the subsequent
> attribute_fallthrough_p wasn't prepared for that.
>
> Bootstrapped/regteste
PR preprocessor/78680 identifies a crash when attempting to issue
a -Wformat warning, where the format string includes a string token
split across multiple physical source lines via backslash-continued
lines.
The issue is that libcpp is generating bogus range information for
such tokens.
For exam
Hi Janne,
I found that you are favoring build_int_cst (size_type_node, 0) over
size_zero_node. Is there a reason to this?
Furthermore did I have to patch this:
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 585f25d..f374558 100644
--- a/gcc/fortran/dump-parse-tr
Hi Janus,
The patch is good - OK for trunk.
Thanks
Paul
On 12 December 2016 at 16:52, Janus Weil wrote:
> Hi all,
>
> I hate to ping this patch once more, but somehow we need to come to a
> conclusion here.
>
> The issue boils down to the fact that there is a piece of code in the
> gfortran co
On Mon, Dec 12, 2016 at 10:54:12AM -0600, Segher Boessenkool wrote:
> On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> > Patch with these changes and a fix because of not handling
> > VOIDmode attached. Bootstrapped and regression tested on s390 and
> > s390x.
>
> Okay for trunk.
>
On Mon, Dec 12, 2016 at 05:46:02PM +0100, Dominik Vogt wrote:
> Patch with these changes and a fix because of not handling
> VOIDmode attached. Bootstrapped and regression tested on s390 and
> s390x.
Okay for trunk.
When did you see VOIDmode, btw? It wasn't on a const_int I hope?
Segher
>
OK.
On Mon, Dec 12, 2016 at 8:53 AM, Nathan Sidwell wrote:
> following discussion on the ABI list, here's an update to the generic lambda
> demangler patch.
>
> The guts of the patch are the same as before -- note when we're printing a
> generic lambda's parms and interpret template type parm ref
The attached patch removes the unsafe assumption behind the ICE.
Is this okay for both trunk and GCC 6?
Thanks
Martin
PR c++/78774 - [6/7 Regression] ICE in constexpr string literals and templates
gcc/cp/ChangeLog:
PR c++/78774
* pt.c (convert_template_argument): Avoid assuming operand type
On Sat, Dec 10, 2016 at 10:37:38AM -0600, Segher Boessenkool wrote:
> On Fri, Dec 09, 2016 at 04:23:44PM +0100, Dominik Vogt wrote:
> > 0001-*
> >
> > Deal with mode expanding zero_extracts in change_zero_ext. The
> > patch looks good to me, but not sure whether endianness is
> > handled pr
On 12/12/2016 09:37 AM, Jakub Jelinek wrote:
On Mon, Dec 12, 2016 at 09:29:44AM -0700, Jeff Law wrote:
2016-12-08 Cesar Philippidis
PR fortran/78027
gcc/
* ipa-icf.c (sem_function::parse): Don't process functions with
oacc decl attributes, as they may be OpenACC routines.
gc
On Mon, Dec 12, 2016 at 09:29:44AM -0700, Jeff Law wrote:
> >>>2016-12-08 Cesar Philippidis
> >>>
> >>>PR fortran/78027
> >>>
> >>>gcc/
> >>>* ipa-icf.c (sem_function::parse): Don't process functions with
> >>>oacc decl attributes, as they may be OpenACC routines.
> >>>
> >>>
On Mon, Dec 12, 2016 at 03:50:14PM +0100, Jakub Jelinek wrote:
> On Mon, Dec 12, 2016 at 03:36:01PM +0100, Dominik Vogt wrote:
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> > b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> > new file mode 100644
> > index 000..d24a334
> >
On 12/09/2016 01:10 AM, Richard Biener wrote:
Yea. Not sure how often something like that would happen in practice, but
using the equivalence to simplify rather than for propagation seems like the
way to go.
I keep thinking about doing some similar in DOM, but haven't gotten around to
seeing w
On 07/12/16 15:22 +, Jonathan Wakely wrote:
This test for the contents of the header doesn't get run for
C++98 mode and doesn't include the C++14 and C++17 additions. I've
split the C++98-only test into a separate file, and added the new
parts so they're tested conditionally depending on how
On Mon, Dec 12, 2016 at 09:32:30AM -0700, Jeff Law wrote:
> On 12/09/2016 03:20 AM, Bin Cheng wrote:
> >Hi,
> >PR78652 was fixed by patch for PR77856, this patch adds a test for it. Test
> >result checked, is it OK?
> >
> >Thanks,
> >bin
> >
> >gcc/testsuite/ChangeLog
> >2016-12-07 Bin Cheng
>
On 12/09/2016 03:20 AM, Bin Cheng wrote:
Hi,
PR78652 was fixed by patch for PR77856, this patch adds a test for it. Test
result checked, is it OK?
Thanks,
bin
gcc/testsuite/ChangeLog
2016-12-07 Bin Cheng
PR rtl-optimization/78652
* gcc.c-torture/execute/pr78652.c: New test
On 12/09/2016 07:05 AM, Cesar Philippidis wrote:
On 12/08/2016 04:37 PM, Jeff Law wrote:
On 12/08/2016 04:05 PM, Cesar Philippidis wrote:
PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with
On 19/10/16 21:13 +0100, Jonathan Wakely wrote:
This patch does three things:
1. Refactor std::enable_shared_from_this support code.
Instead of several overloads of __enable_shared_from_this_helper
that contain the same code but operating on slightly different types
I've split it into two parts
Hello!
Attached patch fixes PR78738 in a different way. The patch enables
X87_ENABLE_ARITH and X87_ENABLE_FLOAT also for
flag_unsafe_math_optimizations.
2016-12-12 Uros Bizjak
PR target/78738
* config/i386/i386.h (X87_ENABLE_ARITH): Also enable for
flag_unsafe_math_optimizations.
On December 12, 2016 4:29:24 PM GMT+01:00, Michael Matz wrote:
>Hi,
>
>On Fri, 9 Dec 2016, Richard Biener wrote:
>
>> On December 9, 2016 4:29:04 PM GMT+01:00, Michael Matz
>wrote:
>> >Hi,
>> >
>> >if the induction variable on which we want to partition the loop
>> >iterations for loop splitting
Hi,
After the recent update from Tamar, I noticed a few discrepancies
between ARM and AArch64 regarding a few poly64 intrinsics.
This patch:
- adds vtst_p64 and vtstq_p64 to AArch64's arm_neon.h
- adds vgetq_lane_p64, vset_lane_p64 and vsetq_lane_p64 to ARM's arm_neon.h
( vget_lane_p64 was alread
On 12/12/2016 02:19 AM, Tamar Christina wrote:
Ping
From: Tamar Christina
Sent: Friday, December 2, 2016 4:20:42 PM
To: Joseph Myers
Cc: GCC Patches; Wilco Dijkstra; rguent...@suse.de; l...@redhat.com; Michael
Meissner; nd
Subject: Re: [PATCH][GCC][PATCH
Hi all,
I hate to ping this patch once more, but somehow we need to come to a
conclusion here.
The issue boils down to the fact that there is a piece of code in the
gfortran code which claims that specification functions are
'constant', but I doubt that this is true. To my understanding the
conce
On Sun, Dec 4, 2016 at 11:38 PM, Janne Blomqvist
wrote:
> Hi,
>
> I'm working on a patch to change the type that GFortran uses for
> string lengths from a C int to a C size_t. I'm at a point where it
> does regtest successfully, with the exception of
> gfortran.dg/char_result_8.f90 with -O1 where
On 12/12/16 13:55 +, Kyrill Tkachov wrote:
Hi all,
I've been investigating the execution failures of:
21_strings/basic_string/numeric_conversions/char/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stold.cc
27_io/basic_
Hi,
On Fri, 9 Dec 2016, Richard Biener wrote:
> On December 9, 2016 4:29:04 PM GMT+01:00, Michael Matz wrote:
> >Hi,
> >
> >if the induction variable on which we want to partition the loop
> >iterations for loop splitting might overflow we would either need
> >runtime
> >tests checking if an o
On Mon, Dec 12, 2016 at 03:36:01PM +0100, Dominik Vogt wrote:
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> new file mode 100644
> index 000..d24a334
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr78748.c
> @@ -0
The attached patch fixes PR/78748. Bootstrapped and regression
tested on s390 and s390x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78748
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
gcc/ChangeLog-pr78748
PR target/78748
* config/s390/s390.md ("*andc_split_"): Allow me
On 12/12/16 12:44 +, Jonathan Wakely wrote:
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Remove stray character at end of dg-do directive.
And another one with the same problem.
Tested x86_64-linux, committed to trunk.
commit c3aaa2055071251d29fd
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while scann
On 21/06/16 15:16, Andre Vieira (lists) wrote:
> Hello,
>
> After some changes to GCC this test no longer tests the desired code
> generation behavior. The generated assembly is better than it used to
> be, but it has become too smart. I add an extra parameter to make sure
> GCC can't optimize awa
This syncs the std::experimental::filesystem code on gcc-6-branch to
match what's on trunk, except that the C++17 std::string_view type
doesn't exist on the branch, so the filesystem::path type only
supports experimental::string_view.
I'm doing it as one big patch, rather than backporting 26 indi
Hi all,
I've been investigating the execution failures of:
21_strings/basic_string/numeric_conversions/char/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stod.cc
21_strings/basic_string/numeric_conversions/wchar_t/stold.cc
27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
o
following discussion on the ABI list, here's an update to the generic
lambda demangler patch.
The guts of the patch are the same as before -- note when we're printing
a generic lambda's parms and interpret template type parm references
differently. however:
1) don't refer to this as a mangli
>
> It's a shame this is the only way to deal with this but I see aarch64 have
> to resort to the same thing for error checking tests.
>
I have looked into this some more and I 've found that the solution I proposed
is incomplete.
The problem is that if no linker plugin is found, -fno-fat-lto-o
> > The -mnan=2008 and -mabs=2008 options are not supported on pre-R2
> targets.
> > This results in failures for tests which use these options, such as
> > nan-2008.c,
> > fabs-2008.c etc.
> >
> > This patch makes the testsuite upgrade to R2 if -mnan=2008 and -mabs=2008
> are
> > used as test opt
On Mon, Dec 12, 2016 at 3:35 PM, Janus Weil wrote:
> Hi guys,
>
>> there is already an ABI change. DTIO needed it.
>
> maybe it would be a good idea to document this in places like:
> * https://gcc.gnu.org/wiki/GFortran/News
> * https://gcc.gnu.org/gcc-7/changes.html
>
> On the first page there ar
Jiong Wang writes:
> On 16/11/16 14:02, Jakub Jelinek wrote:
>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote:
>>> On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote:
The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref
were
designed as short
On 12/09/2016 11:33 AM, Paolo Carlini wrote:
this regression is caused by my fix for c++/60385, where I changed
push_namespace to early return (a bool) when pushdecl fails. In the
present testcase, a different push_namespace call in
cp_parser_namespace_definition, for nested namespace definition
Hi guys,
> there is already an ABI change. DTIO needed it.
maybe it would be a good idea to document this in places like:
* https://gcc.gnu.org/wiki/GFortran/News
* https://gcc.gnu.org/gcc-7/changes.html
On the first page there are "Compatibility notices" for several
earlier versions which menti
On Mon, Dec 12, 2016 at 01:54:41PM +0100, FX wrote:
> > The following patch has remained unreviewed for a week:
> >
> > [build] Disable hwcaps on libgfortran
> >https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
> >
> > It is required to unbreak bootstrap on Solaris/x86 and, tho
On Mon, Dec 12, 2016 at 12:29 PM, Andre Vehreschild wrote:
> I will take on the coarray ABI changes in the next days and also emit a
> pull-request to the opencoarrays to get them to sync. Janne, please wait until
> I have added those changes to prevent people from having to re-compile
> multiple
On Mon, Dec 12, 2016 at 12:20 PM, FX wrote:
> Hi Janne,
>
> This is an ABI change, so it is serious… it will require people to recompile
> older code and libraries with the new compiler. Do we already plan to break
> the ABI in this cycle, or is this the first ABI-breaking patch of the cycle?
A
> The following patch has remained unreviewed for a week:
>
> [build] Disable hwcaps on libgfortran
>https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00336.html
>
> It is required to unbreak bootstrap on Solaris/x86 and, though touching
> both libgfortran and libitm, probably needs pri
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Remove stray character at end of dg-do directive.
Tested x86_64-linux, committed to trunk.
commit 290f8727a83d8f94404fe254bc9334c870f23eca
Author: Jonathan Wakely
Date: Mon Dec 12 12:41:17 2016 +
R
On December 12, 2016 11:56:36 AM GMT+01:00, Marek Polacek
wrote:
>On Mon, Dec 12, 2016 at 11:10:31AM +0100, Tom de Vries wrote:
>> On 08/12/16 22:07, Marek Polacek wrote:
>> > This test ICEs since r240072 where Tom disallowed using va_list *
>as a first
>> > argument to va_arg. I think the probl
Hi Andre,
> the attached patch corrects reporting of "Sorry, unimplemented yet" for
> allocatable and pointer components in polymorphic objects (BT_CLASS) thus
> fixing two ICEs reported in the PR.
>
> The next chunk fixes an ICE when the declaration containing the token
> information is of type P
On Mon, Dec 12, 2016 at 01:09:16PM +0100, Marek Polacek wrote:
> Yeah, given
> expr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (expr)), expr);
> in build_va_arg it seems it'll always be a pointer, so the following is
Well, if you think it is guaranteed it always is a pointer, then you coul
On Mon, Dec 12, 2016 at 12:03:16PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 08, 2016 at 10:07:59PM +0100, Marek Polacek wrote:
> > 2016-12-08 Marek Polacek
> >
> > PR middle-end/78716
> > * gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
> > Case 1.
> >
> > * g+
Hi Iain,
On Sun, Dec 11, 2016 at 08:00:02PM +, Iain Sandoe wrote:
> r239866 removed most of the uses of LR in returns and sibcalls
>
> Darwin had an additional use of LR in the restore_world machinery. This
> patch removes it
> from the pattern in altivec.md and the relevant predicate.
>
From: Chen Gang
On Sat, Dec 10, 2016 at 03:38:10PM +, Bernd Edlinger wrote:
> On 12/10/16 12:23, cheng...@emindsoft.com.cn wrote:
> > From: Chen Gang
> >
> > When check bundle, gcc may still need modify the prev insn. Original
> > implementation will lose the prev insn.
> >
> > Also correct
Hi Mike,
On Fri, Dec 09, 2016 at 03:48:10PM -0500, Michael Meissner wrote:
> @@ -7528,6 +7528,49 @@ rs6000_split_vec_extract_var (rtx dest,
> + if (TARGET_P9_VECTOR
> + && (mode == V16QImode || mode == V8HImode || mode == V4SImode)
> + && INT_REGNO_P (dest_regno)
> + && AL
Hi all,
the attached patch corrects reporting of "Sorry, unimplemented yet" for
allocatable and pointer components in polymorphic objects (BT_CLASS) thus
fixing two ICEs reported in the PR.
The next chunk fixes an ICE when the declaration containing the token
information is of type POINTER or REF
1 - 100 of 121 matches
Mail list logo
