Hello!
We have to check natural alignment of the operand in
misaligned_operand predicate. This predicate is used to check SSE
memory operands for alignment, when movaps instead of movups can be
used. This change makes predicate independent of BIGGEST_ALIGNMENT
setting.
2015-11-13 Uros Bizjak
Probably coming too late, sorry.
On Thu, Nov 12, 2015 at 09:08:36PM -0500, David Malcolm wrote:
> index 4335a87..eb4e1fc 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -47,6 +47,7 @@ along with GCC; see the file COPYING3. If not see
> #include "c-family/c-ubsan.h"
> #include "cil
On 11/10/2015 09:30 PM, Andris Pavenis wrote:
On 11/10/2015 11:20 PM, Jeff Law wrote:
On 11/10/2015 11:16 AM, Andris Pavenis wrote:
One may need to execute extra steps after linking program. This is
required
for example for DJGPP to run stubify.exe on file generated by linker.
The only way how
On 11/10/2015 11:16 AM, Andris Pavenis wrote:
One may need to execute extra steps after linking program. This is required
for example for DJGPP to run stubify.exe on file generated by linker.
The only way how to achieve was to use LINK_COMMAND_SPEC. It would be
much easier
and less error prone t
On 11/11/2015 11:10 AM, Alexandre Oliva wrote:
On Nov 10, 2015, Jeff Law wrote:
* function.c (assign_parm_setup_block): Right-shift
upward-padded big-endian args when bypassing the stack slot.
Don't you need to check the value of BLOCK_REG_PADDING at runtime?
The padding is essentially allowe
On Fri, Nov 13, 2015 at 2:13 PM, Jeff Law wrote:
> On 10/07/2015 10:32 PM, Ajit Kumar Agarwal wrote:
>
>>
>> 0001-RFC-Patch-Optimized-changes-in-the-register-used-ins.patch
>>
>>
>> From f164fd80953f3cffd96a492c8424c83290cd43cc Mon Sep 17 00:00:00 2001
>> From: Ajit Kumar Agarwal
>> Date: Wed, 7
On 10/07/2015 10:32 PM, Ajit Kumar Agarwal wrote:
0001-RFC-Patch-Optimized-changes-in-the-register-used-ins.patch
From f164fd80953f3cffd96a492c8424c83290cd43cc Mon Sep 17 00:00:00 2001
From: Ajit Kumar Agarwal
Date: Wed, 7 Oct 2015 20:50:40 +0200
Subject: [PATCH] [RFC, Patch]: Optimized chan
On Sun, 2015-11-01 at 23:44 -0700, Jeff Law wrote:
> On 10/30/2015 06:47 AM, David Malcolm wrote:
>
> > The typename suggestion seems to be at least somewhat controversial,
> > whereas (I hope) the misspelled field names suggestion is more
> > acceptable.
> >
> > Hence I'm focusing on the field na
The attached patch adds a pattern for CC to register move.
[gcc]
2015-11-11 James Bowman
* config/ft32/ft32.md: New pattern *sne
Index: gcc/config/ft32/ft32.md
===
--- gcc/config/ft32/ft32.md (revision 230144)
+++ gc
I've committed the attached patch as obvious after
testing on x86_64-*-freebsd.
The short story is that gfortran tracks the number
of ENTRY symbols with a reference count. If an
ENTRY was included in a routine within a MODULE the
reference count was not properly increment. This
patch now does th
Hi,
As a result of an unused variable from my patch
of today, it broke bootstrap. Dominique kindly
pointed this out. Thank you.
Committed to trunk as obvious.
Jim
Index: gcc/cp/ChangeLog
===
--- gcc/cp/ChangeLog (revision 230275)
On 12.11.15 14:39, Jonathan Wakely wrote:
On 12/11/15 11:40 +, Jonathan Wakely wrote:
On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jennifer Yao
wrote:
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
pre
On 11/12/2015 08:30 AM, Ilya Enkovich wrote:
Hi,
This patch adds description for several standard pattern names. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-11-12 Ilya Enkovich
* doc/md.texi (vec_cmp@var{m}@var{n}): New item.
(vec_cmpu@var{m}@var{n}): New item.
(vcond@
On 11/12/2015 08:48 AM, Ilya Enkovich wrote:
Hi,
We may get ICE in vectorizer in case stored value get vectype not compatible
with a storage. This may happen for bool values. This patch fixes ICE.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
201
All,
with the work from Jennifer Yao and John Marino we can now update the
locale support on FreeBSD to the level of DragonFly.
Results of this work can be found on the results list.
Here my small addendum to make it work on FreeBSD.
Is this ok for trunk? (Given that the work from Jennifer a
On 11/12/2015 08:34 AM, Ilya Enkovich wrote:
Hi,
libmpx was added close to release date and therefore was disabled by default
for all targets. This patch enables it by default for supported targets. Is
it OK for trunk?
Thanks,
Ilya
--
2015-11-12 Tsvetkova Alexandra
* configure.a
On 11/12/2015 10:08 AM, Bradley Lucier wrote:
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up it a
On 6 November 2015 at 21:29, Christophe Lyon wrote:
> On 4 November 2015 at 13:16, Ramana Radhakrishnan
> wrote:
>> On Fri, Oct 30, 2015 at 2:42 PM, Christophe Lyon
>> wrote:
>>> On 30 October 2015 at 15:33, Ramana Radhakrishnan
>>> wrote:
On 29/10/15 17:23, Jim Wilson wrote:
>>>
Hello!
> this patch rotates the loop generated in the prologue to do stack checking
> when -fstack-check is specified, thereby saving one branch instruction. It
> was initially implemented as a WHILE loop to match the generic implementation
> but can be turned into a DO-WHILE loop because the amo
On 11/12/2015 11:32 AM, Jeff Law wrote:
On 11/12/2015 10:05 AM, Jeff Law wrote:
But IIRC you mentioned it should enable vectorization or so? In this
case
that's obviously too late.
The opposite. Path splitting interferes with if-conversion &
vectorization. Path splitting mucks up the CFG eno
On Thu, Nov 12, 2015 at 4:51 PM, Eric Botcazou wrote:
> Hi,
>
> this patch rotates the loop generated in the prologue to do stack checking
> when -fstack-check is specified, thereby saving one branch instruction. It
> was initially implemented as a WHILE loop to match the generic implementation
>
Hi,
this patch rotates the loop generated in the prologue to do stack checking
when -fstack-check is specified, thereby saving one branch instruction. It
was initially implemented as a WHILE loop to match the generic implementation
but can be turned into a DO-WHILE loop because the amount of s
Hi,
this patch rotates the loop generated in the prologue to do stack checking
when -fstack-check is specified, thereby saving one branch instruction. It
was initially implemented as a WHILE loop to match the generic implementation
but can be turned into a DO-WHILE loop because the amount of s
Hi,
this patch rotates the loop generated in the prologue to do stack checking
when -fstack-check is specified, thereby saving one branch instruction. It
was initially implemented as a WHILE loop to match the generic implementation
but can be turned into a DO-WHILE loop because the amount of s
Hi,
this patch rotates the loop generated in the prologue to do stack checking
when -fstack-check is specified, thereby saving one branch instruction. It
was initially implemented as a WHILE loop to match the generic implementation
but can be turned into a DO-WHILE loop because the amount of s
Hi,
this patch rotates the loop generated in the prologue to do stack checking
when -fstack-check is specified, thereby saving one branch instruction. It
was initially implemented as a WHILE loop to match the generic implementation
but can be turned into a DO-WHILE loop because the amount of s
On 11/12/2015 09:52 AM, Michael Matz wrote:
Hello,
this new pass implements loop iteration space splitting for loops that
contain a conditional that's always true for one part of the iteration
space and false for the other, i.e. such situations:
FWIW, Ajit suggested the same transformation earli
On 11/12/2015 12:08 PM, Bradley Lucier wrote:
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up it a
On Thu, 12 Nov 2015, Marek Polacek wrote:
> As explained in the PR, the issue here was that we were treating a TYPENAME
> wrongly as an ID. That happened because we were using information from the
> wrong scope when parsing a token after an else clause. I.e. in fn1 in the
> attached testcase we
On Thu, 12 Nov 2015, David Malcolm wrote:
> On Tue, 2015-11-10 at 17:55 +, Joseph Myers wrote:
> > On Tue, 10 Nov 2015, David Malcolm wrote:
> >
> > > This is the most trivial example of a real fix-it example I could think
> > > of: if the user writes
> > > ptr.field
> > > rather than ptr->
On 11/12/15 15:22, David Edelsohn wrote:
Nathan,
The ChangeLog was placed in the wrong files.
gcc/
* gimplify.c (oacc_default_clause): New.
(omp_notice_variable): Call it.
Fixed. I placed the entries in the other files, but failed to cleanup the above
one.
natha
On Thu, Nov 12, 2015 at 18:45:09 +0100, Jakub Jelinek wrote:
> But the testcase I wrote (target-33.c) hangs, the problem is in the
> #pragma omp target nowait map (tofrom: a, b) depend(out: d[3])
> {
> #pragma omp atomic update
> a = a + 9;
> b -= 8;
> }
> #pragma omp target now
On Sun, Nov 8, 2015 at 7:44 PM, Michael Meissner
wrote:
> This patch adds support for the IEEE 128-bit hardware instructions that are
> being added to the PowerPC ISA 3.0 (power9). With this patch, users on power7
> and power8 will use the software emulation functions that are committed, but
> st
On Sun, Nov 8, 2015 at 7:48 PM, Michael Meissner
wrote:
> This patch adds support for the new direct move instructions (MFVSRLD and
> MTVSRDD) that simplify moving 128-bit data between GPRs and vector registers.
>
> I have built previous versions of this patch with no regressions. At the
> moment
On Tue, Nov 10, 2015 at 1:39 PM, Michael Meissner
wrote:
> This patch adds support for the MADDLD instruciton, which is a fused
> multiply/add instruction for integers. At this time, it is for 64-bit
> multiplies only. Eventually, we will restructure 128-bit multiply so that we
> can use the 64x
In the testcase, the using-declaration was confusing namespace
comparison into thinking that we were instantiating a template from an
enclosing namespace. Given using-declarations, we need to wait until
we've chosen a template before donig this comparison.
Tested x86_64-pc-linux-gnu, applying
Nathan,
The ChangeLog was placed in the wrong files.
gcc/
* gimplify.c (oacc_default_clause): New.
(omp_notice_variable): Call it.
Should go in gcc/ChangeLog without "gcc/"
gcc/testsuite/
* c-c++-common/goacc/data-default-1.c: New.
should go in gcc/tests
On 12 November 2015 at 16:49, Andreas Schwab wrote:
> Richard Biener writes:
>
>> * tree-vectorizer.h (vect_slp_analyze_and_verify_instance_alignment):
>> Declare.
>> (vect_analyze_data_refs_alignment): Make loop vect specific.
>> (vect_verify_datarefs_alignment): Likewise
As explained in the PR, the issue here was that we were treating a TYPENAME
wrongly as an ID. That happened because we were using information from the
wrong scope when parsing a token after an else clause. I.e. in fn1 in the
attached testcase we need to examine the token after "if (1);" to see if
On 11/12/2015 12:46 PM, Mike Stump wrote:
My port needs the below patch. I think this was reduced by someone on a port
that didn’t use some features (TARGET_SHORT_BRANCH_CHEAPER) of tm.h.
So, the question is, is this the preferred way to do this? I don’t want to
hookize TARGET_SHORT_BRANCH_C
On 11/12/2015 12:40 PM, Richard Biener wrote:
On November 12, 2015 7:32:57 PM GMT+01:00, Jeff Law
wrote:
On 11/12/2015 10:05 AM, Jeff Law wrote:
But IIRC you mentioned it should enable vectorization or so?
In
this
case that's obviously too late.
The opposite. Path splitting interferes with
My port needs the below patch. I think this was reduced by someone on a port
that didn’t use some features (TARGET_SHORT_BRANCH_CHEAPER) of tm.h.
So, the question is, is this the preferred way to do this? I don’t want to
hookize TARGET_SHORT_BRANCH_CHEAPER, which is the other fix.
If yes, Ok
On Tue, 2015-11-10 at 17:55 +, Joseph Myers wrote:
> On Tue, 10 Nov 2015, David Malcolm wrote:
>
> > This is the most trivial example of a real fix-it example I could think
> > of: if the user writes
> > ptr.field
> > rather than ptr->field.
> >
> > gcc/c/ChangeLog:
> > * c-typeck.c (
On November 12, 2015 7:32:57 PM GMT+01:00, Jeff Law wrote:
>On 11/12/2015 10:05 AM, Jeff Law wrote:
>>> But IIRC you mentioned it should enable vectorization or so? In
>this
>>> case
>>> that's obviously too late.
>> The opposite. Path splitting interferes with if-conversion &
>> vectorization.
On Thu, 12 Nov 2015, Stepanyan, Victoria wrote:
> This patch adds znver1 description in changes.html:
:
> Ok for trunk?
Thanks, yes, this looks good to me.
Gerald
I applied this one as obvious.
* Makefile.in (etags tags TAGS): Use && instead of ;.
Index: Makefile.in
===
--- Makefile.in (revision 230269)
+++ Makefile.in (working copy)
@@ -409,7 +409,7 @@ stamp-noasandir:
.PHONY: all et
> >> +
> >> + /* Initialize hash values if we are not in LTO mode. */
> >> + if (!in_lto_p)
> >> + item->get_hash ();
> >> }
> >
> > Hmm, what is the difference to the LTO mode here. I would have expected
> > that all the items
> > was analyzed in both paths?
>
> Difference is t
On 06/11/15 16:29, Richard Biener wrote:
>>> 2) You should be able to use fold_ctor_reference directly (in place
>> of
>>> all your code
>>> in case offset and size are readily available - don't remember
>> exactly how
>>> complete scalarization "walks" elements). Alternatively use
>>> fold_const_
On 11/12/2015 10:05 AM, Jeff Law wrote:
But IIRC you mentioned it should enable vectorization or so? In this
case
that's obviously too late.
The opposite. Path splitting interferes with if-conversion &
vectorization. Path splitting mucks up the CFG enough that
if-conversion won't fire and as
Hi
I have just Merged trunk revision 230248 into the hsa branch. I will
prepare a new submission for inclusion to trunk tomorrow.
Thanks,
Martin
On 11/12/2015 10:08 AM, Jonathan Wakely wrote:
On 12/11/15 08:48 -0700, Martin Sebor wrote:
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C+
On Thu, Nov 12, 2015 at 18:58:22 +0100, Jakub Jelinek wrote:
> > Unfortunately, target-32.c fails for me using emulation mode:
>
> I haven't managed to get it stuck yet (unlike the target-33.c one, see
> another mail), what OMP_NUM_THREADS you are using
> and how many cores/threads?
OMP_NUM_THREA
On Thu, Nov 12, 2015 at 08:43:53PM +0300, Ilya Verbin wrote:
> > Can you please try to cleanup the liboffloadmic side of this, so that
> > a callback instead of hardcoded __gomp_offload_intelmic_async_completed call
> > is used?
>
> Do you mean something like the patch bellow? I'll discuss it wit
On 12/11/15 12:24 -0500, Jennifer Yao wrote:
On 12/11/15 13:39 +, Jonathan Wakely wrote:
One downside of this change is that we introduce some (hopefully safe)
ODR violations, where inline functions and templates that depend on
_GLIBCXX_USE_C99_FOO might now be defined differently in C++98
Hi!
Here is updated patch with the team == NULL case hopefully handled.
But the testcase I wrote (target-33.c) hangs, the problem is in the
#pragma omp target nowait map (tofrom: a, b) depend(out: d[3])
{
#pragma omp atomic update
a = a + 9;
b -= 8;
}
#pragma omp target nowait
On Wed, Nov 11, 2015 at 17:52:22 +0100, Jakub Jelinek wrote:
> On Mon, Oct 19, 2015 at 10:47:54PM +0300, Ilya Verbin wrote:
> > So, here is what I have for now. Attached target-29.c testcase works fine
> > with
> > MIC emul, however I don't know how to (and where) properly check for
> > completi
On 11/12/2015 09:39 AM, Evandro Menezes wrote:
On 11/12/2015 08:55 AM, James Greenhalgh wrote:
On Tue, Nov 10, 2015 at 11:50:12AM -0600, Evandro Menezes wrote:
2015-11-10 Evandro Menezes
gcc/
* config/aarch64/aarch64.md (predicated): Copy attribute from
"arm.md".
Th
> On 12/11/15 13:39 +, Jonathan Wakely wrote:
>>
>> One downside of this change is that we introduce some (hopefully safe)
>> ODR violations, where inline functions and templates that depend on
>> _GLIBCXX_USE_C99_FOO might now be defined differently in C++98 and
>> C++11 code. Previously they
On 11/12/2015 11:57 AM, Bernd Schmidt wrote:
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up it a bit now.
{
+ unsigned int memory_request =
On 12/11/15 08:48 -0700, Martin Sebor wrote:
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C++11 that can be trivially solved by giving
the e
On 11/12/2015 03:58 AM, Richard Biener wrote:
On Wed, Nov 11, 2015 at 9:38 PM, Jeff Law wrote:
On 09/04/2015 11:36 AM, Ajit Kumar Agarwal wrote:
diff --git a/gcc/passes.def b/gcc/passes.def
index 6b66f8f..20ddf3d 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -82,6 +82,7 @@ along with GC
The expanded warning allowed me to see how much memory really was needed
to apply gcse to some of my routines, and 128MB fixes my problem. The
limit has been 50MB for over 10 years, I think we can up it a bit now.
{
+ unsigned int memory_request = n_basic_blocks_for_fn (cfun)
+* SBITMAP_SE
Hello,
this new pass implements loop iteration space splitting for loops that
contain a conditional that's always true for one part of the iteration
space and false for the other, i.e. such situations:
for (i = beg; i < end; i++)
if (i < p)
dothis();
else
dothat();
this i
This patch (a) removes an exact copy of is_too_expensive from cprop.c,
(b) renames is_too_expensive in gcse.c to
gcse_or_cprop_is_too_expensive, (c) expands the warning in
gcse_or_cprop_is_too_expensive to say how much --param max-gcse-memory
needs to be increased, and (d) increases the default
On 11/12/2015 04:58 PM, Ramana Radhakrishnan wrote:
>
>
> On 12/11/15 15:52, Martin Liška wrote:
>> On 11/12/2015 12:29 PM, Richard Biener wrote:
>>> On Thu, Nov 12, 2015 at 11:03 AM, Martin Liška wrote:
Hello.
Following patch was a bit negotiated with Jakub and can save a huge am
On Thu, 12 Nov 2015, Ville Voutilainen wrote:
> Note that that's a separate problem that has nothing to do with the
> tag-type-explicit-default-ctor patch.
On Thu, 12 Nov 2015, Jonathan Wakely wrote:
> Different issue.
Sorry, I had two different libstdc++ bootstrap failures in the
last 24 hours,
On Wed, Nov 11, 2015 at 6:34 PM, Jim Wilson wrote:
> This adds an option for the Qualcomm server parts, qdf24xx, just
> optimizing like a cortex-a57 for now, same as how the initial Samsung
> exynos-m1 support worked.
>
> This was tested with armv8 and aarch64 bootstraps and make check.
>
> I had
On 12/11/15 14:36 +, Jonathan Wakely wrote:
On 12/11/15 15:23 +0100, Gerald Pfeifer wrote:
On Wed, 11 Nov 2015, Jonathan Wakely wrote:
Fixed by this patch.
Thanks, Jonathan! Unfortunately bootstrap is still broken
(on i386-unknown-freebsd11.0 at least):
Different issue.
In file includ
Hi Nathan!
On Thu, 12 Nov 2015 09:03:42 -0500, Nathan Sidwell wrote:
> I've applied this to gomp4 branch. It removes the machinery concerning c++
> references. The openacc std makes no mention of such a type, so originally
> we
> were not permitting the type. But,
> (a) OpenMP supports them
Hi,
When we use LTO for fortran we may have a mix 32bit and 1bit scalar booleans.
It means we may have conversion of one scalar type to another which confuses
vectorizer because values with different scalar boolean type may get the same
vectype. This patch transforms such conversions into comp
On 11/11/15 12:00, Jakub Jelinek wrote:
On Wed, Nov 11, 2015 at 11:51:02AM +0100, Richard Biener wrote:
The option -foffload-alias=pointer instructs the compiler to assume that
objects references in an offload region do not alias.
The option -foffload-alias=all instructs the compiler to make no
On Thu, Nov 12, 2015 at 02:21:56PM +0100, Thomas Schwinge wrote:
> > > --- a/libgomp/libgomp.h
> > > +++ b/libgomp/libgomp.h
> > > @@ -876,7 +876,8 @@ struct gomp_device_descr
> > >void *(*dev2host_func) (int, void *, const void *, size_t);
> > >void *(*host2dev_func) (int, void *, const vo
On 12/11/15 15:52, Martin Liška wrote:
> On 11/12/2015 12:29 PM, Richard Biener wrote:
>> On Thu, Nov 12, 2015 at 11:03 AM, Martin Liška wrote:
>>> Hello.
>>>
>>> Following patch was a bit negotiated with Jakub and can save a huge amount
>>> of memory in cases
>>> where target attributes are he
Richard Biener writes:
> * tree-vectorizer.h (vect_slp_analyze_and_verify_instance_alignment):
> Declare.
> (vect_analyze_data_refs_alignment): Make loop vect specific.
> (vect_verify_datarefs_alignment): Likewise.
> * tree-vect-data-refs.c (vect_slp_analyze_data_ref
On 11/11/2015 02:48 AM, Jonathan Wakely wrote:
As described in the PR, we have operator~ overloads defined for
enumeration types which produce values outside the range of valid
values for the type. In C++11 that can be trivially solved by giving
the enumeration types a fixed underlying type, but
On 11/12/2015 12:29 PM, Richard Biener wrote:
> On Thu, Nov 12, 2015 at 11:03 AM, Martin Liška wrote:
>> Hello.
>>
>> Following patch was a bit negotiated with Jakub and can save a huge amount
>> of memory in cases
>> where target attributes are heavily utilized.
>>
>> Can bootstrap and survives
Hi,
We may get ICE in vectorizer in case stored value get vectype not compatible
with a storage. This may happen for bool values. This patch fixes ICE.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-11-12 Ilya Enkovich
* tree-vect-s
Hi,
Currently compiler may ICE when loaded boolean is compared with vector
invariant or another boolean value. This is because we don't detect mix of
bool and non-bool vectypes and incorrectly determine vectype for boolean loop
invariant for comparison. This was fixed for COND_EXP before but
On Thu, 2015-11-12 at 15:43 +0100, Richard Biener wrote:
> On Thu, Nov 12, 2015 at 3:31 PM, Tom de Vries wrote:
> > On 11/11/15 12:03, Richard Biener wrote:
> >>
> >> On Mon, 9 Nov 2015, Tom de Vries wrote:
> >>
> >>> On 09/11/15 16:35, Tom de Vries wrote:
>
> Hi,
>
> this patc
On 11/12/2015 08:55 AM, James Greenhalgh wrote:
On Tue, Nov 10, 2015 at 11:50:12AM -0600, Evandro Menezes wrote:
2015-11-10 Evandro Menezes
gcc/
* config/aarch64/aarch64.md (predicated): Copy attribute from
"arm.md".
This patch duplicates an attribute from arm.md so
On 11/12/2015 12:33 PM, Bernd Schmidt wrote:
> On 11/12/2015 12:29 PM, Richard Biener wrote:
>> +static bool opts_obstack_initialized = false;
>> +
>> +/* Initialize opts_obstack if not initialized. */
>> +
>> +void
>> +init_opts_obstack (void)
>> +{
>> + if (!opts_obstack_initialized)
>> +{
Hi,
libmpx was added close to release date and therefore was disabled by default
for all targets. This patch enables it by default for supported targets. Is
it OK for trunk?
Thanks,
Ilya
--
2015-11-12 Tsvetkova Alexandra
* configure.ac: Enable libmpx by default.
* configur
On Thu, 2015-11-12 at 15:06 +0100, Richard Biener wrote:
> On Thu, Nov 12, 2015 at 3:04 PM, Richard Biener
> wrote:
> > On Thu, Nov 12, 2015 at 2:49 PM, Tom de Vries
> > wrote:
> >> On 12/11/15 13:26, Richard Biener wrote:
> >>>
> >>> On Thu, Nov 12, 2015 at 12:37 PM, Tom de Vries
> >>> wrote:
Hi,
This patch adds description for several standard pattern names. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-11-12 Ilya Enkovich
* doc/md.texi (vec_cmp@var{m}@var{n}): New item.
(vec_cmpu@var{m}@var{n}): New item.
(vcond@var{m}@var{n}): Specify comparison is signed.
On 12/11/15 15:08, Andre Vieira wrote:
Hi,
This patch changes the memset-inline-10.c testcase to make sure that
it is only compiled for ARM targets that support -mfloat-abi=hard using
the fact that all non-thumb1 targets do.
This is correct because all targets for which -mthumb causes the
Hi,
This patch changes the memset-inline-10.c testcase to make sure that
it is only compiled for ARM targets that support -mfloat-abi=hard using
the fact that all non-thumb1 targets do.
This is correct because all targets for which -mthumb causes the
compiler to use thumb2 will support t
Hi,
This patch changes this testcase to make sure LTO will not optimize
away the assignment of the local array to a global variable which was
introduced to make sure stack space was made available for the test to work.
This is correct because LTO is supposed to optimize this global away
On 11/12/2015 03:59 PM, Alexander Monakov wrote:
On Thu, 12 Nov 2015, Bernd Schmidt wrote:
I've run it through make -k check-c regtesting. These are new fails, all
mysterious:
These would have to be investigated first.
Any specific suggestions? The PTX code emitted from GCC differs only in
On Thu, 12 Nov 2015, Bernd Schmidt wrote:
> > I've run it through make -k check-c regtesting. These are new fails, all
> > mysterious:
>
> These would have to be investigated first.
Any specific suggestions? The PTX code emitted from GCC differs only in
prologue/epilogue, so whatever's broken..
2015-11-05 13:37 GMT+03:00 Aleksandra Tsvetkova :
> New version of libmpx was added. There is a new function get_bd() that
> allows to get bounds directory. Wrapper for memmove was modified. Now
> it moves data and then moves corresponding bounds directly from one
> bounds table to another. This ap
On Tue, Nov 10, 2015 at 11:50:12AM -0600, Evandro Menezes wrote:
>2015-11-10 Evandro Menezes
>
>gcc/
>
>* config/aarch64/aarch64.md (predicated): Copy attribute from
>"arm.md".
>
> This patch duplicates an attribute from arm.md so that the same
> pipeline model can be u
This fixes BB vectorization dependence analysis to not rely on
all instances being vectorized. The dependence check
- gimple *earlier_stmt = get_earlier_stmt (DR_STMT (dra), DR_STMT
(drb));
- if (DR_IS_READ (STMT_VINFO_DATA_REF (vinfo_for_stmt (earlier_stmt
- {
- /* That only
On 12/11/15 13:39 +, Jonathan Wakely wrote:
One downside of this change is that we introduce some (hopefully safe)
ODR violations, where inline functions and templates that depend on
_GLIBCXX_USE_C99_FOO might now be defined differently in C++98 and
C++11 code. Previously they had the same de
On Thu, Nov 05, 2015 at 11:31:33AM -0600, Evandro Menezes wrote:
> James,
>
> Since other members of the "tune_params" structure were signed
> integers, even though negative numbers would make no sense for most
> either, I followed the same pattern.
>
> Regardless, here's a patch with unsigned in
On Thu, Nov 12, 2015 at 3:31 PM, Tom de Vries wrote:
> On 11/11/15 12:03, Richard Biener wrote:
>>
>> On Mon, 9 Nov 2015, Tom de Vries wrote:
>>
>>> On 09/11/15 16:35, Tom de Vries wrote:
Hi,
this patch series for stage1 trunk adds support to:
- parallelize oacc kernels re
I'm proposing the following patch as a step towards resolving the issue with
inaccessibility of stack storage (.local memory) in PTX to other threads than
the one using that stack. The idea is to have preallocated stacks, and have
__nvptx_stacks[] array in shared memory hold current stack pointer
On 12/11/15 15:23 +0100, Gerald Pfeifer wrote:
On Wed, 11 Nov 2015, Jonathan Wakely wrote:
Fixed by this patch.
Thanks, Jonathan! Unfortunately bootstrap is still broken
(on i386-unknown-freebsd11.0 at least):
Different issue.
In file included from
/scratch/tmp/gerald/gcc-HEAD/libstdc++-v
On 12 November 2015 at 16:23, Gerald Pfeifer wrote:
> On Wed, 11 Nov 2015, Jonathan Wakely wrote:
>>
>> Fixed by this patch.
>
>
> Thanks, Jonathan! Unfortunately bootstrap is still broken
> (on i386-unknown-freebsd11.0 at least):
>
> In file included from
> /scratch/tmp/gerald/gcc-HEAD/libstdc++
On 11/11/15 12:03, Richard Biener wrote:
On Mon, 9 Nov 2015, Tom de Vries wrote:
On 09/11/15 16:35, Tom de Vries wrote:
Hi,
this patch series for stage1 trunk adds support to:
- parallelize oacc kernels regions using parloops, and
- map the loops onto the oacc gang dimension.
The patch serie
Hi Arnaud,
On 12/11/15 12:06, Arnaud Charlet wrote:
This change refines the use of the "volatile hammer" to implement the advice
given in RM 13.3(19) by disabling it for object overlays altogether. relying
instead on the ref-all aliasing property of reference types to achieve the
desired effect.
1 - 100 of 181 matches
Mail list logo
