On November 16, 2014 8:15:37 AM CET, Jan Hubicka wrote:
>Hi,
>late in GCC 4.9 development we broke the feature that ltrans stages do
>not read all
>functions in ahead. This is because of late IPA passes that do not
>like to see functions
>without IPA transformations applied. I was originally OK
Hi,
late in GCC 4.9 development we broke the feature that ltrans stages do not read
all
functions in ahead. This is because of late IPA passes that do not like to see
functions
without IPA transformations applied. I was originally OK with the solution
based
on fact that we have only IPA-PTA as
On 11/15/2014 11:59 PM, Jason Merrill wrote:
This handles some more C++14 testcases and has no regressions on C++11
constexpr testcases. Support for jumps will follow soon.
Like this, though it still needs a bit of cleaning up.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 53cfb1
The following patch fixes a x86 bootstrap failure with different sets
of options (-with-arch=corei7 -with-cpu=intel, -with-arch=core2
-with-cpu=slm).
The patch was bootstrapped on x86 (with the 2 sets) and x86-64.
Committed as rev. 217624.
2014-11-15 Vladimir Makarov
* lra-r
I've had a TODO in genericize_cp_loop for a long time suggesting that we
should genericize to LOOP_EXPR rather than gotos, and now that I need to
interpret the function body for constexpr evaluation, making this change
will also simplify that handling.
This change also does away with canonical
This patch implements more support for C++14 constexpr: it allows
arbitrary modification of variables in a constexpr function, but does
not currently handle jumping -- multiple returns, loops, switches.
The approach I took for this was to just use the DECL_SAVED_TREE for a
constexpr function a
On Wed, Nov 12, 2014 at 3:38 AM, Richard Biener
wrote:
> On Wed, Nov 12, 2014 at 5:17 AM, Patrick Palka wrote:
>> On Tue, Nov 11, 2014 at 8:48 AM, Richard Biener
>> wrote:
>>> On Tue, Nov 11, 2014 at 1:10 PM, Patrick Palka wrote:
This patch is a replacement for the 2nd VRP refactoring patc
On 9/15/2014 2:51 PM, Jeff Law wrote:
Let's go with your original inputs + outputs + labels change and punt
the clobbers stuff for now.
jeff
I have also added the test code you requested.
I have a release on file with the FSF, but don't have SVN write access.
Problem:
extract_insn() in reco
On 11/15/2014 07:58 PM, Braden Obrzut wrote:
Variable templates (and thus concepts) are TEMPLATE_ID_EXPR. I changed
the comment to explicitly state that it will be a TEMPLATE_ID_EXPR, but
I'm not sure the name needs to be changed. If I recall correctly, I
initially implemented as *_var_concept
On Sat, 15 Nov 2014, Patrick Palka wrote:
Currently the top-level driver handles SIGINT by immediately killing
itself even when the driver has subprocesses (e.g. cc1, as) running. I
don't think this is a good idea because
1. if the top-level driver is waiting on a hanging subprocess,
pressin
On Sat, Nov 15, 2014 at 8:01 AM, Janne Blomqvist
wrote:
> On Fri, Nov 14, 2014 at 11:02 PM, Tobias Burnus wrote:
>> I think instead of doing a run-time check I'd prefer something like the
>> following, keeping the compile-time assert.
>>
>> --- a/libgfortran/intrinsics/random.c
>> +++ b/libgfortr
On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote:
Hi,
On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka wrote:
Yep, it is because my code does not handle streaming of arrays
into the target optimization nodes. I will take a look on why
that array is really needed. It seems like a overkill?
I am
Currently the top-level driver handles SIGINT by immediately killing
itself even when the driver has subprocesses (e.g. cc1, as) running. I
don't think this is a good idea because
1. if the top-level driver is waiting on a hanging subprocess,
pressing ^C will kill the driver but it may not ne
I don't believe I'll be able to familiarize myself adequately with the
more complex issues before the stage 1 deadline (from what I understand
Andrew is/was taking care of the blocking issues?), so I will leave what
I have for the more trivial issues and a few comments.
On 11/11/2014 12:05 PM,
On Thursday 2014-11-13 17:59, Thomas Schwinge wrote:
> Here is our current set of OpenACC middle end changes. As discussed
> before, this is not yet all of OpenACC 2.0 -- we shall a) document what
> is working already, and b) continue to work on closing the gap.
As David wrote in a different cont
Hi,
this patch enables propagation of speculative contextes I promised to fix after
Martin's
merge. There were few bugs that ended up disturbing testsuite:
1) ipa_polymorphic_call_context::combine_with did not handle very well case
where the incomming type is in construction and it's current
Hi!
I was under the impression that somebody else took over keeping an eye
on syncing common files between gcc, binutils, automake, config, ...
Seems I was kind of wrong with that assumption? Alas, I've started
my scripts again and will continue my former syncing work, starting
with some easy s
Hi,
On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka wrote:
> > Yep, it is because my code does not handle streaming of arrays
> > into the target optimization nodes. I will take a look on why
> > that array is really needed. It seems like a overkill?
>
> I am looking into the nios2_register_cust
Jonah,
> Yep, it is because my code does not handle streaming of arrays into the
> target optimization nodes.
> I will take a look on why that array is really needed. It seems like a
> overkill?
I am looking into the nios2_register_custom_code and I do not quite understand
what it is good for?
With the C++14 constexpr support we were getting confused by using
finish_expr_stmt on something that isn't an expression. This already
should have been add_stmt, so I'm checking it in separately.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 046fdf7db65830bc1030d766ffa8f4ba696e0660
Au
Here are two small constexpr changes that I made while working on C++14
constexpr support that I thought should go in separately. The first
clarifies the error about missing mem-initializers in constexpr
constructors so that people aren't confused about why assigning to the
field in the constr
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
> > gcc/testsuite/
> > * g++.dg/guality/guality.exp (check_guality): Fix `test_counts'
> > restoration.
>
> Ok, thanks.
Applied, thanks.
Maciej
On Fri, 14 Nov 2014, Joseph Myers wrote:
> OK.
Applied, thanks.
Maciej
On Sat, Nov 15, 2014 at 12:29 PM, H.J. Lu wrote:
> On Sat, Nov 15, 2014 at 12:22 PM, FX wrote:
>>> This looks wrong. This test should pass for 64-bit or ia32 && nonpic.
>>
>> It was Kai’s original testcase, so I don’t want to modify it too much, other
>> than make it skip where it clearly fails
On Fri, Nov 14, 2014 at 4:39 AM, Richard Biener wrote:
>
> Following up https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01233.html and
> fixing the regressions this caused as soon as I removed the dispatch
> to fold_unary (and more regressions it would have caused if I managed
> to finish the idea t
>
> The recent work, I'm not exactly sure if it's actually /this/ commit,
> broke nios2-rtems, see eg. build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=376303
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables
Eric Botcazou writes:
> > IIRC, fill_eager and its related friends are all speculative in some
> way
> > and aren't those precisely the ones that are causing us problems.
> Also
> > note we have backends working around this stuff in fairly blunt ways:
>
> I'd say that the PA back-end went a bit t
On Sat, 2014-11-15 17:57:20 +0100, Jan Hubicka wrote:
> Hi,
> this patch implements OPTIMIZATION_NODE streaming same was as previous patch
> did for TARGET_OPTION_NODE. Since the code turned out to be completely
> analogous to the previous one I will go ahead and commit it as obvious.
> It will he
On Sat, Nov 15, 2014 at 12:22 PM, FX wrote:
>> This looks wrong. This test should pass for 64-bit or ia32 && nonpic.
>
> It was Kai’s original testcase, so I don’t want to modify it too much, other
> than make it skip where it clearly fails.
>
Original bug report was filed against x86-64:
The
> This looks wrong. This test should pass for 64-bit or ia32 && nonpic.
It was Kai’s original testcase, so I don’t want to modify it too much, other
than make it skip where it clearly fails.
FX
On Sat, Nov 15, 2014 at 11:46 AM, FX wrote:
> Don’t run gcc.target/i386/sibcall-1.c on PIC targets.
>
>
> 2014-11-15 Francois-Xavier Coudert
>
> PR target/60104
> * gcc.target/i386/sibcall-1.c: Don't run on pic targets.
>
>
> Index: gcc.target/i386/sibcall-1.c
>
2014-11-15 15:49 GMT+00:00 Andrew Pinski :
>> My local modifications can be found in the gcc git at
>> apinski/thunderx-cost. Note I reverted this patch so I can continue
>> working. The testcase is compiling newlib. Let me try to get it
>> again.
>> I was configuring a combined build with:
>> -
Don’t run gcc.target/i386/sibcall-1.c on PIC targets.
2014-11-15 Francois-Xavier Coudert
PR target/60104
* gcc.target/i386/sibcall-1.c: Don't run on pic targets.
Index: gcc.target/i386/sibcall-1.c
===
--- gcc.ta
On Sat, Nov 15, 2014 at 9:07 AM, Vladimir Makarov wrote:
> On 2014-11-15 9:58 AM, H.J. Lu wrote:
>>
>> On Fri, Nov 14, 2014 at 12:07 PM, Vladimir Makarov
>> wrote:
>>>
>>> The LRA rematerialization patch I've submitted about day ago broke
>>> H.J.'s
>>> 32-bit bootstrap. So I switched off the
Hi,
GCC uses xstrndup/xstrdup throughout the source tree and those memory
may not be freed explicitly before exut. LeakSanitizer isn't very
useful here. This patch suppresses LeakSanitizer in bootstrap. OK
for trunk?
This patch isn't sufficient. I got
configure:3612: /export/build/gnu/gcc-as
On Sat, Nov 15, 2014 at 01:03:46PM +0100, Marek Polacek wrote:
> The problem here is that the Cilk+ code wasn't prepared to handle
> internal calls that the new overflow builtins entail. Fixed by
> checking that the CALL_EXPR_FN isn't NULL.
>
> Looking at cilk-plus.exp, I think this file will nee
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 15-11-14 13:14, Tom de Vries wrote:
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1
On 2014-11-15 9:58 AM, H.J. Lu wrote:
On Fri, Nov 14, 2014 at 12:07 PM, Vladimir Makarov wrote:
The LRA rematerialization patch I've submitted about day ago broke H.J.'s
32-bit bootstrap. So I switched off the rematerialization right away. The
set for bootstrapping used by H.J. was very use
Hi,
this patch implements OPTIMIZATION_NODE streaming same was as previous patch
did for TARGET_OPTION_NODE. Since the code turned out to be completely
analogous to the previous one I will go ahead and commit it as obvious.
It will help to make followup changes easier to follow.
I also tested this
All other tests in gcc.dg/ that use __attribute__((__alias__())) are guarded by
dg-require-alias.
Let’s do the same for gcc.dg/tree-ssa/pr61144.c, otherwise it complains on
darwin.
2014-11-15 Francois-Xavier Coudert
* gcc.dg/tree-ssa/pr61144.c: Add dg-require-alias.
Index: gcc.
On Fri, 2014-11-14 19:53:33 +0100, Jan Hubicka wrote:
> > Breaks build:
> >
> > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtu
Committed as trivial.
And also, fixed wrong date on my earlier ChangeLog entry :)
FX
2014-11-15 Francois-Xavier Coudert
* gcc.dg/pubtypes-3.c: Include .
* gcc.dg/pubtypes-4.c: Likewise.
Index: gcc.dg/pubtypes-3.c
==
On Sat, Nov 15, 2014 at 7:21 AM, Andrew Pinski wrote:
> On Sat, Nov 15, 2014 at 6:08 AM, Jiong Wang
> wrote:
>> 2014-11-15 0:15 GMT+00:00 Andrew Pinski :
>>> On Tue, Sep 30, 2014 at 8:00 AM, Jiong Wang wrote:
On 27/09/14 22:20, Kugan wrote:
>
>
> On 23/09/14 01:58, Jiong Wang wr
On Thu, Nov 13, 2014 at 2:58 AM, Dominik Vogt wrote:
>
> What do you think about the attached patches? They work for me, but I'm
> not sure whether the patch to go-test.exp is good because I know
> nothing about tcl.
Looks plausible to me.
Ian
Committed as trivial, as the error wording changed due to more precise
diagnostics: it now says ‘CFStringRef {aka const struct __CFString *}’ instead
of just ‘CFStringRef’
FX
2014-10-19 Francois-Xavier Coudert
* gcc.dg/darwin-cfstring-format-1.c: Adjust dg-error.
Index: gcc.dg/d
On Sat, Nov 15, 2014 at 6:08 AM, Jiong Wang
wrote:
> 2014-11-15 0:15 GMT+00:00 Andrew Pinski :
>> On Tue, Sep 30, 2014 at 8:00 AM, Jiong Wang wrote:
>>> On 27/09/14 22:20, Kugan wrote:
On 23/09/14 01:58, Jiong Wang wrote:
>>
>> + /* If we decided that we didn't need a leaf fra
On Fri, Nov 14, 2014 at 12:07 PM, Vladimir Makarov wrote:
> The LRA rematerialization patch I've submitted about day ago broke H.J.'s
> 32-bit bootstrap. So I switched off the rematerialization right away. The
> set for bootstrapping used by H.J. was very useful. I've fixed several
> existing
2014-11-15 0:15 GMT+00:00 Andrew Pinski :
> On Tue, Sep 30, 2014 at 8:00 AM, Jiong Wang wrote:
>> On 27/09/14 22:20, Kugan wrote:
>>>
>>>
>>> On 23/09/14 01:58, Jiong Wang wrote:
>
> + /* If we decided that we didn't need a leaf frame pointer but then used
> + LR in the function, then we'll w
On Fri, Nov 14, 2014 at 08:35:48PM +0100, Bernd Schmidt wrote:
> On 11/14/2014 08:19 PM, Segher Boessenkool wrote:
> >+ /* If I2 is a PARALLEL of two SETs of REGs (and perhaps some CLOBBERs),
> >+ make those two SETs separate I1 and I2 insns, and make an I0 that is
> >+ the original I1. *
The attached testcase triggers an ICE because it contains pragma Loop_Optimize
which survives down to RTL expansion. There are 2 bugs: first, this should
not ICE but issue a "ignoring loop annotation" message (this was accidentally
disabled in https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00681
Hi,
I'm submitting a patch series with initial support for the oacc kernels
directive.
The patch series uses pass_parallelize_loops to implement parallelization of
loops in the oacc kernels region.
The patch series consists of these 8 patches:
...
1 Expand oacc kernels after pass_build_
Try_unroll_loop_completely logs a message for max-completely-peeled-insns:
else if (unr_insns
> (unsigned) PARAM_VALUE (PARAM_MAX_COMPLETELY_PEELED_INSNS))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Not unrolling loop %d:
The problem here is that the Cilk+ code wasn't prepared to handle
internal calls that the new overflow builtins entail. Fixed by
checking that the CALL_EXPR_FN isn't NULL.
Looking at cilk-plus.exp, I think this file will need some tweaks
now that the C default is gnu11...
Bootstrapped/regtested
> Thus, I don't think it should be put into the wiki. (Admittedly, I also do
> not know which page you are referring to.) In any case, there are several PRs
> about issues fixed by the on-going change to the common diagnostics.
OK. (The page I was referring to is here:
https://gcc.gnu.org/wiki/
> It looks at register that respect the constraints of all the instructions in
> the set and tries to pick one in the preferred class for all the
> instructions involved. This is generally useful for any pass that wants to
> do register renaming. However it also contains some logic to only select
>
FX wrote:
Please document, in the source, the difference between gfc_fatal_error
and gfc_fatal_error_1. They currently have the same generic
description, which wouldn’t help people writing new front-end code to
know which one to use. Moreover, if the transition will not be
complete soon (or in
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
> >> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> >> > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm w
The close of stage 1 is getting close (very close). Even there is not so much
new code (basically
the new code computes the separation class option for AST build), I am not sure
that the patch
qualify for stage 2.
There is very nice code generated by unroll-and-jam (stride mining) for small
ke
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
Please document, in the source, the difference between gfc_fatal_error and
gfc_fatal_error_1. They currently have the same generic description, which
wouldn’t help people writing new front-end code to know which one to use.
Moreover
On November 14, 2014 8:13:15 PM CET, Jan Hubicka wrote:
>Hi,
>this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET
>from target
>attributes. This code was never complete and it should be no-op now
>when we save
>tehe target nodes.
>It also makes free_land_data_in_decl to actually
> IIRC, fill_eager and its related friends are all speculative in some way
> and aren't those precisely the ones that are causing us problems. Also
> note we have backends working around this stuff in fairly blunt ways:
I'd say that the PA back-end went a bit too far here, especially if it marks
Especially since color diagnostic is now the default [1], it makes sense
to convert more gfortran diagnostics to use the common diagnostics.
For an example, see [1]. That also brings all the nice features like
placing the warning option in brackets:
Warning: USE statement at (1) has no ONLY
'fd' may be 0 which does not need 'open' operation, so neither need
'close' operation on it when it is 0.
Also in c_common_read_pch(), when failure occurs, also need be sure the
'fd' is not '-1' for the next close operation.
It passes testsuite under Fedora x86_64-unknown-linux-gnu.
gcc/
> On 13 November 2014 06:14, Yangfei (Felix) wrote:
> > Hi,
> >
> > We find that the VALLDI mode iterator used in *aarch64_simd_ld1r
> pattern is not appropriate.
> > The reason is that it's impossible to get a new operand of DImode by
> vec_duplicating an operand of the same mode.
> > So th
71 matches
Mail list logo
