ort for target
> > address spaces in C++. The basic idea is only to make the parser
> > recognize address spaces, and lower them into GIMPLE, in the same
> > fashion as the C parser. This also makes it possible to merge the
> > function `c_register_addr_space` in one pl
paces, and lower them into GIMPLE, in the same
> fashion as the C parser. This also makes it possible to merge the
> function `c_register_addr_space` in one place which is better than
> before.
>
> The patch still has some drawbacks compared to its C counterpart.
> Namely, much like t
both for C and C++.
Here is a first attempt at a patch to enable the support for target
address spaces in C++. The basic idea is only to make the parser
recognize address spaces, and lower them into GIMPLE, in the same
fashion as the C parser. This also makes it possible to merge th
Hi,
On Wed, Mar 23 2022, Erick Ochoa via Gcc wrote:
> Hi,
>
> I am trying to understand what path is executed in GCC from parsing a C
> expression (in a global variable declaration) to the value in DECL_INITIAL.
> At the moment, I have annotated a tree during parsing. I have another
> debugging pa
> I'm not sure I understand but no pass walks 'global variables', so you're
> not
> going to "see" the annotation from passes (whatever that means).
>
>
What I mean by walking global variables is that I have a GIMPLE_PASS that
ignores the function sent as an argument and instead just uses a
FOR_EAC
On Wed, Mar 23, 2022 at 12:55 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am trying to understand what path is executed in GCC from parsing a C
> expression (in a global variable declaration) to the value in DECL_INITIAL.
> At the moment, I have annotated a tree during parsing. I have another
> de
Hi,
I am trying to understand what path is executed in GCC from parsing a C
expression (in a global variable declaration) to the value in DECL_INITIAL.
At the moment, I have annotated a tree during parsing. I have another
debugging pass that looks for this tree in subsequent passes. The
annotation
u.org"
Subject: Re: Clarification on who can approve Objective-C/Objective-C++ parser
patches
On Thu, 23 Sep 2010, Nicola Pero wrote:
> For example, if I post a patch that changes a piece of code in
> gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I
> a
>> For example, if I post a patch that changes a piece of code in
>> gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I
>> assume that it is part of the Objective-C front-end, and the
>> Objective-C/Objective-C++ maintainers are in charge of approving it.
>> Once they appro
On Thu, 23 Sep 2010, Nicola Pero wrote:
> For example, if I post a patch that changes a piece of code in
> gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I
> assume that it is part of the Objective-C front-end, and the
> Objective-C/Objective-C++ maintainers are in charge o
Most of the Objective-C/Objective-C++ parser code is in files shared with the
C/C++ frontend,
hence I'm confused about who approves what.
For example, if I post a patch that changes a piece of code in gcc/c-parser.c
which is only
ever used if (c_dialect_objc ()), then I assume that it is
Nikola Ikonic wrote:
Hello,
I am working on a modification of C parser and I need some help since
I am having difficulties understanding some issues (I am complete
newbie on GCC). Long story short, I am trying to add a new attribute
to function types (similar to "inline", for examp
Hello,
I am working on a modification of C parser and I need some help since
I am having difficulties understanding some issues (I am complete
newbie on GCC). Long story short, I am trying to add a new attribute
to function types (similar to "inline", for example). Let's say that
t
Ian Lance Taylor wrote:
I'm sure Joseph could explain the reasons better, but some of the
problems with the bison parser were 1) it's hard to generate good
error messages at the right places; 2) C is not LALR(1) (at least, not
in a natural sense) because of the declaration syntax; 3) it made it
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> I was quite surprised to see that the C Parser was manually
> implemented and you didn't use any parser generator.
>
> I would be curious regarding this decision. I would think the
> development of a C parser wo
On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would b
ulo J. Matos <[EMAIL PROTECTED]> wrote:
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountable task an
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountable task and
not very logic given the parser gener
Volker Reichelt wrote:
> Shouldn't we fold cp_parser_declarator_id into the caller and call
> cp_parser_id_expression directly?
Originally, I was trying to have a function for each non-terminal. I'm
not going to be dogmatic about that, but is there a good reason to
remove the function? As Gaby
On 7 Dec, Nathan Sidwell wrote:
> Gabriel Dos Reis wrote:
>
>> If we make it "static inline", would not we gain the same efficiency
>> and preserve the comments and all that? In general, the methodoly
>> seems to have a function for each non-terminal -- following a long
>> tradition of recursive
Gabriel Dos Reis wrote:
If we make it "static inline", would not we gain the same efficiency
and preserve the comments and all that? In general, the methodoly
seems to have a function for each non-terminal -- following a long
tradition of recursive descent parser -- and maintaining that
princip
Volker Reichelt <[EMAIL PROTECTED]> writes:
| The C++ parser contains the static function
| cp_parser_declarator_id (cp_parser* parser)
| which consists of a lot of comments and a single statement
|
| return cp_parser_id_expression (
The C++ parser contains the static function
cp_parser_declarator_id (cp_parser* parser)
which consists of a lot of comments and a single statement
return cp_parser_id_expression (parser,
/*template_keyword_p=*/false
On 09/12/05 15:55, Ashwin Bharambe wrote:
- stop gcc once the cp frontend parses the code and generates the
parse tree structure.
Check -fsyntax-only.
- disable the stage1,stage2 compilation etc. during the build process?
just do 'make all' instead of 'make bootstrap'.
On Mon, 12 Sep 2005, Ashwin Bharambe wrote:
- disable the stage1,stage2 compilation etc. during the build process?
IIRC cross-compilers do not use stage1/2/3 as it is not possible to
execute produced target binary on the host platform. And for compiling
cross-compiler simple `make' is used.
You can start off by looking into how -fsyntax-only option is
implemented.
- fariborz
On Sep 12, 2005, at 12:55 PM, Ashwin Bharambe wrote:
Hmm. Ok fine, I can live with having to keep all extraneous code lying
around. But it seems like there must be a way to:
- stop gcc once the cp front
Hmm. Ok fine, I can live with having to keep all extraneous code lying
around. But it seems like there must be a way to:
- stop gcc once the cp frontend parses the code and generates the
parse tree structure.
- disable the stage1,stage2 compilation etc. during the build process?
Or, is there s
On 09/12/05 15:30, Ashwin Bharambe wrote:
is it possible to plug out the parser and intermediate representation code
(presumably only in the front-end?) relatively easily?
Not really. Though we have been re-designing the internal architecture
to be more modular, all the components are meant
Hi all,
I intend to use gcc's C++ parser and the intermediate representation
it creates for use in source browsing, etc. I have a few questions
regarding this: firstly, is it possible to plug out the parser and
intermediate representation code (presumably only in the front-end?)
relatively e
I'm fixing a problem with ObjC++ going beserk upon encountering
a syntax error, specifically not finding a '{' at the beginning
of a method definition. Is there a safe, established way of
repairing the token stream, i.e., inserting the '{' at that point?
That way, I could print an ObjC++-specific
Now committed to mainline. Bootstrapped with no regressions today on the
listed platforms of x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu
and ia64-hp-hpux11.23.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTE
On 2005-02-25, at 12:22, Joseph S. Myers wrote:
I intend to commit my new C parser to mainline today once it is
confirmed
that the 4.0 branch has been created and after final testing against
today's mainline on x86_64-unknown-linux-gnu,
powerpc64-unknown-linux-gnu
and ia64-hp-hpux11.23.
On Feb 25, 2005 12:22 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> I intend to commit my new C parser to mainline today once it is confirmed
> that the 4.0 branch has been created and after final testing against
> today's mainline on x86_64-unknown-linux-gnu, powerpc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-02-25 20:54:22 +0800 Lars Segerlund <[EMAIL PROTECTED]>
wrote:
btw. what Wiki ??
/ Lars Segerlund
http://gcc.gnu.org/wiki
- --
Got Sharapova?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using the GPG bundle for GNUMa
On Feb 25, 2005, at 7:54 AM, Lars Segerlund wrote:
btw. what Wiki ??
http://gcc.gnu.org/wiki/
-- Pinski
btw. what Wiki ??
/ Lars Segerlund
On Fri, 25 Feb 2005 11:22:11 + (UTC)
"Joseph S. Myers" <[EMAIL PROTECTED]> wrote:
> I intend to commit my new C parser to mainline today once it is confirmed
> that the 4.0 branch has been created and after final testing against
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2005-02-25 19:22:11 +0800 Joseph S. Myers <[EMAIL PROTECTED]>
wrote:
I intend to commit my new C parser to mainline today once it is
confirmed
that the 4.0 branch has been created and after final testing against
today's
mainlin
I intend to commit my new C parser to mainline today once it is confirmed
that the 4.0 branch has been created and after final testing against
today's mainline on x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu
and ia64-hp-hpux11.23.
The version to be committed is version 8
38 matches
Mail list logo
