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
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
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,
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.
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.
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
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 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
to the
development or testing of GCC and not covered by other mailing lists
is suitable for discussion here."
--
Rodrigo
about specifying a unified 'range' concept. The range-for is
just the first, highly visible, user of this implicit specification.
--
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
7;t mean that it will not happen in the real world.
--
Rodrigo
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
>> 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.
> 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/
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
> 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)
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 :-(
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
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
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
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
. 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
_COMPLETED_P() or something like that. But a forward enum always
defines a complete type, so this test is not useful.
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
chars:
"xxx" /**/ _bar;
is parsed fine with your current patch, but I believe it should not.
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
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
>> 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
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
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
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
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
27;, IIRC).
If instead of that, a ':' is found there is your chance to diagnose!
Regards.
Rodrigo
> 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
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
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
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
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
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
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
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
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
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
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
related to
cross-compiling that I could start with? Perhaps cross-compiling for the
XScale/ARM target?
Thank you,
Rodrigo
could be, I would be very
pleased.
Regards,
Rodrigo González
48 matches
Mail list logo
