Re: warnings as errors in gcc/gcc/config/i386/i386.c
Quoting Jack Howarth : Also, I don't seem able to suppress this build failure with... I think fcode should be assigned some value in the default case instead. Is that expected behavior in current gcc trunk? Strange, I just bootstrapped r162030 with a small unrelated change on gcc16 (x86_64-unknown-linux-gnu), and it didn't complain about this... /home/amylaar/pr44874/bldxx/./prev-gcc/g++ -B/home/amylaar/pr44874/bldxx/./prev-gcc/ -B/home/amylaar/instxx/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -I/home/amylaar/pr44874/bldxx/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/amylaar/pr44874/bldxx/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/amylaar/pr44874/gcc/libstdc++-v3/libsupc++ -L/home/amylaar/pr44874/bldxx/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpfr-2.4.1/include -I/opt/cfarm/mpc-0.8/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber \ ../../gcc/gcc/config/i386/i386.c -o i386.o
libgmpxx and multiple C++ libraries
I envision a serious problem for C++ builds of GCC. The next 3 paragraphs provide some context on how I came across it, but are not critical to understand it, so feel free to skip. For the past several hours, I've been trying to get the GCC build machinery to come to terms with gmp in the build tree. My earlier attempts seem to have not taken into account the need for libgmpxx, that such packages as ppl (and cloog?) display and thus bring into gcc compilers. The problem I'm running into ATM is that libgmpxx, in the build tree, is built as a static library, which does not bring the required libstdc++, which C programs linking with libgmpxx need. OTOH, building it as a dynamic library wouldn't quite work, for we don't install the in-tree built gmp, and, from the number of tricks I have to employ to get ppl et al to build, I get the impression that they don't expect to find gmp in its build tree. I don't have a solution for this yet, other than explicitly mentioning -lstdc++ (and -lm) in --with-host-libstdcxx. The reason I hadn't noticed it before was that I happened to have a dynamic libgmpxx installed, and this used to be used for my in-tree PPL builds. This issue became apparent, however, when one of the hosts I use for building was upgraded from Fedora 12 to 13: for reasons as yet undetermined, GNU ld in Fedora 13 fails to link with libgmpxx, unless libstdc++ and libm are linked in explicitly. This is inconvenient, but not such a big deal. Anyhow, the problem I envision is that of having two different C++ libraries linked into a single GCC program. Consider a pre-installed libgmpxx.so that requires libstdc++.so.N. Further consider we're bootstrapping GCC and we get on to stage2, using the stage1 g++ (--enable-build-with-cxx) and libstdc++.so.N+1. This will link both versions of libstdc++.so into the compilers created in stage2. This might fail to link, or it may fail to run while trying to build target libraries. I'm not sure what, if anything, we ought to do about this. Basically, the only way around this is to bootstrap gmpxx and ppl along with the compilers. Perhaps, once we bump the libstdc++ major, we should warn/refuse to configure to build-with-cxx, if gmp (and ppl?) is not being bootstrapped along with the compiler, and the pre-installed version uses the old libstdc++ major. Of course we can also do nothing and let the build fail later on, but this strikes me as undesirable. No immediate action is required, but we'll eventually have to deal with this if we keep on using external C++ libs. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: warnings as errors in gcc/gcc/config/i386/i386.c
On Sat, Jul 10, 2010 at 03:11:51AM -0400, Joern Rennecke wrote: > Quoting Jack Howarth : > >> Also, I don't seem able to suppress this build failure with... > > I think fcode should be assigned some value in the default case instead. > >> Is that expected behavior in current gcc trunk? > > Strange, I just bootstrapped r162030 with a small unrelated change on gcc16 > (x86_64-unknown-linux-gnu), and it didn't complain about this... > > /home/amylaar/pr44874/bldxx/./prev-gcc/g++ > -B/home/amylaar/pr44874/bldxx/./prev-gcc/ > -B/home/amylaar/instxx/x86_64-unknown-linux-gnu/bin/ -nostdinc++ > -I/home/amylaar/pr44874/bldxx/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu > > -I/home/amylaar/pr44874/bldxx/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include > > -I/home/amylaar/pr44874/gcc/libstdc++-v3/libsupc++ > -L/home/amylaar/pr44874/bldxx/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs > > -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. > -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include > -I../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpfr-2.4.1/include > -I/opt/cfarm/mpc-0.8/include -I../../gcc/gcc/../libdecnumber > -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber \ > ../../gcc/gcc/config/i386/i386.c -o i386.o The change suggested by Iain Sandoe of... Index: gcc/config/i386/i386.c === --- gcc/config/i386/i386.c (revision 162037) +++ gcc/config/i386/i386.c (working copy) @@ -30002,7 +30002,7 @@ tree itype = TREE_TYPE (vec_type); bool u = TYPE_UNSIGNED (itype); enum machine_mode vmode = TYPE_MODE (vec_type); - enum ix86_builtins fcode = fcode; /* Silence bogus warning. */ + enum ix86_builtins fcode = IX86_BUILTIN_MAX; bool ok = TARGET_SSE2; switch (vmode) eliminates the bootstrap failure on x86_64-apple-darwin10 when --enable-build-with-cxx is used.. Jack
dwarf, step over
Hi, Im working on a C source level debugger. The debug info available in elf format. How could be 'step over' implemented? The problem is at 'Point1', anyway I can wait for the next source line (reading it from the .debug_line table). Thanks ... if (a == 1) x = 1; //Point1 else if (a == 2) x = 1; z = 1; ...
Re: PING -- MicroBlaze target support patches
On Wed, 12 May 2010, Michael Eager wrote: > Could someone please review these patches? > > Add support for Xilinx MicroBlaze processor: > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01903.html This is okay with three small changes. Please use "Do not" instead of "Don't" in invoke.texi. Use proper markup for -fno-zero-initialized-in-bss in the same. Similarly, please use @var in Supported values are in the format vX.YY.Z, where X is a major version, YY is the minor version, and Z is compatiblity code. in invoke.texi. > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01905.html > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01908.html > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01907.html These three I cannot review/approve, but the strike me as pretty straightforward, not touching lots of core code? Where are we regarding this? Is this stuck somewhere? > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01906.html This is fine, too. For the announcement on the main page, let's say "processor" (lower case) and there is a closing missing on the changes.html page. Good work! Gerald
Re: GCC 4.6 secondary platform update
On Mon, 7 Jun 2010, Paolo Bonzini wrote: > From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html: >> It was also suggested to change hppa2.0w-hp-hpux11.11 >> to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the >> list of secondary targets. > Shall we proceed? I'd say "Yes", and I did not see any comments to the contrary, either. Let me quickly raise this with the steering committee... Gerald
Re: GCC 4.6 secondary platform update
On Sat, Jul 10, 2010 at 9:36 PM, Gerald Pfeifer wrote: > On Mon, 7 Jun 2010, Paolo Bonzini wrote: >> From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html: >>> It was also suggested to change hppa2.0w-hp-hpux11.11 >>> to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the >>> list of secondary targets. >> Shall we proceed? > > I'd say "Yes", and I did not see any comments to the contrary, either. Well, let me add one short comment then. I'd say hppa2-hpux is still much more relevant than ia64-hpux -- at least, everywhere I'm looking i.e. workstations. It may be different in the server market. Anyway, when I look at posted gcc-testresults of this month, there are *zero* postings of testresults for ia64-hpux, and daily results (more, in fact) for hppa2-hpux. can we keep hppa2.0w-hp-hpux11.11 as a secondary target for at least one more release, and not add ia64-hpux? Ciao! Steven
Re: GCC 4.6 secondary platform update
On Sat, 10 Jul 2010, Steven Bosscher wrote: > Well, let me add one short comment then. I'd say hppa2-hpux is still > much more relevant than ia64-hpux -- at least, everywhere I'm looking > i.e. workstations. It may be different in the server market. > > Anyway, when I look at posted gcc-testresults of this month, there are > *zero* postings of testresults for ia64-hpux, and daily results (more, > in fact) for hppa2-hpux. > > can we keep hppa2.0w-hp-hpux11.11 as a secondary target for at least > one more release, and not add ia64-hpux? I find your line of reasoning very convincing. :-) Gerald
Re: GCC 4.6 secondary platform update
On 07/10/2010 10:01 PM, Gerald Pfeifer wrote: On Sat, 10 Jul 2010, Steven Bosscher wrote: Well, let me add one short comment then. I'd say hppa2-hpux is still much more relevant than ia64-hpux -- at least, everywhere I'm looking i.e. workstations. It may be different in the server market. Anyway, when I look at posted gcc-testresults of this month, there are *zero* postings of testresults for ia64-hpux, and daily results (more, in fact) for hppa2-hpux. can we keep hppa2.0w-hp-hpux11.11 as a secondary target for at least one more release, and not add ia64-hpux? I find your line of reasoning very convincing. :-) The reason for ia64-hpux was that it exercises some unique code paths due to addp4, but Steven's reasoning is also convincing... Paolo
Re: [GIMPLE] Local variables
Jérémie Salvucci writes:
> I am trying to get an access to local variables of a function thanks
> to the GIMPLE representation. When I read the dump file after the CFG
> pass, I can see a new temporary variable added. For example with the
> identity function I would like to get an access to the uid of this
> variable.
>
> A piece of code :
>
> float
> id (float x)
> {
> return x;
> }
>
> Dump file :
>
>
> ;; Function id (id)
>
> Merging blocks 2 and 3
> id (float x)
> {
> float D.2718;
>
> :
> D.2718 = x;
> return D.2718;
>
> }
>
> In this example, I can have access to everything except the
> declaration of D.2718. It's the same thing with the explicit
> declaration of an int in an other example.
>
> Does anyone know how can I get this information ? Maybe I can't or
> maybe I do something wrong but I am a little bit stucked.
I think you'll find it in cfun->local_decls.
Ian
Re: Attributes
Sean Hunt writes: > void foo () __attribute__((noreturn)); // right per spec > void foo __attribute__((noreturn)) (); // works > __attribute__((noreturn)) void foo (); // works > > It's obvious that the first example of each kind (noreturn appearing > after the function declarator) must be accepted if it's a GCC > attribute and not if it's a C++0x attributes. The later two (noreturn > appearing before the declaration or after the identifier) must be > accepted for C++0x attributes, but it's not clear if the GCC syntax > being accepted is an accident or by design. As far as I can see they are both documenated as working at http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Attribute-Syntax.html , so I think it is by design. > Is anyone currently working on C++0x attributes in GCC and, if not, is > there anyone who can help me through what we should and shouldn't > accept in clang? I don't know the answer to this. It's clear that C++0x attributes are not the same as GNU attributes. Ian
Re: Compilation time in gcc-4.4.0
Maxiwell Garcia writes: > I am writing a paper about instruction-set architecture simulators. In > first time, I used gcc-4.4.0 and the compilation time reached 33 > minutes (with -O3) for my simulator and the performance reached 270 > MIPS (Million instruction per second). When I used the gcc-4.4.4, in > the same code, the compilation time reached 39 seconds and the > performance reached 600 MIPS. My code have many "switchs" with 512 > "cases" and the library is in use. > How to explain this behavior in the compilation and performance in my paper? If I'm reading this correctly, it sounds like a useful optimization fix in gcc 4.4.4. The compiler runs faster and generates better code. So I'm not sure what your question is. Are you asking us why gcc has gotten better? Ian
Re: dwarf, step over
John Smith writes: > Im working on a C source level debugger. The debug info available in elf > format. How could be 'step over' implemented? > The problem is at 'Point1', anyway I can wait for the > next source line (reading it from the .debug_line table). > > Thanks > > > ... > if (a == 1) > x = 1; //Point1 > else if (a == 2) > x = 1; > > z = 1; > ... This question is not appropriate for the gcc@gcc.gnu.org mailing list, which is for the developers of gcc. I really don't know where to ask questions about developing a debugger. If I were writing a debugger, I would probably just single step until the debug info indicated that I had entered a different line number. But that might be too slow. I don't know what actual debuggers do. Fortunately you can simply look at the source code for gdb to see what it does. Ian
gcc-4.6-20100710 is now available
Snapshot gcc-4.6-20100710 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100710/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 162045 You'll find: gcc-4.6-20100710.tar.bz2 Complete GCC (includes all of below) gcc-core-4.6-20100710.tar.bz2 C front end and core compiler gcc-ada-4.6-20100710.tar.bz2 Ada front end and runtime gcc-fortran-4.6-20100710.tar.bz2 Fortran front end and runtime gcc-g++-4.6-20100710.tar.bz2 C++ front end and runtime gcc-java-4.6-20100710.tar.bz2 Java front end and runtime gcc-objc-4.6-20100710.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.6-20100710.tar.bz2The GCC testsuite Diffs from 4.6-20100703 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
m4 requirement (was: prerequisites page)
Todd, On Wed, 19 May 2010, Todd Rinaldo wrote: > I'm writing to report a discrepancy in > http://gcc.gnu.org/install/prerequisites.html > > I just discovered that if gmp is boot strapped during gcc build and an > older m4 exists, when gmp calls flex, it will fail during configure > with: > > checking for flex... flex > checking lex output file root... configure: error: cannot find output from > flex; giving up > > I mention this because the prerequisites page specifies m4 as optional > if you're just building gcc. m4 appears to have a minimal requirement if > gmp is being boot strapped. thanks for the report, Todd. You mention m4, yet the output you show is around flex? I can update our documentation, but need more details and confirmation by the respective GCC maintainers on what exactly to adjust. Gerald
Re: libgmpxx and multiple C++ libraries
On 10 July 2010 15:52, Alexandre Oliva wrote: > for reasons as yet undetermined, GNU > ld in Fedora 13 fails to link with libgmpxx, unless libstdc++ and libm > are linked in explicitly. This is inconvenient, but not such a big > deal. Isn't that because of http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/sect-Release_Notes-The_GCC_Compiler_Collection.html ?
