GCC 4.7.4 Released
The GNU Compiler Collection version 4.7.4 has been released. GCC 4.7.4 is the last bug-fix release from the GCC 4.7 branch containing important fixes for regressions and serious bugs in GCC 4.7.3 with more than 134 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
Re: Help understand the may_be_zero field in loop niter information
On Thu, Jun 12, 2014 at 7:59 PM, Zdenek Dvorak wrote: > Hi, > >> > I noticed there is below code/comments about may_be_zero field in loop >> > niter desc: >> > >> > tree may_be_zero;/* The boolean expression. If it evaluates to true, >> >the loop will exit in the first iteration (i.e. >> >its latch will not be executed), even if the niter >> >field says otherwise. */ >> > >> > I had difficulty in understanding this because I ran into some cases >> > in which it didn't behave as said. > > actually, in all the examples below, the field behaves as described, > i.e., > > the number of iterations = may_be_zero ? 0 : niter; > > In particular, the fact that may_be_zero is false *does not imply* > that the number of iterations as described by niter is non-zero. > >> > Example1, the dump of loop before sccp is like: >> > >> > : >> > bnd_4 = len_3(D) + 1; >> > >> > : >> > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> >> > _6 = ivtmp_1 + len_3(D); >> > _7 = a[ivtmp_1]; >> > _8 = b[ivtmp_1]; >> > _9 = _7 + _8; >> > a[_6] = _9; >> > ivtmp_11 = ivtmp_1 + 1; >> > if (bnd_4 > ivtmp_11) >> > goto ; >> > else >> > goto ; >> > >> > : >> > goto ; >> > >> > The loop niter information analyzed in sccp is like: >> > >> > Analyzing # of iterations of loop 1 >> > exit condition [1, + , 1] < len_3(D) + 1 >> > bounds on difference of bases: -1 ... 4294967294 >> > result: >> > zero if len_3(D) == 4294967295 >> > # of iterations len_3(D), bounded by 4294967294 >> > >> > Qeustion1, shouldn't it be like "len_3 +1 <= 1" because the latch >> > won't be executed when "len_3 == 0", right? > > the analysis determines the number of iterations as len_3, that is > 0 if len_3 == 0. So, the information is computed correctly here. > >> > But when boundary condition is the only case that latch get ZERO >> > executed, the may_be_zero info will not be computed. See example2, >> > with dump of loop before sccp like: >> > >> > foo (int M) >> > >> > : >> > if (M_4(D) > 0) >> > goto ; >> > else >> > goto ; >> > >> > : >> > return; >> > >> > : >> > >> > : >> > # i_13 = PHI <0(4), i_10(6)> >> > _5 = i_13 + M_4(D); >> > _6 = a[i_13]; >> > _7 = b[i_13]; >> > _8 = _6 + _7; >> > a[_5] = _8; >> > i_10 = i_13 + 1; >> > if (M_4(D) > i_10) >> > goto ; >> > else >> > goto ; >> > >> > : >> > goto ; >> > >> > The niter information analyzed in sccp is like: >> > >> > Analyzing # of iterations of loop 1 >> > exit condition [1, + , 1](no_overflow) < M_4(D) >> > bounds on difference of bases: 0 ... 2147483646 >> > result: >> > # of iterations (unsigned int) M_4(D) + 4294967295, bounded by >> > 2147483646 >> > >> > So may_be_zero is always false here, but the latch may be ZERO >> > executed when "M_4 == 1". > > Again, this is correct, since then ((unsigned int) M_4) + 4294967295 == 0. > >> > Start from Example1, we can create Example3 which makes no sense to >> > me. Again, the dump of loop is like: >> > >> > : >> > bnd_4 = len_3(D) + 1; >> > >> > : >> > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> >> > _6 = ivtmp_1 + len_3(D); >> > _7 = a[ivtmp_1]; >> > _8 = b[ivtmp_1]; >> > _9 = _7 + _8; >> > a[_6] = _9; >> > ivtmp_11 = ivtmp_1 + 4; >> > if (bnd_4 > ivtmp_11) >> > goto ; >> > else >> > goto ; >> > >> > : >> > goto ; >> > >> > : >> > return 0; >> > >> > The niter info is like: >> > >> > Analyzing # of iterations of loop 1 >> > exit condition [4, + , 4] < len_3(D) + 1 >> > bounds on difference of bases: -4 ... 4294967291 >> > result: >> > under assumptions len_3(D) + 1 <= 4294967292 >> > zero if len_3(D) == 4294967295 >> > # of iterations len_3(D) / 4, bounded by 1073741823 >> > >> > The problem is: won't latch be ZERO executed when "len_3 == 0/1/2/3"? > > Again, in all these cases the number of iterations is len_3 / 4 == 0. Thanks, I realized that boundary condition is described by niter part of information and it's more conveniently handled in this way for consumer of may_be_zero like IVOPT. One problem is with below example: : vectp_a.8_57 = &a; vectp_b.11_61 = &b; _67 = _1 * 4; vectp_a.15_66 = &a + _67; : # vectp_a.7_58 = PHI # vectp_b.10_62 = PHI # vectp_a.14_68 = PHI # ivtmp_9 = PHI <0(6), ivtmp_71(14)> vect__6.9_60 = MEM[(float *)vectp_a.7_58]; vect__7.12_64 = MEM[(float *)vectp_b.10_62]; vect__8.13_65 = vect__6.9_60 + vect__7.12_64; MEM[(float *)vectp_a.14_68] = vect__8.13_65; vectp_a.7_59 = vectp_a.7_58 + 16; vectp_b.10_63 = vectp_b.10_62 + 16; vectp_a.14_69 = vectp_a.14_68 + 16; ivtmp_71 = ivtmp_9 + 1; if (ivtmp_71 < bnd.4_36) goto ; else goto ; : goto ; After ivopt: : vectp_a.8_57 = &a; vectp_b.11_61 = &b; _67 = _1 * 4; vectp_a.15_66 = &a + _67; : # ivtmp.24_26 = PHI <0(6), ivtmp.24_33(14)> # ivtmp.27_88 = PHI <0(6), ivtmp.27_89(14)> vect__6.9_60 = MEM[symbol: a, index: ivt
Re: Help understand the may_be_zero field in loop niter information
On Fri, Jun 13, 2014 at 9:43 AM, Bin.Cheng wrote: > On Thu, Jun 12, 2014 at 7:59 PM, Zdenek Dvorak > wrote: >> Hi, >> >>> > I noticed there is below code/comments about may_be_zero field in loop >>> > niter desc: >>> > >>> > tree may_be_zero;/* The boolean expression. If it evaluates to >>> > true, >>> >the loop will exit in the first iteration (i.e. >>> >its latch will not be executed), even if the niter >>> >field says otherwise. */ >>> > >>> > I had difficulty in understanding this because I ran into some cases >>> > in which it didn't behave as said. >> >> actually, in all the examples below, the field behaves as described, >> i.e., >> >> the number of iterations = may_be_zero ? 0 : niter; >> >> In particular, the fact that may_be_zero is false *does not imply* >> that the number of iterations as described by niter is non-zero. >> >>> > Example1, the dump of loop before sccp is like: >>> > >>> > : >>> > bnd_4 = len_3(D) + 1; >>> > >>> > : >>> > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> >>> > _6 = ivtmp_1 + len_3(D); >>> > _7 = a[ivtmp_1]; >>> > _8 = b[ivtmp_1]; >>> > _9 = _7 + _8; >>> > a[_6] = _9; >>> > ivtmp_11 = ivtmp_1 + 1; >>> > if (bnd_4 > ivtmp_11) >>> > goto ; >>> > else >>> > goto ; >>> > >>> > : >>> > goto ; >>> > >>> > The loop niter information analyzed in sccp is like: >>> > >>> > Analyzing # of iterations of loop 1 >>> > exit condition [1, + , 1] < len_3(D) + 1 >>> > bounds on difference of bases: -1 ... 4294967294 >>> > result: >>> > zero if len_3(D) == 4294967295 >>> > # of iterations len_3(D), bounded by 4294967294 >>> > >>> > Qeustion1, shouldn't it be like "len_3 +1 <= 1" because the latch >>> > won't be executed when "len_3 == 0", right? >> >> the analysis determines the number of iterations as len_3, that is >> 0 if len_3 == 0. So, the information is computed correctly here. >> >>> > But when boundary condition is the only case that latch get ZERO >>> > executed, the may_be_zero info will not be computed. See example2, >>> > with dump of loop before sccp like: >>> > >>> > foo (int M) >>> > >>> > : >>> > if (M_4(D) > 0) >>> > goto ; >>> > else >>> > goto ; >>> > >>> > : >>> > return; >>> > >>> > : >>> > >>> > : >>> > # i_13 = PHI <0(4), i_10(6)> >>> > _5 = i_13 + M_4(D); >>> > _6 = a[i_13]; >>> > _7 = b[i_13]; >>> > _8 = _6 + _7; >>> > a[_5] = _8; >>> > i_10 = i_13 + 1; >>> > if (M_4(D) > i_10) >>> > goto ; >>> > else >>> > goto ; >>> > >>> > : >>> > goto ; >>> > >>> > The niter information analyzed in sccp is like: >>> > >>> > Analyzing # of iterations of loop 1 >>> > exit condition [1, + , 1](no_overflow) < M_4(D) >>> > bounds on difference of bases: 0 ... 2147483646 >>> > result: >>> > # of iterations (unsigned int) M_4(D) + 4294967295, bounded by >>> > 2147483646 >>> > >>> > So may_be_zero is always false here, but the latch may be ZERO >>> > executed when "M_4 == 1". >> >> Again, this is correct, since then ((unsigned int) M_4) + 4294967295 == 0. >> >>> > Start from Example1, we can create Example3 which makes no sense to >>> > me. Again, the dump of loop is like: >>> > >>> > : >>> > bnd_4 = len_3(D) + 1; >>> > >>> > : >>> > # ivtmp_1 = PHI <0(2), ivtmp_11(4)> >>> > _6 = ivtmp_1 + len_3(D); >>> > _7 = a[ivtmp_1]; >>> > _8 = b[ivtmp_1]; >>> > _9 = _7 + _8; >>> > a[_6] = _9; >>> > ivtmp_11 = ivtmp_1 + 4; >>> > if (bnd_4 > ivtmp_11) >>> > goto ; >>> > else >>> > goto ; >>> > >>> > : >>> > goto ; >>> > >>> > : >>> > return 0; >>> > >>> > The niter info is like: >>> > >>> > Analyzing # of iterations of loop 1 >>> > exit condition [4, + , 4] < len_3(D) + 1 >>> > bounds on difference of bases: -4 ... 4294967291 >>> > result: >>> > under assumptions len_3(D) + 1 <= 4294967292 >>> > zero if len_3(D) == 4294967295 >>> > # of iterations len_3(D) / 4, bounded by 1073741823 >>> > >>> > The problem is: won't latch be ZERO executed when "len_3 == 0/1/2/3"? >> >> Again, in all these cases the number of iterations is len_3 / 4 == 0. > > Thanks, I realized that boundary condition is described by niter part > of information and it's more conveniently handled in this way for > consumer of may_be_zero like IVOPT. One problem is with below > example: > > : > vectp_a.8_57 = &a; > vectp_b.11_61 = &b; > _67 = _1 * 4; > vectp_a.15_66 = &a + _67; > > : > # vectp_a.7_58 = PHI > # vectp_b.10_62 = PHI > # vectp_a.14_68 = PHI > # ivtmp_9 = PHI <0(6), ivtmp_71(14)> > vect__6.9_60 = MEM[(float *)vectp_a.7_58]; > vect__7.12_64 = MEM[(float *)vectp_b.10_62]; > vect__8.13_65 = vect__6.9_60 + vect__7.12_64; > MEM[(float *)vectp_a.14_68] = vect__8.13_65; > vectp_a.7_59 = vectp_a.7_58 + 16; > vectp_b.10_63 = vectp_b.10_62 + 16; > vectp_a.14_69 = vectp_a.14_68 + 16; > ivtmp_71 = ivtmp_9 + 1; > if (ivtmp_71 < bnd.4_36) > goto ; > else > goto ;
Should we be updating copyright years on branches?
I just realised that all our source files still say -2013 on the 4.8 branch, because the branch was created last year and the script to update all the files in January only gets run on trunk. Is that a problem, or is it OK for files on the branches to only have copyright dates up to the point the branch was created? http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices doesn't say anything either way about old branches, which would imply the copyright year should be updated when making any non-trivial changes on a branch, as for trunk (except we do it proactively in the new year for the trunk, not after changes are made).
RFC: New map kind for GOMP_target{,_data}
Hi!
Hacking on Fortran target support now, I ran into an issue with
Fortran array pointers or other types using array descriptors.
The problem is that right now for OpenMP (I think OpenACC has it different)
we have only the OpenMP mandates kinds (alloc, to, from, tofrom),
which have address, size, kind, alignment quadruplets (the last two
things encoded in a single byte), and one special kind, pointer,
which uses address, bias, kind, alignment quadruplet with
size being implicit - sizeof (void *). Pointer kind works like
alloc, with additional pointer assignment if it has been allocated
(read the host value of the pointer pointed by the address, add bias
to it, translate that address to target address, subtract bias and
store the result into the allocated target memory).
Fortran array descriptor is a pointer plus lots of other data though,
and I'm not sure we want to hardcode forever that the pointer must be
the first in there and certainly can't hardcode the array descriptor size.
Furthermore, if we used the pointer kind for the first sizeof(void*) bytes
of the descriptor and the to kind for the rest of the descriptor, which is
pretty much how we want it to behave, the library doesn't guarantee they
would be consecutive allocations in the target.
So, I'm afraid we need a new kind for this. I'm considering
kind pset (pointer set), which would be like to kind, but in addition to
that it would affect behavior of all following pointer kind map clauses
where the address falls into the pset range.
So, to describe a Fortran array descriptor (say rank 3), there would be e.g.
map (to: ptrvar [pointer set, len: 96]) map (alloc: ptrvar [pointer assign,
bias: 0])
which would transform into:
addr_array[] = { &ptrvar, &ptrvar };
size_array[] = { 96, 0 };
kind_array[] = { (align << 3) | 5, (align << 3) | 4 };
GOMP_target_* (..., addr_array, size_array, kind_array);
If the pset map would be found already allocated, it wouldn't do anything
beyond to kind, nothing and all the following pointer maps would also do
nothing (as they are already alocated too).
If it is found not to be allocated, it would allocate it, copy to target,
and for all immediately following pointer map would check if they fall into
the given host range, if it does, then it wouldn't ignore the pointer, just
wouldn't allocate it again, but would perform pointer assignment.
Does this sound ok to anyone?
Also, I'm afraid we'll need to ignore map clauses where the host address
is NULL, and for pointer assignment if host pointer is NULL assign NULL to
target.
Jakub
Re: Should we be updating copyright years on branches?
On 06/13/14 03:57, Jonathan Wakely wrote: I just realised that all our source files still say -2013 on the 4.8 branch, because the branch was created last year and the script to update all the files in January only gets run on trunk. Is that a problem, or is it OK for files on the branches to only have copyright dates up to the point the branch was created? If a release is made, then the copyright dates ought to be updated in files that have changed, at least that's always been my understanding. Jeff
Re: Should we be updating copyright years on branches?
> If a release is made, then the copyright dates ought to be updated in > files that have changed, at least that's always been my understanding. Yes, but that update should have been done *when the file was changed*. Or am I missing something here? Because anybody can take any of the files at any time, they always have to have an up-to-date copyright notice, reflecting when changes were made.
[RFC] Fortran: How to handle allocatable polymorphic components with OpenMPv5/OpenACCv3
This email is probably a bit premature as the OpenMPv4.0 and OpenACC 2.0a specs do not seem to handle Fortran 2003's polymorphic variables. However, as I am currently thinking how to handle a similar problem for Fortran's coarray, I want to raise the issue for OpenMP/OpenACC to see whether something should be done in gfortran to solve the problem for OpenMP/OpenACC and coarrays at the same time. For coarrays, see also https://gcc.gnu.org/ml/fortran/2014-06/msg00132.html The issue described below occurs when one needs to copy variables which are polymorphic or contain components which are polymorphic. That applies both to copying them to a thread-local variable or with offloading to the memory of an accelerator. In case of Fortran, doing an assignment of a derived type (record type) will also copy the allocatable components, which in turn might have again allocatable components. For nonpolymorphic variables, one can simply recursively walk through all components and do the copying that way. That's how the Fortran FE does for intrinsic assignments – and what Jakub's recently committed OpenMPv4.0 patch does. However, how to handle it for polymorphic types? In case of the intrinsic assignment, the variable/component has a pointer to a virtual table, which contains a function pointer to the type's copy function. But how to handle it in case of OpenMP (v4.1?, v5.0?)? One could augment the vtable by a function pointer to an function which handles this for OpenMP/OpenACC, probably by calling some libgomp library function. In case of coarrays, I have (see link above) the same problem: I need to add library calls to transfer allocatable components forth to and back from a remote process. Thus, I am also thinking of adding a new entry to the virtual table Another issue arises when one mixes code with and without -fopenmp/-facc/-fcoarray=lib. One either has to generate the vtable entry and function unconditionally – or only with that option, but then one might run into corner cases, where the function is not available. One option* I see is some kind of generic function, which takes as additional argument a function pointer; this pointer could point either to libgomp or to the coarray library (for -fcoarray=lib), depending on the caller. In addition, it avoids issues with dependencies on the called library. What do you think? Would this be a sensible way for OpenMPv5/OpenACCv3/coarrays? Or do you see pitfalls with this approach? One additional issue would be the way the arguments are passed, which one would have to agree on. Comments? Suggestions? Questions? Tobias * The other option is to generate specific functions, but that is not only less flexible but also runs into issues like library dependencies. Those can be solved with weak symbols and stubs, but that's also not very elegant.
gnat_rm.texi and makeinfo 5.1
Hi I am trying to build a native GNAT from the head on Fedora 20. It has makeinfo 5.1 which is causing gnat_rm.texi a lot of problems. This is just the beginning of almost 200 error messages. ../../gcc/gcc/ada/gnat_rm.texi:4107: warning: @itemize has text but no @item ../../gcc/gcc/ada/gnat_rm.texi:12057: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12068: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12080: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12091: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12101: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12112: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12121: @item outside of table or list cc'ing Eric B since I remember him mentioning that they autogenerated texinfo from Sphinx and I am wondering if this is manual or autogenerated. Other than fixing the manual or downgrading makeinfo, any suggestions or comments? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: gnat_rm.texi and makeinfo 5.1
pr61505 Dominique
Re: [GSoC] decision tree first steps
On Thu, Jun 12, 2014 at 4:26 PM, Richard Biener
wrote:
> On Wed, Jun 11, 2014 at 4:09 PM, Prathamesh Kulkarni
> wrote:
>> On 6/11/14, Richard Biener wrote:
>>> On Wed, Jun 11, 2014 at 12:53 PM, Richard Biener
>>> wrote:
On Wed, Jun 11, 2014 at 10:51 AM, Richard Biener
wrote:
> On Tue, Jun 10, 2014 at 1:57 PM, Richard Biener
> wrote:
> [...snip...]
>> But then why not generate
>>
>> if (!captures[0]
>> || captures[0] == op0)
>> {
>> captures[0] = op0;
>> // simplification code S1
>> return true;
>> }
>>
>> and go without label and goto? Or did I miss something?
>>
>>> c) Shared captures between all patterns:
>>> In the patch all patterns share the capture array tree captures[4] =
>>> {}
>>> (since all match patterns get interleaved in generated code off
>>> decision tree).
>>> This requires extra code to be generated to make sure captures are
>>> correctly restored for another pattern.
>
> Btw, I see that you back-track the decision tree. That is, for
>
> root
> |--operand: MINUS_EXPR
> |operand: PLUS_EXPR
> |--operand: @0
> |operand: @1
> |--operand: @0
> |simplify
> |--operand: @1
> |simplify
>
> you do
>
> if (code == MINUS_EXPR)
> {
> tree captures[4] = {};
> if (TREE_CODE (op0) == SSA_NAME)
> {
> gimple def_stmt = SSA_NAME_DEF_STMT (op0);
> if (is_gimple_assign (def_stmt) && gimple_assign_rhs_code
> (def_stmt) == PLUS_EXPR)
> {
> tree op01 = gimple_assign_rhs1 (def_stmt);
> if (valueize && TREE_CODE (op01) == SSA_NAME)
> op01 = valueize (op01);
> else
> goto L0;
> if (op01)
> {
> L0:
> tree op11 = gimple_assign_rhs2 (def_stmt);
> if (valueize && TREE_CODE (op11) == SSA_NAME)
> op11 = valueize (op11);
> else
> goto L1;
> if (op11)
> {
> L1:
> tree captures_0 = captures[0];
> if (!captures[0])
> {
> captures[0] = op01;
> goto L2;
> }
> else if (captures[0] == op01)
> {
> L2:
> tree captures_1 = captures[1];
> if (!captures[1])
> {
> captures[1] = op11;
> goto L3;
> }
> else if (captures[1] == op11)
> {
> L3:
> tree captures_2 = captures[0];
> if (!captures[0])
> {
> captures[0] = op1;
> goto L4;
> }
> else if (captures[0] == op1)
> {
> L4:
> res_ops[0] = captures[1];
> *res_code = TREE_CODE (res_ops[0]);
> return true;
> }
> captures [0] = captures_2;
> tree captures_3 = captures[1];
> if (!captures[1])
> {
> captures[1] = op1;
> goto L5;
> }
> else if (captures[1] == op1)
> {
> L5:
> res_ops[0] = captures[0];
> *res_code = TREE_CODE (res_ops[0]);
> return true;
> }
> captures [1] = captures_3;
> }
> captures [1] = captures_1;
> }
> captures [0] = captures_0;
> }
> }
> }
> }
>
> but if you processed all children of a decision tree node and didn't
> hit one of the simplifies (which return true) then you know nothing
> else will match and you can just return false. Th
Re: [GSoC] decision tree first steps
On June 13, 2014 11:48:13 PM CEST, Prathamesh Kulkarni
wrote:
>On Thu, Jun 12, 2014 at 4:26 PM, Richard Biener
> wrote:
>> On Wed, Jun 11, 2014 at 4:09 PM, Prathamesh Kulkarni
>> wrote:
>>> On 6/11/14, Richard Biener wrote:
On Wed, Jun 11, 2014 at 12:53 PM, Richard Biener
wrote:
> On Wed, Jun 11, 2014 at 10:51 AM, Richard Biener
> wrote:
>> On Tue, Jun 10, 2014 at 1:57 PM, Richard Biener
>> wrote:
>> [...snip...]
>>> But then why not generate
>>>
>>> if (!captures[0]
>>> || captures[0] == op0)
>>> {
>>> captures[0] = op0;
>>> // simplification code S1
>>> return true;
>>> }
>>>
>>> and go without label and goto? Or did I miss something?
>>>
c) Shared captures between all patterns:
In the patch all patterns share the capture array tree
>captures[4] =
{}
(since all match patterns get interleaved in generated code off
decision tree).
This requires extra code to be generated to make sure captures
>are
correctly restored for another pattern.
>>
>> Btw, I see that you back-track the decision tree. That is, for
>>
>> root
>> |--operand: MINUS_EXPR
>> |operand: PLUS_EXPR
>> |--operand: @0
>> |operand: @1
>> |--operand: @0
>> |simplify
>> |--operand: @1
>> |simplify
>>
>> you do
>>
>> if (code == MINUS_EXPR)
>> {
>> tree captures[4] = {};
>> if (TREE_CODE (op0) == SSA_NAME)
>> {
>> gimple def_stmt = SSA_NAME_DEF_STMT (op0);
>> if (is_gimple_assign (def_stmt) &&
>gimple_assign_rhs_code
>> (def_stmt) == PLUS_EXPR)
>> {
>> tree op01 = gimple_assign_rhs1 (def_stmt);
>> if (valueize && TREE_CODE (op01) == SSA_NAME)
>> op01 = valueize (op01);
>> else
>> goto L0;
>> if (op01)
>> {
>> L0:
>> tree op11 = gimple_assign_rhs2 (def_stmt);
>> if (valueize && TREE_CODE (op11) == SSA_NAME)
>> op11 = valueize (op11);
>> else
>> goto L1;
>> if (op11)
>> {
>> L1:
>> tree captures_0 = captures[0];
>> if (!captures[0])
>> {
>> captures[0] = op01;
>> goto L2;
>> }
>> else if (captures[0] == op01)
>> {
>> L2:
>> tree captures_1 = captures[1];
>> if (!captures[1])
>> {
>> captures[1] = op11;
>> goto L3;
>> }
>> else if (captures[1] == op11)
>> {
>> L3:
>> tree captures_2 = captures[0];
>> if (!captures[0])
>> {
>> captures[0] = op1;
>> goto L4;
>> }
>> else if (captures[0] == op1)
>> {
>> L4:
>> res_ops[0] = captures[1];
>> *res_code = TREE_CODE
>(res_ops[0]);
>> return true;
>> }
>> captures [0] = captures_2;
>> tree captures_3 = captures[1];
>> if (!captures[1])
>> {
>> captures[1] = op1;
>> goto L5;
>> }
>> else if (captures[1] == op1)
>> {
>> L5:
>> res_ops[0] = captures[0];
>> *res_code = TREE_CODE
>(res_ops[0]);
>> return true;
>> }
>> captures [1] = captures_3;
>> }
>> captures [1] = captures_1;
>> }
>> captures [0] = captures_0;
>> }
>> }
>> }
>> }
>>
>> but
Re: gnat_rm.texi and makeinfo 5.1
> cc'ing Eric B since I remember him mentioning that they autogenerated > texinfo from Sphinx and I am wondering if this is manual or autogenerated. No, that was me, mentioning that we were planning to do that in the future, but not yet. > Other than fixing the manual or downgrading makeinfo, any suggestions > or comments? makeinfo 4.8 does work indeed. I'm sure there's a simple way to modify the syntax here to be suitable for more recent versions of makeinfo. Arno
