I am work on a project related with GCC AST.
In my project, i write a plugin for GCC. This plugin read a AST from a
source code, a covert this source code to another language.
Currently i have a problem with GCC AST. In particular, i cannot
retrieve all information about CALL_EXPR.
I read GCC inter
Richard Kenner wrote:
> "bad" isn't very precise. The claim was made that a reason that it's "bad"
> is that not being able to automatically generate documentation lowers
> the quality of the documentation. That's what I disagree with.
OK, fine; that's a reasonably debatable point. But, we cu
> Richard, your argument is a distraction from the important issue at
> hand. Unless you posit that there is no useful way in which to generate
> documentation from code (and comments therein), which seems an extreme
> statement, then it is desirable that we have the ability to do that.
> Right no
On Aug 2, 2010, at 7:17 PM, Richard Kenner wrote:
>> We are already having trouble keeping our documentation up-to-date.
>> Some of it is in such a poor shape as to be laughable. Yes, it's
>> mostly our fault, but if we were able to generate documentation by
>> simply extracting it from the code
Richard Kenner wrote:
>> That is true, but very often the documentation is needed in two
>> places: in the code and in the manual. Especially for things like
>> machine constraints, flags and options.
>
> Yes, but the audiences are different between users who read the manual and
> developers who
> That is true, but very often the documentation is needed in two
> places: in the code and in the manual. Especially for things like
> machine constraints, flags and options.
Yes, but the audiences are different between users who read the manual and
developers who read the code. For the best qu
On Tue, Aug 3, 2010 at 1:17 AM, Richard Kenner
wrote:
>> We are already having trouble keeping our documentation up-to-date.
>> Some of it is in such a poor shape as to be laughable. Yes, it's
>> mostly our fault, but if we were able to generate documentation by
>> simply extracting it from the c
On 10-08-02 19:17 , Richard Kenner wrote:
We are already having trouble keeping our documentation up-to-date.
Some of it is in such a poor shape as to be laughable. Yes, it's
mostly our fault, but if we were able to generate documentation by
simply extracting it from the code. Tools exist for t
> We are already having trouble keeping our documentation up-to-date.
> Some of it is in such a poor shape as to be laughable. Yes, it's
> mostly our fault, but if we were able to generate documentation by
> simply extracting it from the code. Tools exist for this, and
> properly maintained, they
On Sat, Jul 31, 2010 at 00:16, Mark Mitchell wrote:
> In any case, you're suggesting we go against the express wishes of the
> FSF. Would you suggest that we do that in the context of FSF GCC?
Well, this issue is another one in a long series of roadblocks that
we've had to struggle with over th
Hi, please have a look at the
Bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
And a patch(for gcc-4.4.4) posted therein. It seems to fix the issue.
Yet, I need to confirm whether DW_AT_external flag should be set for the public
functions of a C++ class or not?
I guess not, because th
On Mon 2 Aug 2010 10:44, Kilbane, Stephen pondered:
> For #6101, the test's just started failing for 4.3 because 4.3 adds a
> new xfail condition not applied to 4.1:
>
> 4.1: // { dg-do run { xfail sparc*-*-solaris2* } }
> 4.3: // { dg-do run { xfail { { sparc*-*-solaris2* } || lax_strtofp } } }
On Mon, 2 Aug 2010, Bingfeng Mei wrote:
> Hi,
> I ran a small test to see how the trunk/4.5 works
> with the rewritten restrict qualified pointer code. But it doesn't
> seem to work on both x86-64 and our port.
>
> tst.c:
> void foo (int * restrict a, int * restrict b,
> int * restr
Hi,
I ran a small test to see how the trunk/4.5 works
with the rewritten restrict qualified pointer code. But it doesn't
seem to work on both x86-64 and our port.
tst.c:
void foo (int * restrict a, int * restrict b,
int * restrict c, int * restrict d)
{
*c = *a + 1;
*d = *b + 1;
}
> > If I understand correctly it complains about a move instruction where src
> > memory location should be (reg22+reg23). My arch defines:
> > #define MAX_REGS_PER_ADDRESS 1
> > the first pseudo reg is 13
> >
>
> I think the wording of the second sentence in the M_R_P_A documentation
> (beginn
On 01/08/2010 16:26, Gabor Kerenyi wrote:
> I'm porting GCC 4.4.4 to a new arch and while cross-compiling libgcc I get
> the
> following error:
> ../../../libgcc/../gcc/libgcc2.c: In function ‘__clzsi2’:
> ../../../libgcc/../gcc/libgcc2.c:716: error: unrecognizable insn:
> (insn 49 48 50 16 ../.
16 matches
Mail list logo
