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 ../.
> > 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
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;
}
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
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 } } }
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 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
> 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 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
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
> 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
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
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, 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
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
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
16 matches
Mail list logo
