Re: C++: operator new and disabled exceptions
hello, there is a difference between calling new and new (std::nothrow) from a fno-exceptions context: - new (std::nothrow) would return 0 in case of error - new () would throw std::bad_alloc that would finish in std::terminate() or abort() so there is a possible difference in behavior if an -fno-exceptions application relies on std::terminate(). so if you patch gcc to use the nothrow internally, you would need to compile all your applications and all your libraries and runtimes with -fcheck-new. Christian Christophe LYON wrote: Hello, I have already asked this question on gcc-help (see http://gcc.gnu.org/ml/gcc-help/2007-09/msg00328.html), but I would like advice from GCC developers. Basically, when I compile with -fno-exceptions, I wonder why the G++ compiler still generates calls to the standard new operator (the one that throws bad_alloc when it runs out of memory), rather than new(nothrow) (_ZnwjRKSt9nothrow_t) ? In addition, do you think I can patch my GCC such that it calls new(nothrow) when compiling with -fno-exceptions, or is it a bad idea? (compatibility issues, ...) Thanks for your recommendation, Christophe.
Re: GCC 4.2.2 RC2 (finally)
On 28/09/2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > I'm finally spinning GCC 4.2.2 RC2. > > Please do not make any further check-ins to the GCC 4.2 branch, even > those that have been previously approved, without my explicit approval. > > I apologize to everyone for the delay in bringing out GCC 4.2.2. > > Thanks, > Would you consider the patch in http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01735.html before the release? Also, the script that generates the release is supposed to generate the install documents but, that doesn't seem to be working because GCC 4.0.0 and GCC 4.1.0 contained a lot of HTML files in INSTALL/. However, the HTML files are missing in GCC 4.2.0 and in this GCC 4.2.2 RC2. Cheers, Manuel.
C++: operator new and disabled exceptions
Hello, I have already asked this question on gcc-help (see http://gcc.gnu.org/ml/gcc-help/2007-09/msg00328.html), but I would like advice from GCC developers. Basically, when I compile with -fno-exceptions, I wonder why the G++ compiler still generates calls to the standard new operator (the one that throws bad_alloc when it runs out of memory), rather than new(nothrow) (_ZnwjRKSt9nothrow_t) ? In addition, do you think I can patch my GCC such that it calls new(nothrow) when compiling with -fno-exceptions, or is it a bad idea? (compatibility issues, ...) Thanks for your recommendation, Christophe.
RE: MetaHTML and the GCC web site
On 28 September 2007 18:07, Joel Sherrill wrote: > Dave Korn wrote: >> On 28 September 2007 17:10, François-Xavier Coudert wrote: >>> PS: The compilation error I get, if that rings a bell to someone who >>> installed metahtml on the webserver, is in libmhtml: >> so maybe try escaping the line ends and see if that helps? >> > That's the change that's required. WAG FTW :-) cheers, DaveK -- Can't think of a witty .sigline today
RE: MetaHTML and the GCC web site
On 28 September 2007 17:10, François-Xavier Coudert wrote: > PS: The compilation error I get, if that rings a bell to someone who > installed metahtml on the webserver, is in libmhtml: > > Compiling pagefuncs.c into pagefuncs.o > gcc -Wall -Wstrict-prototypes -Wshadow -g -DHAVE_CONFIG_H -I. -I.. - > I../libutils -I../libutils/regex -I/tmp/gdbm-1.8.3/include -I..- > DCOMPILE_TIME_MODULE_DIRECTORY='"/opt/metahtml-5.091/lib"' -c > pagefuncs.c > pagefuncs.c:1070:1: error: unterminated argument list invoking macro > "DEFINE_SECTION" > pagefuncs.c:135: error: parse error at end of input > > where pagefuncs.c contains at line 135: > > DEFINE_SECTION (PAGE-VARIABLES, , "[... here was multiline > text ...]", "[... and here was also multiline text > like that ...]") I've never heard of metahtml, I don't have the sources, and I have absolutely no idea about what's going on here[*]. But one little flag did pop up at me: sometime in that timeframe (i.e. since late '90s), we stopped supporting continuation of quoted text across line-ends without an escape, i.e. we used to accept char *fred = "this is a multi-line text message\n"; where now we require char *fred = "this is a \ multi-line text \ message\n"; so maybe try escaping the line ends and see if that helps? cheers, DaveK [*] - So, little change there then... ;-) -- Can't think of a witty .sigline today
Re: testsuite for libgomp and so on...
On 9/27/07, Ben Elliston <[EMAIL PROTECTED]> wrote: > libcpp has a testsuite of sorts, GCC's testsuite. ;-) Plus part of GCC's testsuite, there is a preprocessor testcases which are located at gcc.dg/cpp . libssp is tested by two testcases in the gcc testsuite, gcc.dg/ssp-1.c and gcc.dg/ssp-2.c (though it should be noted libssp is not always built even if -fstack-protection is supported). Also there is no testsuite for libgfortran and libobjc but those are both tested by the fortran and Objective-C testcases, respectively. Thanks, Andrew Pinski
Fwd: MetaHTML and the GCC web site
Hi all, I'm currently rewriting the fortran/ part of the GCC website and trying to use the website preprocessor locally, to check my modifications (which include bringing fortran/ to the website common style). The script needs mhc, which seems to be the metahtml compiler. I tried to compile metahtml-5.08 as well as metahtml-5.091 (tarbal from the sources on sourceware, kindly provided by Ian Taylor) but both compilations dies in a subdirectory. I then wanted to ask for help on the metahtml mailing-list, but noticed that there has been no activity on those since 1999, which brings two questions: how was metahtml compiled for the current webserver (the error I see is certainly not target-specific), and should we use a tool that has been deceased for 8 years to produce our website? FX PS: The compilation error I get, if that rings a bell to someone who installed metahtml on the webserver, is in libmhtml: Compiling pagefuncs.c into pagefuncs.o gcc -Wall -Wstrict-prototypes -Wshadow -g -DHAVE_CONFIG_H -I. -I.. - I../libutils -I../libutils/regex -I/tmp/gdbm-1.8.3/include -I..- DCOMPILE_TIME_MODULE_DIRECTORY='"/opt/metahtml-5.091/lib"' -c pagefuncs.c pagefuncs.c:1070:1: error: unterminated argument list invoking macro "DEFINE_SECTION" pagefuncs.c:135: error: parse error at end of input where pagefuncs.c contains at line 135: DEFINE_SECTION (PAGE-VARIABLES, , "[... here was multiline text ...]", "[... and here was also multiline text like that ...]")
Re: MetaHTML and the GCC web site
Dave Korn wrote: On 28 September 2007 17:10, François-Xavier Coudert wrote: PS: The compilation error I get, if that rings a bell to someone who installed metahtml on the webserver, is in libmhtml: Compiling pagefuncs.c into pagefuncs.o gcc -Wall -Wstrict-prototypes -Wshadow -g -DHAVE_CONFIG_H -I. -I.. - I../libutils -I../libutils/regex -I/tmp/gdbm-1.8.3/include -I..- DCOMPILE_TIME_MODULE_DIRECTORY='"/opt/metahtml-5.091/lib"' -c pagefuncs.c pagefuncs.c:1070:1: error: unterminated argument list invoking macro "DEFINE_SECTION" pagefuncs.c:135: error: parse error at end of input where pagefuncs.c contains at line 135: DEFINE_SECTION (PAGE-VARIABLES, , "[... here was multiline text ...]", "[... and here was also multiline text like that ...]") I've never heard of metahtml, I don't have the sources, and I have absolutely no idea about what's going on here[*]. But one little flag did pop up at me: sometime in that timeframe (i.e. since late '90s), we stopped supporting continuation of quoted text across line-ends without an escape, i.e. we used to accept char *fred = "this is a multi-line text message\n"; where now we require char *fred = "this is a \ multi-line text \ message\n"; so maybe try escaping the line ends and see if that helps? That's the change that's required. The RTEMS website is based loosely on the gcc site and I had to make that change or maybe Gerald sent me a patch. I will forward what I got from Gerald to you Francois. --joel cheers, DaveK [*] - So, little change there then... ;-)
Re: Profile information - CFG
On 9/27/07, Hariharan Sandanagobalane <[EMAIL PROTECTED]> wrote: > Hello, > I am implementing support for PBO on picochip port of GCC (not yet > submitted to mainline). > > I see that GCC generates 2 files, xx.gcno and xx.gcda, containing the > profile information, the former containing the flow graph > information(compile-time) and later containing the edge profile > information(run-time). The CFG information seems to be getting emitted > quite early in the compilation process(pass_tree_profile). Is the > instrumentation also done at this time? If it is, as later phases change Yes. > CFG, how is the instrumentation code sanity maintained? If it isnt, How Instrumentation code sanity is naturally maintained since those are global load/stores. The compiler transformations naturally preserve the original semantic of the input and since profile counters are global variables, update to those are preserved to provide what unoptimized code would do. > would you correlate the CFG in gcno file to the actual CFG at > execution(that produces the gcda file)? > As for our port's case, we are already able to generate profile > information using our simulator/hardware, and it is not-too-difficult > for me to format that information into .gcno and .gcda files. But, i > guess the CFG that i would have at runtime would be quite different from > the CFG at initial phases of compilation (even at same optimization > level). Any suggestions on this? Would i be better off keeping the gcno > file that GCC generates, try to match the runtime-CFG to the one on the > gcno file and then write gcda file accordingly? Not only better off, you *need* to provide information that matches what's in gcno, otherwise gcc can't read that gcda nor use it. How you match gcno is a different problem - there's no guarantee that you'll be able to recover enough information from the output assembly of gcc, because without instrumentation, gcc can optimize away the control flow. pass_tree_profile is when both the instrumentation (with -fprofile-generate) and reading of the profile data (with -fprofile-use) are done. The CFG has to remain the same between generate and use - otherwise the compiler isn't able to use the profile data. Seongbae
gcc-4.3-20070928 is now available
Snapshot gcc-4.3-20070928 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070928/ 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 revision 128873 You'll find: gcc-4.3-20070928.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070928.tar.bz2 C front end and core compiler gcc-ada-4.3-20070928.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070928.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070928.tar.bz2 C++ front end and runtime gcc-java-4.3-20070928.tar.bz2 Java front end and runtime gcc-objc-4.3-20070928.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070928.tar.bz2The GCC testsuite Diffs from 4.3-20070921 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
Ada bootstrap broken
This change breaks Ada: 2007-09-27 Ollie Wild <[EMAIL PROTECTED]> * varasm.c (compare_constant): Removed call to ... * langhooks-def.h (lhd_return_tree): Removed. (LANG_HOOKS_EXPAND_CONSTANT): Removed. (LANG_HOOKS_INITIALIZER): Removed LANG_HOOKS_EXPAND_CONSTANT. * langhooks.c (lhd_return_tree): Removed. gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict -prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada -I. ./../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include -I../../gcc/gcc/../l ibcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/d pd -I../libdecnumber../../gcc/gcc/ada/misc.c -o ada/misc.o ../../gcc/gcc/ada/misc.c:162: error: 'lhd_return_tree' undeclared here (not in a function) make[3]: *** [ada/misc.o] Error 1 Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: AltiVec stack boundary
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > I'm sure this has come up before, but I don't understand how the > -maltivec definition of STACK_BOUNDARY can be right. We tell the > compiler that STACK_BOUNDARY == 128 if -maltivec, without telling it > that other people may ignore that, because -maltivec is not supposed > to be an ABI changing option but IIUC STACK_BOUNDARY is. > > Why isn't it 64 in the !TARGET_ALTIVEC case with > PREFERRED_STACK_BOUNDARY == 128? The case where this matters is a 32-bit ELF EABI target (the only case on powerpc that allows 8-byte stack alignment) using -maltivec but not -mabi=no-altivec. It's not clear to me that case works. I don't think that in general you want to do this in an embedded context, because of the extra code generated to align the stack; it'd be much better to just declare that you're going to use the AltiVec ABI, even if some parts of your embedded code won't be allowed to use any AltiVec instructions.
GCC 4.2.2 RC2 Available
GCC 4.2.2 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.2-RC-20070927y If you want to help test this release candidate, please download files from the directory given above, rather than checking out from SVN, so that we can catch any packaging problems. If you find problems, please file them in the GCC bug-tracker. See: http://gcc.gnu.org/bugs.html for instructions regarding fixing bugs. You may CC: me on the bug report, but please do not send mail directly to me about problems. If all goes to plan, I will make the final GCC 4.2.2 release next week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
"Dave Korn" <[EMAIL PROTECTED]> writes: > On 23 August 2007 22:34, Mark Mitchell wrote: > > > I do think that generating the same code, independent of host system, is > > a very important property of GCC's design, just like generating the same > > code independent of whether or not we're compiling with -g. > > Hear, hear. I've always thought these principles were meant to be > sacrosanct, but now I try to look it up, I don't see them explicitly > listed in either the development methodology, the release criteria, > or anywhere else likely-looking. > > Can the SC please consider adding these requirements explicitly to > the list of "Design and Development Goals" in the mission statement? > Or would it make more sense as part of the development methodology, > or the portability section of the gcc-specific coding conventions? > (Perhaps both; as a high-level goal in the mission statement, and > with additions to the portability section of the coding conventions > warning about issues like HOST_WIDE_INT size on 32-vs-64-bit hosts > and not using pointers in hashes.) As far as I know, this actually isn't a property of GCC's design, at present. Although the code generated is equivalent, there are a number of cases where it is not exactly the same. I don't remember them all, but one case was that in many places the code does something like: some_function(gen_reg_rtx(), gen_reg_rtx()); and so details of the RTL generated depend on the order of evaluation of function arguments. This was a big problem before we had GIMPLE, and may still be an issue.
Re: GCC 4.2.2 RC2 Available
On 29/09/2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > GCC 4.2.2 RC2 is now available from: > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.2-RC-20070927y > > If you want to help test this release candidate, please download files > from the directory given above, rather than checking out from SVN, so > that we can catch any packaging problems. If you find problems, > please file them in the GCC bug-tracker. See: > > http://gcc.gnu.org/bugs.html > > for instructions regarding fixing bugs. You may CC: me on the bug > report, but please do not send mail directly to me about problems. > > If all goes to plan, I will make the final GCC 4.2.2 release next > week. > [ I posted this before but I think you missed it. Otherwise let me know. I don't want to be annoying. ] Would you consider the patch in http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01735.html before the release? Also, the script that generates the release is supposed to generate the install documents but, that doesn't seem to be working because GCC 4.0.0 and GCC 4.1.0 contained a lot of HTML files in INSTALL/. However, the HTML files are missing in GCC 4.2.0 and in this GCC 4.2.2 RC2. Cheers, Manuel.
Re: GCC 4.2.2 RC2 Available
> > that we can catch any packaging problems. If you find problems, > > please file them in the GCC bug-tracker. See: > > > > http://gcc.gnu.org/bugs.html > > > > for instructions regarding fixing bugs. You may CC: me on the bug > > report, but please do not send mail directly to me about problems. Oh. I should read the complete mail before replying (* 1000 times). I'll open two PRs for these. Beg your pardon, Manuel.
Re: tgmath.h and newlib
Richard Sandiford <[EMAIL PROTECTED]> writes: > Sorry if this has been discussed before, but the c99-tgmath-* tests > are failing on most newlib targets. The problem is that tgmath.h > unconditionally includes complex.h, which non-linux newlibs don't > provide. What's the best fix? Including complex.h from tgmath.h > seems reasonable on the face of it, given that both are C99 headers. > So should we simply skip these tests for !c99_runtime? Yes, skip the tests; I think this makes most sense. tgmath.h is part of C99.
Re: Ada bootstrap broken
On 9/28/07, John David Anglin <[EMAIL PROTECTED]> wrote: > This change breaks Ada: Sorry, folks. I've rolled this back. Ollie
