p_parser_check_type_definition() function to call
cp_parser_error() instead of error().
Or we can just accept the type definition in the range-for and hope that
nobody will notice :P
Regards.
Rodrigo
Code Analysis and Manipulation [1]
We are expanding this research to a broader community, so I kindly
invite you to answer our new version of the survey at:
https://www.surveymonkey.com/r/SXCB7WJ
Sincerely,
Rodrigo Bonifácio (on behalf of the authors of this research effort).
[1] "The use
,
Rodrigo.
end, exist.
* Look for them independently. This is what my patch does.
Also, if the member begin/end is not accessible or not callable, a
compiler error will follow immediately (this is as expected).
I'll appreciate any comments.
Best regards
--
Rodrigo
diff --git a/gcc/cp/parser.c b/gcc/cp/pars
On Thu, Mar 17, 2011 at 7:18 PM, Jonathan Wakely wrote:
> do you mind if I forward your mail to the committee reflector? The
> fact that there's an implementation is useful.
I'd do that gladly... if only I'd know how...
The [1] reference in the cited paper requires authorization :-(
> Actually, re-reading that and the following messages on the thread,
> I'm wrong about the lookup being independent - if it only finds a
> begin() member and no end() member it should still try to use r.end(),
> and therefore give an error. It should not be possible to use
> r.begin() and end(r)
Exactly what I had in mind!
You could also inhibit the member/non-member error message if any of
the lookups resulted in an error; and likewise inhibit the type
mismatch if this other one happened. But just now, it doesn't really
matter,
--
Rodrigo
> Yes, I was just trying exactly that improvement.
How about this?
> I'm going to let the committee know that option 5 has been
> implemented. Thanks very much!
Cool! Thank you.
--
Rodrigo
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9523fdc..aab9294 100644
--- a/gcc/cp/
>> Nice. The comments should be changed too:
Sure. Also, should this ever be accepted, the std::begin() and
std::end() declarations should be removed from the header files.
h a lot of SFINAE tricks to mimic the
range-for behavior. And there are a lot of subtleties and magic in the
range-for specification that makes that a hard work, if at all
possible.
IMHO, it would be much easier if the standard library provided these
functions for me. Before, I considered that was what
std::begin/std::end did, but now...
--
Rodrigo
7;t mean that it will not happen in the real world.
--
Rodrigo
> On 03/25/2011 11:13 AM, Rodrigo Rivas wrote:
> Note that there was already a special case for arrays.
Yes, but std::begin/std::end are overloaded for arrays also, so the
library implementor would get the right behavior for free.
They are still vulnerable to the ADL issue, though.
--
Rodrigo
about specifying a unified 'range' concept. The range-for is
just the first, highly visible, user of this implicit specification.
--
Rodrigo
to the
development or testing of GCC and not covered by other mailing lists
is suitable for discussion here."
--
Rodrigo
On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely wrote:
> Yes but it's too late to specify it in C++0x.
>
> Boost.Range is the best place to work on that idea at present.
> If/when it's fully baked I hope we'll see something like that in a
> future TR or standard.
Agreed.
But just now, how would
he
>> development or testing of GCC and not covered by other mailing lists
>> is suitable for discussion here."
> you are right this is "gcc@". I am not sure you what you imply by the rest.
I'm merely implying that this list is suitable for this discussion. It
looked like you disagree.
Regards.
--
Rodrigo
On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis
wrote:
> You were earlier talking about some "unified concept"; weren't you?
> Now, it is shifting to library component.
With "unified" I meant that the same concept (range) is present both
in the core language and the standard library. And that i
ied
> without major disruption: the document went into FDIS status.
> Being in draft status does not magically confer appropriateness for gcc@.
Ok, I admit that my point went *slightly* off-topic... so I'll leave it here.
Regards
--
Rodrigo.
Hi,
I am looking at binary auto-vectorization or taking a binary and rewriting
it to use SIMD instructions (either statically or dynamically). I was
wondering if anyone knew of similar work and could help me with some links.
Thank you,
Rodrigo Dominguez
Nathan,
Great! This is the kind of work I am interested in. Thank you.
Rodrigo
> -Original Message-
> From: Nathan Froyd [mailto:froy...@codesourcery.com]
> Sent: Thursday, January 29, 2009 5:04 PM
> To: Rodrigo Dominguez
> Cc: gcc@gcc.gnu.org
> Subject: Re: Binary
fore, the
compilation fails with a 'suffix or operands invalid for shr' message.
I have 2 questions:
1. AFAIK, by default, __asm__ chooses a register according to the size of
the operand (int8_t in this case). Is this correct? Where can I find
documentation of this?
2. If #1 is true, why does this fail?
Thank you,
Rodrigo
ssue? Something like an Intel/AMD/AT&T manual explaining this?
Thank you,
Rodrigo
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, March 24, 2009 2:09 PM
> To: Rodrigo Dominguez
> Cc: gcc@gcc.gnu.org
> Subject: Re: Inline Assembly
> Maybe Rodrigo would be interested in collaborating on this work?
Sure I am! Please, let me a couple of days to re-read the C++ draft,
and check this patch.
Also, take in account that I'm in no way a GCC expert... but I'll do my best.
Also I have a little patch on my own that might
27;, IIRC).
If instead of that, a ':' is found there is your chance to diagnose!
Regards.
Rodrigo
r to the "start_enum"
function, but I don't see how to do it without breaking existing code.
Comments are most welcomed.
Regards.
Rodrigo
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c (revision 164424)
+++ gcc/cp/dec
that: template
> _suffix(). So we'll need to make the lookup of these two signatures more
> complex.
Yes, the problem here is that we don't have to use the usual overload
resolution, but check the results of the lookup by hand.
I guess that it won't be so easy...
Regards.
Rodrigo
On second reading of the C++0x draft in cannot find any reason of what
the new type in range-fors should not be allowed.
Maybe someone can read it differently?
Regard.
Rodrigo
>> The easy solution would be to remove the assignment to
>> type_definition_forbidden_message and then check for this case
>> particulary.
>
> cp_parser_type_specifier_seq could return some indication of why the
> parsing has failed or whether it has parsed a declaration. This is
> much more usefu
ror. Probably it would be better to let the
unknown char to be handled by the calling function. In this way if I
see a ':' I know that it is a range-based for and no tentative is
needed.
But this is too big a change for me at the moment. For now, in order
to solve Magnus's problem I suggest to just remove the check for new
type in cp_parser_range_for().
Regards.
Rodrigo
uot;build_real()" to build the constant. Then
you can build a tree for the identifier (with "get_identifier()",
perhaps) and attach it somehow to the constant.
You may consider creating a new TREE type for that...
I'm afraid that you have quite some job here...
Best regards.
Rodrigo
chars:
"xxx" /**/ _bar;
is parsed fine with your current patch, but I believe it should not.
Rodrigo.
m look like in
> tree? Maybe the tree for enum could have a has_definition flag.
As far as I know it is a "tree_type". I was thinking of using
lang_flag_0 or similar, but I'm unsure if they are used for any other
purpose, or if there is a protocol to assign them...
Rodrigo
_COMPLETED_P() or something like that. But a forward enum always
defines a complete type, so this test is not useful.
Rodrigo.
. But the
compiler cannot know that. That's why it emits the *possible*
uninitialized warning.
Curiously, it does so with -O2 but not with -O0, probably due to the
extra analysis of the life of variables.
Regards.
Rodrigo
essage = saved_message;
/* If all is well, we might be looking at a declaration. */
if (cp_parser_error_occurred (parser))
{
Admittedly, this is not a "trailing_return_type", but AFAICT it has
exactly the same restrictions. Maybe renaming the parameter would be a
good idea.
Regards.
Rodrigo
ss body, but we give an error about it.
Well, the net effect is the same: the tentative parsing is aborted.
Then the C-style loop for parses the code, and it is this that prints
the error message if needed.
Regards.
Rodrigo
initialize the variables, while range-loops may not.
If these restrictions apply to the Obj-C fast-loops then the code
could be shared easily. If not, well, maybe with a little more work.
Regards.
Rodrigo
related to
cross-compiling that I could start with? Perhaps cross-compiling for the
XScale/ARM target?
Thank you,
Rodrigo
for the links. They were helpful.
Rodrigo
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 30, 2008 4:09 PM
To: Rodrigo Dominguez
Cc: gcc@gcc.gnu.org
Subject: Re: Contributing to cross-compiling
"Rodrigo Dominguez" <[EMAIL PROTE
I was only able
to find one reference to this project:
http://gcc.gnu.org/ml/gcc/2005-08/msg00667.html
Thank you,
Rodrigo Dominguez
work? Will my email be added to the
active thread (I don't want the system to create a new thread)? Is there a
better way to do it beside copy/pasting?
Thanks for your help.
Rodrigo
On Sat, 2 Feb 2008, NightStrike wrote:
> On 2/2/08, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > On 02/02/2008, Rodrigo Dominguez wrote:
> > >
> > > How do you reply to a thread in the mailing lists? The only way I can
> > > think of is sending an
On Sat, 2 Feb 2008, NightStrike wrote:
> On 2/2/08, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > On 02/02/2008, Rodrigo Dominguez <[EMAIL PROTECTED]> wrote:
> > >
> > > On Sat, 2 Feb 2008, NightStrike wrote:
> > >
> > > > On 2/2/08
Hi,
I am looking for information on how GCC implements Structured Exception
Handling (try/catch) in C++ programs. I would really appreciate any pointers
that helped me understand the internals.
Thank you,
Rodrigo
In addition to the bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
I wanted to add some comment:
It would be very useful if the _Atomic keyword would be supported in C++.
This way the header could be included inconditionally in C++ code.
Even if it is not compatible with the C++ header,
On Tue, May 15, 2018 at 12:27 AM, Jonathan Wakely wrote:
> On 14 May 2018 at 22:32, Rodrigo V. G. wrote:
>> In addition to the bug:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932
>> I wanted to add some comment:
>>
>> It would be very useful if the _Atomi
On Tue, May 15, 2018 at 12:50 PM, Jonathan Wakely wrote:
> On 15 May 2018 at 11:01, Rodrigo V. G. wrote:
>> On Tue, May 15, 2018 at 12:27 AM, Jonathan Wakely
>> wrote:
>>> On 14 May 2018 at 22:32, Rodrigo V. G. wrote:
>>>> In addition to the bug:
>>&g
could be, I would be very
pleased.
Regards,
Rodrigo González
48 matches
Mail list logo
