Re: Making CFLAGS=-g1 bigger but more useful
On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote: > > I'm working on a little patch that extends the data produced for the > little-used (?) -g1 mode. Normally, this produces very little DWARF > data (basically just function declaration locus, PC range, and basic > backtrace-enabling data). Compared to normal -g (== -g2) mode, this > is very small. I think what I would like to have is a modus to generate line numbers (so that objdump -S works nicely) but nothing else. That would be useful for crash dump analysis etc. -Andi
Any plans to upgrade svn repository format to 1.5.0+ ?
Hi, Apparently the server is already running svn 1.5.5 but the repository format is pre-1.5.0. If the repository format was upgraded, we could start using proper svn merge support for branch maintenance and get rid of manual merges and svnmerge.py. There is even an upgrade path from the svnmerge.py to svn 1.5.0 merge support for existing branches. And the upgrade would not disturb those who are using pre-1.5.0 svn clients. Any thoughts? -- Laurynas
Re: Making CFLAGS=-g1 bigger but more useful
> The basic question though is whether there is interest here for this > sort of -g1.5 mode. We could ... Yes, definitely. I thought about it in two contexts -- regular debugging, and the fact that the OpenCL GSOC project might require looking at debug info for memory spaces and types of arguments. > - ignore the value of this enlarged -g1 and forget the idea > > - adopt the enlarged definition for -g1 and live with the size penalty > > - introduce a new -g1.5 (between DINFO_LEVEL_TERSE and DINFO_LEVEL_NORMAL) > to select the enlarged definition (syntax suggestions wanted) Another possibility, though a much bigger amount of work, would be to introduce -g options like -f. The presence of such an option would imply -g1 or higher, and then you could add -gparameters, -gline-numbers, -gvar-tracking, -gmacros, etc. Paolo
gcc-gdb compatibilty
hi , I have a small query. I am using gcc-4.3.3 version and gdb 5.3 version. Are the versions of gcc and gdb which I am using are compatible. Thanks in advance, Sumanth
heise.de comment on 4.4.0 release
Hello world, http://www.heise.de/newsticker/GCC-4-4-0-erschienen--/meldung/136529 reports the release of gcc 4.4.0 and also claims that 453.povray from SPEC CPU 2006 caused an ICE in g++. The tone of the report is fairly negative. Can somebody with access to SPEC sources confirm / deny and file a bug report, if appropriate? Thomas
Re: heise.de comment on 4.4.0 release
On Sat, Apr 25, 2009 at 7:02 AM, Thomas Koenig wrote: > Can somebody with access to SPEC sources confirm / deny and file a bug > report, if appropriate? It is an x87 bug only and has already been filed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856 and working on being fixed already. Thanks, Andrew Pinski
Re: heise.de comment on 4.4.0 release
Thomas Koenig wrote: > Hello world, > > http://www.heise.de/newsticker/GCC-4-4-0-erschienen--/meldung/136529 > > reports the release of gcc 4.4.0 and also claims that 453.povray from > SPEC CPU 2006 caused an ICE in g++. The tone of the report is fairly > negative. They accused us of a too-hasty release. My irony meter exploded! cheers, DaveK
Re: -O3 and new optimizations in 4.4.0
Sebastian Pop wrote: On Fri, Apr 24, 2009 at 08:12, Robert Dewar wrote: What would we have to do to make PPL and CLooG required to build GCC? Why would that be desirable? Seems to me the current situation is clearly preferable. To enable loop transforms in -O3. Note that loop optimizations like vectorization were only enabled after a cost analysis was in place that assured us (on average) that only beneficial optimizations would be attempted. Is that true for the loop transformations enabled by these optimizations as well ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
Re: heise.de comment on 4.4.0 release
Andrew Pinski wrote: On Sat, Apr 25, 2009 at 7:02 AM, Thomas Koenig wrote: Can somebody with access to SPEC sources confirm / deny and file a bug report, if appropriate? It is an x87 bug only and has already been filed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856 and working on being fixed already. A x87 bug only exposed using SPEC ?!?!?!? What are these guys thinking - like, lets cripple this benchmark and use completely out of date floating point arithmetic ? Duh, I hope the rest of their reporting is more useful ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.4/changes.html
Re: Making CFLAGS=-g1 bigger but more useful
> Another possibility, though a much bigger amount of work, would be to > introduce -g options like -f. The presence of such an option would > imply -g1 or higher, and then you could add -gparameters, > -gline-numbers, -gvar-tracking, -gmacros, etc. I would like to have that. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: heise.de comment on 4.4.0 release
Toon Moene wrote: >>> Can somebody with access to SPEC sources confirm / deny and file a bug >>> report, if appropriate? >> >> It is an x87 bug only and has already been filed: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856 and working on >> being fixed already. The reason that is was not found before - despite several people running SPEC's CPU benchmark - was exactly that they run it in 32bit mode. After they send me the options, Richard could immediately reproduce the problem. The patch is at: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01926.html > A x87 bug only exposed using SPEC ?!?!?!? Seemingly yes. To a certain extend this was by accident as "-msse3" was used, but it is on i586 only effective with -mfpmath=sse (that is not completely obvious). By the way, my tests using the Polyhedron benchmark show that for 32bit, x87 and SSE are similarly fast, depending a lot on the test case thus it does not slow down the benchmark too much. The author regretted that Atom support is not available in 4.4 - it will be in 4.5, but that's rather late given that the CPUs are around since some time. I agree with this. If I understood correctly, the 32bit mode was used since the 64bit mode needs more than the available 2GB memory. Similarly, the option -funroll-loops was avoided as they expect that unrolling badly interacts with the small cache Atom processors have. (That CPU2006 runs that long, does not make testing different options that easy.) > What are these guys thinking - like, lets cripple this benchmark and > use completely out of date floating point arithmetic ? > Duh, I hope the rest of their reporting is more useful ... Well, I think it will be just a short article announcing the new version. I think it is difficult to give a full account of a new compiler if the article needs to be in the next issue. And SPEC seemingly runs for 4 days with the additional problem that if a result is too much off, the run completely aborts (which makes the journalists avoid certain options). I would have liked that the options were reported. For instance -ffast-math was not used out of fear that it results in too imprecise results causing SPEC to abort. (Admittedly, I'm also careful with that option, though I assume that -ffast-math works for SPEC.) On the other hand, certain flags implies by -ffast-math are already applied with -O1 in some commercial compilers. David Korn wrote: > They accused us of a too-hasty release. My irony meter exploded! I think their accuse it right and wrong at the same time. Between the release candidate and the release there was indeed very little time. Thus 4.4.0 was released before he could report the bug which he found in RC1. -- And it is wrong since there was a very long Stage4. Whether one agrees, also depends on one's expectations. I think .0 releases are usually not as stable as people only start with .0 testing the release and that release candidates are also not much more tested than the Stage4 builds. (And in general, I believe .0 releases or - even most of the time the trunk - are quite well usable.) Tobias
Re: Making CFLAGS=-g1 bigger but more useful
Andi Kleen writes: > On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote: >> >> I'm working on a little patch that extends the data produced for the >> little-used (?) -g1 mode. Normally, this produces very little DWARF >> data (basically just function declaration locus, PC range, and basic >> backtrace-enabling data). Compared to normal -g (== -g2) mode, this >> is very small. > > I think what I would like to have is a modus to generate line numbers > (so that objdump -S works nicely) but nothing else. That would be useful > for crash dump analysis etc. It's not quite that, but the gold linker has a --strip-debug-non-line option which discards all the debugging information except what is needed to map addresses to lines. Ian
Re: gcc-gdb compatibilty
sumanth writes: > I have a small query. > I am using gcc-4.3.3 version and gdb 5.3 version. > Are the versions of gcc and gdb which I am using are compatible. The gcc@gcc.gnu.org mailing list is for discussion of gcc development. This question would be better directed to gcc-h...@gcc.gnu.org or to g...@sourceware.org. Please take any followups there. Thanks. Yes, while there are of course occasional bugs and mismatches, in general all versions of gcc and gdb are compatible. That said, gdb 5.3 is old; it was released over five years ago. It will ignore some of the newer types of debugging information emitted by gcc. The current gdb release is 6.8, and is considerably enhanced over 5.3. You should consider upgrading if possible. Ian
Re: Making CFLAGS=-g1 bigger but more useful
On Sat, Apr 25, 2009 at 10:30:51AM -0700, Ian Lance Taylor wrote: > Andi Kleen writes: > > > On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote: > >> > >> I'm working on a little patch that extends the data produced for the > >> little-used (?) -g1 mode. Normally, this produces very little DWARF > >> data (basically just function declaration locus, PC range, and basic > >> backtrace-enabling data). Compared to normal -g (== -g2) mode, this > >> is very small. > > > > I think what I would like to have is a modus to generate line numbers > > (so that objdump -S works nicely) but nothing else. That would be useful > > for crash dump analysis etc. > > It's not quite that, but the gold linker has a --strip-debug-non-line > option which discards all the debugging information except what is > needed to map addresses to lines. The reason I would like to have it is that generating so much data slows down gcc compilation a lot and there are cases where I don't need the full data. Striping it in the linker is a start, but doesn't address the size of the object files. So doing it in the compiler would be better. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: GCC 4.5: "nonconstant array index in initializer" error
Thanks for the patch.
There are another error while building linux kernel with GCC 4.5.0
revision 146771.
The minimal code for reproducing the error looks like:
extern unsigned int __invalid_size_argument;
#define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
__invalid_size_argument )
enum {
ENUM_VALUE_NAME = TYPECHECK(int),
};
int main()
{
return 0;
}
The error is following:
test.c:5: error: enumerator value for 'ENUM_VALUE_NAME' is not an
integer constant
GCC 4.4.0 compiles this code without any error.
2009/4/24 Joseph S. Myers :
> On Thu, 23 Apr 2009, Denis Onischenko wrote:
>
>> The minimal code example is following:
>>
>>
>> extern unsigned int __invalid_size_argument;
>> #define TYPECHECK(t) ( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
>> __invalid_size_argument )
>>
>> static int arr[] = {
>> [TYPECHECK(int)] = 0,
>> };
>>
>> int main()
>> {
>> return 0;
>> }
>
> Given this usage in the Linux kernel I've applied this patch to make
> this case into a pedwarn-if-pedantic, as previously done for case
> labels. Bootstrapped with no regressions on i686-pc-linux-gnu.
>
> 2009-04-24 Joseph Myers
>
> * c-typeck.c (set_init_index): Allow array designators that are
> not integer constant expressions with a pedwarn if pedantic.
>
> testsuite:
> 2009-04-24 Joseph Myers
>
> * gcc.dg/array-const-1.c, gcc.dg/array-const-2.c,
> gcc.dg/array-const-3.c: New tests.
>
> Index: gcc/testsuite/gcc.dg/array-const-2.c
> ===
> --- gcc/testsuite/gcc.dg/array-const-2.c (revision 0)
> +++ gcc/testsuite/gcc.dg/array-const-2.c (revision 0)
> @@ -0,0 +1,9 @@
> +/* Test for array designators not integer constant expressions but
> + folding to integer constants (used in Linux kernel,
> + ). */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu99 -pedantic" } */
> +
> +extern int i;
> +int a[] = { [1 ? 1 : i] = 0 }; /* { dg-warning "array index in initializer
> is not an integer constant expression" } */
> +/* { dg-warning "near initialization" "near init" { target *-*-* } 8 } */
> Index: gcc/testsuite/gcc.dg/array-const-1.c
> ===
> --- gcc/testsuite/gcc.dg/array-const-1.c (revision 0)
> +++ gcc/testsuite/gcc.dg/array-const-1.c (revision 0)
> @@ -0,0 +1,8 @@
> +/* Test for array designators not integer constant expressions but
> + folding to integer constants (used in Linux kernel,
> + ). */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu99" } */
> +
> +extern int i;
> +int a[] = { [1 ? 1 : i] = 0 };
> Index: gcc/testsuite/gcc.dg/array-const-3.c
> ===
> --- gcc/testsuite/gcc.dg/array-const-3.c (revision 0)
> +++ gcc/testsuite/gcc.dg/array-const-3.c (revision 0)
> @@ -0,0 +1,9 @@
> +/* Test for array designators not integer constant expressions but
> + folding to integer constants (used in Linux kernel,
> + ). */
> +/* { dg-do compile } */
> +/* { dg-options "-std=gnu99 -pedantic-errors" } */
> +
> +extern int i;
> +int a[] = { [1 ? 1 : i] = 0 }; /* { dg-error "array index in initializer is
> not an integer constant expression" } */
> +/* { dg-error "near initialization" "near init" { target *-*-* } 8 } */
> Index: gcc/c-typeck.c
> ===
> --- gcc/c-typeck.c (revision 146679)
> +++ gcc/c-typeck.c (working copy)
> @@ -6403,6 +6403,24 @@ set_init_index (tree first, tree last)
> }
>
> if (TREE_CODE (first) != INTEGER_CST)
> + {
> + first = c_fully_fold (first, false, NULL);
> + if (TREE_CODE (first) == INTEGER_CST)
> + pedwarn_init (input_location, OPT_pedantic,
> + "array index in initializer is not "
> + "an integer constant expression");
> + }
> +
> + if (last && TREE_CODE (last) != INTEGER_CST)
> + {
> + last = c_fully_fold (last, false, NULL);
> + if (TREE_CODE (last) == INTEGER_CST)
> + pedwarn_init (input_location, OPT_pedantic,
> + "array index in initializer is not "
> + "an integer constant expression");
> + }
> +
> + if (TREE_CODE (first) != INTEGER_CST)
> error_init ("nonconstant array index in initializer");
> else if (last != 0 && TREE_CODE (last) != INTEGER_CST)
> error_init ("nonconstant array index in initializer");
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: GCC 4.5: "nonconstant array index in initializer" error
On Sat, 25 Apr 2009, Denis Onischenko wrote:
> Thanks for the patch.
>
> There are another error while building linux kernel with GCC 4.5.0
> revision 146771.
>
> The minimal code for reproducing the error looks like:
>
> extern unsigned int __invalid_size_argument;
> #define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
> __invalid_size_argument )
>
> enum {
> ENUM_VALUE_NAME = TYPECHECK(int),
Is the kernel using this sort of non-integer-constant-expression in
bit-field widths as well? Sizes of file-scope arrays (OK, a special case
for that was added for WINE)? Null pointer constants (that's much more
problematic to add special cases for)? __builtin_choose_expr conditions?
It seems to be making rather a lot of use of an old obscure undocumented
extension.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Making CFLAGS=-g1 bigger but more useful
Andi Kleen writes: >> It's not quite that, but the gold linker has a --strip-debug-non-line >> option which discards all the debugging information except what is >> needed to map addresses to lines. > > The reason I would like to have it is that generating so much data > slows down gcc compilation a lot and there are cases where I don't > need the full data. Striping it in the linker is a start, but > doesn't address the size of the object files. So doing it in the compiler > would be better. Yes, I agree. Ian
Re: GCC 4.5: "nonconstant array index in initializer" error
> Is the kernel using this sort of non-integer-constant-expression in > bit-field widths as well? Sizes of file-scope arrays (OK, a special case > for that was added for WINE)? Null pointer constants (that's much more > problematic to add special cases for)? __builtin_choose_expr conditions? > It seems to be making rather a lot of use of an old obscure undocumented > extension. It is possible that the kernel uses this sort of expression in other places. I can not say for sure. At the moment I found only these two.
Re: Any plans to upgrade svn repository format to 1.5.0+ ?
Errr, the format is not pre-1.5.0 It was svnadmin upgraded a while ago. On Sat, Apr 25, 2009 at 5:06 AM, Laurynas Biveinis wrote: > Hi, > > Apparently the server is already running svn 1.5.5 but the repository > format is pre-1.5.0. If the repository format was upgraded, we could > start using proper svn merge support for branch maintenance and get > rid of manual merges and svnmerge.py. There is even an upgrade path > from the svnmerge.py to svn 1.5.0 merge support for existing branches. > And the upgrade would not disturb those who are using pre-1.5.0 svn > clients. > > Any thoughts? > > -- > Laurynas >
gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
A successful build on Open Solaris 2008.11: $../gcc-4.4.0/config.guess i386-pc-solaris2.11 $ gcc-4.4.0t -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.4.0/configure --enable-languages=c,c++,fortran --disable-multilib --program-suffix=-4.4.0t --disable-nls --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld Thread model: posix gcc version 4.4.0 (GCC) Note that the host/target is one number higher that that listed in the installation notes, i.e., the one ther is "*solaris2.10" while this host/target is "*solaris2.11" I had problems later building ppl and cloog to incorporate into g++. I have asked about this on the gcc-help mailing list. -Tom Tom Browder Niceville, Florida USA
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> A successful build on Open Solaris 2008.11: > > $../gcc-4.4.0/config.guess > i386-pc-solaris2.11 > > $ gcc-4.4.0t -v > Using built-in specs. > Target: i386-pc-solaris2.11 > Configured with: ../gcc-4.4.0/configure > --enable-languages=c,c++,fortran --disable-multilib > --program-suffix=-4.4.0t --disable-nls --with-gnu-as > --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld > Thread model: posix > gcc version 4.4.0 (GCC) > > Note that the host/target is one number higher that that listed in the > installation notes, i.e., the one ther is "*solaris2.10" while this > host/target is "*solaris2.11" > > I had problems later building ppl and cloog to incorporate into g++. > I have asked about this on the gcc-help mailing list. well done, do you have a full testsuite report ? Dennis
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
On Sat, Apr 25, 2009 at 9:09 PM, Dennis Clarke wrote: > >> A successful build on Open Solaris 2008.11: >> >> $../gcc-4.4.0/config.guess >> i386-pc-solaris2.11 >> >> $ gcc-4.4.0t -v >> Using built-in specs. >> Target: i386-pc-solaris2.11 >> Configured with: ../gcc-4.4.0/configure >> --enable-languages=c,c++,fortran --disable-multilib >> --program-suffix=-4.4.0t --disable-nls --with-gnu-as >> --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld >> Thread model: posix >> gcc version 4.4.0 (GCC) >> >> Note that the host/target is one number higher that that listed in the >> installation notes, i.e., the one ther is "*solaris2.10" while this >> host/target is "*solaris2.11" >> >> I had problems later building ppl and cloog to incorporate into g++. >> I have asked about this on the gcc-help mailing list. > > well done, do you have a full testsuite report ? Thanks, Dennis, I feel lucky! No, but I'll fire one off now before I go to bed. It'll probably take all night since it's a virtual host running on Linux Centos 5.3 x86_64 (Intel Core 2 duo 1.86 GHz). -Tom
Re: gcc-4.4.0 Build Report: Success on Open Solaris 2008.11, x86_64
> On Sat, Apr 25, 2009 at 9:09 PM, Dennis Clarke > wrote: >> >>> A successful build on Open Solaris 2008.11: >>> >>> $../gcc-4.4.0/config.guess >>> i386-pc-solaris2.11 >>> >>> $ gcc-4.4.0t -v >>> Using built-in specs. >>> Target: i386-pc-solaris2.11 >>> Configured with: ../gcc-4.4.0/configure >>> --enable-languages=c,c++,fortran --disable-multilib >>> --program-suffix=-4.4.0t --disable-nls --with-gnu-as >>> --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld >>> Thread model: posix >>> gcc version 4.4.0 (GCC) >>> >>> Note that the host/target is one number higher that that listed in the >>> installation notes, i.e., the one ther is "*solaris2.10" while this >>> host/target is "*solaris2.11" >>> >>> I had problems later building ppl and cloog to incorporate into g++. >>> I have asked about this on the gcc-help mailing list. >> >> well done, do you have a full testsuite report ? > > Thanks, Dennis, I feel lucky! > > No, but I'll fire one off now before I go to bed. It'll probably take > all night since it's a virtual host running on Linux Centos 5.3 x86_64 > (Intel Core 2 duo 1.86 GHz). ha ! I can relate to that! I have builds that run all night and day and then you get a result set where you look at it and wonder .. gee, what went wrong and you have to go do it all over again. I admire people that have the patience to see this through to the end *and* focus on quality. -- Dennis Clarke
Re: heise.de comment on 4.4.0 release
Tobias Burnus wrote: > Toon Moene wrote: Can somebody with access to SPEC sources confirm / deny and file a bug report, if appropriate? I just started working on SPEC CPU2006 issues this week. > Seemingly yes. To a certain extend this was by accident as "-msse3" was > used, but it is on i586 only effective with -mfpmath=sse (that is not > completely obvious). By the way, my tests using the Polyhedron benchmark > show that for 32bit, x87 and SSE are similarly fast, depending a lot on > the test case thus it does not slow down the benchmark too much. Certain AMD CPUs had shorter latencies for scalar single precision sse, but generally the advantage of sse comes from vectorization. > > If I understood correctly, the 32bit mode was used since the 64bit mode > needs more than the available 2GB memory. Certain commercial compilers make an effort to switch to 32-bit mode automatically on several CPU2006 benchmarks, as they are too small to run as fast in 64-bit mode. > > Similarly, the option -funroll-loops was avoided as they expect that > unrolling badly interacts with the small cache Atom processors have. > (That CPU2006 runs that long, does not make testing different options > that easy.) I'm surprised that spec 2006 is considered relevant to Atom. The entire thing (base only) has been running under 10 hours on a dual quad core system. I've heard several times the sentiment that there ought to be an "official" harness to run a single test, trying various options. > I would have liked that the options were reported. For instance > -ffast-math was not used out of fear that it results in too imprecise > results causing SPEC to abort. (Admittedly, I'm also careful with that > option, though I assume that -ffast-math works for SPEC.) On the other > hand, certain flags implies by -ffast-math are already applied with -O1 > in some commercial compilers. SPEC probably has been the biggest driver for inclusion of insane options at default in commercial compilers. It's certainly not an example of acceptable practice in writing portable code. I have yet to find a compiler which didn't fail at least one SPEC test, and I don't blame the compilers. There are dependencies on unusual C++ extensions, which somehow weren't noticed before, examples of using "f77" as an excuse for hiding one's intentions, and expectations of optimizations which have little relevance for serious applications. > > David Korn wrote: >> They accused us of a too-hasty release. My irony meter exploded! Anyway, a fault in support for a not-so-open benchmark application seems even less relevant in an open source effort than it is to compilers which depend on ranking for sales success.
