Re: Tree aliasing

[Richard Guenther]

On Tue, Aug 4, 2009 at 4:25 AM, Andrew Pinski wrote:
> I was improving tree aliasing for pointers by adding support a+1 and a
> not aliasing.  But I ran into a bug in the aliasing where:
>  /* If both references are through the same type, they do not alias
>     if the accesses do not overlap.  This does extra disambiguation
>     for mixed/pointer accesses but requires strict aliasing.  */
>  if (same_type_for_tbaa (TREE_TYPE (TREE_TYPE (ptr1)),
>                          TREE_TYPE (TREE_TYPE (ptr2))) == 1)
>    return ranges_overlap_p (offset1, max_size1, offset2, max_size2);
>
> Would return false even.  I can't see how this can be true if one
> pointer is defined as an offset as the other and the offset1 or
> offset2 are non zero.
>
> Can someone explain why this is true?

This is true because if you have two pointers pointing to the indentical
type T then with strict-aliasing you either have a full overlap
(ptr1 == ptr2) or no overlap.  I can see one mistake here in that
the offsets (I need to think about the max-sizes) need to be modulo
the size of the pointed-to type, but
other than that it's ok.  A fix for that is appreciated (together with
a testcase of course).

Richard.

> Even nonaliasing_component_refs_p looks to have the same issue if the
> types are the same, they could be an extra offset from each other,
> even though the compiler cannot figure that out.  I am thinking of
> when storing the pointer in an array and then accessing that pointer.
>
> gcc.dg/20030324-1.c is the testcase where I am running into this bug too.
>
> Thanks,
> Andrew Pinski
>

Re: [lambda] Segmentation fault in simple lambda program

[Adam Butcher]

Jason Merrill wrote:
> On 08/03/2009 09:36 PM, Adam Butcher wrote:
>> Thanks.  I haven't any copyright assignments on file -- this is my first 
>> dabbling with gcc and I've been doing it
>> mostly to experiment with C++ lambda support and non-standard extensions 
>> such as polymorphic lambda support.
>
> OK.  We'll need an assignment in order to incorporate your changes into
> GCC.  If you want to assign all present and future changes to the
> compiler, you could use the form
>
OK I've kicked that off.

>> I've been working in my own repository which I rebased earlier today from 
>> trunk (r150148).  I've attached the
>> rebase including the fix for generating correct copying of lambda classes 
>> (re-laying out after parsing body).

> Hmm, having the new changes folded into the old changes is kind of
> inconvenient, but I suppose I can deal.  It's moot anyway until your
> assignment is on file.
>
Yes sorry about that.  I appreciate the issue.  I had taken a branch of trunk 
and applied the lambda changes to it to
keep only lambda changes on my working branch (allowing simpler future 
rebaseing).  There were a number of things I
had to change to to get the lambda changes a) building and b) working with test 
programs.  Unfortunately I did all
this in one commit.  Not very helpful.  I will mail you my 'fixes' diff against 
the latest lambda branch head
independent of the rebase noise if you want.

> Incidentally, comments like
>
> /*
>   *
>   *
>   */
>
> aren't customary in GCC sources; that's just something John did that
> we'll need to clean up before the code goes into the trunk.  There are
> other formatting irregularities, some of which I've corrected.
>
Ah I see.  I was following the principle of following the nearest style!  I 
have reworked my changes in this style.

>> Experimenting with a working version and seeing it's issues will be useful 
>> to me.  To others to maybe.  With
>> concepts
>> gone from C++0x and being reworked for C++15(?) maybe support for 
>> polymorphic lambdas could be reintroduced? --
>> though
>> I'm sure its much too late for that and that its likely been around the buoy 
>> many times.  From what I have read I
>> got
>> the idea that the Callable concept was the primary reason for polymorphic 
>> lambdas not being accepted.
>
> I don't know what the reasoning was there, but people have been somewhat
> conservative about what usages of lambdas are allowed for fear of
> unforseen implementation issues.  Certainly having a working
> implementation would go a lot toward convincing people to allow it, even
> if it doesn't make it into C++0x.
>
Hopefully.  From my point of view the class generated by a lambda expression 
should be equivalent to something you
could write yourself -- aside from the single stack-pointer reference 
optimization which only a compiler could achieve
-- the class has a name, albeit invisible to the user (except in 
errors/warnings), and instances of should be useable
just as if there were user-defined functors.  I'm sure there are things I've 
overlooked but hopefully this
proof-of-concept will help to allay people's fears.

>> Implied template typename arguments via auto are not currently supported.  
>> The syntax parses but I haven't yet
>> synthesized the template arguments and therefore not replaced the auto's 
>> with them so it doesn't compile.
>
> Since templates work so differently from normal functions, I'm a little
> uncomfortable with the idea of templates that don't involve any template
> syntax, just the use of auto in the parameter list.  But I'm open to
> giving it a try, at least in the lambda context.  Maybe outside of
> lambda it could be used with a small template introducer...
>
I did think about auto as a shortcut for template typename outside of lambdas 
but I figured that was pushing it a bit
too far.  It wouldn't be obvious that a function declared in that way was 
actually a function template.  The benefit
of using it in lambdas is that the call operator is never 'seen', so whether 
its a template or not shouldn't affect
the caller providing the input arguments are compatible.

>> I'd welcome feedback on the syntax and semantics and of course any 
>> fundamental things I've missed by coming up with
>> such a syntax!
>>
>>  From a grammar point of view I've just expanded 
>> lambda-parameter-declaration to start with:
>>lambda-template-param-decl [opt]
>> where lambda-template-param-decl is:
>><  template-parameter-list>
>
> Makes sense.  I suppose to specify explicit template arguments users
> would have to write
>
> lambdaob.operator()(fn-arg)
>
That would be the case for explicit instantiation yes.  With my implementation 
you could only get such as nullary
function template if you explicitly specified the template parameters and 
explicitly specified an empty call argument
list.  I've made the template parameter list optional within the already 
optional lambda-parameter-declaration.  If
present, it has to be fo

���� ��� �o��� � ������ ��e�o �� 1�900�000.

[553710]

