Re: Build using --with-gmp and shared libraries
> Or did I miss the point entirely? Right now, having the GMP/MPFR libraries (later refered as GMP) in /home/gmp and typing: configure --with-gmp=/home/gmp --enable-languages=c,fortran does configure fine but running "make" then fails when it attempts to build libgfortran. This is PR 21547, see the audit trail for more details. The general opinion is that it is normal to have to set your LD_LIBRARY_PATH to run the installed compiler, but using --with-gmp should be enough to build it in any case. This is what the toplevel part of my patch does. Moreover, I think that running the testsuite shouldn't require setting LD_LIBRARY_PATH either, which is what the gcc/ part of the patch is about. FX
fixincludes make check broken?
Running make check in fixincludes on x86_64-gnu-linux I get the following failure: Fixed: Xm/Traversal.h cmp: EOF on string.h *** string.h2005-11-10 12:25:31.0 +0100 --- /cvs/gcc-svn/trunk/fixincludes/tests/base/string.h 2005-11-10 12:23:56.0 +0100 *** *** 10,13 #ifndef _STRING_INCLUDED #define _STRING_INCLUDED #include ! #endif /* _STRING_INCLUDED */ \ No newline at end of file --- 10,13 #ifndef _STRING_INCLUDED #define _STRING_INCLUDED #include ! #endif /* _STRING_INCLUDED */ There were fixinclude test FAILURES make: *** [check] Error 1 Any ideas? Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpNw9bkbTl8d.pgp Description: PGP signature
Incorrect default options for h8300 target
At some point between 4.0 and 4.1 the mechanism for option handling was changed over to the new style using the .opt file but the default setting of quickcall seems to have been lost in the process. It seems to me that this was unintentional - but please let me know if otherwise. adding the following 2 lines into h8300.c #undef TARGET_DEFAULT_TARGET_FLAGS #define TARGET_DEFAULT_TARGET_FLAGS (MASK_QUICKCALL) immediately before the line struct gcc_target targetm = TARGET_INITIALIZER; appears to fix the problem allthough I am not sure that this is completely the correct way to do this. regards Mike Lerwill
RE: Cross compile, no grmic/grmiregistry
Tom>No, it is more like some weird configure/build thing having to Tom>do with cross-builds. I tried to make the following changes, but a error on generating Jv-convert has been thrown during buildinig cross compiler to win platform. (I was able to successfully build this cross compiler before I made these changes.) Any input would be much appreciated. Ok, here goes the changes: /my_gcc_src_dir/libjava/Makefile.am Orignal: --- ## For now, only on native systems. FIXME. if NATIVE bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool ## It is convenient to actually build and install the default database ## when gcj-dbtool is available. dbexec_DATA = $(db_name) Endif After change:nothing special really, just comment out if Native. - ## For now, only on native systems. FIXME. ##if NATIVE bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool ## It is convenient to actually build and install the default database ## when gcj-dbtool is available. dbexec_DATA = $(db_name) ##endif - Then I ran automake in the make file directory to create new Makefile.in(automake 1.9.3): Automake Makefile After started building the cross compiler, a error has been thrown while make: mingw32-ar cru .libs/libgij.a gij.o mingw32-ranlib .libs/libgij.a creating libgij.la (cd .libs && rm -f libgij.la && ln -s ../libgij.la libgij.la) /bin/sh ./libtool --tag=GCJ --mode=link /root/gccbuild/gcc/gcj -B/root/gccbuild/gcc/ -B/extra/crossgcc/mingw32/bin/ -B/extra/crossgcc/mingw32/lib/ -isystem /extra/crossgcc/mingw32/include -isystem /extra/crossgcc/mingw32/sys-include -L/root/gccbuild/mingw32/libjava -ffloat-store -fno-omit-frame-pointer -O2 -pipe -g0 -s -o jv-convert.exe --main=gnu.gcj.convert.Convert -rpath /extra/crossgcc/mingw32/lib -shared-libgcc -L/root/gccbuild/mingw32/libjava/.libs libgcj.la /root/gccbuild/gcc/gcj -B/root/gccbuild/gcc/ -B/extra/crossgcc/mingw32/bin/ -B/extra/crossgcc/mingw32/lib/ -isystem /extra/crossgcc/mingw32/include -isystem /extra/crossgcc/mingw32/sys-include -ffloat-store -fno-omit-frame-pointer -O2 -pipe -g0 -s -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc -L/root/gccbuild/mingw32/libjava -L/root/gccbuild/mingw32/libjava/.libs ./.libs/libgcj.a -L/root/gccbuild/mingw32/libstdc++-v3/src -L/root/gccbuild/mingw32/libstdc++-v3/src/.libs -L/root/gccbuild/gcc -L/extra/crossgcc/mingw32/bin -L/extra/crossgcc/mingw32/lib -L/extra/crossgcc/lib/../mingw32/lib -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -Wl,--rpath -Wl,/extra/crossgcc/mingw32/lib ./.libs/libgcj.a(natLogger.o):natLogger.cc:(.text$_ZN4java4util7logging6 Logger7getNameEv[java::util::logging::Logger::getName()]+0x0): multiple definition of `java::util::logging::Logger::getName()' ./.libs/libgcj.a(logging.o):logging.lolist:(.text+0x2004): first defined here collect2: ld returned 1 exit status make[2]: *** [jv-convert.exe] Error 1 make[2]: Leaving directory `/root/gccbuild/mingw32/libjava' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gccbuild/mingw32/libjava' make: *** [all-target-libjava] Error 2 Press ENTER when you are ready to install... Tom>Yeah... RMI doesn't get much love. If you have a Tom>self-contained test case, please file a PR. That way at least Tom>we won't lose it... Call me silly, I don't really know how and where to file a PR. Is there any guideline? Regards Rui
PR24138 and flexible arrays in C++
Hi folks.
The code below is ICE-ing in C++:
typedef struct {
unsigned char dir;
int data[];
} AiDefaultRailBlock;
static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
According to our docs, this is valid under flexible arrays:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Zero-Length.html#Zero-Length
Mark has a note on the PR that says C++ does not support flexible arrays,
but our documentation seems to imply we do. The discussion of
zero-length arrays (and flexible arrays) is under the "Extensions to the
C Language Family" section.
Should we specify that flexible arrays are not supported in C++?
How about:
struct foo {
int bar;
int a[];
} hot;
This compiles fine with either C or C++. Shouldn't we disallow this
initialization in C++ if we don't support flexible sized arrays?
Aldy
RE: Cross compile, no grmic/grmiregistry
TJ>You're right. When building the cross compiler, these items TJ>are excluded. It was when going on from there to build the TJ>native compiler from the cross compiler that they are included. After all, I think you may be right. Cos when I tried to remove the If Native ... End if from Makefile.am during building the cross compiler, The error is identical to the error of building the native compiler from cross compiler. This is how it make me thinking. Do you have any experience of the error I got from building the native compiler? (you may reference my previous email for more Details) mingw32-ar cru .libs/libgij.a gij.o mingw32-ranlib .libs/libgij.a creating libgij.la (cd .libs && rm -f libgij.la && ln -s ../libgij.la libgij.la) /bin/sh ./libtool --tag=GCJ --mode=link /root/gccbuild/gcc/gcj -B/root/gccbuild/gcc/ -B/extra/crossgcc/mingw32/bin/ -B/extra/crossgcc/mingw32/lib/ -isystem /extra/crossgcc/mingw32/include -isystem /extra/crossgcc/mingw32/sys-include -L/root/gccbuild/mingw32/libjava -ffloat-store -fno-omit-frame-pointer -O2 -pipe -g0 -s -o jv-convert.exe --main=gnu.gcj.convert.Convert -rpath /extra/crossgcc/mingw32/lib -shared-libgcc -L/root/gccbuild/mingw32/libjava/.libs libgcj.la /root/gccbuild/gcc/gcj -B/root/gccbuild/gcc/ -B/extra/crossgcc/mingw32/bin/ -B/extra/crossgcc/mingw32/lib/ -isystem /extra/crossgcc/mingw32/include -isystem /extra/crossgcc/mingw32/sys-include -ffloat-store -fno-omit-frame-pointer -O2 -pipe -g0 -s -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc -L/root/gccbuild/mingw32/libjava -L/root/gccbuild/mingw32/libjava/.libs ./.libs/libgcj.a -L/root/gccbuild/mingw32/libstdc++-v3/src -L/root/gccbuild/mingw32/libstdc++-v3/src/.libs -L/root/gccbuild/gcc -L/extra/crossgcc/mingw32/bin -L/extra/crossgcc/mingw32/lib -L/extra/crossgcc/lib/../mingw32/lib -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -Wl,--rpath -Wl,/extra/crossgcc/mingw32/lib ./.libs/libgcj.a(natLogger.o):natLogger.cc:(.text$_ZN4java4util7logging6 Logger7getNameEv[java::util::logging::Logger::getName()]+0x0): multiple definition of `java::util::logging::Logger::getName()' ./.libs/libgcj.a(logging.o):logging.lolist:(.text+0x2004): first defined here collect2: ld returned 1 exit status make[2]: *** [jv-convert.exe] Error 1 make[2]: Leaving directory `/root/gccbuild/mingw32/libjava' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gccbuild/mingw32/libjava' make: *** [all-target-libjava] Error 2 Press ENTER when you are ready to install... Cheers Rui
arm-rtems Ada Aligned_Word compilation error
Hi, Gcc on the head fails to compile arm-rtems4.7 at the following point when Ada is enabled. ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg s-auxdec.adb -o s-auxdec.o s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4 Any ideas? -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED] On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
RFC/RFH: My new library call rewriting optimization pass is ICEing
The essence of the pass is that it transforms
new java.lang.StringBuffer();
into
new gnu.gcj.runtime.StringBuffer();
My first attempt is to insert my pass immediatly after pass_build_ssa.
I am trying to do the first part of transform with this code:
.
.
.
tree stmt = bsi_stmt (bsi);
tc = TREE_CODE(stmt);
if (MODIFY_EXPR == tc) {
tree rhs = TREE_OPERAND(stmt, 1);
tc = TREE_CODE(rhs);
if (CALL_EXPR == tc) {
tree fn = TREE_OPERAND(rhs, 0);
tc = TREE_CODE(fn);
if (ADDR_EXPR == tc) {
tree ddd = TREE_OPERAND(fn, 0);
tc = TREE_CODE(ddd);
if (FUNCTION_DECL == tc) {
tree id = DECL_NAME(ddd);
tc = TREE_CODE(id);
const char *name = IDENTIFIER_POINTER(id);
if (name && 0 == strcmp(name, "_Jv_AllocObjectNoFinalizer")) {
tree args = TREE_OPERAND(rhs, 1);
tc = TREE_CODE(args);
tree arg1 = TREE_VALUE(args);
tc = TREE_CODE(arg1);
tree tch = TREE_CHAIN(args);
if (!tch && ADDR_EXPR == tc) {
tree jj = TREE_OPERAND(arg1, 0);
tc = TREE_CODE(jj);
if (VAR_DECL == tc) {
tree jjid = DECL_NAME(jj);
const char *jjname = IDENTIFIER_POINTER(jjid);
if (jjname && 0 == strcmp(jjname,
"java.lang.StringBuffer.class")) {
tree jjtype = TREE_TYPE(jj);
tree id = get_identifier ("gnu.gcj.runtime.StringBuffer");
tree cls = resolve_and_layout(id, NULL);
tree overridden = build_class_ref(TREE_TYPE(cls));
java_mark_addressable (TREE_OPERAND (overridden, 0));
TREE_VALUE(args) = overridden;
}
}
}
}
}
}
}
}
.
.
.
The tree dumps show that the call to _Jv_AllocObjectNoFinalizer is being
transformed in the desired manner, but I am getting an ICE in
compute_may_aliases(). Because the gnu.gcj.runtime.StringBuffer.class
var has not been properly initialized (missing var_ann). This
annotation is added by one of the passes previous to pass_build_ssa.
I am starting to think that even if I figure out how to add the proper
annotations to my new var, that this will be very brittle and there will
be an unending series of similar problems.
Q: Is this type of rewriting possible or advisable at this point in the
compilation process?
I could move the transformation to a point much earlier (perhaps in the
java front end) but that might make it much more difficult to analyze
the control flow to see if the optimization is possible.
Opinions?
Thanks,
David Daney
Re: r106743 - in /trunk/gcc: ChangeLog Makefile.in ...
On Thu, 10 Nov 2005 [EMAIL PROTECTED] wrote: > Author: dberlin > Date: Thu Nov 10 17:23:49 2005 > New Revision: 106743 > 2005-11-10 Daniel Berlin <[EMAIL PROTECTED]> > (heapvar_lookup): New function. /home/hp/combined/combined/gcc/tree-ssa-structalias.c: In function `heapvar_lookup': /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: `from' undeclared (first use in this function) /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: (Each undeclared identifier is reported only once /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: for each function it appears in.) /home/hp/combined/combined/gcc/tree-ssa-structalias.c:317: warning: unused parameter `stmt' make[4]: *** [tree-ssa-structalias.o] Error 1 I'll make the obvious s/stmt/from/ in that function if it trivially fixes the build (and nobody else got to it). But as it must've been untested, it seems likely there are other bugs in that commit. brgds, H-P
Re: r106743 - in /trunk/gcc: ChangeLog Makefile.in ...
On Thu, 2005-11-10 at 13:37 -0500, Hans-Peter Nilsson wrote: > On Thu, 10 Nov 2005 [EMAIL PROTECTED] wrote: > > > Author: dberlin > > Date: Thu Nov 10 17:23:49 2005 > > New Revision: 106743 > > > 2005-11-10 Daniel Berlin <[EMAIL PROTECTED]> > > > (heapvar_lookup): New function. > > /home/hp/combined/combined/gcc/tree-ssa-structalias.c: In function > `heapvar_lookup': > /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: `from' > undeclared (first use in this function) > /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: (Each > undeclared identifier is reported only once > /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: for each > function it appears in.) > /home/hp/combined/combined/gcc/tree-ssa-structalias.c:317: warning: unused > parameter `stmt' > make[4]: *** [tree-ssa-structalias.o] Error 1 > > I'll make the obvious s/stmt/from/ in that function if it > trivially fixes the build (and nobody else got to it). > > But as it must've been untested, it seems likely there are other > bugs in that commit. Actually, it was tested. I stupidly renamed it when i was doing the commit, to match the comment. > > brgds, H-P
[RFC] PR C++/24138
More questions wrt this PR. The problem here is in reshape_init_array_1. Ever since we made max_index_cst and index *unsigned* HOST_WIDE_INT, we are causing the loop over initializers to wrongly iterate when we have zero sized arrays. Since on a zero sized array, we have "tree max_index" set to: constant invariant -1> We set max_index_cst to be set to MAX_INT, and the loop over the initializers happens (when it shouldn't). We originally made max_index_cst/index an unsigned here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01962.html I believe we should special case max_index being -1 to handle zero sized arrays correctly. (Frustratingly, max_index above yields false on integer_all_onesp(), but we can tackle that once we can agree what to do here.) Is it ok to special case max_index being -1? Aldy
Re: Cross compile, no grmic/grmiregistry
Rui, I just checked in the patch to correct this problem. See PR 20993. This has also been backported to the 4.0 branch, so if you update on either mainline or the 4.0 branch, you should get the fix. Note that the fix is to gcjh, so you are best rebuilding from scratch. TJ On 11/10/05, Rui Wang <[EMAIL PROTECTED]> wrote: > Tom>No, it is more like some weird configure/build thing having to > Tom>do with cross-builds. > > I tried to make the following changes, but a error on generating > Jv-convert has been thrown during buildinig cross compiler to win > platform. (I was able to successfully build this cross compiler before I > made these changes.) Any input would be much appreciated. > > Ok, here goes the changes: > > /my_gcc_src_dir/libjava/Makefile.am > Orignal: > --- > ## For now, only on native systems. FIXME. > if NATIVE > bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool > > ## It is convenient to actually build and install the default database > ## when gcj-dbtool is available. > dbexec_DATA = $(db_name) > Endif > > > After change:nothing special really, just comment out if Native. > - > ## For now, only on native systems. FIXME. > ##if NATIVE > bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool > > ## It is convenient to actually build and install the default database > ## when gcj-dbtool is available. > dbexec_DATA = $(db_name) > ##endif > - > > Then I ran automake in the make file directory to create new > Makefile.in(automake 1.9.3): > Automake Makefile > > After started building the cross compiler, a error has been thrown while > make: > > mingw32-ar cru .libs/libgij.a gij.o > mingw32-ranlib .libs/libgij.a > creating libgij.la > (cd .libs && rm -f libgij.la && ln -s ../libgij.la libgij.la) > /bin/sh ./libtool --tag=GCJ --mode=link /root/gccbuild/gcc/gcj > -B/root/gccbuild/gcc/ -B/extra/crossgcc/mingw32/bin/ > -B/extra/crossgcc/mingw32/lib/ -isystem /extra/crossgcc/mingw32/include > -isystem /extra/crossgcc/mingw32/sys-include > -L/root/gccbuild/mingw32/libjava -ffloat-store -fno-omit-frame-pointer > -O2 -pipe -g0 -s -o jv-convert.exe --main=gnu.gcj.convert.Convert -rpath > /extra/crossgcc/mingw32/lib -shared-libgcc > -L/root/gccbuild/mingw32/libjava/.libs libgcj.la > /root/gccbuild/gcc/gcj -B/root/gccbuild/gcc/ > -B/extra/crossgcc/mingw32/bin/ -B/extra/crossgcc/mingw32/lib/ -isystem > /extra/crossgcc/mingw32/include -isystem > /extra/crossgcc/mingw32/sys-include -ffloat-store > -fno-omit-frame-pointer -O2 -pipe -g0 -s -o jv-convert.exe > --main=gnu.gcj.convert.Convert -shared-libgcc > -L/root/gccbuild/mingw32/libjava -L/root/gccbuild/mingw32/libjava/.libs > ./.libs/libgcj.a -L/root/gccbuild/mingw32/libstdc++-v3/src > -L/root/gccbuild/mingw32/libstdc++-v3/src/.libs -L/root/gccbuild/gcc > -L/extra/crossgcc/mingw32/bin -L/extra/crossgcc/mingw32/lib > -L/extra/crossgcc/lib/../mingw32/lib -lmingw32 -lgcc -lmoldname > -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 > -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -lgcc -lmoldname -lmingwex > -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc > -lmoldname -lmingwex -lmsvcrt -Wl,--rpath > -Wl,/extra/crossgcc/mingw32/lib > ./.libs/libgcj.a(natLogger.o):natLogger.cc:(.text$_ZN4java4util7logging6 > Logger7getNameEv[java::util::logging::Logger::getName()]+0x0): multiple > definition of `java::util::logging::Logger::getName()' > ./.libs/libgcj.a(logging.o):logging.lolist:(.text+0x2004): first defined > here > collect2: ld returned 1 exit status > make[2]: *** [jv-convert.exe] Error 1 > make[2]: Leaving directory `/root/gccbuild/mingw32/libjava' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/gccbuild/mingw32/libjava' > make: *** [all-target-libjava] Error 2 > Press ENTER when you are ready to install... > > > > Tom>Yeah... RMI doesn't get much love. If you have a > Tom>self-contained test case, please file a PR. That way at least > Tom>we won't lose it... > > Call me silly, I don't really know how and where to file a PR. Is there > any guideline? > > Regards > Rui >
Re: Cross compile, no grmic/grmiregistry
> Call me silly, I don't really know how and where to file a PR. Is there > any guideline? I just realized that I referred you to a PR and you had asked what that meant. It is a record in the GCC Bugzilla database: http://gcc.gnu.org/bugzilla/ TJ
Re: PR24138 and flexible arrays in C++
Aldy Hernandez wrote:
> Hi folks.
>
> The code below is ICE-ing in C++:
>
> typedef struct {
> unsigned char dir;
> int data[];
> } AiDefaultRailBlock;
> static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
>
> According to our docs, this is valid under flexible arrays:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Zero-Length.html#Zero-Length
>
> Mark has a note on the PR that says C++ does not support flexible arrays,
> but our documentation seems to imply we do.
What I actually said is that I'm not sure we ought to support this in
C++. I agree that there's nothing in the manual at the moment that
suggests that we don't support it. I don't really think anybody has
thought hard about this issue or consciously triedto implement it in G++.
Ideally, I think we would support it; I'm just not sure exactly what
restrictions, if any, should apply to the flexible array data member.
For example, perhaps the type of the elements should be one that does
not require construction. Perhaps that's OK; I'm just not sure.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: Cross compile, no grmic/grmiregistry
> On Thu, 2005-11-10 at 14:05 -0700, TJ Laurenzo wrote: > > Call me silly, I don't really know how and where to file a PR. Is there > > any guideline? > I just realized that I referred you to a PR and you had asked what > that meant. It is a record in the GCC Bugzilla database: > http://gcc.gnu.org/bugzilla/ Each PR/issue/bug number can also be accessed through an URL like: http://gcc.gnu.org/PR20993 And at the bottom of each page you have links for querying or creating new PRs. signature.asc Description: This is a digitally signed message part
Re: PR24138 and flexible arrays in C++
Mark Mitchell <[EMAIL PROTECTED]> writes: | Ideally, I think we would support it; I'm just not sure exactly what | restrictions, if any, should apply to the flexible array data member. | For example, perhaps the type of the elements should be one that does | not require construction. Perhaps that's OK; I'm just not sure. Maybe accept it just the way it is used in C, e.g. POD, no inheritance, no fancy stuff. -- Gaby
gcc-4.0-20051110 is now available
Snapshot gcc-4.0-20051110 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051110/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 106756 You'll find: gcc-4.0-20051110.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20051110.tar.bz2 C front end and core compiler gcc-ada-4.0-20051110.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20051110.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20051110.tar.bz2 C++ front end and runtime gcc-java-4.0-20051110.tar.bz2 Java front end and runtime gcc-objc-4.0-20051110.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20051110.tar.bz2The GCC testsuite Diffs from 4.0-20051020 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: PR24138 and flexible arrays in C++
On Thu, Nov 10, 2005 at 11:35:20PM +0100, Gabriel Dos Reis wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > | Ideally, I think we would support it; I'm just not sure exactly what > | restrictions, if any, should apply to the flexible array data member. > | For example, perhaps the type of the elements should be one that does > | not require construction. Perhaps that's OK; I'm just not sure. > > Maybe accept it just the way it is used in C, e.g. POD, no > inheritance, no fancy stuff. I think we have to do at least that, because using the extension in C is common, and headers get shared by C and C++. It's probably fine to refuse it in the context of inheritance and the like.
RE: Cross compile, no grmic/grmiregistry
Thank you all you guys' help. I went for the new version in GCC-4_0-branch, it is working wonderfully. Rui >-Original Message- >From: Mark Wielaard [mailto:[EMAIL PROTECTED] >Sent: 10 November 2005 21:28 >To: [EMAIL PROTECTED] >Cc: Rui Wang; [EMAIL PROTECTED]; Ranjit Mathew; >gcc@gcc.gnu.org; [EMAIL PROTECTED] >Subject: Re: Cross compile, no grmic/grmiregistry > >> On Thu, 2005-11-10 at 14:05 -0700, TJ Laurenzo wrote: >> > Call me silly, I don't really know how and where to file a PR. Is >> > there any guideline? >> I just realized that I referred you to a PR and you had asked what >> that meant. It is a record in the GCC Bugzilla database: >> http://gcc.gnu.org/bugzilla/ > >Each PR/issue/bug number can also be accessed through an URL like: >http://gcc.gnu.org/PR20993 > >And at the bottom of each page you have links for querying or >creating new PRs. >
