Hi,
Sorry to bother people again. Is this OK to go now?
Thanks!
David.
> >
> > > On Mon, 29 Jun 2015, David Sherwood wrote:
> > >
> > > > Hi,
> > > >
> > > > I have added new STRICT_MAX_EXPR and STRICT_MIN_EXPR expressions to
> > > > support the
> > > > IEEE versions of fmin and fmax. This is d
This avoids regressions when removing the remaining dispatching to
fold () from fold_stmt. First, when a valueization is rejected by
stmt replacement (for example when propagating an abnormal, where
the patch improves some cases here as well) then we fail to do
operand order canonicalization on t
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 regressions in gcc testsuite
x86_64 - bootstrap bui
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 not overflow
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 have a new target_globals structure that is
>> >> initialised with the resul
On Tue, Jul 28, 2015 at 3:19 PM, Steve Kargl
wrote:
> On Tue, Jul 28, 2015 at 03:04:52PM +0200, Mikael Morin wrote:
>> Le 21/07/2015 21:08, Steve Kargl a ?crit :
>> > When C++ was injected into trans-expr.c in the form of vec,
>> > it seems whomever did the conversion to vec forgot to check
>> > f
Hello,
> This patch enables inline memcpy for R6 which was previously disabled and
> adds support for expansion when source and destination are at least half-word
> aligned.
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00749.html
Thanks,
Simon
On 28/07/15 16:19 +0100, Jonathan Wakely wrote:
What I'm concerned about is assignment. You haven't defined an
assignment operator. If there's an unwanted assignment we could get
undefined behaviour. Please delete the assignment operator if it's not
needed.
Apologies, you have a user-declared m
On 28/07/15 21:44 -0700, Tim Shen wrote:
On Tue, Jul 28, 2015 at 3:27 AM, Jonathan Wakely wrote:
On 27/07/15 19:40 -0700, Tim Shen wrote:
Done by s/_M_add_collating_element/_M_add_collate_element/.
Great, thanks. OK for trunk and gcc-5-branch.
Committed. Is there no need for gcc-4_9-bran
Andrew Pinski writes:
> On Tue, Jul 28, 2015 at 3:10 PM, Richard Sandiford
> wrote:
>> Andrew Pinski writes:
>>> On Tue, Jul 28, 2015 at 1:36 PM, Richard Sandiford
>>> wrote:
Bootstrapped & regression-tested on x86_64-linux-gnu and aarch64-linux-gnu.
Also tested via config-list.mk. C
On Wed, Jul 29, 2015 at 1:32 AM, Jonathan Wakely wrote:
> Apologies, you have a user-declared move constructor, so assignment is
> already deleted. It wouldn't hurt to make that explicit though:
I'm just bad at memorizing when they are implicitly
declared/defined/deleted and fully unware of the d
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...
> (aarch64_float_truncate_lo_): ...this, for both V2SF and V4HF.
> (aarch64_float_truncate_hi_v4sf):
On Wed, Jul 29, 2015 at 1:35 AM, Jonathan Wakely wrote:
> The 4.9 branch is the oldest one we still support, so should be very
> stable now, although C++11 support in 4.9 is still labelled
> experimental, and this only changes C++11 code. How important is it to
> fix?
Um... I'd say medium importa
On Tue, Jul 28, 2015 at 12:25:55PM +0100, Alan Lawrence wrote:
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.c (aarch64_split_simd_combine): Add V4HFmode.
> * config/aarch64/aarch64-builtins.c (VAR13, VAR14): New.
> (aarch64_scalar_builtin_types, aarch64_init_simd_builtin_scalar_
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...
(aarch64_float_truncate_lo_): ...this, for both V2SF and V4HF.
(aarch64_f
On 29/07/15 01:56 -0700, Tim Shen wrote:
If 4.9 is `stable` and expected to be experimetal, which by my
definition should only include important changes, we may leave it as
is?
Yes, let's not change the 4.9 version.
On 29/07/15 01:43 -0700, Tim Shen wrote:
On Wed, Jul 29, 2015 at 1:32 AM, Jonathan Wakely wrote:
Apologies, you have a user-declared move constructor, so assignment is
already deleted. It wouldn't hurt to make that explicit though:
I'm just bad at memorizing when they are implicitly
declared/
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
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
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.
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.
>
>
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 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
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 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
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
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 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
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: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
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 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 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,
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
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
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 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: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
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
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
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
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 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 15/07/15 02:49 +0300, Ville Voutilainen wrote:
Tested on Linux-PPC64.
Committed to trunk with some whitespace changes.
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 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/
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
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
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
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
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
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
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
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: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.
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
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
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
> 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
> 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
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
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
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-
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
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 :
>
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 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:
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 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,
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.
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
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/
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
* 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 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
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 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
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 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 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 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
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
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.
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/
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
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 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 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
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 -
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
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
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
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
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
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
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:
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 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
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 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)
> >
1 - 100 of 117 matches
Mail list logo
