> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, May 28, 2013 8:48 PM
> To: Iyer, Balaji V
> Cc: Richard Henderson; Jakub Jelinek; Aldy Hernandez; Jeff Law; Joseph S.
> Myers; gcc-patches
> Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C pat
On May 28, 2013, at 3:56 PM, Dehao Chen wrote:
> The attached patch restricts the test only run on linux-gnu targets. Is it ok?
Ok. You can put HAVE_AS_DWARF2_DEBUG_LINE in a comment above it to help
explain why the target restriction applies. The idea is, if enough people
care, or some x86 t
I made a thinko when I asserted gcc_unreachable outside the main loop
of appears_later_in_bb in my previous fix to PR 57337. It is quite
possible for STMT1 to be followed by a one or more statements with the
same UID till the end of the BB without encountering STMT2. Right fix
is to return STMT1 ou
> The attached patch restricts the test only run on linux-gnu targets. Is it ok?
Ideally we would restrict the test to those targets where
HAVE_AS_DWARF2_DEBUG_LINE is set, but I don't think that can be done
in dg. OK if no one suggests a way to do exactly that.
-cary
> gcc/ChangeLog:
>
> 2013-
On Tue, May 28, 2013 at 5:35 PM, H.J. Lu wrote:
> On Tue, May 28, 2013 at 1:02 PM, Iyer, Balaji V
> wrote:
>>
>>
>>> -Original Message-
>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
>>> Sent: Tuesday, May 28, 2013 2:52
On Tue, May 28, 2013 at 1:02 PM, Iyer, Balaji V wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
>> Sent: Tuesday, May 28, 2013 2:52 PM
>> To: Iyer, Balaji V
>> Cc: Jakub Jelinek; Aldy Hernande
Christian Bruel wrote:
> However I feel a little bit uncomfortable with this solution that
> doesn't seem to fix the root cause. The dbx_register_number hooks is
> called basically from two places : dwarf2cfi.c and dwarf2out.c. That
> show different uses: either we want to refer to the hard regno
> i386 only, might be related
>
> ,.,. CXG2021 ACATS 2.5 13-05-27 17:47:57
> CXG2021 Check the accuracy of the complex SIN and COS functions.
>* CXG2021 Identity_2_Test 3 0: Cos(( 1.60300E+01, 1.6E+01))
> imaginary part actual: 1.40623E+06 expected:
>
Richard,
This patch adds the micromips multilib to the mips-mti-elf and mips-mti-linux
targets. It also adds mips16 multilib to mips-mti-linux. I hadn't added
that earlier because I was waiting for the mips16 changes to get checked in
to glibc and they are in now. It shouldn't affect any other
ChangeLog fix patch committed in r199394.
The attached patch restricts the test only run on linux-gnu targets. Is it ok?
Thanks
Dehao
gcc/ChangeLog:
2013-05-28 Dehao Chen
testsuite/debug/dwarf2/discriminator.c: Restrict the test to linux only.
Index: gcc/testsuite/gcc.dg/debug/dwarf2/discr
On Wed, 2013-05-22 at 07:30 +0100, Richard Sandiford wrote:
> Oops -- only if someone submitted one :-) So we should definitely
> change the mips32r2 entry. I'd suggest one of PROCESSOR_24KF* or
> PROCESSOR_74KF*, so that we get the FPU scheduling, but I don't know
> which would be more represen
On 05/28/13 16:20, Iyer, Balaji V wrote:
Regarding the tests, I will merge trunk->cilk-in-gomp so we can reuse the c-c++-
common infrastructure you wrote. There is no sense having multiple tests for
vectorlength, linear, etc.
Can you please add them under c-c++-common/cilk-plus/PS directory?
>
> Regarding the tests, I will merge trunk->cilk-in-gomp so we can reuse the
> c-c++-
> common infrastructure you wrote. There is no sense having multiple tests for
> vectorlength, linear, etc.
Can you please add them under c-c++-common/cilk-plus/PS directory?
AN = Array Notation
PS = Pragma
On 05/21/13 10:46, Iyer, Balaji V wrote:
Thank you for working on this!
static tree
find_invalid_stmts (tree *tp, int *walk_subtrees, void *data)
{
bool *valid = (bool *) data;
location_t loc = EXPR_HAS_LOCATION (*tp) ? EXPR_LOCATION (*tp) :
UNKNOWN_LOCATION;
if (!tp || !*tp)
retu
* src/c++11/compatibility-chrono.cc (steady_clock::now()): If
!_GLIBCXX_USE_GETTIMEOFDAY perform conversion inline instead of
calling non-existent from_time_t.
Tested x86_64-linux, committed to trunk and the 4.8 branch.
Steve, trunk should build OK now, thanks for testing
On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
wrote:
> Hi Steven,
>
> Steven Bosscher writes:
>> Imho the active-insn "idiom" is the best solution for the moment. I
>> will fix this mess properly asap, probably next week.
>
> Just wondering, how are things going with this? (I assume fixing
All tests passed. Committed as r199390 in google/gcc-4_8.
Thanks,
Sharad
On Tue, May 28, 2013 at 11:45 AM, Sharad Singhai wrote:
> On Fri, May 24, 2013 at 7:42 PM, Xinliang David Li wrote:
>> On Fri, May 24, 2013 at 2:32 PM, Sharad Singhai wrote:
>>>if (flag_gcov_file)
>>> {
>>> - c
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Richard Henderson
> Sent: Tuesday, May 28, 2013 2:52 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; Aldy Hernandez; Jeff Law; 'Joseph S. Myers'; 'gcc-patches'
> Subject: Re: [PI
On May 28, 2013, at 7:59 AM, Yufeng Zhang wrote:
> The attached patch updates the g++ test g++.dg/cpp0x/alias-decl-debug-0.C to
> skip aarch64*-*-*, on which there is no support for STABS.
>
> OK for the trunk?
Ok.
Hi Steven,
Steven Bosscher writes:
> Imho the active-insn "idiom" is the best solution for the moment. I
> will fix this mess properly asap, probably next week.
Just wondering, how are things going with this? (I assume fixing it
properly means getting rid of the FIXME in next_active_insn?)
Tha
On 05/28/2013 11:44 AM, Iyer, Balaji V wrote:
> i Richard, Jakub et al..
> I think I have fixed everything requested by RTH
> (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have
> also moved the tests in the correct place Jakub requested. It is passing all
> the corr
On Fri, May 24, 2013 at 7:42 PM, Xinliang David Li wrote:
> On Fri, May 24, 2013 at 2:32 PM, Sharad Singhai wrote:
>>if (flag_gcov_file)
>> {
>> - char *gcov_file_name
>> -= make_gcov_file_name (file_name, src->coverage.name);
>> + if (flag_intermediate_format)
>> +
Hi Richard, Jakub et al..
I think I have fixed everything requested by RTH
(http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01400.html). I think I have also
moved the tests in the correct place Jakub requested. It is passing all the
correct regression tests and not affecting others.
Is th
Sorry, my patch had bad formatting in one of the functions
(output_gcov_file). Here is the corrected version.
Thanks,
Sharad
(2013-05-28
* gcov.c (print_usage): Handle new option.
(process_args): Ditto.
(get_gcov_intermediate_filename): New function.
(output_intermediate_file): New function.
On 05/28/2013 11:00 AM, David Malcolm wrote:
On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote:
On 05/25/2013 07:02 AM, David Malcolm wrote:
I can think of three approaches to "cfun":
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun
Hi Tobias,
> the attached patch now enables the *parsing* of "FINAL ::" - however, *no*
> finalization will be done. Adding FINALIZATION will be deferred to several
> follow-up patches.
>
> Build on x86-64-gnu-linux.
> OK for the trunk?
yes, ok from my side. It's definitely time to get the finali
On Mon, 2013-05-27 at 15:38 +0200, Richard Biener wrote:
> On Sat, May 25, 2013 at 3:02 PM, David Malcolm wrote:
> > Eliminate all direct references to "cfun" from macros in
> > basic-block.h and introduce access methods to control_flow_graph
> >
> > * basic-block.h (contro
On 05/28/2013 04:25 AM, Jan Hubicka wrote:
> According to dicussion with Jakub, I do not see reason why not move whole
> thing upwards into lowering. This make the child functio nto get throug
> optimization as a regular function and things works smoother.
>
> Bootstrapped/regtested x86_64, seem
On 28 May 2013 18:39, Steve Ellcey wrote:
> On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:
>
>>
>> I don't think it was my patch that broke it, because
>> compatibility-chrono.cc didn't exist when my patch went in :-)
>
> Sorry about that, I guess I got lost in a maze of twisty checkins
On Tue, 2013-05-28 at 17:29 +0100, Jonathan Wakely wrote:
>
> I don't think it was my patch that broke it, because
> compatibility-chrono.cc didn't exist when my patch went in :-)
Sorry about that, I guess I got lost in a maze of twisty checkins.
> Does this help?
>
> --- src/c++11/compatibil
On Tue, May 28, 2013 at 4:11 AM, Richard Biener
wrote:
> On Mon, May 27, 2013 at 10:20 AM, Richard Biener
> wrote:
>> On Sun, May 26, 2013 at 5:53 AM, Easwaran Raman wrote:
>>> On Sat, May 25, 2013 at 4:46 AM, Richard Biener
>>> wrote:
Easwaran Raman wrote:
>In that case, if my i
Richi,
I would greatly appreciate if you would bootstrap and test this on
ppc64-linux as well.
Thanks, David
On 05/28/13 11:49, Iyer, Balaji V wrote:
At present, I did not have a g++.dg/cilk-plus/cilk-plus.exp script,
thus C++ compiler does not execute these tests.
Ah, I see. Perfect.
This patch adds an intermediate coverage format ('gcov -i'). This is a
compact format as it does not require source files.
The new option ('gcov -i') outputs .gcov files in an intermediate text
format that can be post-processed by lcov or other tools. It outputs a
single *.gcov file per *.gcda fi
Honza,
I would greatly appreciate if you would bootstrap GCC and run the
testsuite with your symtab cleanup patches on ppc64-linux.
Thanks, David
On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote:
> On 05/25/2013 07:02 AM, David Malcolm wrote:
> > I can think of three approaches to "cfun":
> > (a) status quo: a global variable, with macros to prevent direct
> > assignment, and an API for changing cfun.
> > (b) have a global "context" or
Hi Aldy
Please see my responses below.
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
> Sent: Tuesday, May 28, 2013 12:38 PM
> To: Iyer, Balaji V
> Cc: Jakub Jelinek; Jeff La
On Tue, May 28, 2013 at 11:37:32AM -0500, Aldy Hernandez wrote:
> > I moved all the tests from gcc.dg/cilk-plus/AN directory to
> > c-c++-common/cilk-plus/AN directory. The gcc.dg/cilk-plus directory just
> > contains cilk-plus.exp script, which will handle all the tests in
> > cilk-plus, no
On 05/24/13 13:43, Iyer, Balaji V wrote:
Hi Jakub,
I moved all the tests from gcc.dg/cilk-plus/AN directory to
c-c++-common/cilk-plus/AN directory. The gcc.dg/cilk-plus directory just
contains cilk-plus.exp script, which will handle all the tests in cilk-plus,
not just array notation
On Tue, May 28, 2013 at 05:29:38PM +0100, Jonathan Wakely wrote:
> > This has broken the mips-mti-elf build for me,
>
> I don't think it was my patch that broke it, because
> compatibility-chrono.cc didn't exist when my patch went in :-)
Yeah, this is from the latest change set.
> Does this h
On 28 May 2013 17:10, Steve Ellcey wrote:
> On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
>> This alters the configure script to enable C++11 thread library
>> features based on targets that are known to support the features,
>> rather than based on link tests which are disabled by defa
On Wed, 2013-05-22 at 09:14 +0100, Jonathan Wakely wrote:
> This alters the configure script to enable C++11 thread library
> features based on targets that are known to support the features,
> rather than based on link tests which are disabled by default. With
> Glibc 2.17 this enables a nanoseco
See PR for details. A rather obvious fix by Dominique. Thanks to him and
to the bug reporter.
Committed to the trunk as Rev. 199382 after building+regtesting the
patch on x86-64-gnu-linux.
Tobias
2013-05-28 Dominique d'Humieres
PR fortran/57435
* module.c (check_for_ambiguous): Avoid nu
>> A rather simple patch found while testing the draft finalization patch.
>>
>> For a "class(...), allocatable, intent(out)" dummy argument, the actual
>> argument has to be deallocated. That worked for scalar polymorphic vars, but
>> not for polymorphic arrays.
>
>
> Actually, it turned out to be
Hi,
The attached patch updates the g++ test
g++.dg/cpp0x/alias-decl-debug-0.C to skip aarch64*-*-*, on which there
is no support for STABS.
OK for the trunk?
Thanks,
Yufeng
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-debug-0.C: Add aarch64*-*-* to the
dg-skip-if "No stabs".dif
On Thu, May 16, 2013 at 10:49 AM, Pavel Chupin wrote:
> On Mon, Apr 29, 2013 at 5:36 PM, Alexander Ivchenko
> wrote:
>> *ping*
>>
>> thank you,
>> Alexander
>>
>> 2013/4/15 Pavel Chupin :
>>> On Tue, Apr 2, 2013 at 1:59 PM, Pavel Chupin
>>> wrote:
On Mon, Apr 1, 2013 at 7:07 PM, Pavel Chu
> > I agree that it is possible to use define_subst (apart from the
> fact
> > that it doesn't support define_insn_and_split yet). It's just
> that I
> > think it looks hacky and makes the patterns look
> > less readable if the reader has to remember that predication is
> implicit
> > when a subst_
This properly accounts for remaining unvectorized scalar uses of
stmts we vectorize during BB vectorization. Previously we
happily retained all of the scalar loads and computations, just
optimizing the final stores, alongside the vectorized code.
To account for scalar uses properly the following
Hi!
This is on top of the earlier patch from today.
This handles expansion of #pragma omp distribute, so far without collapse
clause (for collapse > 1 we'll need expand_omp_for_static_*chunk to handle
collapsed loops, because we can't easily use library function for that,
that implicitly looks at
On Tue, 28 May 2013, Martin Jambor wrote:
> Hi,
>
> On Mon, May 27, 2013 at 10:02:19AM +0200, Richard Biener wrote:
> > On Fri, 24 May 2013, Martin Jambor wrote:
> >
> > > Hi,
> > >
> > > On Thu, May 23, 2013 at 11:38:10AM +0200, Richard Biener wrote:
> > > > On Thu, 23 May 2013, Eric Botcazou
Hi,
On Mon, May 27, 2013 at 10:02:19AM +0200, Richard Biener wrote:
> On Fri, 24 May 2013, Martin Jambor wrote:
>
> > Hi,
> >
> > On Thu, May 23, 2013 at 11:38:10AM +0200, Richard Biener wrote:
> > > On Thu, 23 May 2013, Eric Botcazou wrote:
> > >
> > > > > earlier this week I asked on IRC whet
Hi!
This patch handles
#pragma omp declare target
...
#pragma omp end declare target
and adds some accelerator related nesting restrictions.
I haven't done much checking that both the opening and closing
directive appear in the same scope, perhaps that can be done later on.
Plus I guess further c
On 05/25/2013 07:02 AM, David Malcolm wrote:
I can think of three approaches to "cfun":
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun.
(b) have a global "context" or "universe" object, and put cfun in
there (perhaps with tricks
On Tue, 28 May 2013, Jakub Jelinek wrote:
> On Tue, May 28, 2013 at 02:07:25PM +0200, Richard Biener wrote:
> > The following fixes vectorization of loops with CLOBBER statements
> > in the way of ignoring them during analysis and removing them during
> > vectorization (because we ignored them for
This is the final variant of the patch working towards enabling
a less costly vectorization variant at -O2 by default. It introduces
a "cheap" cost-model variant by means of transforming the existing
-fvect-cost-model option to one taking an argument,
"unlimited" (same as -fno-vect-cost-model), "
On Tue, May 28, 2013 at 02:07:25PM +0200, Richard Biener wrote:
> The following fixes vectorization of loops with CLOBBER statements
> in the way of ignoring them during analysis and removing them during
> vectorization (because we ignored them for store/load placement
> and do not handle them in c
The following fixes vectorization of loops with CLOBBER statements
in the way of ignoring them during analysis and removing them during
vectorization (because we ignored them for store/load placement
and do not handle them in case we need to unroll the loop body).
Bootstrap / regtest pending on x
Eric Botcazou writes:
>> * The new gnat.dg/fp_exception.adb test fails on Solaris 9 and 10/x86,
>> Solaris 9 and 11/SPARC:
>>
>> +FAIL: gnat.dg/fp_exception.adb execution test
>>
>> raised CONSTRAINT_ERROR : SIGFPE
>
> Patch collision. After
>
> 2013-05-24 Eric Botcazou
>
> * gcc-
>> Anyway, anything in this direction is probably a non-regression and
>> should rather be handled as a follow-up. Is the current patch
>> (http://gcc.gnu.org/ml/fortran/2013-05/msg00045.html) ok for
>> trunk/4.8/4.7?
>
> OK.
Thanks. Committed to trunk as r199375. Will do 4.8 and 4.7 soon.
> Sti
Hi,
this testcase has volatile variable read to prevent vectorization but then
it is shadowed by local var of the same name. Currently it prevents
vectorization
but not reliably (i.e. we can manage to optimize the conditional away from loop
since it is invariant and that is what happens in my tree
> I've included the patch in my Solaris bootstraps this weekend, and
> results don't look good:
>
> * On Solaris 9/x86 and Solaris 10/x86 (both 32- and 64-bit), I get a new
> ACATS failure which may or may not be related:
>
> +FAIL: cxg2021
>
> i386 only, might be related
>
> ,.,. CXG2021
Hi,
I have hit problem with this pass several times. OMP is split into two passes,
one run before CFG construction (lower_omp) and other after (expand_omp).
Their purpose (as I understand it) is to outline part of the function body
into child function. This happens in two steps and part of body
(D
On Mon, May 27, 2013 at 10:20 AM, Richard Biener
wrote:
> On Sun, May 26, 2013 at 5:53 AM, Easwaran Raman wrote:
>> On Sat, May 25, 2013 at 4:46 AM, Richard Biener
>> wrote:
>>> Easwaran Raman wrote:
>>>
In that case, if my insert_stmt immediately follows dep_stmt and both
have the same
This fixes copy-propagation (in DOM in this case) which breaks
virtual SSA form by introducing overlapping life-ranges which
in turn breaks CFG transforms that rely on that property.
The patch disables copy-propagation of virtuals in general
(for all passes checking may_propagate_copy) because th
> builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
> foo3 and foo4.
It turns out that you need to combine 4 instructions on the IA-64 to get rid
of the bswaps, so -O2 (actually -fexpensive-optimizations) is required.
Tested on x86_64-suse-linux, applied on the mainline.
2
From: Eric Botcazou
Date: Tue, 28 May 2013 11:56:40 +0200
> This changes the 3 occurrences of bmasksi_vis to use %g0 as the destination
> register instead of an otherwise unused pseudo-register.
>
> Tested on SPARC/Solaris, applied on the mainline.
Thanks for improving this.
Hi Eric,
> this isn't really valid Ada semantics, but some people enable traps-on-fp-
> exceptions in the FPU on Solaris and expect the Ada exception to be caught.
> There is a glitch with the x87 and the SPARC FPUs: the SIGFPE is delivered
> after the faulting instruction by Solaris, so the unwi
This changes the 3 occurrences of bmasksi_vis to use %g0 as the destination
register instead of an otherwise unused pseudo-register.
Tested on SPARC/Solaris, applied on the mainline.
2013-05-28 Eric Botcazou
* config/sparc/sparc.c (sparc_expand_vec_perm_bmask): Use %g0 as
de
On Tue, May 28, 2013 at 11:41:50AM +0200, Rainer Orth wrote:
> Fixed by the following patch, tested with the appropriate runtest
> invocation on sparc-sun-solaris2.11.
>
> Ok for mainline and 4.8 branch?
Yes, thanks.
> 2013-05-28 Rainer Orth
>
> * config/abi/post/solaris2.10/sparcv9/ba
Jakub Jelinek writes:
> On Sun, May 26, 2013 at 07:58:09AM +0200, Jakub Jelinek wrote:
>> On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote:
>> >
>> > > Looks good to me.
>> >
>> > Great, trunk patch in.
>> >
>> > > Will you prepare corresponding patch for the 4.8
>> > > bra
27;t pretend the inside of a SUBREG is
> the actual destination. Invalidate single/leading registers by
> setting reg_mode to VOIDmode.
> Use move2add_record_sym_value, move2add_valid_value_p and
> move2add_record_mode.
This breaks m68k.
Executing on host: /daten/arany
Hi!
On Wed, 08 May 2013 11:27:09 +0200, Rainer Orth
wrote:
> As described in the PR, amd64-pc-solaris2.1[01] Ada bootstrap was failing
> for some time. It has turned out that this patch is the culprit:
>
> 2013-04-23 Eric Botcazou
> Pascal Obry
>
> * gcc-interface/M
72 matches
Mail list logo
