On Tue, 15 Feb 2005 22:26:31 +0100, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> I guess the above
> should rather read
>
> if (TREE_CODE (exp) == VAR_DECL)
> {
> if (!cxx_mark_addressable (exp))
> return error_mark_node;
> adr = build1 (ADDR_EXPR, ptrtype, exp);
> return adr;
> }
>
> no? At least this let's my bootstrap continue.
No, while this bootstraps ok, all hell breaks loose during g++ testing :(
With the patch as attached in this thread further up (removing the
broken fix) bootstrap fails with
/net/pherkad/scratch/rguenth/gcc-obj/gcc/xgcc -shared-libgcc
-B/net/pherkad/scratch/rguenth/gcc-obj/gcc/ -nostdinc++
-L/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include
-I/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/libsupc++ -g -O2
-D_GNU_SOURCE -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -c
/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/src/pool_allocator.cc
-fPIC -DPIC -o .libs/pool_allocator.o
/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/src/pool_allocator.cc:
In member function '__gnu_cxx::__pool_alloc_base::_Obj* volatile*
__gnu_cxx::__pool_alloc_base::_M_get_free_list(size_t)':
/net/pherkad/scratch/rguenth/gcc/libstdc++-v3/src/pool_allocator.cc:47:
internal compiler error: in check_pointer_types_r, at gimplify.c:4403
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
There with the patch we will now fold the
return _S_free_list + __i;
to
_S_free_list[i];
I'll debug this further, so do not waste your own time yet - it's for
sure a bug in my patch.
Thanks anyway,
Richard.
