Description:
* This patch provides changes in libffi for providing the Go closure on AIX.
Tests:
* AIX: Build of GCC 8 trunk: SUCCESS
- build made by means of gmake.
ChangeLog:
* src/powerpc/aix.S (ffi_call_AIX): Add debugging pseudo-op and labels
for EH.
(ffi_call_go_AIX): Ne
Status
==
The 5.5 branch is now frozen for the final GCC 5.5 release, the release
candidate has been announced. All changes to the branch require RM
approval.
Quality Data
Priority # Change from last report
--- ---
P1
On 09/27/2017 03:46 PM, Thomas Schwinge wrote:
Hi!
On Mon, 25 Sep 2017 16:57:52 +0200, Tom de Vries wrote:
currently for a GOACC_REDUCTION internal fn call we print:
...
sum_5 = GOACC_REDUCTION (SETUP, _3, 0, 0, 67, 0);
...
This patch adds a comment for some arguments explaining the meani
Hi Richard,
> The following patch adjust GRAPHITE testing to check that existing
> code generation issues occur and makes code generation ICE with
> -fchecking --param graphite-allow-codegen-errors=0. The param
> is really a testsuite artifact so we can have testcases with
> issues where we have
Hi!
LOG_LINKS normally are just within a basic block and various parts of
the combiner assume that this_basic_block is the basic block where all the
i[3210] insns are residing. Except when we turn a conditional trap into
an unconditional one, we split the block during try_combine and then we can
Hi!
The qsort cmp transitivity checks may fail with the sort_by_operand_rank
comparator, because if one of the operands has stmt_to_insert and the
other doesn't (but likely also if one SSA_NAME is (D) and the other is not),
we fallthrough into SSA_NAME_VERSION comparison, but if both aren't (D) an
On Tue, 3 Oct 2017, Jakub Jelinek wrote:
> The qsort cmp transitivity checks may fail with the sort_by_operand_rank
> comparator, because if one of the operands has stmt_to_insert and the
> other doesn't (but likely also if one SSA_NAME is (D) and the other is not),
> we fallthrough into SSA_NAME_V
On October 3, 2017 11:48:35 AM GMT+02:00, Rainer Orth
wrote:
>Hi Richard,
>
>> The following patch adjust GRAPHITE testing to check that existing
>> code generation issues occur and makes code generation ICE with
>> -fchecking --param graphite-allow-codegen-errors=0. The param
>> is really a tes
On October 3, 2017 12:00:21 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>The qsort cmp transitivity checks may fail with the
>sort_by_operand_rank
>comparator, because if one of the operands has stmt_to_insert and the
>other doesn't (but likely also if one SSA_NAME is (D) and the other is
>not),
>w
Hi Richard,
> What ISL Versions are affected?
it's 0.18.
>>Besides, there's
>>
>>+UNRESOLVED: gfortran.dg/graphite/pr42393-1.f90 -O
>>scan-tree-dump-times graphite "code generation error" 1
>>
>>for both 32 and 64-bit. The log indicates
>>
>>gfortran.dg/graphite/pr42393-1.f90 -O : dump
On Tue, Oct 03, 2017 at 01:24:32PM +0300, Alexander Monakov wrote:
> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
> > The qsort cmp transitivity checks may fail with the sort_by_operand_rank
> > comparator, because if one of the operands has stmt_to_insert and the
> > other doesn't (but likely also if
On October 3, 2017 1:55:35 PM GMT+02:00, Jakub Jelinek wrote:
>On Tue, Oct 03, 2017 at 01:24:32PM +0300, Alexander Monakov wrote:
>> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
>> > The qsort cmp transitivity checks may fail with the
>sort_by_operand_rank
>> > comparator, because if one of the operan
Hello world,
I noticed that EXEC_WAIT wasn't handled in the Fortran tree dump.
This patch does that. While preparing this, I also noticed that
the values for the END and EOR tags were interchanged and fixed
this as well.
Committed as obvious and simple.
Just a cleanup for the time when WAIT ac
On 02/10/17 07:43 +0200, François Dumont wrote:
On 28/09/2017 23:56, Jonathan Wakely wrote:
On 28/09/17 21:59 +0200, François Dumont wrote:
The current istreambuf_iterator implementation capture the current
streambuf state each time it is tested for eof or evaluated. This
is why I considered
Hi Steve,
>> >> In general one can argue about whether or not it's a good idea to use
>> >> non-std extensions. But I think gfortran should rather leave the
>> >> choice to its users, whether they want to use 'dirty and covenient'
>> >> code or have very strict checking. We have nice mechanisms fo
On 02/10/17 15:13 +0100, Jonathan Wakely wrote:
+#ifndef _GLIBCXX_CHARCONV
+#define _GLIBCXX_CHARCONV 1
+
+#pragma GCC system_header
+
+#if __cplusplus >= 201402L
+
+#include
+#include
+#include
+#include // for std::errc
I forgot to mention that I've made this header work for C++14 not jus
Ping
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg173877.html
> On Sep 19, 2017, at 2:22 PM, Qing Zhao wrote:
>
> Hi,
>
> This patch fixes the aarch64 bug 81422
> https://gcc.gnu.org/PR81422
>
> Before adding REG_EQUIV notes in the TLS symbol handling code,
> we should check wheth
r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling
behaviour on AArch64 as autopref scheduling no longer checks the base.
This patch fixes the bootstrap failure and cleans up autopref scheduling.
The code is greatly simplified. Sort accesses on the offset first, and
only
[non-c++ people on CC, there's a reason ...]
This patch adds a new warning, concerning unnecessary parentheses on a
declaration. For instance:
prettyprinter (pp);
That's a declaration of a pp variable of type prettyprinter -- not a
call of a prettyprinter function. The reason is that in C
On x86, micro architecture selection affects the use of "sub" vs "lea".
The stack-check-11 test was searching for "sub" instructions and of
course failed if the compiler was configured for one of the micro
architecture variants that prefers "lea".
Per HJ's recommendation in the BZ, we can avoid
On Tue, Oct 03, 2017 at 04:27:15PM +0200, Janus Weil wrote:
> >>
> >> ... with regards to the F08 standard, which forbids it, yes. I guess
> >> that is the nature of a "non-standard extension". It can still give a
> >> meaningful result, after the smaller kind is implicitly converted to
> >> the la
I committed the import of AIX Go support from libffi repository into
the GCC copy of libffi.
Thanks, David
This patch uses global rather than member operators for wide-int.h,
so that the first operand can be a non-wide-int type.
The patch also removes the and_not and or_not member functions.
It was already inconsistent to have member functions for these
two operations (one of which was never used) and
Hello world,
I have re-thought and simplified the patch for PR49232.
This now uses gfc_is_simply_contiguous, in the
non-strict version. I have also opted for an error
because, well, the use cases rejected by this are really
errors, and will very likely lead to wrong code in
user applications.
R
> Reading the patch I think that it gets conservativeness wrong -- shouldn't
> it be
>
> if (is_definitely_initialized)
>{
> SUBREG_PROMOTED_VAR_P (temp) = 1;
> SUBREG_PROMOTED_SET (temp, unsignedp);
>}
>
> ? Of course it's not easy to compute is_definitely_initialized
> co
On Mon, 2017-10-02 at 15:38 +0100, Szabolcs Nagy wrote:
>
> looks good to me, but i cannot approve.
>
> (this will make libatomic depend on ifuncs on aarch64*-linux-gnu.)
If you build GCC with default options, ifunc is enabled on aarch64 and
used by libatomic but if you configure with '--disable
One of the original requirements for getting wide-int.h accepted
was that it should work efficiently on trees. Through a process
that I no longer recall exactly, this ended up meaning that we can
use things like:
wi::add (t, 1)
to add 1 to an INTEGER_CST T in its native precision. However, w
Hi!
I have implemented a warning -Wcast-function-type that analyzes
type casts which change the function signatures.
I would consider function pointers with different result type
invalid, also if both function types have a non-null TYPE_ARG_TYPES
I would say this deserves a warning. As an except
2017-10-03 20:10 GMT+02:00 Steve Kargl :
>> > There is no mechanism available to warn the user of nonstandard code.
>>
>> Of course there is:
>>
>> $ gfortran -std=f2008 a.f90
>> a.f90:4:17:
>>
>> print *, iand(i,j)
>> 1
>> Error: GNU Extension: Different type kinds at (1)
>>
>
I think the change is good. But I don’t have the permission for approval…
Qing
> On Sep 25, 2017, at 12:36 PM, Steve Ellcey wrote:
>
> Ping.
>
> Steve Ellcey
> sell...@cavium.com
>
>
> On Fri, 2017-09-15 at 11:22 -0700, Steve Ellcey wrote:
>> PR 81356 points out that doing a __builtin_strcpy
Hi,
This follow-up patch implements the patterns mentioned in $subject.
Bootstrap+test in progress on x86_64-unknown-linux-gnu and aarch64-linux-gnu.
OK to commit if passes ?
Thanks,
Prathamesh
2017-10-03 Prathamesh Kulkarni
* match.pd ((X >> CST) == 0 -> X < (1 << CST)): New pattern.
On 10/02/2017 02:45 AM, Iain Buclaw wrote:
> Changes since previous are just merge latest 2.076 release.
>
> Uploaded patch to my ftp due to size limitations.
So if the code was assigned by Walter to the FSF back in 2011 (per your
message on Sep 11 and Walter's reply on Sep 11) then the copyright
Here is the patch to add the round to odd instructions using separate UNSPEC
names instead of putting the operation into the unspec.
I have done a bootstrap and check on a little endian power8 system and there
were no regressions. Can I check this into the trunk?
[gcc]
2017-10-03 Michael Meissn
On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:
> Hi,
> This follow-up patch implements the patterns mentioned in $subject.
> Bootstrap+test in progress on x86_64-unknown-linux-gnu and aarch64-linux-gnu.
> OK to commit if passes ?
>
> Thanks,
> Prathamesh
> 2017-10-03 Pratha
On Thu, 28 Sep 2017 13:38:06 +0100
Jonathan Wakely wrote:
> On 28/09/17 15:06 +0300, Petr Ovtchenkov wrote:
> >On Thu, 28 Sep 2017 11:34:25 +0100
> >Jonathan Wakely wrote:
> >
> >> On 23/09/17 09:54 +0300, Petr Ovtchenkov wrote:
> >> >istreambuf_iterator should not forget about attached
> >> >st
On Tue, 3 Oct 2017, Jakub Jelinek wrote:
On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:
Hi,
This follow-up patch implements the patterns mentioned in $subject.
Bootstrap+test in progress on x86_64-unknown-linux-gnu and aarch64-linux-gnu.
OK to commit if passes ?
Thanks,
P
On 10/03/2017 03:00 PM, Marc Glisse wrote:
> On Tue, 3 Oct 2017, Jakub Jelinek wrote:
>
>> On Tue, Oct 03, 2017 at 12:54:39PM -0700, Prathamesh Kulkarni wrote:
>>> Hi,
>>> This follow-up patch implements the patterns mentioned in $subject.
>>> Bootstrap+test in progress on x86_64-unknown-linux-gnu
On Tue, 3 Oct 2017, Bernd Edlinger wrote:
> invalid, also if both function types have a non-null TYPE_ARG_TYPES
> I would say this deserves a warning. As an exception I have
I'm not convinced by the TYPE_ARG_TYPES check, at least for C.
In C, unprototyped function types are not compatible with
On Tue, 3 Oct 2017, Jeff Law wrote:
> /* Copyright (c) 2010-2014 by Digital Mars
> * All Rights Reserved, written by Walter Bright
> * http://www.digitalmars.com
> * Distributed under the Boost Software License, Version 1.0.
> * (See accompanying file LICENSE or copy at
> http://www.boost.org/
On Aug 17 2017, Martin Sebor wrote:
> * g++.dg/ext/attr-ifunc-1.C: Adjust.
> * g++.dg/ext/attr-ifunc-2.C: Same.
> * g++.dg/ext/attr-ifunc-3.C: Same.
> * g++.dg/ext/attr-ifunc-4.C: Same.
All the tests are now crashing on powerpc. Klass::resolver doesn't look
like a valid
I'm no longer at Linaro, so I checked in a patch to update my entry on
the steering committee list page. This patch was verified as XHTML 1.0
Transitional.
Jim
Index: steering.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,
On Tue, Oct 03, 2017 at 04:15:23PM -0400, Michael Meissner wrote:
> Here is the patch to add the round to odd instructions using separate UNSPEC
> names instead of putting the operation into the unspec.
>
> I have done a bootstrap and check on a little endian power8 system and there
> were no regr
On Sun, 1 Oct 2017, Rasmus Villemoes wrote:
> 2017-10-01 Rasmus Villemoes
>
> PR preprocessor/64965
> * gcc.c-torture/compile/pr64965.c: New test.
>
> If the current filename contains a newline character, __FILE__ would
> expand to a string literal containing an actual embedde
On Mon, 2 Oct 2017, David Malcolm wrote:
> gcc/c/ChangeLog:
> * c-decl.c (push_parm_decl): Store c_parm's location into the
> PARAM_DECL.
> (build_c_parm): Add "loc" param and store it within the c_parm.
> * c-parser.c (struct c_parser): Add "last_token_location" field.
>
On 10/03/2017 03:41 PM, Andreas Schwab wrote:
On Aug 17 2017, Martin Sebor wrote:
* g++.dg/ext/attr-ifunc-1.C: Adjust.
* g++.dg/ext/attr-ifunc-2.C: Same.
* g++.dg/ext/attr-ifunc-3.C: Same.
* g++.dg/ext/attr-ifunc-4.C: Same.
All the tests are now crashing on po
From: Vladimir Mezentsev
Tested on aarch64-linux-gnu.
No regression.
No bootstrap failure.
gcc/ChangeLog:
2017-09-26 Vladimir Mezentsev
* gcc/config/aarch64/aarch64.c: restore fix in aarch64_use_blocks_for_constant_p
---
gcc/config/aarch64/aarch64.c | 8 +++-
1 file changed, 3 insertion
On 04.10.2017 00:41, Joseph Myers wrote:
> On Sun, 1 Oct 2017, Rasmus Villemoes wrote:
>
>> 2017-10-01 Rasmus Villemoes
>>
>> PR preprocessor/64965
>> * gcc.c-torture/compile/pr64965.c: New test.
>>
>> If the current filename contains a newline character, __FILE__ would
>> expan
istreambuf_iterator should not forget about attached
streambuf when it reach EOF.
Checks in debug mode has no infuence more on character
extraction in istreambuf_iterator increment operators.
In this aspect behaviour in debug and non-debug mode
is similar now.
Test for detached srteambuf in istre
On Tue, Oct 03, 2017 at 09:38:51PM +0200, Janus Weil wrote:
> 2017-10-03 20:10 GMT+02:00 Steve Kargl :
> >> > There is no mechanism available to warn the user of nonstandard code.
> >>
> >> Of course there is:
> >>
> >> $ gfortran -std=f2008 a.f90
> >> a.f90:4:17:
> >>
> >> print *, iand(i,j)
>
49 matches
Mail list logo
