On Wed, Jul 29, 2015 at 09:11:21AM +0100, Richard Sandiford wrote:
> Trevor Saunders writes:
> > On Tue, Jul 28, 2015 at 09:24:17PM +0100, Richard Sandiford wrote:
> >> Trevor Saunders writes:
> >> > On Mon, Jul 27, 2015 at 09:05:08PM +0100, Richard Sandiford wrote:
> >> >> Alternatively we could
In this testcase, having previously determined that "int" is not
dependent was confusing us into thinking that ValueType was not
dependent. But under DR 1558, it is.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4f4b8497f404ab8f8d641878ee03ee91e6dcf6fb
Author: Jason Merrill
Date: Th
Hi Benedikt,
I ran SPEC2006 fp with your previous patch (v2) for cortex-a57. Gromacs
gains ~5% for -mcpu=cortex-a57 -Ofast and gains ~11% with -mcpu=cortex-a57
-Ofast -mlow-precision-recip-sqrt.
Other FP benchmarks were within noise.
However I will leave it for Aarch64 maintainers to dec
On Wed, Jul 29, 2015 at 9:21 PM, Tim Shen wrote:
> On Wed, Jul 29, 2015 at 2:15 AM, Jonathan Wakely wrote:
>> Yes, that makes sense. See the code in for how
>> to set the alignment of the buffer appropriately. You can use the size
>> and alignment of std::function even though it will
>> sometime
On Wed, Jul 29, 2015 at 2:15 AM, Jonathan Wakely wrote:
> Yes, that makes sense. See the code in for how
> to set the alignment of the buffer appropriately. You can use the size
> and alignment of std::function even though it will
> sometimes be a different std::function specialization.
Done.
A
Paper bag time. Committing as obvious fix. Bootstrapped and regression
checked on powerpc64-linux and powerpc64le-linux; also bootstrapped the
latter with --enable-checking=release and -O3 (the PR67045 case). Will
do an --enable-checking=yes,rtl as well.
Segher
2015-07-29 Segher Boessenkool
On Wed, Jul 29, 2015 at 11:16:40AM +0100, Richard Earnshaw wrote:
> I'm getting a bit worried about the potential performance impact from
> all these indirect function call hooks. This is a good example of when
> it's probably somewhat unnecessary. I doubt that the compiler could
> function corre
The attached patch canonicalizes sink dependence clauses into one folded
clause if possible (as discussed in the paper "Expressing DOACROSS Loop
Dependences in OpenMP").
The basic algorithm is to create a sink vector whose first element is
the GCD of all the first elements, and whose remaining
I've committed this to gomp4. When I broke out the oacc_default_clause
function from omp_notice_variable, I was puzzled by the ordering of the lookups,
but could quite figure out what was wrong. further investigation and standard
reading showed that for openacc, we look in outer lexical scop
Jakub,
this patch augments the lto wrapper to print out the arguments to spawned
commands when verbose. I found this useful in debugging recent development.
ok for trunk?
nathan
2015-07-29 Nathan Sidwell
* lto-wrapper.c (verbose_exec): New.
(compile_offload_image, run_gcc): Call it.
In
On Wed, Jul 29, 2015 at 05:46:42PM -0500, Segher Boessenkool wrote:
> On Wed, Jul 29, 2015 at 06:38:45PM -0400, Michael Meissner wrote:
> > On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> > > On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > > > +;; Return
I've committed this to gomp4 branch. It changes the ptx target data format from
a string array with embedded NULs, to an array of pointers & sizes to separate
strings for each object file. This avoids the use of strlen when loading onto
the PTX device.
Not incrementing the PTX version number
2015-07-29 19:48 GMT+02:00 Jason Merrill :
> On 07/28/2015 04:10 PM, Kai Tietz wrote:
>>
>> 2015-07-28 1:14 GMT+02:00 Kai Tietz :
>>
>>> 2015-07-27 18:51 GMT+02:00 Jason Merrill :
I've trimmed this to the previously mentioned issues that still need to
be
addressed; I'll do anoth
On 07/27/2015 09:47 PM, Trevor Saunders wrote:
On Mon, Jul 27, 2015 at 11:06:58AM +0200, Richard Biener wrote:
On Sat, Jul 25, 2015 at 4:37 AM, wrote:
From: Trevor Saunders
* config/arc/arc.h, config/bfin/bfin.h, config/frv/frv.h,
config/ia64/ia64-protos.h, config/ia64/ia6
On 07/29/2015 02:00 AM, David Sherwood wrote:
Hi,
This patch follows on from
[PATCH][1/N] Change GET_MODE_INNER to always return a non-void mode
It is another tidy up, replacing the pattern GET_MODE_SIZE (GET_MODE_INNER (m))
with GET_MODE_UNIT_SIZE (m).
Tested:
aarch64 and aarch64_be - no reg
On Wed, Jul 29, 2015 at 06:38:45PM -0400, Michael Meissner wrote:
> On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> > On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > > +;; Return constant 0x8000 in an Altivec
> > > register.
>
On 07/29/2015 08:08 AM, Marek Polacek wrote:
As discussed elsewhere, -Wtautological-compare shouldn't warn about
floating-point types because of the way NaN behave.
I've been meaning to commit this one as obvious, but I'm not sure
whether I should also use HONOR_NANS or whether I can safely igno
On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > +;; Return constant 0x8000 in an Altivec
> > register.
> > +
> > +(define_expand "altivec_high_bit"
> > + [(set (match_dup 1)
> >
On 07/29/2015 07:49 AM, Kyrill Tkachov wrote:
Hi all,
This patch improves RTL if-conversion on sequences that perform a
conditional select on integer constants.
Most of the smart logic to do that already exists in the
noce_try_store_flag_constants function.
However, currently that function is tr
On 07/28/2015 12:18 PM, Alex Velenko wrote:
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Hi, Jeff
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.j
Richard and Jeff,
Any conclusion to this discussion? Is this okay in match.pd or would you
like to see it implemented elsewhere?
On 7/28/2015 12:41 AM, Richard Biener wrote:
On Mon, Jul 27, 2015 at 6:20 PM, Jeff Law wrote:
On 07/27/2015 03:25 AM, Richard Biener wrote:
On Mon, Jul 27, 2015
On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> +;; Return constant 0x8000 in an Altivec register.
> +
> +(define_expand "altivec_high_bit"
> + [(set (match_dup 1)
> + (vec_duplicate:V16QI (const_int 7)))
> + (set (match_dup 2)
> + (ashift:
On 07/29/15 08:24, Nathan Sidwell wrote:
On 07/29/15 05:22, Thomas Schwinge wrote:
Likewise for the other torture testing flags.
Investigating ... (I've seen those failures be intermittent)
Interestingly the fails go away with an unoptimized libgomp. I've observed
something vaguely lik
The last change to libgo/mksysinfo.sh was missing some spaces, which
apparently causaed mksysinfo to hang on some systems. This is
https://golang.org/issue/11924. This patch from Lynn Boger fixes the
problem. Bootstrapped on x86_64-unknown-linux-gnu, where it made no
difference. Committed to ma
Sebastian Pop wrote:
> Aditya Kumar wrote:
> > More than 3 params consumes too much memory while bootstrapping gcc
> > with graphite enabled.
>
> Ok. I will commit the patch.
> Thanks for fixing bootstrap with graphite enabled.
We will increase the max when we will use ISL's mechanism to count t
More than 3 params consumes too much memory while bootstrapping gcc
with graphite enabled.
BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-block -floop-interchange
-floop-strip-mine"
---
gcc/params.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/params.def b/gcc/params
Aditya Kumar wrote:
> More than 3 params consumes too much memory while bootstrapping gcc
> with graphite enabled.
Ok. I will commit the patch.
Thanks for fixing bootstrap with graphite enabled.
Sebastian
Since IA MCU uses the same debug register map as Linux/x86, we copy
DBX_REGISTER_NUMBER together with TARGET_ASM_FILE_START_FILE_DIRECTIVE
and ASM_COMMENT_START from i386/gnu-user.h to i386/iamcu.h.
* config/i386/iamcu.h (TARGET_ASM_FILE_START_FILE_DIRECTIVE):
New. Copied from con
Dominik Vogt writes:
> With that problem fixed I still see one minor glitch. Maybe
> someone knows how to fix the following:
>
> * With a cross compiler that generates i686 binaries on s390x:
>
>$ i686-elf-gcc -c ~/foo.c -march=native
>/home/vogt/foo.c:1:0: error: bad value (native) for -
On Wed, Jul 29, 2015 at 09:50:16PM +0200, Uros Bizjak wrote:
>
> Please also add the testcase from the PR, Comment #14 [1]. The failure
> mode of this problem is a difficult to detect invalid read in
> class_allocate_18, but the testcase from the PR outright crashes.
>
> [1] https://gcc.gnu.org/b
On Wed, Jul 29, 2015 at 1:13 PM, Alexandre Oliva wrote:
> On Jul 23, 2015, "H.J. Lu" wrote:
>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66978
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
>
> Thanks, both of these are also fixed (I merged your patch for x32, and I
> verified manu
On Jul 23, 2015, "H.J. Lu" wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66978
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
Thanks, both of these are also fixed (I merged your patch for x32, and I
verified manually that another fix I just wrote fixes all the -m32
-msse2 regress
On Jul 23, 2015, Segher Boessenkool wrote:
> On Thu, Jul 23, 2015 at 12:29:14PM -0300, Alexandre Oliva wrote:
>> Yeah. Thanks, I've tested it with this change, and I'm now checking
>> this in (full patch first; adjusted incremental patch at the end):
> Unfortunately it causes about a thousand t
Hi
Here is a patch to add irreflexive debug check.
Standard algos signatures are such that there is no guaranty that
the operator < or predicate to compare the iterator value type will
exist. So I had to check if the call is valid using C++11 features
declval and decltype.
* include/
This is another intermediate patch to get IEEE 128-bit support on the PowerPC
into the GCC compiler. This patch adds a lot of the support to allow IEEE
128-bit support in VSX registers. Note, it will need future patches that
updates rs6000.c and rs6000.md to enable the basic IEEE 128-bit support.
Hello!
> I submit the PR64921 fix I posted two days ago on bugzilla.
>
> The problem comes from the finalization wrapper not having the
> always_explicit attribute set, so
> that when it is called, the array argument is passed without descriptor, but
> the argument
> declaration is a descriptor
On Wed, Jul 29, 2015 at 10:19:52PM +0300, Ville Voutilainen wrote:
> Although the commit message for this supposedly obvious change is f**ked up
> since it claims I modified MAINTAINERS, whereas I modified ChangeLog.
> Such fun.
The commit message doesn't matter that much. Your last change looks
On 29 July 2015 at 22:18, Ville Voutilainen wrote:
> On 29 July 2015 at 21:48, Marek Polacek wrote:
>> On Wed, Jul 29, 2015 at 08:29:34PM +0300, Ville Voutilainen wrote:
>>> Fyi.
>>>
>>> 2015-07-29 Ville Voutilainen
>>> * MAINTAINERS (Write After Approval): Add myself.
>>
>> There shou
On 29 July 2015 at 21:48, Marek Polacek wrote:
> On Wed, Jul 29, 2015 at 08:29:34PM +0300, Ville Voutilainen wrote:
>> Fyi.
>>
>> 2015-07-29 Ville Voutilainen
>> * MAINTAINERS (Write After Approval): Add myself.
>
> There should be a blank line between these two lines.
Ok, I added the
On Mon, Jul 06, 2015 at 22:42:10 +0200, Jakub Jelinek wrote:
> As has been clarified on omp-lang, we actually shouldn't be mapping or
> unmapping the pointer and/or reference, only the array slice itself, except
> in target construct (and even for that it is changing from mapping to
> private + poi
On Wed, Jul 29, 2015 at 08:29:34PM +0300, Ville Voutilainen wrote:
> Fyi.
>
> 2015-07-29 Ville Voutilainen
> * MAINTAINERS (Write After Approval): Add myself.
There should be a blank line between these two lines.
Marek
Hello,
I'm unburrying the patch from the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00439.html
I provide the patch in two flavors read-only (without whitespace
changes) and write-only (with them).
This has been tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
On 07/28/2015 09:38 PM, Jason Merrill wrote:
Sorry about the slow response on IRC today, I got distracted onto
another issue and forgot to check back. What I started to write:
No problem.
I'm exploring your suggestion to see if the back end could emit the
diagnostics. But I'm not sure it h
* config/aarch64/aarch64-builtins.c: Builtins for rsqrt and
rsqrtf.
* config/aarch64/aarch64-opts.h: -mrecip has a default value
depending on the core.
* config/aarch64/aarch64-protos.h: Declare.
* config/aarch64/aarch64-simd.md: Matching expressions
On 07/28/2015 04:10 PM, Kai Tietz wrote:
2015-07-28 1:14 GMT+02:00 Kai Tietz :
2015-07-27 18:51 GMT+02:00 Jason Merrill :
I've trimmed this to the previously mentioned issues that still need to be
addressed; I'll do another full review after these are dealt with.
Thanks for doing this summary
This third revision of the patch:
* makes -mrecip default value specified per core.
* disables rsqrt when -Os is given.
Ok for check in.
Benedikt Huber (1):
2015-07-29 Benedikt Huber
Philipp Tomsich
gcc/ChangeLog | 19
gcc/
Hello,
I submit the PR64921 fix I posted two days ago on bugzilla.
The problem comes from the finalization wrapper not having the
always_explicit attribute set, so that when it is called, the array
argument is passed without descriptor, but the argument declaration is a
descriptor array. Boom
Fyi.
2015-07-29 Ville Voutilainen
* MAINTAINERS (Write After Approval): Add myself.
diff --git a/ChangeLog b/ChangeLog
index 4fcf016..bf49729 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,6 @@
+2015-07-29 Ville Voutilainen
+ * MAINTAINERS (Write After Approval): Add myself.
On July 29, 2015 6:14:58 PM GMT+02:00, Paolo Carlini
wrote:
>Hi,
>
>On 07/28/2015 09:20 AM, Richard Biener wrote:
>> This moves/merges the equality folding of decl addresses from
>> fold_comparison with that from fold_binary in match.pd.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu,
Hi,
This is a set of 19 new tests for OpenACC reductions, covering several
ways of performing reductions over the parallel and loop directives
using gang or worker/vector level parallelism. (The semantics are quite
subtle in some places, but I believe the tests follow the specification
to the lett
On 29/07/15 14:00, Richard Biener wrote:
On Wed, Jul 29, 2015 at 1:22 PM, Tom de Vries wrote:
On 29/07/15 10:09, Richard Biener wrote:
On Tue, Jul 28, 2015 at 2:08 PM, Tom de Vries
wrote:
On 28/07/15 09:59, Richard Biener wrote:
On Fri, Jul 24, 2015 at 4:39 PM, Tom de Vries
wrote:
On Fri, Jul 24, 2015 at 10:04:57PM +0200, Jakub Jelinek wrote:
> Another version.
> What to do with zero-length array sections vs. objects is still under heated
> debates, so target8.f90 keeps failing intermittently.
Here is a new version of the patch, with various additions (implemented
GOMP_MAP_
On Wed, Jul 29, 2015 at 02:04:12PM +0200, Richard Biener wrote:
> On Wed, Jul 29, 2015 at 1:59 PM, Mikael Morin wrote:
> > Le 29/07/2015 13:22, Richard Biener a écrit :
> >>
> >> On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin
> >> wrote:
> >>>
> >>> Le 29/07/2015 10:26, Richard Biener a écrit :
>
Well. We don't generally introduce regressions with changes.
Understood. Regressions are bad, of course. TTBOMK the
regressions in question are temporary. Once they are gone,
I think we can then look at whether or not we still
need to keep the old if converter in trunk. Ideally,
it eventual
Hi,
On 07/28/2015 09:20 AM, Richard Biener wrote:
This moves/merges the equality folding of decl addresses from
fold_comparison with that from fold_binary in match.pd.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-07-28 Richard Biener
* fold-
Dear All,
My reply is the same as FX's. However, I am perfectly happy to
eliminate the initialization. The correct state is ensured by
gfc_dump_module.
Cheers
Paul
On 29 July 2015 at 17:31, FX wrote:
>> Why do you initialize a static variable to false?
>
> You mean because false is equal to ze
On Wed, Jul 29, 2015 at 05:31:57PM +0200, FX wrote:
> > Why do you initialize a static variable to false?
>
> You mean because false is equal to zero and it will be the default
> initialization anyway?
Yes.
> I quite like that the default value is explicit.
Ok then.
Marek
> Why do you initialize a static variable to false?
You mean because false is equal to zero and it will be the default
initialization anyway?
I quite like that the default value is explicit.
FX
> 2015-07-29 Uros Bizjak
>
>PR libgfortran/66650
>* libgfortran.h (GFC_DTYPE_SIZE_MASK): Rewrite to avoid
>"left shift of negative value" warning.
OK. Thanks for the patch.
FX
On Wed, Jul 29, 2015 at 05:08:19PM +0200, Paul Richard Thomas wrote:
> Index: gcc/fortran/module.c
> ===
> *** gcc/fortran/module.c (revision 226054)
> --- gcc/fortran/module.c (working copy)
> *** read_module (vo
Dear All,
On 24 July 2015 at 10:08, Damian Rouson wrote:
> I love this idea and had similar thoughts as well.
>
> :D
>
> Sent from my iPhone
>
>> On Jul 24, 2015, at 1:06 AM, Paul Richard Thomas
>> wrote:
>>
>> Dear Mikael,
>>
>> It had crossed my mind also that a .mod and a .smod file could be
This file contains some C++98 instantiations that are then compared to
similar instantiations in C++11 tests, so it needs to be compiled with
an explicit -std option now that g++ defaults to gnu++14.
Tested i686-linux, x86_64-linux and ppc64le-linux.
Committed to trunk.
commit 641f48dbc01bb134d
Hi Alan,
On 28/07/15 12:24, Alan Lawrence wrote:
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00477.html.
The only change is to publish float16x8_t only if we actually have a scalar
__fp16 type.
gcc/ChangeLog:
* config/arm/arm.h (VALID_NEON_QREG_MODE): Add V8HFmode.
Hi Alan,
On 28/07/15 12:23, Alan Lawrence wrote:
This is a respin of https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00476.html.
The change is to provide all the new float16 intrinsics only if we actually have
an scalar __fp16 type. (This covers the intrinsics whose implementation is
entirely withi
Hi Alan,
On 28/07/15 12:23, Alan Lawrence wrote:
This makes the existing float16 vector intrinsics available only when we have an
__fp16 type (i.e. when one of the ARM_FP16_FORMAT_... macros is defined).
Thus, we also rearrange the float16x[48]_t types to use the same type as __fp16
for the ele
The following fixes PR67053 by more closely mirror what fold_binary()s
STRIP_NOPS does to avoid the C++ FE constexpr code to regress.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Yes, I'm thinking on an automated way to more closely mirror
STRIP_[SIGN_]NOPS behavior (on topleve
On Wed, Jul 29, 2015 at 3:57 PM, Ulrich Weigand wrote:
> Hello,
>
> this patch is a workaround for the problem discussed here:
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01597.html
>
> The problem is that the new pool allocator code relies on C++ aliasing
> rules related to placement new (bas
On Wed, Jul 29, 2015 at 04:08:22PM +0200, Marek Polacek wrote:
> As discussed elsewhere, -Wtautological-compare shouldn't warn about
> floating-point types because of the way NaN behave.
>
> I've been meaning to commit this one as obvious, but I'm not sure
> whether I should also use HONOR_NANS or
As discussed elsewhere, -Wtautological-compare shouldn't warn about
floating-point types because of the way NaN behave.
I've been meaning to commit this one as obvious, but I'm not sure
whether I should also use HONOR_NANS or whether I can safely ignore
that here.
Bootstrapped/regtested on x86_64
Hello,
this patch is a workaround for the problem discussed here:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01597.html
The problem is that the new pool allocator code relies on C++ aliasing
rules related to placement new (basically, that placement new changes
the dynamic type of the reference
Hi all,
This patch improves RTL if-conversion on sequences that perform a conditional
select on integer constants.
Most of the smart logic to do that already exists in the
noce_try_store_flag_constants function.
However, currently that function is tried after noce_try_cmove.
noce_try_cmove is a
On Tue, Jul 28, 2015 at 12:26:35PM +0100, Alan Lawrence wrote:
> commit 214fcc00475a543a79ed444f9a64061215397cc8
> Author: Alan Lawrence
> Date: Wed Jan 28 13:01:31 2015 +
>
> AArch64 6/N: vcvt{,_high}_f32_f16 (using vect_par_cnst_hi_half, fixing
> bigendian indices)
>
> diff --git a/
I had the following conversation with richi about this patch.
Sorry to reply off thread, but i do net read this group in my mailer.
[09:00]zadeckrichi: i am reviewing a patch and i have a couple
of questions, do you have a second to look at something?
[09:00]richizadeck: sure
On 15/07/15 02:49 +0300, Ville Voutilainen wrote:
Tested on Linux-PPC64.
Committed to trunk with some whitespace changes.
On 25/07/15 22:01 +0300, Ville Voutilainen wrote:
Tested on Linux-PPC64.
The proposed resolution of the issue doesn't really say whether our
regression test for PR libstdc++/52931 should remain valid. However,
it doesn't say that we shouldn't keep it valid, either. This approach
keeps it valid,
On Tue, Jul 28, 2015 at 12:26:22PM +0100, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/arm_neon.h (vreinterpret_p8_f16, vreinterpret_p16_f16,
> vreinterpret_f16_f64, vreinterpret_f16_s8, vreinterpret_f16_s16,
> vreinterpret_f16_s32, vreinterpret_f16_s64, vreinterpre
On 07/29/15 05:22, Thomas Schwinge wrote:
Hi Nathan!
On Tue, 28 Jul 2015 12:52:02 -0400, Nathan Sidwell wrote:
I've committed this patch to the gomp4 branch to redo the launch API. I'll post
a version for trunk once the versioning patch gets approved & committed.
Thanks!
(I have not yet l
This removes folding of conditions in GIMPLE_CONDs using fold_binary
from fold_stmt. All cases appearing during bootstrap and regtest on
x86_64-unknown-linux-gnu are now handled by gimple_simplify and
match.pd patterns (remember this is just two bare operand cases).
I've verified this using the 2
This merges the recently introduced address comparison patterns
and makes them handle more cases in that process.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-07-29 Richard Biener
* match.pd: Merge address comparison patterns and make them
On Wed, Jul 29, 2015 at 1:59 PM, Mikael Morin wrote:
> Le 29/07/2015 13:22, Richard Biener a écrit :
>>
>> On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin
>> wrote:
>>>
>>> Le 29/07/2015 10:26, Richard Biener a écrit :
>>
>>
>> Did you try using vec_safe_splice?
Tha
On Wed, Jul 29, 2015 at 1:38 PM, Tom de Vries wrote:
> On 28/07/15 12:11, Richard Biener wrote:
>>
>> On Fri, Jul 24, 2015 at 12:10 PM, Tom de Vries
>> wrote:
>>>
>>> On 20/07/15 15:04, Tom de Vries wrote:
On 16/07/15 12:15, Richard Biener wrote:
>
>
> On Thu, Jul 16, 2
On Wed, Jul 29, 2015 at 1:22 PM, Tom de Vries wrote:
> On 29/07/15 10:09, Richard Biener wrote:
>>
>> On Tue, Jul 28, 2015 at 2:08 PM, Tom de Vries
>> wrote:
>>>
>>> On 28/07/15 09:59, Richard Biener wrote:
On Fri, Jul 24, 2015 at 4:39 PM, Tom de Vries
wrote:
>
>
Le 29/07/2015 13:22, Richard Biener a écrit :
On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin wrote:
Le 29/07/2015 10:26, Richard Biener a écrit :
Did you try using vec_safe_splice?
That handles NULL retargs, not NULL or empty arglist.
I think retargs is NULL.
Not if the patch fixes any
Attached patch rewrites GFC_DTYPE_SIZE_MASK definition to avoid "left
shift of negative value" warning. during ligfortran build.
2015-07-29 Uros Bizjak
PR libgfortran/66650
* libgfortran.h (GFC_DTYPE_SIZE_MASK): Rewrite to avoid
"left shift of negative value" warning.
Bootstrapped
On 28/07/15 12:11, Richard Biener wrote:
On Fri, Jul 24, 2015 at 12:10 PM, Tom de Vries wrote:
On 20/07/15 15:04, Tom de Vries wrote:
On 16/07/15 12:15, Richard Biener wrote:
On Thu, Jul 16, 2015 at 11:39 AM, Tom de Vries
wrote:
On 16/07/15 10:44, Richard Biener wrote:
On Wed, Jul 15,
On 29/07/15 10:09, Richard Biener wrote:
On Tue, Jul 28, 2015 at 2:08 PM, Tom de Vries wrote:
On 28/07/15 09:59, Richard Biener wrote:
On Fri, Jul 24, 2015 at 4:39 PM, Tom de Vries
wrote:
Hi,
this patch allows parallelization and vectorization of reduction
operators
that are guaranteed to
On Wed, Jul 29, 2015 at 11:34 AM, Mikael Morin wrote:
> Le 29/07/2015 10:26, Richard Biener a écrit :
Did you try using vec_safe_splice?
>>
>>
>> That handles NULL retargs, not NULL or empty arglist.
>>
> I think retargs is NULL.
Not if the patch fixes anything.
Richard.
On Wed, Jul 29, 2015 at 10:10:09AM +0100, Alan Lawrence wrote:
> James Greenhalgh wrote:
> > On Tue, Jul 28, 2015 at 12:26:09PM +0100, Alan Lawrence wrote:
> >> gcc/ChangeLog:
> >>
> >>* config/aarch64/aarch64-simd.md (aarch64_float_truncate_lo_v2sf):
> >>Reparameterize to...
> >>(aarch
This makes us error on
(simplify
(plus @0 integer_zerop)
@1)
rather than silently emitting "uninitialized" code. Likewise it
avoids crashing on
(simplify
(plus @0 @1)
(if (@2)
@0))
Bootstrap pending on x86_64-unknown-linux-gnu.
Richard.
2015-07-29 Richard Biener
* genmatch
On Wed, Jul 29, 2015 at 10:59:43AM +0100, Richard Earnshaw wrote:
> On 22/07/15 19:43, Martin Sebor wrote:
> > On 07/14/2015 09:18 AM, Marek Polacek wrote:
> >> Code such as "if (i == i)" is hardly ever desirable, so we should be able
> >> to warn about this to prevent dumb mistakes.
> >
> > I hav
Hi Prathamesh,
This is probably not appropriate for -Os optimisation.
And for speed optimisation I imagine it can vary a lot on the target the code
is run.
Do you have any benchmark results for this patch?
Thanks,
Kyrill
On 29/07/15 11:09, Prathamesh Kulkarni wrote:
Hi,
This patch tries to im
On Tue, Jul 28, 2015 at 12:25:40PM +0100, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.c (aarch64_vector_mode_supported_p): Support
> V4HFmode and V8HFmode.
> (aarch64_split_simd_move): Add case for V8HFmode.
> * config/aarch64/aarch64-builtins.c (v4hf
On 27/07/15 04:10, tbsaunde+...@tbsaunde.org wrote:
> From: Trevor Saunders
>
> Hi,
>
> $subject.
>
> patches individually bootstrapped + regtested on x86_64-linux-gnu, and run
> through config-list.mk with more patches removing usage of the macro. Ok?
>
> Trev
>
> Trevor Saunders (9):
> r
Hi,
This patch tries to implement division with multiplication by
reciprocal using vrecpe/vrecps
with -funsafe-math-optimizations and -freciprocal-math enabled.
Tested on arm-none-linux-gnueabihf using qemu.
OK for trunk ?
Thank you,
Prathamesh
2015-07-28 Prathamesh Kulkarni
Charles
On 22/07/15 19:43, Martin Sebor wrote:
> On 07/14/2015 09:18 AM, Marek Polacek wrote:
>> Code such as "if (i == i)" is hardly ever desirable, so we should be able
>> to warn about this to prevent dumb mistakes.
>
> I haven't tried the patch or even studied it very carefully but
> I wonder if this
On Tue, Jul 28, 2015 at 12:25:26PM +0100, Alan Lawrence wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/fp16/fp16.exp: New.
> * gcc.target/aarch64/fp16/f16_convs_1.c: New.
> * gcc.target/aarch64/fp16/f16_convs_2.c: New.
OK.
Thanks,
James
On Tue, Jul 28, 2015 at 12:25:06PM +0100, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-builtins.c (aarch64_fp16_type_node): New.
> (aarch64_init_builtins): Make aarch64_fp16_type_node, use for __fp16.
>
> * config/aarch64/aarch64-modes.def: Add HFmode.
>
>
Le 29/07/2015 10:26, Richard Biener a écrit :
Did you try using vec_safe_splice?
That handles NULL retargs, not NULL or empty arglist.
I think retargs is NULL.
Hi Nathan!
On Tue, 28 Jul 2015 12:52:02 -0400, Nathan Sidwell wrote:
> I've committed this patch to the gomp4 branch to redo the launch API. I'll
> post
> a version for trunk once the versioning patch gets approved & committed.
Thanks!
(I have not yet looked at the patch in detail.) There
On Tue, Jul 28, 2015 at 7:57 PM, Abe wrote:
> [Richard wrote:]
>>
>> Note the store to *pointer can be done unconditionally
>
>
> Yes; if I`m mapping things correctly in my mind, this is
> something that Sebastian [and Alan, via email?] and I have
> already discussed and which we plan to fix in go
1 - 100 of 117 matches
Mail list logo
