[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Support for Altivec Vector types in the CDT parser?
|
Yes, I need to update the documentation on the UPC and XLC parsers. I did write some decent documentation some time ago but now its horribly out of date.
Thanks for helping with the altivec support.
Mike Kucera
Software Developer
Eclipse CDT/PTP
IBM Toronto
mkucera@xxxxxxxxxx
George Russell ---01/08/2010 11:40:59 AM---Aha, the parser found in org.eclipse.cdt.core.lrparser.xlc
From: |
George Russell <george@xxxxxxxxxxxx> |
To: |
"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
Date: |
01/08/2010 11:40 AM |
Subject: |
Re: [cdt-dev] Support for Altivec Vector types in the CDT parser? |
Aha, the parser found in org.eclipse.cdt.core.lrparser.xlc
Just as a note, its deeply non-obvious (to me at least!) that CDT has
more than 1 C++ parser from reading the wiki pages at
http://wiki.eclipse.org/CDT/cdt-core ,
http://wiki.eclipse.org/CDT/designs and
http://wiki.eclipse.org/CDT/User/NewIn60, http://wiki.eclipse.org/CDT
and http://wiki.eclipse.org/Getting_started_with_CDT_development
I have already been working on extending the default CDT parser; I'll
see if I get it to accept __vector and __pixel.
Thanks,
George
Mike Kucera wrote:
>
> Your assumption is incorrect. The CDT project contains its own
> implementation of the XL C/C++ parser, which is completely independent
> of the XLC compiler. It integrates with CDT just like the default
> parser does, it builds an AST and works with the outline view and
> everything else. You don't need to be doing your builds with xlc to
> use the parser. And since the xlc compiler tries to be compatible with
> gcc the parser has support for most gcc extensions.
>
> Having said that, the XLC C++ parser does lag behind the default CDT
> parser in a few areas. For example it doesn't support parsing
> declarations in inactive code blocks. Also the altivec support is
> purely syntactic, CDT does not actually recognize vector types and so
> they will not be considered when doing overload resolution. Therefore
> it still makes a lot of sense to add alitivec support to the main
> parser. In the meantime you can either set up some macros so that the
> vector keyword is ignored or you can use the XLC parser to get by.
>
>
> Mike Kucera
> Software Developer
> Eclipse CDT/PTP
> IBM Toronto
> mkucera@xxxxxxxxxx
>
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev