ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>> ‘c-common.h’ lacks this declaration:
>>>
>>> extern tree xref_tag (enum tree_code code, tree name);
>>>
>>> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
>>> tag.
>>>
>>> Unfortunately, declares a different ‘xref_
Snapshot gcc-4.5-20110317 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110317/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This brings in the refactoring in cp/parser.c. I have not yet sent
the fix to obj-c++ (PR 48167), so the branch cannot bootstrap with
obj-c++ enabled for now. I'll re-merge after I fix it in trunk.
Diego.
>> 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.
Quoting Jeff Law :
Use of floating point within the compiler (we generally avoid it),
unstable qsort (again, we generally try to avoid it), hashing issues,
particularly with pointers, etc etc.
The floating point issues also mean that the compiler behaviour is
not defined by the standard; the o
On 17 March 2011 20:10, Jonathan Wakely wrote:
> On 17 March 2011 20:00, Rodrigo Rivas wrote:
>>> Yes, I was just trying exactly that improvement.
>> How about this?
>
> Nice. The comments should be changed too:
>
> If RANGE_EXPR is an array:
> BEGIN_EXPR = __range
> END_EXPR = __ran
On 17 March 2011 20:00, Rodrigo Rivas wrote:
>> Yes, I was just trying exactly that improvement.
> How about this?
Nice. The comments should be changed too:
If RANGE_EXPR is an array:
BEGIN_EXPR = __range
END_EXPR = __range + ARRAY_SIZE(__range)
Else if __range.begin() or __r
> 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/parser.c
+++ b/gc
On 17 March 2011 19:40, Rodrigo Rivas wrote:
> 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,
Yes
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
On 17 March 2011 18:29, Rodrigo Rivas wrote:
>> 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 shoul
On 17/03/2011 18:29, Jeff Law wrote:
> On 03/17/11 12:25, David Daney wrote:
>>> Instruction sequence #1 has been combined into a single equivalent
>>> instruction. Instruction sequence #2 moved. Register usage is also
>>> different but equivalent.
> In my experience, there's all kinds of reasons
> In my experience, there's all kinds of reasons why this can happen.
>
> Use of floating point within the compiler (we generally avoid it),
> unstable qsort (again, we generally try to avoid it), hashing issues,
> particularly with pointers, etc etc.
>
> For those reasons and many more, we don't t
On 17 March 2011 18:26, Rodrigo Rivas wrote:
> 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
> 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)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/17/11 12:25, David Daney wrote:
> On 03/17/2011 11:20 AM, McCall, Ronald SIK wrote:
>>> If you let us in on what exactly the secret differences were, it would
>>> be easier to opine on this topic.
>>
>> Sure thing! Here is an instruction sequenc
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 :-(
On 03/17/2011 11:20 AM, McCall, Ronald SIK wrote:
If you let us in on what exactly the secret differences were, it would
be easier to opine on this topic.
Sure thing! Here is an instruction sequence from the original Solaris
toolchain:
Resending to gcc@. I didn't really want a private mes
On 17 March 2011 18:18, Jonathan Wakely wrote:
> On 17 March 2011 18:09, Rodrigo Rivas wrote:
>> Hello all.
>>
>> I've just read the paper titled "Range-based for statements and ADL"
>> by Jonathan Wakely and Bjarne Stroustrup at:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3257.pdf
On 17 March 2011 18:09, Rodrigo Rivas wrote:
> Hello all.
>
> I've just read the paper titled "Range-based for statements and ADL"
> by Jonathan Wakely and Bjarne Stroustrup at:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3257.pdf
>
> The point of this article is that the argument de
Hello all.
I've just read the paper titled "Range-based for statements and ADL"
by Jonathan Wakely and Bjarne Stroustrup at:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3257.pdf
The point of this article is that the argument dependent lookup in the
range-for specification will make s
On 03/16/2011 10:21 PM, H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
so we get back to my original e-mail:
are you getting a unique host t
On 03/17/2011 09:59 AM, McCall, Ronald SIK wrote:
Hi,
I am attempting to move an old gcc powerpc-eabi cross toolchain
from an old Solaris SPARC server to a new Linux x86_64 server. I
have built and installed the exact same cross-binutils (2.13.2.1),
cross-gcc (3.2.3) and cross-newlib (1.11.0) f
Hi,
I am attempting to move an old gcc powerpc-eabi cross toolchain from an old
Solaris SPARC server to a new Linux x86_64 server. I have built and installed
the exact same cross-binutils (2.13.2.1), cross-gcc (3.2.3) and cross-newlib
(1.11.0) from source using the exact same target (powerpc-e
On Wed, Mar 16, 2011 at 10:45 PM, Mike Frysinger wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> > ok, took long enough, but that answers most things. your usage of "x32-"
>> > prefixed binaries in the documentation seems
2010/10/26 Ian Lance Taylor :
> roy rosen writes:
>
>> I am trying to demonstrate my port capabilities.
>> I am writing an application which needs to use instructions like max
>> a,b,c,d,e,f where a,b,c are inputs and d,e,f are outputs.
>> Is that possible to write an intrinsic function for that?
Hi,
Ian Lance Taylor writes:
> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>> ‘c-common.h’ lacks this declaration:
>>
>> extern tree xref_tag (enum tree_code code, tree name);
>>
>> AFAICS it makes it impossible for plug-ins to lookup a struct/union/enum
>> tag.
>>
>> Unfortunately,
27 matches
Mail list logo
