On Tue, Jun 28, 2016 at 5:50 PM, Yuri Rumyantsev wrote:
> Hi All!
>
> Here is the second part of patch to improve loop invariant code motion
> for loop marked with pragma omp simd.
>
> Bootstrapping and regression testing did not show any new failures.
> Is it OK for trunk?
Ok.
Thanks,
Richard.
I plan to commit this patch as obvious and simple.
Regression tested on x86-64. I will provide two test cases from the PR
Regards,
Jerry
2016-06-28 Jerry DeLisle
PR fortran/71686
* scanner.c (gfc_next_char_literal): Only decrement nextc if it
is not NULL.
diff --g
Hi,
As Uros pointed out, there are a number of existing tests for __float128 in
gcc.dg and gcc.dg/torture. This patch enables an appropriate subset of those
tests for 64-bit PowerPC, BE and LE. A few of the tests aren't appropriate
for our architecture, as Joseph stated. Still, this gives us so
The attached patch removes some unnecessary calls to pa_output_arg_descriptor.
It just returns on TARGET_64BIT.
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2016-06-28 John David Anglin
* config/pa/pa.md (call_symref_64bi
On Tue, 28 Jun 2016, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs because C_TYPE_INCOMPLETE_VARS is cleared even
> on the main type, while it should be cleared only on the variant types.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk/6.2?
O
As we discussed in the patch review, there were some issues with using %Y for
the ISA 3.0 instructions LXSD and STXSD.
I have rewritten the patch so that we have a new memory constraint (%wY) that
explicitly targets those instructions. I went back to the mov{DF,DD} patterns
and changed their use
Hi,
Currently GCC generates a store followed by a load for __builtin_signbit for
both IBM long double and IEEE-128 floating point. This patch, originating with
Michael Meissner, adds logic to instead use direct move instructions. The
original patch also added direct-move support for single- and
> "Matthew" == Matthew Fortune writes:
Matthew> I'm not sure this will matter if the only arch is x86 as
Matthew> ffi_arg will be 32-bit anyway there.
Aha, right. Thanks for looking.
Matthew> There would need to be a
Matthew> 64bit arch using the raw api. I don't really understand what
Mat
Hi Bill,
On Tue, Jun 28, 2016 at 02:28:37PM -0500, Bill Schmidt wrote:
> On POWER7 and earlier hardware, -mvsx is not on by default, causing the new
> tests for __float128 builtins to fail. This patch makes the dependency on VSX
> hardware explicit in the tests.
>
> Tested on powerpc64-unknown-l
Hi
Following below discussion here is a patch to make sure we
correctly deal with insertion of instances stored into the vector itself.
When we don't need reallocation I have implemented the libc++ trick
to avoid an intermediate copy. I did my best to detect when a value_type
instanc
Hi,
On POWER7 and earlier hardware, -mvsx is not on by default, causing the new
tests for __float128 builtins to fail. This patch makes the dependency on VSX
hardware explicit in the tests.
Tested on powerpc64-unknown-linux-gnu on POWER7. Ok for trunk, and for later
backport to 6.2?
Thanks,
Bi
On Tue, Jun 28, 2016 at 01:06:46PM -0600, Kelvin Nilsen wrote:
> This patch improves upon a recently committed patch to change the
> DejaGnu conditionals that control when the tests run. The patch
> corrects failures that occur on aix platforms.
>
> This patch has bootstrapped on and regression t
This patch improves upon a recently committed patch to change the
DejaGnu conditionals that control when the tests run. The patch
corrects failures that occur on aix platforms.
This patch has bootstrapped on and regression tested on powerpc64le-
unknown-linux-gnu with no regressions. Is this ok
Hi!
The following testcase ICEs because C_TYPE_INCOMPLETE_VARS is cleared even
on the main type, while it should be cleared only on the variant types.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/6.2?
2016-06-28 Jakub Jelinek
PR c/71685
*
On 06/20/16 04:55:16, H.J. Lu wrote:
> TImode register referenced in debug insn can be converted to V1TImode
> by scalar to vector optimization. We need to convert a debug insn if
> it has a variable in a TImode register.
Hello,
We have a situation on a few of the UPC tests, where they ICE on
th
On Tue, Jun 28, 2016 at 12:49:12PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 28, 2016 at 01:27:45PM -0400, Michael Meissner wrote:
>
>
>
> Thanks for the explanation.
>
> > I think the thing to do is create yet another memory constraint, that is
> > just
> > an offsetable address, with th
Committed.
2016-06-27 14:41 GMT+03:00 Pitchumani Sivanupandi
:
> Ping!
>
>
> On Wednesday 22 June 2016 12:05 PM, Pitchumani Sivanupandi wrote:
>>
>> On Tuesday 21 June 2016 09:39 PM, Georg-Johann Lay wrote:
>>>
>>> Pitchumani Sivanupandi schrieb:
Attached patches add documentation for -m
On Tue, Jun 28, 2016 at 01:27:45PM -0400, Michael Meissner wrote:
Thanks for the explanation.
> I think the thing to do is create yet another memory constraint, that is just
> an offsetable address, with the bottom 2 bits 0, and no PRE_MODIFY, etc.
That sounds best yes. The current patch seem
On Mon, Jun 27, 2016 at 09:37:16PM -0500, Segher Boessenkool wrote:
> On Mon, Jun 27, 2016 at 08:08:20PM -0400, Michael Meissner wrote:
> > This patch fixes PR 71667 that I discovered when trying to build the Spec
> > 2006
> > xalancbmk benchmark for the Power9. The Altivec indexed memory load/st
On 21/06/16 17:52, Martin Sebor wrote:
> On 06/21/2016 10:00 AM, Jakub Jelinek wrote:
>> On Tue, Jun 21, 2016 at 09:57:59AM -0600, Jeff Law wrote:
Would a new attribute to annotate async-signal safe functions
help? I envision that the attribute on a function definition
would turn of
This patch removes the build dependencies on linux headers, by
defining a few definitions that we need from those headers.
libgcc/ChangeLog:
2016-06-28 Walter Lee
* config/tilepro/atomic.h: Do not include arch/spr_def.h and
asm/unistd.h.
(SPR_CMPEXCH_VALUE): Define for tilegx.
On 06/28/2016 08:40 AM, Aldy Hernandez wrote:
Hi.
In addressing the issues that were brought up I ran into bounded allocas
that are bounded by an unknown size. Should we warn on these?:
if (n < SOME_GLOBAL)
alloca(n)
In my WIP I am warning with:
x.c:6:5: warning: alloca
On 6/27/16 8:30 PM, Peter Bergner wrote:
On 6/27/16 3:21 PM, Segher Boessenkool wrote:
On Sat, Jun 25, 2016 at 07:14:01PM -0500, Peter Bergner wrote:
Okay for trunk, okay for 6 later. One comment:
+ if (VECTOR_MODE_P (mode)
+ && !mode_supports_vsx_dform_quad (mode))
+return false;
On 03/06/16 09:30, Kyrill Tkachov wrote:
> Hi all,
>
> The test gcc.target/arm/builtin-bswap16-1.c refuses to compile when
> testing a toolchain configured with
> --with-mode=thumb --with-float=hard and an architecture that supports
> Thumb2.
> This is because the test explicitly sets the -march o
c++/71675 - __atomic_compare_exchange_n returns wrong type for
typed enum
__atomic_compare_exchange_n is documented to return bool but when
its operands are of one of the character types or derived from
it (such as a class enum in C++) it converts the bool result to
that type. The attached patch
Hi All!
Here is the second part of patch to improve loop invariant code motion
for loop marked with pragma omp simd.
Bootstrapping and regression testing did not show any new failures.
Is it OK for trunk?
ChangeLog:
2016-06-28 Yuri Rumyantsev
PR tree-optimization/70729
* tree-ssa-loop-im.c (
Tom Tromey writes:
> > "Matthew" == Matthew Fortune writes:
> Matthew> I've identified a latent bug in the java interpreter that affects
> MIPS
> Matthew> n32 and n64 ABIs both little and big endian and, I presume, any
> 64-bit
> Matthew> big endian target with int as 32-bit.
> [...]
>
> M
On Tue, Jun 28, 2016 at 4:19 PM, Jakub Jelinek wrote:
> On Tue, Jun 28, 2016 at 12:26:55PM +0200, Jakub Jelinek wrote:
>> On Tue, Jun 28, 2016 at 12:09:51PM +0200, Uros Bizjak wrote:
>> > > So, this patch instead changes ix86_expand_vector_move, so that
>> > > for SUBREGs it forces the SUBREG_REG
On Tue, Jun 28, 2016 at 12:26 PM, Jakub Jelinek wrote:
> On Tue, Jun 28, 2016 at 12:09:51PM +0200, Uros Bizjak wrote:
>> > So, this patch instead changes ix86_expand_vector_move, so that
>> > for SUBREGs it forces the SUBREG_REG into memory (or register if
>> > that fails, though I don't have a te
On 2016.06.28 at 14:40 +0100, Jonathan Wakely wrote:
> On 27/06/16 22:45 +0200, François Dumont wrote:
> >Trivial attached patch applied to fix this regression. I am surprised that
> >gcc had not detected it.
>
> Yes, we should report a front-end bug for this if there isn't one
> already.
FYI I'v
Hi.
In addressing the issues that were brought up I ran into bounded allocas
that are bounded by an unknown size. Should we warn on these?:
if (n < SOME_GLOBAL)
alloca(n)
In my WIP I am warning with:
x.c:6:5: warning: alloca bound is unknown [-Walloca]
Though
On 28/06/16 11:01, Jiong Wang wrote:
On 28/06/16 10:51, Jiong Wang wrote:
On 27/06/16 17:26, Dominik Vogt wrote:
On Thu, Jun 09, 2016 at 09:52:39AM -0600, Jeff Law wrote:
On 06/08/2016 10:47 AM, Jiong Wang wrote:
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751
Hi!
This is just first small step towards this PR.
It brings the ADDR_EXPR of DECL_P bases roughly on the same level as
SSA_NAMEs pointers - so get_stridx_plus_constant works for them, and
more importantly, before this patch there was a very severe bug in
addr_stridxptr (missing list = list->next;
On Tue, Jun 28, 2016 at 12:26:55PM +0200, Jakub Jelinek wrote:
> On Tue, Jun 28, 2016 at 12:09:51PM +0200, Uros Bizjak wrote:
> > > So, this patch instead changes ix86_expand_vector_move, so that
> > > for SUBREGs it forces the SUBREG_REG into memory (or register if
> > > that fails, though I don't
On 28 Jun 15:24, Ilya Enkovich wrote:
> On 16 Jun 10:54, Jeff Law wrote:
> >
> > I don't see anything particularly worrisome here either -- I have a slight
> > concern about correctness issues with only masking loads/stores and
> > reductions. But I will defer to your judgment on whether or not t
Ping.
Thanks,
Kyrill
On 10/06/16 10:28, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00249.html
Thanks,
Kyrill
On 03/06/16 09:30, Kyrill Tkachov wrote:
Hi all,
The test gcc.target/arm/builtin-bswap16-1.c refuses to compile when testing a
toolchain configured wi
On 23 Jun 12:54, Ilya Enkovich wrote:
>
> Here is an updated version with less typos and more comments.
>
> Thanks,
> Ilya
> --
Here is an updated version with trapping statements check added
to vect_analyze_stmt.
Thanks,
Ilya
--
gcc/
2016-06-28 Ilya Enkovich
* tree-vect-loop.c: In
On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek wrote:
> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
>> gimple_predicate
>> rhs_predicate_for (tree lhs)
>> {
>> - if (is_gimple_reg (lhs))
>> + if (will_be_gimple_reg (lhs))
>> return is_gimple_reg_rhs_or_call;
>>else
On Tue, Jun 28, 2016 at 3:38 PM, Martin Liška wrote:
> Hello.
>
> Following patch marks -fstack-protect as Optimization flag.
> That let a user to mark a function with #pragma GCC optimize
> ("-fno-stack-protector")
> to disable the optimization for a function.
>
> Patch survives regression tests
On Tue, Jun 28, 2016 at 1:26 PM, Ilya Enkovich wrote:
> Hi,
>
> Currently we use operands swap when compare masks using LT and LE codes.
> Operands swap misses swap for their definition types and this patch
> fixes it. Testing is in progress. OK for trunk if pass?
Ok.
Thanks,
Richard.
> Thank
Hi!
I've merged trunk into gomp-4_5-branch, the following change was all that
was needed to make it build.
2016-06-28 Jakub Jelinek
* openmp.c (match_acc): Change mask type from uint64_t to
const omp_mask.
--- gcc/fortran/openmp.c.jj 2016-06-28 14:51:11.0 +0200
++
On 27/06/16 22:45 +0200, François Dumont wrote:
Trivial attached patch applied to fix this regression. I am surprised
that gcc had not detected it.
Yes, we should report a front-end bug for this if there isn't one
already.
2016-06-27 François Dumont
PR libstdc++/71640
* include/bits
Hello.
Following patch marks -fstack-protect as Optimization flag.
That let a user to mark a function with #pragma GCC optimize
("-fno-stack-protector")
to disable the optimization for a function.
Patch survives regression tests and bootstraps on x86_64-linux-gnu.
Ready to install?
Thanks,
Mart
On Thu, Jun 23, 2016 at 6:34 PM, Wilco Dijkstra wrote:
> This patch fixes a bug in the bswap pass. In big-endian BIT_FIELD_REF uses
> big-endian bit numbering so we need to adjust the bit position.
> The existing version could potentially generate incorrect code however GCC
> doesn't
> emit a BI
On 16 Jun 10:54, Jeff Law wrote:
> On 05/19/2016 01:44 PM, Ilya Enkovich wrote:
> >Hi,
> >
> >This patch introduces support for loop epilogue combining. This includes
> >support in cost estimation and all required changes required to mask
> >vectorized loop.
> >
> >Thanks,
> >Ilya
> >--
> >gcc/
>
On Tue, Jun 28, 2016 at 02:19:13PM +0200, Thomas Schwinge wrote:
> This also makes it obvious that stuff like:
>
> void foo()
> {
> if (0)
> #pragma omp cancellation FOO
> ;
> }
>
> ... currently produces "wrong" ;-) diagnostics:
>
> ../omp.c: In function 'foo':
On Tue, Jun 28, 2016 at 02:13:24PM +0200, Thomas Schwinge wrote:
> Looking at how OpenMP declare simd is handled in the C++ front end, I ran
> into it being parsed for PRAGMA_OMP_DECLARE_REDUCTION, which got me
> confused. OK to commit the following to un-confuse this, in that
> PRAGMA_OACC_* and
Hi!
On Tue, 28 Jun 2016 14:13:24 +0200, I wrote:
> PRAGMA_OACC_* and PRAGMA_OMP_* don't describe what *eventually* is to be
> parsed [...], but instead they describe what *so far* has been parsed.
> --- gcc/c/c-parser.c
> +++ gcc/c/c-parser.c
> @@ -10186,7 +10186,7 @@ c_parser_pragma (c_parser *p
Hi!
Looking at how OpenMP declare simd is handled in the C++ front end, I ran
into it being parsed for PRAGMA_OMP_DECLARE_REDUCTION, which got me
confused. OK to commit the following to un-confuse this, in that
PRAGMA_OACC_* and PRAGMA_OMP_* don't describe what *eventually* is to be
parsed (which
I am reviving this patch from 2013 which properly handles
DECL_BIT_FIELD_REPRESENTATIVE appearing as FIELD_DECL operand in
a COMPONENT_REF (as I am currently reviving a patch to lower
bitfield accesses now that BIT_INSERT_EXPR is on trunk).
Bootstrapped and tested on x86_64-unknown-linux-gnu, app
Hi,
Currently we use operands swap when compare masks using LT and LE codes.
Operands swap misses swap for their definition types and this patch
fixes it. Testing is in progress. OK for trunk if pass?
Thanks,
Ilya
--
gcc/
2016-06-28 Ilya Enkovich
* tree-vect-stmts.c (vectorizable_c
On Tue, Jun 28, 2016 at 12:09:51PM +0200, Uros Bizjak wrote:
> > So, this patch instead changes ix86_expand_vector_move, so that
> > for SUBREGs it forces the SUBREG_REG into memory (or register if
> > that fails, though I don't have a testcase for when that would happen),
> > and just re-creates a
On Tue, Jun 28, 2016 at 11:27 AM, Jakub Jelinek wrote:
> On Tue, Jun 28, 2016 at 09:15:13AM +0200, Richard Biener wrote:
>> I wonder why we can rely on the MODE_FLOAT case not seeing
>> (subreg:DF (reg:V2DF ) 0) but have to handle
>> (subreg:V1DF (reg:DF ...) 0) in the MODE_VECTOR case.
>
> Seems
On 28/06/16 10:51, Jiong Wang wrote:
On 27/06/16 17:26, Dominik Vogt wrote:
On Thu, Jun 09, 2016 at 09:52:39AM -0600, Jeff Law wrote:
On 06/08/2016 10:47 AM, Jiong Wang wrote:
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751,
here is the patch.
This commit has i
On 27/06/16 17:26, Dominik Vogt wrote:
On Thu, Jun 09, 2016 at 09:52:39AM -0600, Jeff Law wrote:
On 06/08/2016 10:47 AM, Jiong Wang wrote:
As discussed on the PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70751,
here is the patch.
This commit has introduced an ICE with s390x, march=z13.
On Tue, Jun 28, 2016 at 09:15:13AM +0200, Richard Biener wrote:
> I wonder why we can rely on the MODE_FLOAT case not seeing
> (subreg:DF (reg:V2DF ) 0) but have to handle
> (subreg:V1DF (reg:DF ...) 0) in the MODE_VECTOR case.
Seems all of force_const_mem is just unprepared to handle SUBREGs
of C
ping https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01703.html
Thanks,
Prathamesh
On 23 June 2016 at 22:51, Prathamesh Kulkarni
wrote:
> On 17 June 2016 at 19:52, Prathamesh Kulkarni
> wrote:
>> On 14 June 2016 at 18:31, Prathamesh Kulkarni
>> wrote:
>>> On 13 June 2016 at 16:13, Jan Hubicka w
On 28/06/16 02:03, Jim Wilson wrote:
On Mon, Jun 13, 2016 at 3:01 AM, Kyrill Tkachov
wrote:
Hi Jim,
On 10/06/16 23:48, Jim Wilson wrote:
This adds a tuning structure for qdf24xx. This was tested with an
aarch64-linux bootstrap and a make check, with no regressions. I also
tested it with an
On Fri, 24 Jun 2016, Jakub Jelinek wrote:
> On Thu, Jun 23, 2016 at 05:23:21PM +0200, Jakub Jelinek wrote:
> > Thinking about this again, there could be another option - keep
> > __atomic_compare_exchange_N in the IL, but under certain conditions (similar
> > to what the patch uses in fold_builtin
On Thu, 23 Jun 2016, Jakub Jelinek wrote:
> Hi!
>
> This PR is about 2 issues with the *atomic_compare_exchange* APIs, which
> didn't exist with __sync_*_compare_and_swap:
> 1) the APIs make the expected argument addressable, although it is very
>common it is an automatic variable that is add
> "Matthew" == Matthew Fortune writes:
Matthew> I've identified a latent bug in the java interpreter that affects MIPS
Matthew> n32 and n64 ABIs both little and big endian and, I presume, any 64-bit
Matthew> big endian target with int as 32-bit.
[...]
Matthew> libjava/
Matthew> * interpret-ru
On Thu, 16 Jun 2016, Kyrill Tkachov wrote:
>
> On 15/06/16 22:53, Marc Glisse wrote:
> > On Wed, 15 Jun 2016, Kyrill Tkachov wrote:
> >
> > > This is a respin of
> > > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00952.html following
> > > feedback.
> > > I've changed the code to cast the opera
On Mon, 27 Jun 2016, Jakub Jelinek wrote:
> Hi!
>
> This patch is an attempt to fix ICE on the following testcase.
> In output_constant_pool_2 we assume that for vector modes, force_const_mem
> must be a CONST_VECTOR, but for the weirdo vector modes with single element
> it could very well be jus
On Mon, 27 Jun 2016, Jakub Jelinek wrote:
> Hi!
>
> On targets which don't support sub-word operations trying OPTAB_DIRECT
> AND on e.g. QImode or HImode leads to NULL being returned, so we ICE on
> builtin-arith-overflow-p-19.c e.g. on arm, aarch64 or sparc*.
>
> Fixed thusly, bootstrapped/regt
On Mon, Jun 27, 2016 at 04:22:01PM -0700, Cesar Philippidis wrote:
> + while (ret == MATCH_YES)
> {
> - if (cp->gang_static)
> - return MATCH_ERROR;
> + if (gfc_match (" static :") == MATCH_YES)
> + {
> + if (cp->gang_static)
> + return M
65 matches
Mail list logo