Ïpeäcòàâëÿåì Âaì çeìåëüíûå ó÷añtêè ñ ïîñòðîéêîé èëè áeç íà Ñèìôèðîïîëüñêîì 
øîñcå , óäàëåííîñtü oò ÌÊÀÄ 39-64 kì . Â êîòòeäæíoì ïîñåëkå - èíôpàcòpóêòyðà , 
ïpîâåäeíû ýëåkòpè÷ecòâî, ãàç .
 

 
Êîòtåäæíûé ïîñåëîê íà Ñèìôåðîïîëüñêîm øîcñå - ýòo îïòèìaëüíîå ìeñtî äëÿ 
ïðoæèâàíèÿ è îòäûxà. È ìàëåíüêèå oáèòàòeëè ïîñeëkà íå îñtàíótñÿ áåç âíèìàíèÿ: â 
øàãoâîé äîñòóïíîñòè íåîáxîäèìûå îáúåêòû èíôðàñòpóêòyðû.
 

 
Ó÷àcòêè çeìeëüíûe ñ kîmmóíèêàöèÿìè oò 9 - 21 ñîòîê íà Ñèìôåðîïîëückîì øoññå . 
Íàõîäèòñÿ îêîëî îò âoäîeìà, ëåñà . Êpèçèñíûå öåíû!
 

 
Âñåão çà 1900 0 00 äom ñ y÷actêîì ía Ñèmôåðîïîëüñêîì øîcñå , 68kì.
 

 
Çâîíèòå ïî tåë. :   (499) 5O2   I0 - 93 

Re: PR33113

[Dorit Nuzman]

Jack Howarth  wrote on 03/08/2009 17:26:18:

> Ira and Dorit,
>Is there any chance that PR33113 will be addressed for
> gcc 4.5? If I recall correctly, it was one of the last
> major issues with vectorization in gfortran that wasn't
> addressed yet. Dorit made the following comment back in
> Aug 2008...
>

Hi Jack,
AFAIK this topic has not been addressed (closest thing is Richard
Guenther's work on versioning unknown strides
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
about the prospects of this being done for gcc4.5 (I'd definitely lobby for
it... do you know which of the polyhedron benchmarks have this issue,
and/or which other benchmarks suffer from it?)
Thanks for the reminder...
dorit

> >From: Dorit Nuzman 
> >Date: Tue, 12 Aug 2008 14:48:07 +0300
> >X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.
> 1|February 07, 2008) at
> > 12/08/2008 14:43:23
> >MIME-Version: 1.0
> >Content-type: text/plain; charset=US-ASCII
> >Status: RO
> >X-Status: A
> >Content-Length: 11751
> >Lines: 335
> >
> >Jack Howarth  wrote on 10/08/2008 19:00:08:
> >
> >> Dorit,
> >> I believe the attached email has the most detailed discussion of
the
> >> issue that I recall seeing. Perhaps Tobias can expand on these
previous
> >> conversations.
> >>   Jack
> >> ps I was hoping that the graphite code generation would be enabled by
> >>default
> >> at -O3 in gcc 4.4 and that the vectorization code could be modified to
> >utilize
> >> its presence to do some optimizations on gfortran flat arrays which
will
> >now
> >> have stride information via graphite.
> >
> >Hi Jack,
> >
> >There is currently no connection between the Graphite pass and any
passes
> >that follow it. We will be looking into how to incorporate vectorization
> >with Graphite, but that will not happen during the 4.4 timeframe.
However,
> >I think that this is not a prerequisite for vectorizing flat arrays;
AFAIU,
> >Graphite itself is based on the scev analysis, so whichever stride
> >information Graphite gets out of scev, the vectorizer can already get it
> >too. Following our discussion below I had opened PR33113, where it
turned
> >out that scev can easily be made to return symbolic stride information
> >instead of failing, and the problem is only inside the vectorizer which
> >needs to be enhanced to handle symbolic strides. I would actually be
> >interested in enabling that - I will try to look into it in the coming
> >weeks.
> >
> >dorit
>
> I ask because we seem to only get marginal improvements in the Polyhedron
> 2005 benchmarks between recent releases and these missed vectorization
> opportunities might provide a significant performance increase for those
> benchmarks. Thanks in advance for any clarifications.
>Jack

Re: MELT tutorial on the wiki

[Dave Korn]

Tom Tromey wrote:
>> "Dave" == Dave Korn  writes:
> 
> Dave> Were you using a --prefix?  The PPL checks (by design I think) only
> Dave> look for PPL in your prefix.
> 
> Dave>   I do not know it; I have merely observed the behaviour.  It may
> Dave> even not be by design for all I know, though I suspect it makes
> Dave> sense - where else would you look but in the prefix?  Prefixes
> Dave> exist to create separation between packages.
> 
> That didn't seem to be what the code on Basile's branch does.
> 
> But, if this is what the PPL checks do actually do somewhere, then they
> are broken.  Prefix is for specifying the install tree -- specifying how
> the build is done is handled by other options.

  Ah, I think I misunderstood what's going on.  If you specify --with-ppl, what
happens:

> AC_ARG_WITH(ppl, [  --with-ppl=PATH Specify prefix directory for the 
> installed PPL package
>   Equivalent to --with-ppl-include=PATH/include
>   plus --with-ppl-lib=PATH/lib],, with_ppl=no)
> AC_ARG_WITH(ppl_include, [  --with-ppl-include=PATH Specify directory for 
> installed PPL include files])
> AC_ARG_WITH(ppl_lib, [  --with-ppl-lib=PATH Specify the directory for the 
> installed PPL library])
> 
> case $with_ppl in 
>   no)
> ppllibs=
> ;;
>   *)
> ppllibs="-L$with_ppl/lib -lppl_c -lppl -lgmpxx"
> pplinc="-I$with_ppl/include $pplinc"
> LIBS="$ppllibs $LIBS"
> ;;
> esac

... is that it looks in /lib and /include, which is fairly likely to succeed -
but only because you'll also have $prefix/lib and $prefix/include in the -L and
-I settings anyway (when compiling stages 2/3 and target libs).  Change your
--prefix setting to some other tree where you don't have a PPL installation and
all of a sudden using plain "--with-ppl" will fail, and you may think it's
because it is looking for ppl in $prefix, when in fact the answer is that it
should complain about an empty --with-ppl with no argument.

cheers,
  DaveK

Re: PR33113

[Jack Howarth]

