The documentation in vec.h says that pointer values are dereferenced:
Both the structure object and pointer variants
pass pointers to objects around -- in the former case the pointers
are stored into the vector and in the latter case the pointers are
dereferenced and the objects copied into the
Andreas Tobler wrote:
Dominique Dhumieres wrote:
On OSX 1Â0.3 updating to gcc-4.3-20061209 failed with:
...
cc1: warnings being treated as errors
../../gcc-4.3-20061209/gcc/varasm.c: In function
'elf_record_gcc_switches':
../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: fo
Dominique Dhumieres wrote:
On OSX 1Â0.3 updating to gcc-4.3-20061209 failed with:
...
cc1: warnings being treated as errors
../../gcc-4.3-20061209/gcc/varasm.c: In function 'elf_record_gcc_switches':
../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: format '%llu' expe
On OSX 1Â0.3 updating to gcc-4.3-20061209 failed with:
...
cc1: warnings being treated as errors
../../gcc-4.3-20061209/gcc/varasm.c: In function 'elf_record_gcc_switches':
../../gcc-4.3-20061209/gcc/varasm.c:6268: warning: format '%llu' expects type
'long long unsigned
O, Sat, Dec 09, 2006 at 11:03:21AM -0500, Daniel Berlin écrivait/wrote:
> On 12/9/06, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
> >Le Fri, Dec 08, 2006 at 07:09:23PM -0500, Daniel Berlin écrivait/wrote:
> >
> >> You see, we currently waste a lot of memory to avoid the fact that our
> >> GC is
Snapshot gcc-4.3-20061209 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061209/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On 12/9/06, Alexey Smirnov <[EMAIL PROTECTED]> wrote:
typedef void* handle_t;
DEF_VEC_I(handle_t);
DEF_VEC_ALLOC_I(handle_t,heap);
Why DEF_VEC_I instead of DEF_VEC_P?
See vec.h.
Gr.
Steven
Hello,
I am trying to use vec.h to implement a vector of pointers:
typedef void* handle_t;
DEF_VEC_I(handle_t);
DEF_VEC_ALLOC_I(handle_t,heap);
extern VEC(handle_t,heap) *handles;
It does not compile:
In function 'VEC_handle_t_must_be_integral_type':
error: wrong type argument to bit-comple
On 12/9/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] writes:
> Hi,
> I want to know that the patch at
> "http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00211.html"; submitted for
> which version of gcc?
> How can we know that any of patch submitted , that for which version?
>
On 12/9/06, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Le Fri, Dec 08, 2006 at 07:09:23PM -0500, Daniel Berlin écrivait/wrote:
> You see, we currently waste a lot of memory to avoid the fact that our
> GC is very slow.
> We still take it on the chin when it comes to locality. Previous
> th
Le Fri, Dec 08, 2006 at 07:09:23PM -0500, Daniel Berlin écrivait/wrote:
>
> Uh, well, you see, there are points in between these two extremes.
> Most commercial compilers are not garbage collected, they rely on
> allocation pools (ie multiple heap) to get sane performance and
> lifetime managemen
[EMAIL PROTECTED] writes:
> Hi,
> I want to know that the patch at
> "http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00211.html"; submitted for
> which version of gcc?
> How can we know that any of patch submitted , that for which version?
> Kindly help me to figure it out soon.
I'm guessing t
12 matches
Mail list logo
