Re: RFC: [ARM] Disable peeling
On Tue, Oct 1, 2013 at 5:49 PM, Christophe Lyon
wrote:
> Hi,
>
> I am resuming investigations about disabling peeling for
> alignment (see thread at
> http://gcc.gnu.org/ml/gcc/2012-12/msg00036.html).
>
> As a reminder, I have a simple patch which disables peeling
> unconditionally and gives some improvement in benchmarks.
>
> However, I've noticed a regression where a reduced test case is:
> #define SIZE 8
> void func(float *data, float d)
> {
> int i;
> for (i=0; i data[i] = d;
> }
>
> With peeling enabled, the compiler generates:
> fstss0, [r0]
> fstss0, [r0, #4]
> fstss0, [r0, #8]
> fstss0, [r0, #12]
> fstss0, [r0, #16]
> fstss0, [r0, #20]
> fstss0, [r0, #24]
> fstss0, [r0, #28]
>
> with my patch, the compiler generates:
> vdup.32 q0, d0[0]
> vst1.32 {q0}, [r0]!
> vst1.32 {q0}, [r0]
> bx lr
>
> The performance regression is mostly caused by the dependency
> between vdup and vst1 (removing the dependency on r0
> post-increment did not show any perf improvement).
>
> I have tried to modify the vectorizer cost model such that
> scalar->vector stmts have higher cost than currently with the hope
> that the loop prologue would become too expensive; but to reach this
> level, this cost needs to be increased quite a lot, so this approach
> does not seem right.
>
> The vectorizer estimates the cost of the prologue/epilogue/loop body
> with and without vectorization and computes the number of iterations
> needed for profitability. In the present case, keeping reasonable
> costs, this number is very low (2 or 3 typically), while the compiler
> knows we have 8 iterations for sure.
>
> I think we need something to describe the dependency between vdup
> and vst1.
>
> Otherwise, from the vectorizer point of view, this looks like an
> ideal loop.
>
> Do you have suggestions on how to tackle this?
>
> (I've just had a look at the recent vectorizer cost model
> modification, which doesn't seem to handle this case.)
With the new vectorizer cost model hooks (init_cost, add_stmt_cost,
finish_cost) you can setup target specific data in init_cost, add to it
during add_stmt_cost and thus at finish_cost time you can take
all vectorized stmts into account, modeling this kind of dependency.
Well, if the GIMPLE the vectorizer hands you exposes enough information
to guess the final instructions, of course.
PPC uses this to model vector shift resource constraints.
Richard.
> Thanks,
>
> Christophe.
>
> On 13 December 2012 10:42, Richard Biener wrote:
>> On Wed, Dec 12, 2012 at 6:50 PM, Andi Kleen wrote:
>>> "H.J. Lu" writes:
i386.c has
{
/* When not optimize for size, enable vzeroupper optimization for
TARGET_AVX with -fexpensive-optimizations and split 32-byte
AVX unaligned load/store. */
>>>
>>> This is only for the load, not for deciding whether peeling is
>>> worthwhile or not.
>>>
>>> I believe it's unimplemented for x86 at this point. There isn't even a
>>> hook for it. Any hook that is added should ideally work for both ARM64
>>> and x86. This would imply it would need to handle different vector
>>> sizes.
>>
>> There is
>>
>> /* Implement targetm.vectorize.builtin_vectorization_cost. */
>> static int
>> ix86_builtin_vectorization_cost (enum vect_cost_for_stmt type_of_cost,
>> tree vectype,
>> int misalign ATTRIBUTE_UNUSED)
>> {
>> ...
>> case unaligned_load:
>> case unaligned_store:
>> return ix86_cost->vec_unalign_load_cost;
>>
>> which indeed doesn't distinguish between unaligned load/store cost. Still
>> it does distinguish between aligned and unaligned load/store cost.
>>
>> Now look at the cost tables and see different unaligned vs. aligned costs
>> dependent on the target CPU.
>>
>> generic32 and generic64 have:
>>
>> 1,/* vec_align_load_cost. */
>> 2,/* vec_unalign_load_cost. */
>> 1,/* vec_store_cost. */
>>
>> The missed piece in the vectorizer is that peeling for alignment should have
>> the
>> option to turn itself off based on that costs (and analysis).
>>
>> Richard.
Re: Getting the ARC port reviewed and accepted
On 10/02/2013 12:47 AM, David Edelsohn wrote: > It is unfortunate that global reviewers are so busy that they cannot > review the few, infrequent new port submissions. But I find it very > distasteful for someone to hyperventilate because other, busy people > don't do something that appears obvious. I'm sure you do, but I find it far more distasteful to have a willing volunteer blocked for so long under such circumstances. This is not the way that we should be doing things. Andrew.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
2013/10/1 Jakub Jelinek : > On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote: >> I'd like to restart discussion on this topic. I see two viable options >> in this thread for PLT entry for MPX. >> >> The first one is to use new relocation for calls requiring extended >> PLT. Linker may decide then which PLT entries should be extended and >> use 16 byte entries when possible. The only question here is how >> dynamic linker may detect MPX binary and try to search for MPX shared >> libraries. Does it have access to PLT section to check it? Isn't still >> better to just use note section? >> >> The second one is a note section. It does not have as good granularity >> as new relocation but in the most cases all calls in MPX object file >> would require extended PLT. Therefore linker create extended PLT entry >> if it used by function from object files marked with the MPX note >> section. The only drawback here is that old linker will just silently >> ignore this note section and user have to check linker version. >> >> Due to mentioned drawback of the second approach I would vote for the >> new relocation but still with note section for dynamic liker. > > Whether the PLT is extended or not can be determined either by the kind > of dynamic relocations applied to it (either the relocation for > non-PLT resp. PLT MPX calls should be only for ld(1) purposes and not > dynamic, or there could be also some dynamic relocation, counterpart of > R_*_JMP_SLOT). In the former case, if the dynamic linker would need to find > out if the PLT is extended or not for some reason, the linker could add some > .dynamic tag, that is the usual way to handle this kind of stuff. I do not see the reason for new dynamic relocation now. Adding PLT MPX calls for ld is enough. As H.J. suggested it wouldn't require any changes in compiler, 'as' may just check for 'bnd' prefix in instruction and generate proper relocation for ld. Having an entry in .dynamic section with special MPX tag is a good idea. No need for a new section then. Does anyone see flaws in this scheme? Thanks, Ilya > > Jakub
RE: [gomp4, openacc-1_0-branch] Re: OpenACC branch
Hi, Thomas! > > Unfortunately, even with that in place, I'm getting ICEs in LTO > streaming (that is, the test cases specifying -flto GCC's testsuite), > and also for trivial OpenACC code with -fopenacc, both for Fortran and > C code. This was fixed yesterday with exception of LTO which was not tested. > As you said yourself (but what is of course totally fine at this early > development stage), the code is not yet mature: there are TODOs for > missing error checking, catching invalid usage of directives by users, > generally robustness, and so on. We shall address these as we continue > working on this. Sure, it's true. > A bit more "trivia": changes to contrib/gcc_update are missing for the > generated files in liboacc, and these should be using the same Autoconf > and Automake versions as the rest of GCC is. It will be fixed soon. > For gcc/tree.def and gcc/gimple.def I agree it makes sense to have > codes specific to OpenACC instead of, for example, shoehorning > OACC_PARALLEL into the existing OMP_PARALLEL (and then adding a flag to > it whether it is an OpenACC or OpenMP parallel statement...). The only > concept I can think of where it'd make sense to even there re-use the > existing OpenMP codes would be if there was a distinct "context" inside > which it's clear whether OMP_PARALLEL means an OpenACC or OpenMP > parallel construct. But that's probably more complex than simply > having separate codes. But, we can re-use > gcc/gimple.h:gimple_statement_omp as basis for OpenACC codes, avoiding > gcc/gimple.h:gimple_statement_acc, > gcc/gsstruct.def:gimple_statement_acc. There is a problem with this approach: gimple_statement_omp is based on gimple_statement_base, but we need gimple_statement_with_memory_ops_base for gimple_statement_acc. > > The new gcc/diagnose-gotos.c should probably re-use/be merged with the > existing omp-low.c:pass_diagnose_omp_blocks from which it duplicates. Sure, it's planned. > Your loop analysis and parallelization for OpenACC kernels constructs > seems to be based on tree-parloops.c code, which should also be > properly shared instead of duplicating it. > > In gcc/tree-inline.c:estimate_num_insns there is OpenACC cost > management not re-using OpenMP's (which might make sense to do?) -- but > I can't see acc_cost being initialized anywhere? Yes, these are planned too. Best wishes, Dmitri Botcharnikov
Re: Bug x86 backend 4.8.1?
Hendrik Greving writes:
> gcc --version
> gcc (GCC) 4.8.1
>
> (4.7.2 seems to work)
>
> gcc -g -fPIC -O2 -Wall -o test test.c
>
> ./test
> type_a is 0x0
>
> Correct would be 0x14000. I don't see how the C-code could be
> ambiguous, I think this is a bug?
>
> test.c:
>
> #include
>
> typedef struct
> {
> unsigned int a:4;
> unsigned int b:5;
> unsigned int c:5;
> unsigned int d:18;
> } my_comb_t;
>
> struct my_s
> {
> int l;
> };
>
> my_comb_t *getps_f (struct my_s *a);
>
> #define GETPS(x) getps_f(&(x))
>
> my_comb_t *
> getps_f (struct my_s *a)
> {
> my_comb_t *p = (my_comb_t *) &(a->l);
> return p;
This is where the test case is wrong. You need to use a union so that
gcc can see the type punning, or compile with -fno-strict-aliasing.
Without -fno-strict-aliasing I see different results for -m32 vs -m64,
but not across gcc versions; with -fno-strict-aliasing all results match.
> }
>
> int g_modes = 5;
>
> int main(void)
> {
> int modes = g_modes;
> int type_a = 0;
>
> if (modes)
> {
> struct my_s m;
> m.l = type_a;
> my_comb_t *p = GETPS(m);
> p->d |= modes;
> type_a = m.l;
> }
> printf("type_a is 0x%x\n", type_a);
> return 0;
> }
Re: [gomp4, openacc-1_0-branch] Re: OpenACC branch
Hi! On Mon, 30 Sep 2013 09:30:47 +0200, Jakub Jelinek wrote: > On Mon, Sep 30, 2013 at 12:05:55AM +0200, Thomas Schwinge wrote: > > Is my understanding correct that the GCC policy regarding extensions such > > as support for OpenACC or OpenMP 4 is: first develop and polish this on a > > branch (such as openacc-1_0-branch or gomp-4_0-branch), and once > > *everything* of the respective standard has been implemented, the > > development branch is then merged into mainline (closing it at the same > > time), instead of committing individual sub-features (such as support for > > only »#pragme acc parallel« but not yet covering the whole respective > > standard) directly to trunk? The issue with the latter, I assume, is > > that such half-finished implementations in trunk might delay/disturb GCC > > releases. > > My actual plan with gomp-4_0-branch is to merge the branch to the trunk > in a week or two.> Ah, nice! > The missing parts of OpenMP 4.0 support right now are: > 1) Fortran support - didn't have spare cycles for it yet, but I think >initially we can just support C/C++ OpenMP 4.0 and Fortran OpenMP 3.1, >and as time permits add the missing Fortran support > 2) OMP_PLACES/affinity - library only side, plan to work on that this week > 3) target support ICV handling - library side only, plan to work on that this > week > 4) elemental functions - this is currently parsed, but ignored, I'd prefer >this being developed on the gomp-4_0-branch after the branch is merged >with trunk, then committed > 5) offloading - once 3) is supported, we should be hopefully OpenMP 4.0 >compliant with regards to target* constructs, just always do host >fallback, further development of actual offloading should continue >on gomp-4_0-branch 6) Documentation (*.texi) updates. ;-) So, this means gomp-4_0-branch will stay open for development. As we (meaning both Samsung and Mentor Graphics) are interested in building upon 3)/5) does it make sense for us to develop OpenACC support directly on gomp-4_0-branch, does that make sense to you? On Mon, 30 Sep 2013 00:05:55 +0200, I wrote: > OpenACC and OpenMP's target construct are very similar in that they can > be expected to share at least a large part of the "device offloading" > functionality: managing memory mappings and data copying, device > detection, initalization, code offloading, and so on. In my > understanding it makes no sense to duplicate that, and instead the > OpenACC implementation shall re-use what has already been implemented for > OpenMP, or rather: is currently being implemented on gomp-4_0-branch > (using per-device plugins). Does it make sense to you to directly implement the OpenACC runtime library routines acc_* plus internal support routines OACC_* in libgomp, or would you rather have that live in a separate library (built inside [GCC]/libgomp/ or strictly "outside")? Doing it directly as part of libgomp (and having -fopenacc imply -lgomp and all that) will make sharing of existing code easier, but will add a bit of overhead to non-OpenACC users of libgomp (also known as OpenMP users) ;-) -- but I don't think the overhead will really be noticeable, as it'll be just a tiny bit of initial setup (ICV; environment variables parsing, etc.); the (unused) OpenACC-only code won't be paged in by the operating system unless used. > So, how to continue? Would it make sense that we first > rework/stabilitize the general infrastructure in openacc-1_0-branch, or > gomp-4_0-branch, or trunk, or yet another branch -- based on > gomp-4_0-branch? Then, flesh out the implementation of one construct, > OpenACC parallel (for it is simpler than the kernels one)? Then, after > we're happy with that, add the other ones? I'd vote for doing that in gomp-4_0-branch. Grüße, Thomas pgpktoqW5MSvw.pgp Description: PGP signature
Re: Getting the ARC port reviewed and accepted
On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley wrote: > On 10/02/2013 12:47 AM, David Edelsohn wrote: >> It is unfortunate that global reviewers are so busy that they cannot >> review the few, infrequent new port submissions. But I find it very >> distasteful for someone to hyperventilate because other, busy people >> don't do something that appears obvious. > > I'm sure you do, but I find it far more distasteful to have a willing > volunteer blocked for so long under such circumstances. This is not > the way that we should be doing things. Productive, helpful suggestions on how to improve the situation are welcome. One issue is encouraging more recent but experienced GCC developers to become maintainers. Thanks, David
Re: Getting the ARC port reviewed and accepted
On 10/02/2013 01:46 PM, David Edelsohn wrote: On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley wrote: On 10/02/2013 12:47 AM, David Edelsohn wrote: It is unfortunate that global reviewers are so busy that they cannot review the few, infrequent new port submissions. But I find it very distasteful for someone to hyperventilate because other, busy people don't do something that appears obvious. I'm sure you do, but I find it far more distasteful to have a willing volunteer blocked for so long under such circumstances. This is not the way that we should be doing things. Productive, helpful suggestions on how to improve the situation are welcome. Clearly, insisting that only one of the few global maintainers can review the port is a problem. Global maintainers don't scale. There is no reason why the maintainer of another port can't review this port. It doesn't necessarily need an global maintainer. While a technical review of the port would undoubtedly be helpful, it does not make any sense to block the ARC port until it receives one: this is an unbounded wait. If there aren't any middle-end changes, the consequence of an ARC port that's not good is at worst an ARC port in GCC that is not good. Even if there are middle-end changes, these can be reviewed separately. The downside of continuing to block this submission for another year is obvious, and is, I submit, worse than the downside of accepting a port that still needs some work. Andrew.
Re: Getting the ARC port reviewed and accepted
On Wed, Oct 2, 2013 at 3:49 PM, Andrew Haley wrote: > On 10/02/2013 01:46 PM, David Edelsohn wrote: >> >> On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley wrote: >>> >>> On 10/02/2013 12:47 AM, David Edelsohn wrote: It is unfortunate that global reviewers are so busy that they cannot review the few, infrequent new port submissions. But I find it very distasteful for someone to hyperventilate because other, busy people don't do something that appears obvious. >>> >>> >>> I'm sure you do, but I find it far more distasteful to have a willing >>> volunteer blocked for so long under such circumstances. This is not >>> the way that we should be doing things. >> >> >> Productive, helpful suggestions on how to improve the situation are >> welcome. > > > Clearly, insisting that only one of the few global maintainers can > review the port is a problem. Global maintainers don't scale. There > is no reason why the maintainer of another port can't review this > port. It doesn't necessarily need an global maintainer. > > While a technical review of the port would undoubtedly be helpful, it > does not make any sense to block the ARC port until it receives one: > this is an unbounded wait. > > If there aren't any middle-end changes, the consequence of an ARC port > that's not good is at worst an ARC port in GCC that is not good. Even > if there are middle-end changes, these can be reviewed separately. > > The downside of continuing to block this submission for another year > is obvious, and is, I submit, worse than the downside of accepting a > port that still needs some work. The main reason for technical review of a port is to avoid that it uses deprecated mechanisms and thus blocks removal of them. Like accepting a port that uses target macros when a corresponding target hook exists, or accepting a port that uses reload instead of LRA, or any other partial transition thing we had this matrix for somewhere somewhen. Richard. > Andrew.
Re: Getting the ARC port reviewed and accepted
On Wed, 2013-10-02 at 15:59 +0200, Richard Biener wrote: > On Wed, Oct 2, 2013 at 3:49 PM, Andrew Haley wrote: > > On 10/02/2013 01:46 PM, David Edelsohn wrote: > >> > >> On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley wrote: > >>> > >>> On 10/02/2013 12:47 AM, David Edelsohn wrote: > > It is unfortunate that global reviewers are so busy that they cannot > review the few, infrequent new port submissions. But I find it very > distasteful for someone to hyperventilate because other, busy people > don't do something that appears obvious. > >>> > >>> > >>> I'm sure you do, but I find it far more distasteful to have a willing > >>> volunteer blocked for so long under such circumstances. This is not > >>> the way that we should be doing things. > >> > >> > >> Productive, helpful suggestions on how to improve the situation are > >> welcome. > > > > > > Clearly, insisting that only one of the few global maintainers can > > review the port is a problem. Global maintainers don't scale. There > > is no reason why the maintainer of another port can't review this > > port. It doesn't necessarily need an global maintainer. > > > > While a technical review of the port would undoubtedly be helpful, it > > does not make any sense to block the ARC port until it receives one: > > this is an unbounded wait. > > > > If there aren't any middle-end changes, the consequence of an ARC port > > that's not good is at worst an ARC port in GCC that is not good. Even > > if there are middle-end changes, these can be reviewed separately. > > > > The downside of continuing to block this submission for another year > > is obvious, and is, I submit, worse than the downside of accepting a > > port that still needs some work. > > The main reason for technical review of a port is to avoid that it uses > deprecated mechanisms and thus blocks removal of them. Like > accepting a port that uses target macros when a corresponding > target hook exists, or accepting a port that uses reload instead of LRA, > or any other partial transition thing we had this matrix for somewhere > somewhen. Presumably this page: http://gcc.gnu.org/wiki/Partial_Transitions Out of interest, is that page itself up-to-date? The last update was on 2012-02-17. Thanks Dave
Re: Bug x86 backend 4.8.1?
I didn't realize the code violated strict aliasing. After reading it,
it seems trivial. Somehow I also thought this is only a C++ thing.
Apparently this is "defined as undefined behavior" in C99?
Thanks a lot! You just found a bug in my code.
Regards,
Thanks,
Hendrik Greving
On Wed, Oct 2, 2013 at 3:19 AM, Mikael Pettersson wrote:
> Hendrik Greving writes:
> > gcc --version
> > gcc (GCC) 4.8.1
> >
> > (4.7.2 seems to work)
> >
> > gcc -g -fPIC -O2 -Wall -o test test.c
> >
> > ./test
> > type_a is 0x0
> >
> > Correct would be 0x14000. I don't see how the C-code could be
> > ambiguous, I think this is a bug?
> >
> > test.c:
> >
> > #include
> >
> > typedef struct
> > {
> > unsigned int a:4;
> > unsigned int b:5;
> > unsigned int c:5;
> > unsigned int d:18;
> > } my_comb_t;
> >
> > struct my_s
> > {
> > int l;
> > };
> >
> > my_comb_t *getps_f (struct my_s *a);
> >
> > #define GETPS(x) getps_f(&(x))
> >
> > my_comb_t *
> > getps_f (struct my_s *a)
> > {
> > my_comb_t *p = (my_comb_t *) &(a->l);
> > return p;
>
> This is where the test case is wrong. You need to use a union so that
> gcc can see the type punning, or compile with -fno-strict-aliasing.
>
> Without -fno-strict-aliasing I see different results for -m32 vs -m64,
> but not across gcc versions; with -fno-strict-aliasing all results match.
>
> > }
> >
> > int g_modes = 5;
> >
> > int main(void)
> > {
> > int modes = g_modes;
> > int type_a = 0;
> >
> > if (modes)
> > {
> > struct my_s m;
> > m.l = type_a;
> > my_comb_t *p = GETPS(m);
> > p->d |= modes;
> > type_a = m.l;
> > }
> > printf("type_a is 0x%x\n", type_a);
> > return 0;
> > }
Re: automatic dependencies
Ping? > Here's the corrected ChangeLog entry. > > 2013-09-30 Tom Tromey > > * Makefile.in (DRIVER_DEFINES): Use $(if), not $(and). -- Eric Botcazou
Re: automatic dependencies
> "Eric" == Eric Botcazou writes: Eric> Ping? Sorry, I think it requires a review. I'll send it to gcc-patches. Tom
Re: automatic dependencies
> Sorry, I think it requires a review. > I'll send it to gcc-patches. IMO it clearly falls into the obvious category. -- Eric Botcazou
Re: automatic dependencies
> "Eric" == Eric Botcazou writes: >> Sorry, I think it requires a review. >> I'll send it to gcc-patches. Eric> IMO it clearly falls into the obvious category. I wasn't so sure; but in any case Jakub quickly approved it and I have checked it in. Tom
graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope
Hi, currently bootstrap is broken for me with errors of this kind: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function ‘void canonicalize_loop_closed_ssa(loop_p)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope make[2]: *** [graphite-scop-detection.o] Error 1 make[2]: *** Waiting for unfinished jobs /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c: In function ‘void propagate_expr_outside_region(tree, tree, sese)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c:2135:30: error: ‘replace_exp’ was not declared in this scope /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c: In function ‘void rewrite_cross_bb_scalar_dependence(scop_p, tree, tree, gimple)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c:2348:31: error: ‘replace_exp’ was not declared in this scope is the issue known? Trivially, a missing include? Thanks, Paolo.
Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope
On 10/02/2013 03:29 PM, Paolo Carlini wrote: Hi, currently bootstrap is broken for me with errors of this kind: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function ‘void canonicalize_loop_closed_ssa(loop_p)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope make[2]: *** [graphite-scop-detection.o] Error 1 make[2]: *** Waiting for unfinished jobs /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c: In function ‘void propagate_expr_outside_region(tree, tree, sese)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c:2135:30: error: ‘replace_exp’ was not declared in this scope /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c: In function ‘void rewrite_cross_bb_scalar_dependence(scop_p, tree, tree, gimple)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c:2348:31: error: ‘replace_exp’ was not declared in this scope is the issue known? Trivially, a missing include? Thanks, Paolo. Yeah, see http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00198.html Can you verify that adding #include "tree-ssa-propagate.h" to graphite-scop-detection.c and graphite-sese-to-poly.c solves the issue? I believe it to be an issue of not having CLOOG vs having it. And I dont have it which #ifdefs out a lot of code. Andrew
Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope
On 10/02/2013 03:33 PM, Andrew MacLeod wrote: On 10/02/2013 03:29 PM, Paolo Carlini wrote: Hi, currently bootstrap is broken for me with errors of this kind: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function ‘void canonicalize_loop_closed_ssa(loop_p)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope make[2]: *** [graphite-scop-detection.o] Error 1 make[2]: *** Waiting for unfinished jobs /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c: In function ‘void propagate_expr_outside_region(tree, tree, sese)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c:2135:30: error: ‘replace_exp’ was not declared in this scope /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c: In function ‘void rewrite_cross_bb_scalar_dependence(scop_p, tree, tree, gimple)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-sese-to-poly.c:2348:31: error: ‘replace_exp’ was not declared in this scope is the issue known? Trivially, a missing include? Thanks, Paolo. Yeah, see http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00198.html Can you verify that adding #include "tree-ssa-propagate.h" to graphite-scop-detection.c and graphite-sese-to-poly.c solves the issue? I believe it to be an issue of not having CLOOG vs having it. And I dont have it which #ifdefs out a lot of code. Andrew ie, like this And I'll check it in Andrew Index: graphite-scop-detection.c === *** graphite-scop-detection.c (revision 203121) --- graphite-scop-detection.c (working copy) *** along with GCC; see the file COPYING3. *** 38,43 --- 38,44 #include "tree-scalar-evolution.h" #include "tree-pass.h" #include "sese.h" + #include "tree-ssa-propagate.h" #ifdef HAVE_cloog #include "graphite-poly.h" Index: graphite-sese-to-poly.c === *** graphite-sese-to-poly.c (revision 203121) --- graphite-sese-to-poly.c (working copy) *** along with GCC; see the file COPYING3. *** 41,46 --- 41,47 #include "tree-scalar-evolution.h" #include "domwalk.h" #include "sese.h" + #include "tree-ssa-propagate.h" #ifdef HAVE_cloog #include "graphite-poly.h"
Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope
On 10/02/2013 09:35 PM, Andrew MacLeod wrote: ie, like this And I'll check it in Thanks. I'm bootstrapping while we speak. I'll let you know in a few minutes. Paolo.
Cilk Library
Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync implementation in GCC (patch submitted link: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to add a foreign library (Cilk Runtime Library) into the gcc repository. With this email, I am attaching the README file that will accompany Cilk Runtime Library (libcilkrts). I am also copy-pasting the header comment from one of the libcilkrts files. The header shown below will be in all the source files in libcilkrts. Does this look OK? Thanks, Balaji V. Iyer. /* cilk_api.c -*-C-*- * * * * @copyright * Copyright (C) 2009-2013, Intel Corporation * All rights reserved. * * @copyright * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * ** Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. ** Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. ** Neither the name of Intel Corporation nor the names of its * contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * @copyright * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS * OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY * WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. **/ README Description: README
Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope
.. patchlet worked for me. Thanks again! Paolo.
Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope
On 10/02/2013 03:55 PM, Paolo Carlini wrote: .. patchlet worked for me. Thanks again! NP.. , all checked in. thanks for testing it. Andrew
Re: Cilk Library
On 10/02/13 13:40, Iyer, Balaji V wrote: Dear steering committee, To support the _Cilk_spawn, and _Cilk_sync implementation in GCC (patch submitted link: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00859.html), we need to add a foreign library (Cilk Runtime Library) into the gcc repository. With this email, I am attaching the README file that will accompany Cilk Runtime Library (libcilkrts). I am also copy-pasting the header comment from one of the libcilkrts files. The header shown below will be in all the source files in libcilkrts. Does this look OK? I've forwarded this to the steering committee. jeff