On Tue, Aug 04, 2009 at 12:35:15PM +0300, Dorit Nuzman wrote:
> 
> Hi Jack,
> AFAIK this topic has not been addressed (closest thing is Richard
> Guenther's work on versioning unknown strides
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
> about the prospects of this being done for gcc4.5 (I'd definitely lobby for
> it... do you know which of the polyhedron benchmarks have this issue,
> and/or which other benchmarks suffer from it?)
> Thanks for the reminder...
> dorit
> 

Dorit,
   While I don't have the list of effected benchmarks handy, a testcase which 
Tobias Burnus
made is discussed in the previous email below. I believe the issue was supposed 
to be pretty
wide spread in the benchmarks.
Jack

> > Tobias Burnus  wrote on 13/08/2007 22:58:54:
>
> > Hi Dorit and Jack,
> >
> > Dorit Nuzman wrote:
> > > I actually wouldn't expect much improvement yet, as this initial
> version
> > > still has quite a few limitations. But if there are loops that you
> expect
> > > to get vectorized that do not, I'd be happy to take a look.
> > >
> > If something can be improved in the frontend, please tell us/the
> > gfortraners.
> >
> > Neither of the two loops get vectorized; the first one should be easier
> > than the second one:
> >
> > subroutine sub(aa,bb,n,m)
> >   implicit none
> >   integer, intent(in) :: n,m
> >   real, intent(inout) :: aa(n,m)
> >   real, intent(in):: bb(n,m)
> >   integer :: i,j
> >   do i = 1,m
> > do j= 2,n
> >   aa(i,j)= aa(i,j-1)+bb(i,j-1)
> > enddo
> >   enddo
> >   do j= 2,n
> > do i = 1,m
> >   aa(i,j)= aa(i,j-1)+bb(i,j-1)
> > enddo
> >   enddo
> > end subroutine
> > end
> >
> > First loop:
> > a.f90:8: note: not vectorized: data ref analysis failed D.1462_61 =
> > (*aa_60(D))[D.1461_59]
>
> Here, AFAIU, the inner-loop accesses non-consecutive data, whereas the
> outer-loop accesses consecutive data. So the only way to vectorize this
> loop is either to interchange the loops, or to do outer-loop
vectorization
> (unless we want to gather disjoint elements in each vectorized inner-loop
> iteration, which probably we don't). What fails the outer-loop vectorizer
> (i.e. when attempting to vectorize the loop in line 7) is the fact that
the
> inner-loop bound is unknown, in which case the compiler creates a
> guard-code before the inner-loop to decide whether to skip it or not,
which
> makes the structure of the outer-loop more complicated than is currently
> unhandled. (This is also what I referred to here:
> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00743.html).
> So we get:
>   a.f90:7: note: not vectorized: too many BBs in loop.
> To work around that (just to see how far we can get) I put in constant
> bound for the inner-loop. Now outer-loop vectorization fails with:
>   a.f90:7: note: not vectorized: data ref analysis failed D.1444_64 =
> (*aa_63(D))[D.1443_62]
>   a.f90:7: note: bad data references.
> This is because the stride in the inner-loop is unknown (because I guess
> the dimention size is unknown). You can see that the data-ref analyzer
> reports:
>   "failed: evolution of offset is not affine."
> I'll bring it up with Sebastian and Zdenek, see what they think can be
done
> within the data-ref analyzer in this resepct.
>
> After outer-loop vectorization fails we move on to vectorize the loop in
> line 8, and fail with the same data-ref analysis problem (unknown
stride).
> So for now, we need a testcase with a known inner-loop bound and known
> dimentions/strides.
> However, even when we are able to overcome all the above, we still won't
be
> able to vectorize the loop unless the inner-loop execution order is
> reversed (otherwise there's a true dependnece from a(i,j) to a(i,j-1)).
> ifort probably has loop reversal capabilities. We don't reverse loops yet
> in the middle-end, and also we don't vectorize loops with a reverse
access
> yet.
>
> > Second loop:
> > a.f90:13: note: Unknown alignment for access: *aa_60(D)
> > a.f90:13: note: Unknown alignment for access: *bb_68(D)
> > a.f90:13: note: Unknown alignment for access: *aa_60(D)
> > a.f90:13: note: not vectorized: can't determine dependence between
> > (*aa_60(D))[D.1461_59] and (*aa_60(D))[D.1456_53]
> >
>
> Here, the outer-loop (in line 12) accesses non-consecutive data, whereas
> the inner-loop (in line 13) accesses consecutive data, so the inner-loop
is
> a better candidate for vectorization. At first, the outer-loop vectorizer
> fails with:
>   a.f90:12: note: not vectorized: too many BBs in loop.
> (same as above), but after I change the inner-loop bound to a constnat it
> fails with:
>   a.f90:12: note: evolution of offset is not affine.
> (again, same problem as above, because the outer-loop stride is unknown).
>
> Moving on to the loop at line 13, we get:
>   a.f90:13: note: not vectorized: can't determine dependence between
> (*aa_63(D))[D.1443_91] and (*aa_63(D))[D.1438_85]
>   a.f90:13: note: bad data depende

Re: [lambda] Segmentation fault in simple lambda program

[Adam Butcher]

Hi Jason,

Pending response from assign at gnu dot org, I've attached diffs made against 
your latest lambda head.  They are
cleaned up a little to from the previous diffs against trunk.  First is the 
re-layout fix, second is experimental
polymorphic lambda support.

Cheers,
Adam


0001-Re-laid-out-lambda-class-after-parsing-body.patch
Description: Binary data


0002-First-pass-polymorphic-lambda-support.patch
Description: Binary data

Re: [lambda] Segmentation fault in simple lambda program

[John Freeman]

Adam Butcher wrote:


Hopefully.  From my point of view the class generated by a lambda expression 
should be equivalent to something you
could write yourself -- aside from the single stack-pointer reference 
optimization which only a compiler could achieve
-- the class has a name, albeit invisible to the user (except in 
errors/warnings), and instances of should be useable
just as if there were user-defined functors.  I'm sure there are things I've 
overlooked but hopefully this
proof-of-concept will help to allay people's fears.
  


In my opinion, lambdas are not intended as just a shortcut to writing a 
function object class.  This is why our proposal did not require that 
lambdas be implemented as classes; it is simply one implementation.  
(Awaiting word to see if this is still the case in the working draft of 
the standard; it may not be, but that doesn't change my opinion :)  
Thus, users should never see the class name.  In warnings and errors, a 
lambda should be treated like an anonymous class, swapping its 
compiler-generated name with a placeholder like  
(similar to ).  Additionally, users should never be 
able to instantiate a function call operator member, as below:



Makes sense.  I suppose to specify explicit template arguments users
would have to write

lambdaob.operator()(fn-arg)


  
That would be the case for explicit instantiation yes.  With my implementation you could only get such as nullary

function template if you explicitly specified the template parameters and 
explicitly specified an empty call argument
list.  I've made the template parameter list optional within the already 
optional lambda-parameter-declaration.  If
present, it has to be followed by a function parameter list.  The intent of 
course is that any template parameters
will be referenced in the function parameter list.  Though it does not prevent 
having unreferenced template parameters
that would need to be explicitly bound.


If a higher-order function were to accept a "function-like object" and 
instantiate its function call operator member, then it is using it as a 
class, and should not pretend to accept function pointers or lambdas.  
The argument types of a lambda function can be deduced from the context 
of the lambda expression, meaning a template constant lambda function 
should never be necessary.


  

Since templates work so differently from normal functions, I'm a little
uncomfortable with the idea of templates that don't involve any template
syntax, just the use of auto in the parameter list.  But I'm open to
giving it a try, at least in the lambda context.  Maybe outside of
lambda it could be used with a small template introducer...



In response to Jason's concern here, a template implementation is not 
required, just convenient.  Hopefully you won't think of it as 
"templates without template syntax", but "deduction using the existing 
template mechanism".



[snip]  The benefit
of using it in lambdas is that the call operator is never 'seen', so whether 
its a template or not shouldn't affect
the caller providing the input arguments are compatible.
  


Exactly.


so we'd really expect them to be only deduced.


Yes.
  


Exactly.


When I last left the discussion, the biggest
issue in my opinion was concept map dropping.  The workaround made the
deduction algorithm intimidatingly complex.



I am not up to speed with the issues but they obviously exist.  One thing I 
don't understand, and perhaps you could
help, is that whatever issues polymorphic lambdas have -- surely manually 
written function objects with template call
operators have the same issues.  Is this true?  


We did not want (and I doubt a concept proposal would approve) 
polymorphic lambdas to interrupt the modular type checking of 
constrained templates, i.e. templates using concepts, so the constraints 
would have to be deduced and added to the function call operator (in a 
class implementation for lambdas).  Hand-written function object classes 
bypass this issue by not allowing the deduction of constraints - they 
must be hand-written if the function object class is to be used in a 
constrained context.



And if so does it mean that future standard library algorithms will be
more constraining than exisiting ones -- or am I barking up the wrong tree?
  


When concepts come, standard library algorithms /will/ be constrained, 
but not to disallow any correct uses.  The constraints /will/ expose 
improper uses of the standard library.


- John

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-03 15:52:37 +0200, Unruh, Erwin wrote:
> In current gcc the order of options -D and -U is significant. The
> Single Unix(r) Specification explicitly specifies that the order
> should not matter for the c89 command. It reads (cited from
> version 2, which is ten years old):
[...]

FYI, I reported a bug there:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960

(but I mentioned c99 instead of c89, as this is what's in the
current discussion in the austin-group list).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-04 08:23:52 +0200, Paolo Bonzini wrote:
> User-specified CFLAGS are always passed last in the Makefiles (at
> least for Automake, but it is a good practice in general) so that
> the user can override options like -D, -U, -O, -g, -f, -m.
> 
> The specified behavior would make this impossible.

Yes, but this is already non-portable anyway and there are other
things that are impossible (such as overriding -I). How about a
new way to override options or define a precedence and which could
work with other options?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: [lambda] Segmentation fault in simple lambda program

[Jason Merrill]

On 08/04/2009 09:35 AM, John Freeman wrote:


In my opinion, lambdas are not intended as just a shortcut to writing a
function object class. This is why our proposal did not require that
lambdas be implemented as classes; it is simply one implementation.
(Awaiting word to see if this is still the case in the working draft of
the standard; it may not be, but that doesn't change my opinion :)


From N2859: "The type of the lambda-expression (which is also the type 
of the closure object) is a unique, unnamed non-union class type—called 
the closure type"


IMO, it's better to define new functionality in terms of already 
familiar features rather than have to specify everything about how a new 
feature interacts with the rest of the language.



Thus,
users should never see the class name. In warnings and errors, a lambda
should be treated like an anonymous class, swapping its
compiler-generated name with a placeholder like 
(similar to ).


Yep.


Since templates work so differently from normal functions, I'm a little
uncomfortable with the idea of templates that don't involve any template
syntax, just the use of auto in the parameter list. But I'm open to
giving it a try, at least in the lambda context. Maybe outside of
lambda it could be used with a small template introducer...


In response to Jason's concern here, a template implementation is not
required, just convenient. Hopefully you won't think of it as "templates
without template syntax", but "deduction using the existing template
mechanism".


As above, suggesting that it doesn't have to be a template suggests that 
there's a lot more specification left to do, such as how do you deal 
with expressions whose type you don't know yet?  If you allow non-lambda 
uses, how do they fit into overload resolution?  If you just say it's a 
template, we already know how they work.


Jason

Re: [lambda] Segmentation fault in simple lambda program

[John Freeman]

Jason Merrill wrote:

On 08/04/2009 09:35 AM, John Freeman wrote:


In my opinion, lambdas are not intended as just a shortcut to writing a
function object class. This is why our proposal did not require that
lambdas be implemented as classes; it is simply one implementation.
(Awaiting word to see if this is still the case in the working draft of
the standard; it may not be, but that doesn't change my opinion :)


From N2859: "The type of the lambda-expression (which is also the type 
of the closure object) is a unique, unnamed non-union class 
type—called the closure type"


Yes, this is the wording I'm worried about (it changed in N2914, but is 
similar).  I don't think it was in our original proposal.  I'm awaiting 
a response from Daveed Vandevoorde to see if it prescribes an 
implementation.




IMO, it's better to define new functionality in terms of already 
familiar features rather than have to specify everything about how a 
new feature interacts with the rest of the language.


Right.  We defined the new functionality in terms of existing 
functionality for just this reason, but we did not prescribe an 
implementation (similar to other features in the standard).  Granted, a 
class is the obvious and intended implementation, but we don't want to 
prevent optimizations where possible, as long as they preserve 
behavior.  I'm not sure if this allowance is implicit in the wording; 
I'm not a standardese expert.  Hopefully, this answers the below as well.




In response to Jason's concern here, a template implementation is not
required, just convenient. Hopefully you won't think of it as "templates
without template syntax", but "deduction using the existing template
mechanism".


As above, suggesting that it doesn't have to be a template suggests 
that there's a lot more specification left to do, such as how do you 
deal with expressions whose type you don't know yet?  If you allow 
non-lambda uses, how do they fit into overload resolution?  If you 
just say it's a template, we already know how they work.


Reiterating, to allow more freedom in implementation, we can just say it 
"behaves as" a template, rather than "is" a template.


- John

Re: [lambda] Segmentation fault in simple lambda program

[Jason Merrill]

On 08/04/2009 04:52 AM, Adam Butcher wrote:

Yes sorry about that.  I appreciate the issue.  I had taken a branch of trunk 
and applied the lambda changes to it to
keep only lambda changes on my working branch (allowing simpler future 
rebaseing).  There were a number of things I
had to change to to get the lambda changes a) building and b) working with test 
programs.  Unfortunately I did all
this in one commit.  Not very helpful.  I will mail you my 'fixes' diff against 
the latest lambda branch head
independent of the rebase noise if you want.


No need, it was easy enough to just apply it on another branch and 
compare against my branch.  Git makes so many things easier...



Hopefully.  From my point of view the class generated by a lambda expression 
should be equivalent to something you
could write yourself -- aside from the single stack-pointer reference 
optimization which only a compiler could achieve
-- the class has a name, albeit invisible to the user (except in 
errors/warnings), and instances of should be useable
just as if there were user-defined functors.  I'm sure there are things I've 
overlooked but hopefully this
proof-of-concept will help to allay people's fears.


I agree.

Incidentally, how does it work to just move the existing call of 
finish_struct to after we parse the body?  I don't see why we need it to 
be complete while we're in the body.


I suppose I'll go ahead and review the current code; I haven't really 
looked at it closely yet.


Jason

Re: [lambda] Segmentation fault in simple lambda program

[Jason Merrill]

On 08/04/2009 10:17 AM, John Freeman wrote:

Reiterating, to allow more freedom in implementation, we can just say it
"behaves as" a template, rather than "is" a template.


I don't see the difference.  As long as they work the same, the compiler 
is free to do whatever it wants internally.


Jason

GCC 4.3.5 Status Report (2009-08-04)

[Richard Guenther]

Status
==

The 4.3.4 release has been created and the final bits of the release
process will be carried out soon.

The 4.3 branch is now open again for checkins under the usual release
branch rules (regression and documentation fixes only).  A 4.3.5
release is expected shortly after the 4.4.2 release.

Quality Data


Priority #Changes from Last Report
   ---
P1   0+-0
P2 132+-0
P3   1 +1
-  ------
Total  133 +1

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-07/msg00561.html


The next report will be sent by Jakub.

Re: order of -D and -U is significant

[Tom Tromey]

> "Erwin" == Unruh, Erwin  writes:

Erwin> In current gcc the order of options -D and -U is significant. The
Erwin> Single Unix(r) Specification explicitly specifies that the order
Erwin> should not matter for the c89 command. It reads (cited from
Erwin> version 2, which is ten years old):

Erwin> I did not find a justification for the current gcc
Erwin> behavior.

GCC's behavior is more useful.  And, given its age, I think it would be
a mistake to change it.

I think if you want the c89 behavior, a wrapper program of some kind
would be the way to go.

Tom

Re: [lambda] Segmentation fault in simple lambda program

[Richard Henderson]

On 08/03/2009 09:39 PM, John Freeman wrote:

* Instead of transforming:
*
* [&] { i = 1; j = 2; k = 3; };
*
* into
*
* [&i,&j,&k] { i = 1; j = 2; k = 3; };
*
* and thus storing three pointers to int, transform it into:
*
* [sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1;
* var-from-stack(j,sp) = 2;
* var-from-stack(k,sp) = 3; };
*
* and only store one pointer.


This is preferred for reference default captures, but I was not familiar
with stack pointer mechanics in GCC. I just wanted to get something
working first that could be improved later.


Have a look at the documentation at the beginning of tree-nested.c.
Having something so magic as an "enclosing stack pointer" got us into
a lot of trouble in the past.  It's much better to be explicit about
things and create a struct to pop onto the stack of the caller.

Lets say you have

  int i, j, k, l;
  ...
  [&] { return i + j + k; }
  ...
  [&] { return j + k + l; }

you'd create a

  struct frame
  {
int i,j,k,l;
  };

  frame f;
  [&f] { return f.i + f.j + f.k; }
  [&f] { return f.j + f.k + f.l; }

which is effectively what tree-nested.c does.


r~

Re: extern variable

[sumanth]

Hi jim ,
   forgot to mention , I am accessing variable a as extern in file2.c
   I am going through the solutions pointed by you but not able to 
figure out one .



Thanks ,
Sumanth G

Jim Wilson wrote:

On Tue, 2009-08-04 at 00:06 +0530, sumanth wrote:
  

 > mycompiler-gcc -g file1.c file2.c
 > mycompiler-gdb a.out
  >> when i print "a" in file1.c , i am able to see value 10;
  >> when i print "a" int file2.c, it prints , no symbol defined. 
Instead I can access it with " print _a"



This sounds odd, as there is no variable a or _a in file2.c, and if you
can see a variable in one file you should be able to see if with the
same name in another file.

Anyways, I think I already answered this with my first message when I
pointed you at ASM_OUTPUT_* and ASM_GENERATE_INTERNAL_LABEL etc.  If you
compile with -g -S, and look at the assembly language, you will see that
"_a" is being used in the debug info someplace for the variable name
where "a" should be used instead.  "_a" is correct for the variable
address, but not the variable name.  So you will have to step through
your gcc port to figure out why the "_a" is incorrectly printed, and
most likely it is a bug in one of the macros I have mentioned.  Take a
look at a port that handles this correctly to see what they do
differently to make this work.

Jim




  

Re: How to set the alignment

[Jean Christophe Beyler]

I had a similar issue on my port. I fixed it by adding a check_move
before the generation of the move to look at the potential offset
used.

That allowed the compiler to not generate those wrong offsets
depending on the mode on my port. It looks something like this :

/* Check the operands of the move to make sure we can perform the move */
bool check_move (rtx op0, rtx op1)
{
/* First check offsets */
if (MEM_P (op0))
{
int offset;
int res = rtx_get_offset (XEXP (op0, 0), &offset);

if (res < 0)
return false;

if (! cyclops_check_offset (offset, GET_MODE (op0)))
{
return false;
}
}

/* Check second operand */
if (MEM_P (op1))
{
int offset;
int res = rtx_get_offset (XEXP (op1, 0), &offset);

if (res < 0)
return false;

if (! cyclops_check_offset (offset, GET_MODE (op1)))
{
return false;
}
}

return true;
}

Jc

On Tue, Aug 4, 2009 at 1:39 AM, Mohamed Shafi wrote:
> 2009/8/3 Jim Wilson :
>> On 08/03/2009 02:14 AM, Mohamed Shafi wrote:
>>>
>>> short - 2 bytes
>>> i am not able to implement the alignment for short.
>>> The following is are the macros that i used for this
>>> #define PARM_BOUNDARY 8
>>> #define STACK_BOUNDARY 64
>>
>> You haven't explained what the actual problem is.  Is there a problem with
>> global variables?  Is the variable initialized or uninitialized? If it is
>> uninitialized, is it common?  If this a local variable?  Is this a function
>> argument or parameter?  Is this a named or unnamed (stdarg) argument or
>> parameter?  Etc.  It always helps to include a testcase.
>>
>> You should also mention what gcc is currently emitting, why it is wrong, and
>> what the output should be instead.
>>
>> All this talk about stack and parm boundary suggests that it might be an
>> issue with function arguments, in which case you will probably have to
>> describe the calling conventions a bit so we can understand what you want.
>>
>  This is the test case that i tried
>
> short funs (int a, int b, char w,short e,short r)
> {
>  return e+r;
> }
>
> The target is 32bit . The first two parameters are passed in registers
> and the rest in stack. For the parameters that are passed in stack the
> alignment is that of the data type. The stack pointer is 8 byte
> aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
> that is getting generated is give below (-O0 -fomit-frame-pointer)
>
> funs:
>        add      16,sp
>        mov  d0,(sp-16)
>        mov  d1,(sp-12)
>        movh  (sp-19),d0
>        movh  d0,(sp-8)
>        movh  (sp-21),d0
>        movh  d0,(sp-6)
>        movh  (sp-8),d1
>        movh  (sp-6),d0
>        add     d1,d0,d0
>        sub    16,sp
>        ret
>
>
> From the above code you can see that some of the half word access is
> not aligned on a 2byte boundary.
>
> So where am i going wrong.
> Hope this info is enough
>
> Regards,
> Shafi
>

Re: order of -D and -U is significant

[Joe Buck]

On Tue, Aug 04, 2009 at 08:03:56AM -0700, Tom Tromey wrote:
> > "Erwin" == Unruh, Erwin  writes:
> 
> Erwin> In current gcc the order of options -D and -U is significant. The
> Erwin> Single Unix(r) Specification explicitly specifies that the order
> Erwin> should not matter for the c89 command. It reads (cited from
> Erwin> version 2, which is ten years old):
> 
> Erwin> I did not find a justification for the current gcc
> Erwin> behavior.
> 
> GCC's behavior is more useful.  And, given its age, I think it would be
> a mistake to change it.
> 
> I think if you want the c89 behavior, a wrapper program of some kind
> would be the way to go.

Another alternative would be an extra flag that would turn on conformance
to the spec.  But gcc can't change its default behavior; this would cause
massive breakage.

Re: [lambda] Segmentation fault in simple lambda program

[John Freeman]

Jason Merrill wrote:

On 08/04/2009 10:17 AM, John Freeman wrote:

Reiterating, to allow more freedom in implementation, we can just say it
"behaves as" a template, rather than "is" a template.


I don't see the difference.  As long as they work the same, the 
compiler is free to do whatever it wants internally.


Ok, sounds great then.  Like I said, I wasn't sure if that allowance was 
implicit in the wording.


- John

Re: [lambda] Segmentation fault in simple lambda program

[John Freeman]

Jason Merrill wrote:
Incidentally, how does it work to just move the existing call of 
finish_struct to after we parse the body?  I don't see why we need it 
to be complete while we're in the body.


When I was working on it, there were some checks to make sure the class 
was complete.  I can't recall exactly where or why, but it was what led 
to me have two calls to finish_struct.


- John

Building/installing gcc-4.4.1, pb with headers/libraries

[Etienne Lorrain]

 Hello,

 I am trying to rebuild gcc, for my target (ia32/amd64 bootloader) I will
not use any library whatsoever, target is ia32.

 If I do:
rm -f -r ../toolchain
mkdir ../toolchain ../toolchain/source ../toolchain/build
tar --directory ../toolchain -xjf ../binutils-2.19.1.tar.bz2
mv ../toolchain/binutils-2.19.1 ../toolchain/source/binutils
tar --directory ../toolchain -xjf ../gmp-4.3.1.tar.bz2
mv ../toolchain/gmp-4.3.1 ../toolchain/source/gmp
tar --directory ../toolchain -xzf ../mpfr-2.4.1.tar.gz
mv ../toolchain/mpfr-2.4.1 ../toolchain/source/mpfr
tar --directory ../toolchain -xjf ../ppl-0.10.2.tar.bz2
mv ../toolchain/ppl-0.10.2 ../toolchain/source/ppl
tar --directory ../toolchain -xzf ../cloog-ppl-0.15.3.tar.gz
#mv ../toolchain/cloog-ppl-0.15.3 ../toolchain/source/cloog-ppl
mv ../toolchain/cloog-ppl ../toolchain/source/cloog-ppl
tar --directory ../toolchain -xjf ../gcc-4.4.1.tar.bz2
mv -f ../toolchain/gcc-4.4.1/* ../toolchain/source
rmdir ../toolchain/gcc-4.4.1
( cd ../toolchain/build ; \
../source/configure --prefix=/home/etienne/projet/toolchain 
--without-headers --without-libs --enable-languages=c --disable-multilib 
--disable-threads --disable-nls --disable-shared --enable-tls ; \
make bootstrap ; make install )

the install ends up with:

make[6]: Entering directory 
`/home/etienne/projet/toolchain/build/binutils/libiberty/testsuite'
make[6]: Nothing to be done for `install'.
make[6]: Leaving directory 
`/home/etienne/projet/toolchain/build/binutils/libiberty/testsuite'
make[5]: Leaving directory 
`/home/etienne/projet/toolchain/build/binutils/libiberty'
make[4]: Nothing to be done for `install-target'.
make[4]: Leaving directory `/home/etienne/projet/toolchain/build/binutils'
make[3]: Leaving directory `/home/etienne/projet/toolchain/build/binutils'
/bin/sh: line 3: cd: ./fixincludes: No such file or directory
make[2]: *** [install-fixincludes] Error 1
make[2]: Leaving directory `/home/etienne/projet/toolchain/build'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/etienne/projet/toolchain/build'
make: *** [newtoolchain] Error 2

 I tried simpler configure commands like:
../source/configure --prefix=$(P_PWD)/toolchain --enable-languages=c 
--disable-multilib --disable-threads --enable-tls
 but got exactly the same error message.

 Is there something obviously wrong here, or something to disable
fixinclude treatments? This is on a simple Debian v5 ia32 PC.
 If I try to compile/install binutils, then gmp, then mfpr, then
gcc I get a working compiler, but it seems that it is not the
"right way" to do it.

 Thanks for any pointers,
 Etienne.

Re: order of -D and -U is significant

[Ross Smith]

On 2009-08-05, at 04:03, Joe Buck wrote:


Another alternative would be an extra flag that would turn on  
conformance

to the spec.


Traditionally spelled -posixly-correct in other GNU software. This would
presumably also affect other options, such as making the default - 
std=c99

instead of gnu89.

-- Ross Smith

Re: [lambda] Segmentation fault in simple lambda program

[John Freeman]

John Freeman wrote:



+/* relayout again -- to allow for implicit
+ * parameters to have been added to the capture if it was a
+ * 'default capture' -- note that this would not be necessary if
+ * the stack-pointer variant was implemented -- since the layout
+ * would be known.
+ * Relayingout here might have nasty effect if one were to query
+ * sizeof *this from within the body -- would that even be
+ * possible -- *this would refer to the lambda or the enclosing
+ * class instance -- if there was one.???
+ *
+ * NOTE: I think this is a redefinition error; I'm just faking that
+ * it isn't by clearing the size node... need to use stack pointer
+ * method.  But that will likely bring its own issues -- not with
+ * class layout though.
+ */
+TYPE_SIZE (type) = NULL_TREE;
+finish_struct_1 (type);


Relaying out the class after the lambda body was parsed is something I 
had attempted to do, but possibly failed at.  It will absolutely need 
to be done.


I just inspected my code again.  The call to layout_class_type at the 
beginning of finish_lambda_function_body at semantics.c:5241 was 
intended to recalculate offsets to members in the case of default captures.


Here is the complete order of the pertinent function calls (file 
location has nothing to do with call order; I supply them to help the 
reader to follow):


finish_struct @ parser.c:6985

cp_parser_lambda_body @ parser.c:6992
--> finish_lambda_function_body @ parser.c:7380
> layout_class_type @ semantics.c:5241

finish_struct_1 @  I don't see this added yet.  I've checked out 
revision 150396.



- John

Re: order of -D and -U is significant

[Joe Buck]

On Tue, Aug 04, 2009 at 11:42:51AM -0700, Ross Smith wrote:
> 
> On 2009-08-05, at 04:03, Joe Buck wrote:
> >
> > Another alternative would be an extra flag that would turn on
> > conformance
> > to the spec.
> 
> Traditionally spelled -posixly-correct in other GNU software. This would
> presumably also affect other options, such as making the default -
> std=c99
> instead of gnu89.

But AFAIK neither Posix nor the C89 standard nor the C99 standard
say anything about -D and -U flags.  It's the Single UNIX specification
that is the issue, and it refers to a command that is spelled "c89",
or (in later versions) "c99", not "gcc".

gcc-4.4-20090804 is now available

[gccadmin]

Snapshot gcc-4.4-20090804 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090804/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 150469

You'll find:

gcc-4.4-20090804.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20090804.tar.bz2 C front end and core compiler

gcc-ada-4.4-20090804.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20090804.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20090804.tar.bz2  C++ front end and runtime

gcc-java-4.4-20090804.tar.bz2 Java front end and runtime

gcc-objc-4.4-20090804.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20090804.tar.bz2The GCC testsuite

Diffs from 4.4-20090728 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: PR33113

[Jack Howarth]

On Tue, Aug 04, 2009 at 12:35:15PM +0300, Dorit Nuzman wrote:
> 
> Hi Jack,
> AFAIK this topic has not been addressed (closest thing is Richard
> Guenther's work on versioning unknown strides
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
> about the prospects of this being done for gcc4.5 (I'd definitely lobby for
> it... do you know which of the polyhedron benchmarks have this issue,
> and/or which other benchmarks suffer from it?)
> Thanks for the reminder...
> dorit
> 

Dorit,
   Using the assumption that occurances of "data ref analysis failed" in the
-fdump-tree-vect-details output represent instances where the the stride in 
the inner-loop is unknown (and hence is PR33113), the following instances
exist in the Polyhedron 2005 benchmarks. It seems clear that vectorization of
some of the benchmarks could be severely impacted by this bug.
Jack
ps These results were generated for x86_64-apple-darwin10 using gfortran 4.4.1.

ac.f90:753: note: not vectorized: data ref analysis failed D.2551_33 = 
(*iz_32(D))[D.2550_31];
ac.f90:778: note: not vectorized: data ref analysis failed D.2625_65 = 
(*iz_64(D))[D.2624_63];
ac.f90:316: note: not vectorized: data ref analysis failed D.2000_208 = 
dclold[D.1981_207];
ac.f90:306: note: not vectorized: data ref analysis failed D.1991_186 = 
deneold[D.1981_185];
ac.f90:296: note: not vectorized: data ref analysis failed D.1982_163 = 
dsusold[D.1981_162];

aermod.f90:33934: note: not vectorized: data ref analysis failed D.57115_20 = 
(*pretmp.8898_73)[D.57114_19];
aermod.f90:30101: note: not vectorized: data ref analysis failed D.49870_79 = 
(*pretmp.9464_200)[D.49866_78];
aermod.f90:23823: note: not vectorized: data ref analysis failed 
(*pretmp.9677_446)[D.42752_547] = 0.0;
aermod.f90:23812: note: not vectorized: data ref analysis failed 
(*pretmp.9685_78)[D.42708_490] = 0.0;
aermod.f90:23809: note: not vectorized: data ref analysis failed 
(*pretmp.9708_514)[D.42695_472] = 0.0;
aermod.f90:23800: note: not vectorized: data ref analysis failed 
(*pretmp.9724_888)[D.42665_425] = 0.0;
aermod.f90:23796: note: not vectorized: data ref analysis failed 
(*pretmp.9749_1779)[D.42637_384] = 0.0;
aermod.f90:23770: note: not vectorized: data ref analysis failed 
(*pretmp.9781_1847)[D.42564_275] = 0.0;
aermod.f90:23760: note: not vectorized: data ref analysis failed 
(*pretmp.9812_1965)[D.42446_94] = 0.0;
aermod.f90:20646: note: not vectorized: data ref analysis failed 
(*pretmp.10368_146)[D.36985_38] = 0.0;
aermod.f90:20648: note: not vectorized: data ref analysis failed 
(*pretmp.10374_155)[D.36997_52] = 0.0;
aermod.f90:20641: note: not vectorized: data ref analysis failed 
(*pretmp.10360_135)[D.36972_24] = 0.0;
aermod.f90:20635: note: not vectorized: data ref analysis failed 
(*pretmp.10385_172)[D.36959_11] = 0.0;
aermod.f90:16040: note: not vectorized: data ref analysis failed 
(*pretmp.10858_230)[D.31273_11] = 0.0;
aermod.f90:43612: note: not vectorized: data ref analysis failed 
(*D.70861_1391)[D.70868_1402] = 0;
aermod.f90:43608: note: not vectorized: data ref analysis failed 
(*D.70839_1359)[D.70846_1370] = 0;
aermod.f90:43581: note: not vectorized: data ref analysis failed 
(*D.70746_1222)[D.70750_1228] = 0;
aermod.f90:43543: note: not vectorized: data ref analysis failed 
(*D.70595_941)[D.70602_952] = 0.0;
aermod.f90:43573: note: not vectorized: data ref analysis failed 
(*D.70731_1199)[D.70738_1210] = 0.0;
aermod.f90:43570: note: not vectorized: data ref analysis failed 
(*D.70718_1180)[D.70725_1191] = 0.0;
aermod.f90:43421: note: not vectorized: data ref analysis failed 
(*D.70487_667)[D.70491_673] = 1.0e+0;
aermod.f90:43406: note: not vectorized: data ref analysis failed 
(*D.70429_589)[D.70433_595] = 0.0;
aermod.f90:43399: note: not vectorized: data ref analysis failed 
(*D.70408_557)[D.70419_573] = 0.0;
aermod.f90:43391: note: not vectorized: data ref analysis failed 
(*D.70374_518)[D.70381_529] = 0;
aermod.f90:43386: note: not vectorized: data ref analysis failed 
(*D.70349_485)[D.70356_496] = 0.0;
aermod.f90:43381: note: not vectorized: data ref analysis failed 
(*D.70318_441)[D.70325_452] = 0.0;
aermod.f90:43378: note: not vectorized: data ref analysis failed 
(*D.70305_422)[D.70312_433] = 0;
aermod.f90:43375: note: not vectorized: data ref analysis failed 
(*D.70292_403)[D.70299_414] = 0.0;
aermod.f90:43364: note: not vectorized: data ref analysis failed 
(*D.70241_332)[D.70249_343] = 0.0;
aermod.f90:48844: note: not vectorized: data ref analysis failed D.77133_262 = 
(*D.77003_251)[D.77132_261];
aermod.f90:50537: note: not vectorized: data ref analysis failed D.78695_135 = 
(*pretmp.15503_51)[D.78680_134];
aermod.f90:8975: note: not vectorized: data ref analysis failed D.19916_822 = 
(*D.19908_810)[D.19915_821];
aermod.f90:8887: note: not vectorized: data ref analysis failed D.19800_269 = 
(*D.19792_257)[D.19799_268];
aermod.f90:8906: note: not vectorized: data ref analysis failed D.19800_401 = 
(*D.19792_389)[D.19799

Re: order of -D and -U is significant

[Vincent Lefevre]

On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> But AFAIK neither Posix nor the C89 standard nor the C99 standard
> say anything about -D and -U flags.  It's the Single UNIX specification
> that is the issue, and it refers to a command that is spelled "c89",
> or (in later versions) "c99", not "gcc".

c99 with the mentioned -D and -U flags is specified by:

The Open Group Base Specifications Issue 7
IEEE Std 1003.1-2008

That's POSIX.1-2008.

See http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: How to set the alignment

[Jim Wilson]

On Tue, 2009-08-04 at 11:09 +0530, Mohamed Shafi wrote:
> >> i am not able to implement the alignment for short.
> >> The following is are the macros that i used for this
> >> #define PARM_BOUNDARY 8
> >> #define STACK_BOUNDARY 64
> The target is 32bit . The first two parameters are passed in registers
> and the rest in stack. For the parameters that are passed in stack the
> alignment is that of the data type. The stack pointer is 8 byte
> aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
> that is getting generated is give below (-O0 -fomit-frame-pointer)

Er, wait.  You set PARM_BOUNDARY to 8.  This means all arguments will be
padded to at most an 8-bit boundary, which means that yes, a short after
a char will have only 1 byte alignment.  If you want all arguments to
have 2-byte alignment, then you need to set PARM_BOUNDARY to 16.  But
you probably want a value of 32 here so that 4-byte ints get 4-byte
alignment.  This will allocate a minimum 4-byte stack slot for every
argument.  I don't know the calling convention, so I don't know exactly
how you want arguments arranged on the stack.

If you are pushing arguments, then you can lie in the PUSH_ROUNDING
macro.  You could say for instance that one byte pushes always push 2
bytes.  This ensures that the stack always has 2-byte alignment while
pushing arguments.  If your push instruction doesn't actually do this,
then you need to modify the pushqi pattern to emit two pushes or use a
HImode push to get the right behaviour.

Try looking at the code in store_one_arg in calls.c, and emit_push_insn
in expr.c.

Jim