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
Hi Andre,
On 9 December 2016 at 17:16, Andre Vieira (lists)
wrote:
> On 09/12/16 16:02, Ramana Radhakrishnan wrote:
>> On Fri, Dec 9, 2016 at 3:58 PM, Bernd Schmidt wrote:
>>> On 12/09/2016 04:34 PM, Andre Vieira (lists) wrote:
>>>
Regardless, the other testcases I add in this patch show a
aarch64 (Enable descriptors for nested functions in Ada):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01253.html
arm (Enable descriptors for nested functions in Ada):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01254.html
rs6000 (Fix reload failures in 64-bit mode):
https://gcc.gnu.org/
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][PATCHv3] Improve fpclassify w.r.t IEEE like numbers
i
In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.
This is an ABI change, as procedures with character arguments take
hidden arguments with the character length.
I also changed the _size member in vtables from int to size_t
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 problem is in the ADDR_EXPR check in
gimplify_va_arg_expr. It's meant to handle Case 1, but the valist doesn't
always have to be ADDR_EXPR. E.g.
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? And do
we have real-life examples of character strings
Hi FX,
there is already an ABI change. DTIO needed it.
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
times.
- A
Hi all,
I perceive that the git-mirror is lacking the commits of the last two days.
What did I miss? I have searched the gcc.gnu.org site already, but did not find
any reports.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
On Mon, Dec 12, 2016 at 11:32:06AM +0100, Andre Vehreschild wrote:
> Hi all,
>
> I perceive that the git-mirror is lacking the commits of the last two days.
> What did I miss? I have searched the gcc.gnu.org site already, but did not
> find
> any reports.
https://gcc.gnu.org/ml/gcc/2016-12/msg00
Same as for PR77933, I'm trying to get this in for the next GCC 6 release.
I've successfully done a Thumb-1 bootstrap of the backport and testsuite shows
no regression when run with an arm-none-eabi GCC cross-compiler targeting ARM
Cortex-M0.
Is this ok for gcc-6-branch?
Best regards,
Thoma
On 12/12/16 10:44, Thomas Preudhomme wrote:
Same as for PR77933, I'm trying to get this in for the next GCC 6 release.
I've successfully done a Thumb-1 bootstrap of the backport and testsuite shows
no regression when run with an arm-none-eabi GCC cross-compiler targeting ARM
Cortex-M0.
Is th
Hi Naveen,
On 12/12/16 03:16, Hurugalawadi, Naveen wrote:
Hi,
Please find attached the patch that implements the support for popcount
patterns in AArch64.
The implementation improves OVS-DPDK on ThunderX by 3%. It would have a
similar effect on other AArch64 targets.
Please review the patch a
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 problem is in the ADDR_EXPR check in
> > gimplify_va_arg_expr. It's meant to
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++.dg/other/vararg-5.C: New.
>
> diff --git gcc/gimplify.c gcc/gimplify
> Ok. I'm sending a patch that put gcc_unreachable to places where either size
> or (and) offset is a non-constant. This survives regression tests
> (including ada) on x86_64-linux-gnu. Apart from that normal bootstrap +
> regression tests works fine on ppc64le-redhat-linux.
I didn't manage to bre
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/extend.texi (Floating Types): Document a
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 after "TS", and it's -3:2015 no
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 primarily a bu
Hi Andrew,
These should be fixed now.
Thanks,
Tamar
From: Andrew Pinski
Sent: Wednesday, December 7, 2016 4:33:51 AM
To: Christophe Lyon
Cc: Tamar Christina; Kyrill Tkachov; James Greenhalgh; GCC Patches;
christophe.l...@st.com; Marcus Shawcroft; Richar
https://gcc.gnu.org/r243545
Applied this obvious tweak to trunk.
Johann
libgcc/
* config/avr/lib1funcs.S (__ashldi3): Use __tmp_reg__ to restore
R16 instead of push + pop.
(__ashrdi3, __lshrdi3): Same. And use __zero_reg__ for signs.
Index: config/avr/lib1funcs.S
=
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
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 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
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+
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
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 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
* 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
> 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
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
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 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
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 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
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 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
> > 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
>
> 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
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
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
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
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
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 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
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 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
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 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_
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
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 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,
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 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
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 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
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 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 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 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 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 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 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 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 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
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
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
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
>
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.
>
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
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
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
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
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,
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,
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 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
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
> 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
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
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
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
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
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
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_
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 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
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
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 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
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
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 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
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
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
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
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/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
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
1 - 100 of 121 matches
Mail list logo
