Please commit if it is OK for trunk.
Thanks,
Nikolai
On 10/22/2015 06:38 PM, Nikolai Bozhenov wrote:
Hi!
Currently -fsched-verbose option redirects debugging dumps to stderr
if there is no dump_file for the current pass. It would be fine if
there were the only scheduling pass. But for example
Hi!
The attached patch adds a procedure to dump the scheduler's dependency
graph into a dot file. The patch has been bootstrapped and regtested
on x86_64. Please commit if it is OK for trunk.
Thanks,
Nikolai
2015-11-04 Nikolai Bozhenov
* sched-int.h (dump_rgn_dependencies_dot): Declare
* s
Hi Nikolai,
On 05/11/15 08:29, Nikolai Bozhenov wrote:
Hi!
The attached patch adds a procedure to dump the scheduler's dependency
graph into a dot file. The patch has been bootstrapped and regtested
on x86_64. Please commit if it is OK for trunk.
Thanks,
Nikolai
A couple of style nits.
+
On 11/04/2015 05:17 PM, Andreas Arnez wrote:
gcc/c/ChangeLog:
PR debug/67192
* c-parser.c (c_parser_while_statement): Finish the loop before
parsing ahead for misleading indentation.
(c_parser_for_statement): Likewise.
This is OK. Does C++ have similar issues?
On Wed, Nov 04, 2015 at 05:21:03PM -0600, Evandro Menezes wrote:
> Please, ignore the previous patch. This is the intended patch.
>
> Sorry.
>
> --
> Evandro Menezes
>
> On 11/04/2015 05:18 PM, Evandro Menezes wrote:
> >This patch adds extra tuning information about AArch64 targets:
> >
> > *
On 11/05/2015 09:11 AM, Nikolai Bozhenov wrote:
Please commit if it is OK for trunk.
Hmm, do you have a copyright assignment on file?
Bernd
Hi all,
This cleanup patch removes handling of CONST_DOUBLE rtxes that carry large
integers.
These should never be passed down from the midend and the arm backend doesn't
create them.
The code has been there since 2007 but the arm backend was moved to
TARGET_SUPPORTS_WIDE_INT
in 2014, so this
On Wed, Nov 04, 2015 at 02:26:31PM +, Ramana Radhakrishnan wrote:
>
>
> On 03/11/15 17:09, James Greenhalgh wrote:
> > On Tue, Nov 03, 2015 at 04:36:45PM +, Ramana Radhakrishnan wrote:
> >> Hi,
> >>
> >>Now that PR63304 is fixed and we have an option to address
> >> any part of the me
Is there any objection to commit the following (see comments 21 and 22)?
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 229793)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the need to postpone splitting off the k
On 11/05/2015 12:26 PM, Bernd Schmidt wrote:
On 11/05/2015 09:11 AM, Nikolai Bozhenov wrote:
Please commit if it is OK for trunk.
Hmm, do you have a copyright assignment on file?
Yes I do have a copyright assignment for all past and future changes
to GCC (RT:828836).
Thanks,
Nikolai
On 11/04/2015 01:54 PM, Julian Brown wrote:
That's not all targets by any means, but may be enough to warrant a
change in the interface. I propose that:
* The output_address function should have a machine_mode argument
added. Bare addresses (e.g. the 'a' case in final.c) should pass
"VOIDm
On 11/05/2015 12:18 PM, Kyrill Tkachov wrote:
Hi Nikolai,
On 05/11/15 08:29, Nikolai Bozhenov wrote:
Hi!
The attached patch adds a procedure to dump the scheduler's dependency
graph into a dot file. The patch has been bootstrapped and regtested
on x86_64. Please commit if it is OK for trunk.
Hi!
This patch updates the mapping of vars to what has been ratified
in OpenMP 4.5, or where left unspecified, hopefully follows the
discussed intent.
In particular:
1) for C++ references we map what they refer to, and on target
construct privatize the references themselves (but not what
th
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On 11/02/2015 11:29 PM, Anatoly Sokolov wrote:
@@ -5522,12 +5516,7 @@
op0 = SUBREG_REG (op0);
code0 = GET_CODE (op0);
if (code0 == REG && REGNO (op0) < FIRST_PSEUDO_REGISTER)
- op0 = gen_rtx_REG (word_mode,
- (REGNO (op0) +
-
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 approach made moving unaligned pointers
possible. It also ma
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On Thu, 5 Nov 2015, Joseph Myers wrote:
> On Wed, 4 Nov 2015, Martin Sebor wrote:
>
> > Improving the compiler output is a good idea. The attached patch
> > prints "[disabled by -O0]" instead of "[enabled]" when an optimization
> > option is enabled by default but when optimization (i.e., -O1 or
>
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
Hi,
> It seems this code has moved to fold-const.c, so the patch will need
> updating.
I have updated the patch and sending again.
> Now, is it actually correct for integer_valued_real_single_p (now) to
> treat sNaN as an integer? Looking at existing uses, they all appear to be
> in match.pd: i
On 05/11/15 11:16, Tom de Vries wrote:
Hi,
now that we have committed -foffload-alias in gomp-4_0-branch (
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00214.html ), we no longer
need the kernels region to be a part of the original function when doing
alias analysis.
So, we no longer have the
On Wed, Nov 4, 2015 at 6:29 PM, Nathan Sidwell wrote:
> On 11/04/15 05:26, Richard Biener wrote:
>>
>> On Tue, Nov 3, 2015 at 7:11 PM, Nathan Sidwell wrote:
>>>
>>> Richard,
>
>
>> this all seems a little bit fragile and relying on implementation details?
>> Is the attribute always present? Is t
On Thu, Nov 05 2015, Bernd Schmidt wrote:
> On 11/04/2015 05:17 PM, Andreas Arnez wrote:
>>
>> gcc/c/ChangeLog:
>>
>> PR debug/67192
>> * c-parser.c (c_parser_while_statement): Finish the loop before
>> parsing ahead for misleading indentation.
>> (c_parser_for_statement): Like
On 11/05/2015 12:33 PM, Andreas Arnez wrote:
Thanks again for reviewing. Are you going to look at patch #2 as well?
Yeah, still thinking about that one.
Does C++ have similar issues?
Not this particular issue, AFAIK. But I've just looked at how C++ fares
with the enhanced version of pr67
Hi Segher,
On 04/11/15 23:50, Segher Boessenkool wrote:
Hi Kyrill,
On Mon, Nov 02, 2015 at 02:15:27PM +, Kyrill Tkachov wrote:
This patch attempts to restrict combine from transforming ZERO_EXTEND and
SIGN_EXTEND operations into and-bitmask
and weird SUBREG expressions when they appear ins
Hi Cesar!
On Tue, 3 Nov 2015 14:16:59 -0800, Cesar Philippidis
wrote:
> This patch does the following to the c and c++ front ends:
> * updates c_oacc_split_loop_clauses to filter out the loop clauses
>from combined parallel/kernels loops
> gcc/c-family/
> * c-omp.c (c_oacc_spl
On 29 Oct 15:29, Richard Biener wrote:
>
> I think this should unconditionally produce the COND_EXPR and
> build cst_true using build_all_ones_cst (stype).
>
> Ok with that change.
>
> Thanks,
> Richard.
>
Here is an updated patch version. Bootstrapped and regtested on
powerpc64le-unknown-li
libgcc/config/arm/linux-atomic-64bit.c uses __write to print an error
message if the 64bit xchg method is not available in the kernel.
__write is not part of the public libc abi. Since this code is only
run on linux the write syscall can be invoked directly.
And __builtin_trap is a simpler way
On Thu, Nov 5, 2015 at 12:45 AM, Mike Stump wrote:
>
> On Nov 4, 2015, at 12:50 PM, Richard Sandiford
> wrote:
>
>> Mike Stump writes:
>>> Index: dwarf2out.c
>>> ===
>>> --- dwarf2out.c (revision 229720)
>>> +++ dwarf2out.c
On 30/10/15 10:54, Eric Botcazou wrote:
> On 30/10/15 10:44, Richard Biener wrote:
>>
>> I think you want to use wide-ints here and
>>
>> wide_int idx = wi::from (minidx, TYPE_PRECISION (TYPE_DOMAIN
>> (...)), TYPE_SIGN (TYPE_DOMAIN (..)));
>> wide_int maxidx = ...
>>
>> you can then simply
On 3 November 2015 at 11:35, Richard Biener wrote:
>
> I think this should simply re-write A << B to (type) (unsigned-type) A
> * (1U << B).
>
> Does that then still vectorize the signed case?
I didn't realize our representation of chrec's could express that.
Yes, it does - thanks! (And the avx51
On 03/11/15 13:39, Richard Biener wrote:
> On Tue, Oct 27, 2015 at 6:38 PM, Alan Lawrence wrote:
>>
>> Say I...P are consecutive, the input would have gaps 0 1 1 1 1 1 1 1. If we
>> split the load group, we would want subgroups with gaps 0 1 1 1 and 0 1 1 1?
>
> As said on IRC it should be 4 1 1 1
Hi,
On Wed, 4 Nov 2015, Richard Biener wrote:
> Ah, it was _left_ shift of negative values that ubsan complains about.
Note that this is only for the frontend definition of shifts. I don't see
why gimple shouldn't define it to the only sensible definition there is,
which also happens to be th
On Thu, Nov 5, 2015 at 6:08 AM, Alexandre Oliva wrote:
> On Sep 23, 2015, Alexandre Oliva wrote:
>
>> @@ -2982,38 +2887,39 @@ assign_parm_setup_block (struct assign_parm_data_all
>> *all,
> [snip]
>> + if (GET_CODE (reg) != CONCAT)
>> +stack_parm = reg;
>> + else
>> +/*
On Wed, Nov 4, 2015 at 5:50 PM, Jan Hubicka wrote:
>> > Are these supposed to be fixed by Richard's change to not use
>> > useless_type_conversion for VCE, or is it another issue?
>>
>> Richard's change not to use useless_type_conversion for VCE was causing
>> additional GIMPLE verification failur
Hi all,
attached is a rather trivial patch to prevent multiple evaluations of a
function in:
allocate( array(func()) )
The patch tests whether the upper bound of the array is a function
and calls gfc_evaluate_now().
Bootstrapped and regtested for x86_64-linux-gnu/f21.
Ok for trunk?
Regards,
Hi,
this patch reverts omp_data_i init handling in copy_prop.
Committed to gomp-4_0-branch.
Thanks,
- Tom
Revert omp_data_i init handling in copy_prop
2015-11-05 Tom de Vries
revert:
2015-04-21 Tom de Vries
* tree-ssa-copy.c (stmt_may_generate_copy): Handle .omp_data_i init
conserv
On 11/05/2015 04:14 AM, Thomas Schwinge wrote:
> On Tue, 3 Nov 2015 14:16:59 -0800, Cesar Philippidis
> wrote:
>> This patch does the following to the c and c++ front ends:
>
>> * updates c_oacc_split_loop_clauses to filter out the loop clauses
>>from combined parallel/kernels loops
>
>>
Hi,
this patch:
- removes a superfluous test on gimple_stmt_omp_data_i_init_p in
tree-parloops.c
- removes unused functions gimple_stmt_omp_data_i_init_p and
get_omp_data_i.
Committed to gomp-4_0-branch.
Thanks,
- Tom
Remove gimple_stmt_omp_data_i_init_p
2015-11-05 Tom de Vries
* omp-
Hi,
this patch removes a number of unused function related to the oacc
kernels region.
Committed to gomp-4_0-branch.
Thanks,
- Tom
Remove misc oacc kernels functions
2015-11-05 Tom de Vries
* omp-low.c (get_bbs_in_oacc_kernels_region):
(loop_get_oacc_kernels_region_entry, get_oacc_kern
Hi,
This patch reverts the omp_data_i init handling in ccp and forwprop.
Committed to gomp-4_0-branch.
Thanks,
- Tom
Revert omp_data_i init handling in ccp and forwprop
2015-11-05 Tom de Vries
Revert:
2015-04-21 Tom de Vries
* tree-ssa-ccp.c: Include omp-low.h.
(surely_varying_stmt
Marcus Shawcroft writes:
+#ifdef HAVE_AS_TINY_TLSGD_RELOCS
+ return SYMBOL_TINY_TLSGD;
+#else
+ return SYMBOL_SMALL_TLSGD;
+#endif
Rather than introduce blocks of conditional compilation it is better
to gate different behaviours with a test on a constant expression. In
this case add something
On 11/04/2015 11:29 PM, Jakub Jelinek wrote:
> On Wed, Nov 04, 2015 at 08:58:32PM -0800, Cesar Philippidis wrote:
>> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
>> index e3f55a7..4424596 100644
>> --- a/gcc/cp/pt.c
>> +++ b/gcc/cp/pt.c
>> @@ -14395,6 +14395,15 @@ tsubst_omp_clauses (tree clauses, bool
On 11/04/2015 09:27 PM, Jason Merrill wrote:
On 11/04/2015 07:15 PM, Martin Sebor wrote:
There was a lot of discussion of C++ aliasing rules at the recent
meeting; we really seem to be moving in the direction of being stricter
about which union member is active. So I think we do want to diagnos
It was overloading equal_keys and not keys and thus the hash table
lookup used equal from the inerited pointer_hash ... (so pointer
equality rather than operand_equal_p as desired).
This makes hash_map work as intented.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2015-11-
On Thu, Nov 5, 2015 at 2:26 PM, Alan Lawrence wrote:
> On 3 November 2015 at 11:35, Richard Biener
> wrote:
>>
>> I think this should simply re-write A << B to (type) (unsigned-type) A
>> * (1U << B).
>>
>> Does that then still vectorize the signed case?
>
> I didn't realize our representation o
On Wed, Nov 4, 2015 at 3:20 AM, Jonathan Wakely wrote:
> On 4 November 2015 at 02:11, Daniel Gutson wrote:
>> Since this is a nothrow new, we thought that probably the system
>> might not be exceptions-friendly (such as certain embedded systems),
>> so we wanted to provide the new_handler the abil
On 11/05/2015 10:12 AM, Martin Sebor wrote:
On 11/04/2015 09:27 PM, Jason Merrill wrote:
On 11/04/2015 07:15 PM, Martin Sebor wrote:
There was a lot of discussion of C++ aliasing rules at the recent
meeting; we really seem to be moving in the direction of being stricter
about which union member
On Thu, Nov 05 2015, Bernd Schmidt wrote:
> On 11/05/2015 12:33 PM, Andreas Arnez wrote:
>
>> Thanks again for reviewing. Are you going to look at patch #2 as well?
>
> Yeah, still thinking about that one.
>
>>> Does C++ have similar issues?
>>
>> Not this particular issue, AFAIK. But I've just
On 11/05/15 10:29, Jakub Jelinek wrote:
Hi!
I've merged the current state of gomp-4_5-branch into trunk, after
bootstrapping/regtesting it on x86_64-linux and i686-linux.
There are
+FAIL: gfortran.dg/goacc/private-3.f95 -O (test for excess errors)
+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-
Hi,
pinging this (admittedly minor) issue...
On 10/26/2015 07:10 PM, Paolo Carlini wrote:
Hi,
in mainline this ICE on invalid doesn't exist anymore but we may want
to avoid issuing the additional redundant "error: cannot convert
‘A::foo’ from type ‘void (A::)()’ to type ‘void (A::*)()’" and/
Hi All!
I prepared another patch which performs insertion additional check on
zero mask for masked stores if only parameter
PARAM_ZERO_TEST_FOR_MASK_STORE has non-zero value. My attempt to use
approach proposed by Richard with simpler alternative for comparison -
use scalar type for 256-bit was no
On 11/04/15 05:02, Bernd Schmidt wrote:
On 11/02/2015 02:56 PM, Nathan Sidwell wrote:
On 10/28/15 14:40, Nathan Sidwell wrote:
Richard,
this patch adds folding for the new GOACC_DIM_POS and GOACC_DIM_SIZE
internal
functions. IIUC gimple_fold_call is the right place to add this.
The size of a
On 11/05/2015 03:48 AM, Alexander Monakov wrote:
On Thu, 5 Nov 2015, Joseph Myers wrote:
On Wed, 4 Nov 2015, Martin Sebor wrote:
Improving the compiler output is a good idea. The attached patch
prints "[disabled by -O0]" instead of "[enabled]" when an optimization
option is enabled by default
On 05/11/15 12:30, Szabolcs Nagy wrote:
> libgcc/config/arm/linux-atomic-64bit.c uses __write to print an error
> message if the 64bit xchg method is not available in the kernel.
>
> __write is not part of the public libc abi. Since this code is only
> run on linux the write syscall can be invoke
2015-10-27 23:52 GMT+03:00 Jeff Law :
>
> Sigh. I searched for the enum type, not for CODE_FOR_nothing ;( My bad.
>
> If it's easy to get rid of, yes. I believe we've got 3 uses of
> CODE_FOR_nothing. AFAICT in none of those cases do we care about the code
> other than does it correspond to COD
Hi,
This patch fixes a way vectype is computed in vectorizable_operation.
Currently op0 is always used to compute vectype. If it is a loop invariant
then its type is used to get vectype which is impossible for booleans requiring
a context to correctly compute vectype. This patch uses output
On 05/11/15 15:59, Richard Earnshaw wrote:
On 05/11/15 12:30, Szabolcs Nagy wrote:
libgcc/config/arm/linux-atomic-64bit.c uses __write to print an error
message if the 64bit xchg method is not available in the kernel.
__write is not part of the public libc abi. Since this code is only
run on l
[Explicitly copying build maintainers.]
Paolo and Alexandre,
Could you review and help with this patch?
TLS symbols in AIX display a new, different symbol type in nm output.
Libtool explicitly creates a list of exported symbols for shared
libraries using nm and does not recognize the new TLS sym
Hi!
On Wed, Nov 04, 2015 at 09:55:49AM -0800, Cesar Philippidis wrote:
So, you are going to deal with gang parsing incrementally?
Fine with me.
> +/* OpenACC 2.0:
> + tile ( size-expr-list ) */
> +
> +static tree
> +c_parser_oacc_clause_tile (c_parser *parser, tree list)
> +{
> + tree c, expr
On 05/11/2015 17:28, David Edelsohn wrote:
> [Explicitly copying build maintainers.]
>
> Paolo and Alexandre,
>
> Could you review and help with this patch?
>
> TLS symbols in AIX display a new, different symbol type in nm output.
> Libtool explicitly creates a list of exported symbols for sha
On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini wrote:
>
>
> On 05/11/2015 17:28, David Edelsohn wrote:
>> [Explicitly copying build maintainers.]
>>
>> Paolo and Alexandre,
>>
>> Could you review and help with this patch?
>>
>> TLS symbols in AIX display a new, different symbol type in nm output.
>
If we use gcc_checking_assert it won't fire in release builds; let's go
with that.
Okay. Attached is an updated patch with that change.
Martin
gcc ChangeLog
2015-11-05 Martin Sebor
PR c++/67942
* invoke.texi (-Wplacement-new): Document new option.
* gcc/testsuite/g++.dg/warn/Wpla
On Thu, 5 Nov 2015, Sujoy Saraswati wrote:
> > Some other places in this patch have similar issues with checking
> > HONOR_SNANS && REAL_VALUE_ISNAN when they should check if the particular
> > value is sNaN.
>
> I modified the code to check for sNaN specifically. The modified patch
> is below.
Hi!
Nathan, question here about clause splitting for combined OpenACC
"parallel loop" and "kernels loop" constructs, in particular:
#pragma acc parallel loop reduction([...])
On Thu, 5 Nov 2015 06:47:58 -0800, Cesar Philippidis
wrote:
> On 11/05/2015 04:14 AM, Thomas Schwinge wrote:
>
> >
On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
> I don't think that reiterating in a condensed form what the manual
> doesn't make clear in many more words will help. First, even users
> who do find the relevant text in the manual often misunderstand it.
> Others are misled by the "[
On 5 November 2015 at 20:52, Daniel Gutson wrote:
> Real use cases: statistics and logging. It's a (one time) callback
> reporting that something went wrong,
> but not intended to fix things e.g. by attempting to free more memory.
Why can't that be done by replacing operator new with a user-define
On Thu, 5 Nov 2015, Martin Sebor wrote:
> optimiziation. We seem to have consensus that even though there
> might be exceptions (do we know what some of them are?) the vast
> majority optimizations that have -fxxx options are in fact not
> performed at -O0. I think reflecting that in the output is
On 11/05/15 12:01, Thomas Schwinge wrote:
On Thu, 5 Nov 2015 06:47:58 -0800, Cesar Philippidis
wrote:
On 11/05/2015 04:14 AM, Thomas Schwinge wrote:
Sorry, I must have mis-phrased it. The spec is unclear here. There are
three possible ways to interpret 'acc parallel loop reduction':
1.
On November 5, 2015 5:38:45 PM GMT+01:00, David Edelsohn
wrote:
>On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini wrote:
>>
>>
>> On 05/11/2015 17:28, David Edelsohn wrote:
>>> [Explicitly copying build maintainers.]
>>>
>>> Paolo and Alexandre,
>>>
>>> Could you review and help with this patch?
>>
Hi, Richi
You mentioned GCC 5.3 release around the time of stage 1 ending in the
GCC 5 status report:
https://gcc.gnu.org/ml/gcc/2015-07/msg00197.html
If the timeframe is later, we have more time to address the AIX libtool problem.
Thanks, David
On Thu, Nov 5, 2015 at 9:13 AM, Richard Biener
On November 5, 2015 2:40:30 PM GMT+01:00, Michael Matz wrote:
>Hi,
>
>On Wed, 4 Nov 2015, Richard Biener wrote:
>
>> Ah, it was _left_ shift of negative values that ubsan complains
>about.
>
>Note that this is only for the frontend definition of shifts. I don't
>see
>why gimple shouldn't define
On 05/11/2015 17:38, David Edelsohn wrote:
> On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini wrote:
>>
>>
>> On 05/11/2015 17:28, David Edelsohn wrote:
>>> [Explicitly copying build maintainers.]
>>>
>>> Paolo and Alexandre,
>>>
>>> Could you review and help with this patch?
>>>
>>> TLS symbols in
On 11/05/2015 09:13 AM, Nathan Sidwell wrote:
> On 11/05/15 12:01, Thomas Schwinge wrote:
>
>> On Thu, 5 Nov 2015 06:47:58 -0800, Cesar Philippidis
>> wrote:
>>> On 11/05/2015 04:14 AM, Thomas Schwinge wrote:
>
>>> Sorry, I must have mis-phrased it. The spec is unclear here. There are
>>> three
This fixes an error-recovery problem, where we were trying to build
a C_MAYBE_CONST_EXPR even though the type is invalid. I think let's
just skip this for error_mark_nodes.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-11-05 Marek Polacek
PR c/68090
* c-parser.c
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 integers as you requested:
[AArch64] Add extra tuning parameters for targ
On 11/05/2015 10:10 AM, Joseph Myers wrote:
On Thu, 5 Nov 2015, Martin Sebor wrote:
optimiziation. We seem to have consensus that even though there
might be exceptions (do we know what some of them are?) the vast
majority optimizations that have -fxxx options are in fact not
performed at -O0. I
On Thu, Nov 5, 2015 at 2:11 PM, Jonathan Wakely wrote:
> On 5 November 2015 at 20:52, Daniel Gutson wrote:
>> Real use cases: statistics and logging. It's a (one time) callback
>> reporting that something went wrong,
>> but not intended to fix things e.g. by attempting to free more memory.
>
> Why
On Thu, 5 Nov 2015, Marek Polacek wrote:
> This fixes an error-recovery problem, where we were trying to build
> a C_MAYBE_CONST_EXPR even though the type is invalid. I think let's
> just skip this for error_mark_nodes.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
--
Joseph S
Hi!
Committed to gomp-4_0-branch in r229821:
commit bed2efe185cf13a52b9cf87ee52d74265f97d97b
Merge: bb6471e bf3a27b
Author: tschwinge
Date: Thu Nov 5 18:02:08 2015 +
svn merge -r 229562:229764 svn+ssh://gcc.gnu.org/svn/gcc/trunk
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/
On Thu, 5 Nov 2015, Martin Sebor wrote:
> > There are several options marked Optimization that are actually matters of
> > language semantics that I don't think have anything to do with -O options,
> > e.g. -fexceptions and -fcx-limited-range. The Optimization tag really
> > just means that it's
OK, thanks.
Jason
On 11/05/2015 11:07 AM, Joseph Myers wrote:
On Thu, 5 Nov 2015, Martin Sebor wrote:
There are several options marked Optimization that are actually matters of
language semantics that I don't think have anything to do with -O options,
e.g. -fexceptions and -fcx-limited-range. The Optimization t
On Thu, 5 Nov 2015, Martin Sebor wrote:
> Yes, I agree that printing "disabled by -O0" when -fexceptions is
> explicitly enabled on the command line is not right if the option
> isn't actually affected by -O0. This would be prevented if we knew
> which of the -fxxx options are or aren't controlled
On 3 November 2015 at 14:01, Richard Biener wrote:
>
> Hum. I still wonder why we need all this complication ...
Well, certainly I'd love to make it simpler, and if the complication
is because I've gone about trying to deal with especially Ada in the
wrong way...
> I would
> expect that if
> w
On 11/02/2015 09:55 PM, Jason Merrill wrote:
On 10/26/2015 10:06 PM, Martin Sebor wrote:
+ if (TREE_CONSTANT (maybe_constant_value (outer_nelts)))
+{
+ if (tree_int_cst_lt (max_outer_nelts_tree, outer_nelts))
maybe_constant_value may return a constant, but that doesn't mean that
2015-11-05 Evandro Menezes
gcc/
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Increase loop peeling limit.
This patch increases the limit for the number of peeled insns. With
this change, I noticed no major regression in either Geekbench v3 or
SPEC CPU
On 11/05/2015 10:09 AM, Segher Boessenkool wrote:
On Thu, Nov 05, 2015 at 08:58:25AM -0700, Martin Sebor wrote:
I don't think that reiterating in a condensed form what the manual
doesn't make clear in many more words will help. First, even users
who do find the relevant text in the manual often
* graphite-optimize-isl.c (optimize_isl): Call
isl_options_set_schedule_maximize_band_depth.
* gcc.dg/graphite/fuse-1.c: New.
* gcc.dg/graphite/fuse-2.c: New.
* gcc.dg/graphite/interchange-13.c: Remove bogus check.
---
gcc/graphite-optimize-isl.c
Hi,
we have had a few last-minute issues, so I apologize this is happening
a bit late, but I would like to start the process or merging the HSA
branch to GCC trunk. Changes to different parts of the compiler and
libgomp are posted as individual emails in this thread. No two
patches touch any sin
Hi,
this patch contains changes to the configuration mechanism and offload
bits, so that users can build compilers with HSA support and it plays
nicely with other accelerators despite using an altogether different
implementation approach.
With this patch, the user can request HSA support by inclu
Hi,
The patch below contains all changes to libgomp files. First, it adds
a new constant identifying HSA devices and a structure that is shared
between libgomp and the compiler when kernels from kernels are invoked
via dynamic parallelism.
Second it modifies the GOMP_target_41 function so that i
Hi,
the patch below adds the HSA-specific plugin for libgomp. The plugin
implements the interface mandated by libgomp and takes care of finding
any available HSA devices, finalizing HSAIL code and running it on
HSA-capable GPUs. The plugin does not really implement any data
movement functions (i
Hi,
the patch in this email contains the changes to make our OpenMP
lowering and expansion machinery produce GPU kernels for a certain
limited class of loops. The plan is to make that class quite a big
bigger, but only the following is ready for submission now.
Basically, whenever the compiler c
1 - 100 of 136 matches
Mail list logo
