[Bug middle-end/39260] Failed to build lame-3.98-2 source with graphite
--- Comment #7 from yast4ik at yahoo dot com 2009-02-22 08:01 --- It is seems to me patch works. Thank you for quick solution. -- yast4ik at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39260
[Bug ada/39263] [miro] - Revision 144368 - g-socket.adb:41:06: file "g-sothco.ads" not found
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-22 09:24 --- The micro branch is not part of the FSF SVN so this is not a bug here. Report this to the developers of the micro branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39263
[Bug ada/39264] New: gnat.dg/pack3.adb fails on powerpc64
When testing a 64 bits compiler ACATS is clean but gnat.dg has one FAIL: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02180.html FAIL: gnat.dg/pack3.adb execution test raised PROGRAM_ERROR : pack3.adb:29 explicit raise pack3.adb test was introduced together with this patch: 2008-03-07 Eric Botcazou * decl.c (gnat_to_gnu_entity) : Add comment for the packed array type case. * utils.c (build_template): Use a loop to strip padding or containing records for justified modular types. To build on powerpc64 on debian etch one small patch is needed: Index: configure === --- configure (revision 144347) +++ configure (working copy) @@ -3332,10 +3332,6 @@ # in both places for now and restore CFLAGS at the end of config. save_CFLAGS="$CFLAGS" -# Add -Wall -Werror if we are using GCC. -if test "x$GCC" = "xyes"; then - XCFLAGS="$XCFLAGS -Wall -Werror" -fi # Find other programs we need. if test -n "$ac_tool_prefix"; then http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01865.html Otherwise the build showing this FAIL is still available on compile farm gcc40 in /n/40/guerby/build-144347 and installed in /n/40/guerby/install-trunk-144347/bin . Configure: export CC="gcc -m64" ../trunk/configure --disable-nls --enable-__cxa_atexit --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2-64 --enable-languages=c,ada --prefix=/n/40/guerby/install-trunk-144347 --with-long-double-128 --with-gmp=/opt/cfarm/gmp-4.2.4-64/ ssh public key can be added on request to my account (8h30 for bootstrap+check c,ada on gcc40). -- Summary: gnat.dg/pack3.adb fails on powerpc64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39264
[Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays
--- Comment #42 from hubicka at gcc dot gnu dot org 2009-02-22 11:21 --- Actual representation of constructor don't seem to be major problem here. We seem to build _a lot_ (117MB) of CONVERT exprs just to call fold on it and convert integer to proper type, so counting in INTEGER_CSTs should be just slightly less than half of memory needed. This seems quite silly. The patch to not use HOST_WIDE_INT or similar for counting should save another 70MB of garbage (and speed up compilation), so perhaps you could dig it out? :)) Following patch: Index: convert.c === --- convert.c (revision 144352) +++ convert.c (working copy) @@ -749,6 +749,11 @@ convert_to_integer (tree type, tree expr break; } + /* When parsing long initializers, we might end up with a lot of casts. + Shortcut this. */ + if (TREE_CODE (expr) == INTEGER_CST) + return fold_unary (CONVERT_EXPR, type, expr); + return build1 (CONVERT_EXPR, type, expr); case REAL_TYPE: Cuts gabrage production in half: c-typeck.c:6472 (output_init_element) 0: 0.0% 47910400:100.0% 45541112:23.7% 26342936:99.5% 19 ggc-common.c:187 (ggc_calloc) 67094608:46.1% 0: 0.0% 67162736:34.9% 1088: 0.0% 58 tree.c:1004 (build_int_cst_wide) 78264768:53.8% 0: 0.0% 78266496:40.7% 0: 0.0%3261068 Total 145570627 47910416 192171521 26481588 3275033 source location GarbageFreed Leak OverheadTimes I will give the patch testing, but I am not too hopeful it will just work. ;) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug testsuite/39265] New: [miro] revision 144368 - "make -i check" autogen "fixinclude test FAILURES"
+++ This bug was initially created as a clone of Bug #38727 +++
The autogen program finds fixinclude test failures in miro :
# gmake -i check
gmake[2]: Entering directory `/usr/share/src/miro_build/fixincludes'
autogen -T ../../miro/fixincludes/check.tpl ../../miro/fixincludes/inclhack.def
/bin/sh ./check.sh ../../miro/fixincludes/tests/base
Fixed: testing.h
Fixed: testing.h
Fixed: ansi/math.h
Fixed: ansi/stdlib.h
...
Fixed: pixrect/memvar.h
sed: command garbled: /define[ ]\+PTHREAD_MUTEX_INITIALIZER[ ]*\\/,+1s/{ {
0, } }/{ { 0, 0, 0, 0, 0, 0 } }/
Fixed: regex.h
...
Fixed: Xm/Traversal.h
sys/stat.h /usr/share/src/miro/fixincludes/tests/base/sys/stat.h differ: char
432, line 18
*** sys/stat.h Sun Feb 22 04:17:27 2009
--- /usr/share/src/miro/fixincludes/tests/base/sys/stat.h Sat Feb 21
18:06:34 2009
***
*** 15,23
#if defined( GLIBC_C99_INLINE_2_CHECK )
- extern int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull ((2));
#ifdef __GNUC_GNU_INLINE__
extern
#endif
__inline__ int
__NTH (fstat64 (int __fd, struct stat64 *__statbuf))
--- 15,26
#if defined( GLIBC_C99_INLINE_2_CHECK )
#ifdef __GNUC_GNU_INLINE__
extern
+ #endif
+ __inline__ int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull
((2));
+ #ifdef __GNUC_GNU_INLINE__
+ extern
#endif
__inline__ int
__NTH (fstat64 (int __fd, struct stat64 *__statbuf))
Missing header fix: pthread.h
There were fixinclude test FAILURES
gmake[2]: [check] Error 1 (ignored)
gmake[2]: Leaving directory `/usr/share/src/miro_build/fixincludes'
gmake[2]: Entering directory `/usr/share/src/miro_build/gcc'
...
Thanks,
Rob
--
Summary: [miro] revision 144368 - "make -i check" autogen
"fixinclude test FAILURES"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug testsuite/39265] [miro] revision 144368 - "make -i check" autogen "fixinclude test FAILURES"
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-22 12:18 --- What is the miro branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug ada/39263] [miro] - Revision 144368 - g-socket.adb:41:06: file "g-sothco.ads" not found
--- Comment #2 from rob1weld at aol dot com 2009-02-22 12:19 --- (In reply to comment #1) > The micro branch is not part of the FSF SVN so this is not a bug here. Report > this to the developers of the micro branch. > It is not "micro" it is "miro" ! http://gcc.gnu.org/wiki/MIRO svn co svn://gcc.gnu.org/svn/gcc/branches/miro miro Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39263
[Bug testsuite/39265] [miro] revision 144368 - "make -i check" autogen "fixinclude test FAILURES"
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-22 12:21 --- "creating MIRO (Mudflap Improved with Referent Objects) branch" Seb? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug ada/39263] [miro] - Revision 144368 - g-socket.adb:41:06: file "g-sothco.ads" not found
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-22 12:23 --- miro branch was created but never touched so invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39263
[Bug testsuite/39265] [miro] revision 144368 - "make -i check" autogen "fixinclude test FAILURES"
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-22 12:23 --- miro branch was created but never touched so invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug bootstrap/39262] [miro] - Revision 144368 - Werror in ../miro/gcc/genconstants.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-22 12:24 --- miro branch was created but never touched so invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39262
[Bug bootstrap/39262] [miro] - Revision 144368 - Werror in ../miro/gcc/genconstants.c
--- Comment #3 from rob1weld at aol dot com 2009-02-22 12:51 --- (In reply to comment #1) > Rob, did you ever read http://gcc.gnu.org/bugs.html#report ? > > To be honest, I don't even know _what_ are you reporting here. There is no > point to post hundreds of lines from build logs, since this is too much for > anybody to even read it. Sorry. > > So, please stop wasting yours and others time and please post a precise > bugreport that _explains_ what you think is going wrong. On one or max two > screens of text, please. > > From the bug report guide, you will note following bullet: > > "Bugs in releases or snapshots of GCC not issued by the GNU Project. Report > them to whoever provided you with the release" > > FYI, "miro" (or whatever) is not issued by the GNU project. > http://gcc.gnu.org/wiki/MIRO svn co svn://gcc.gnu.org/svn/gcc/branches/miro miro Who issues it ? > please post a precise bugreport that _explains_ what you think ... Read the title, it is a Werror. In addition to the Werror, while someone is doing that they may (or may not) desire to catch the few warnings in other files that are generating thousands of warnings (and lead to the Werror). Two ways to fix this, a simple exclusion or fix all the warnings. > To be honest, I don't even know _what_ are you reporting ... This much we know. We thank you for your input on something that you know nothing about, do you have more to offer? Did you ever read: http://gcc.gnu.org/svn.html#devbranches The "miro branch" is listed under "Active Development Branches". Lets go with this Branch needs it's web page fixed (instead of exchanges of rudeness). Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39262
[Bug web/39265] [miro] revision 144368 - "make -i check" autogen "fixinclude test FAILURES"
--- Comment #4 from rob1weld at aol dot com 2009-02-22 12:54 --- http://gcc.gnu.org/wiki/MIRO svn co svn://gcc.gnu.org/svn/gcc/branches/miro miro Please read: http://gcc.gnu.org/svn.html#devbranches The "miro branch" is listed under "Active Development Branches". Lets go with this Branch needs it's web pages fixed. Re-open as "web" (and no more Bug Reports about 'miro'). Rob -- rob1weld at aol dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|testsuite |web Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug bootstrap/39262] [miro] - Revision 144368 - Werror in ../miro/gcc/genconstants.c
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-22 12:56 --- > Did you ever read: http://gcc.gnu.org/svn.html#devbranches > > The "miro branch" is listed under "Active Development Branches". Well, it doesn't look active to me. Seb, please do something here (move to inactive, or close, or whatever), because it's indeed confusing and it creates false expectations. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39262
[Bug ada/39263] [miro] - Revision 144368 - g-socket.adb:41:06: file "g-sothco.ads" not found
--- Comment #4 from rob1weld at aol dot com 2009-02-22 12:58 --- (In reply to comment #3) > miro branch was created but never touched so invalid. > It is listed as an ADB, if it were to merge I wanted to be sure it worked. I was not going to spend a lot of time on it, just one run through. No more miro-posts. Resolved here http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265 with a request to fix the web pages. Thanks for your reply, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39263
[Bug web/39265] [miro] branch listed as active development branch appears to be dead
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-22 12:59 --- Indeed. But Rob, Pinski has a point: There really are better things to spend your time on than building development branches. Such branches are often highly experimental or very unstable, so bugs are not usually tracked in bugzilla but in the branch maintainer's head or email box. We only track bugs on branches for some of the higher-profile branches that are more-or-less stable and close to being merged (like the alias-improvements branch, or LTO). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-22 12:59:32 date|| Summary|[miro] revision 144368 -|[miro] branch listed as |"make -i check" autogen |active development branch |"fixinclude test FAILURES" |appears to be dead http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug c++/14179] [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers
--- Comment #49 from hubicka at gcc dot gnu dot org 2009-02-22 13:23 --- Similarly as in PR c/12245 we build a tons of unnecesary CONVERT_EXPRs. Avoiding this by same patch as attached to PR c/12245 brings garbage donwn by 54% from: cp/lex.c:511 (build_lang_decl)94176: 0.0% 116432: 0.0% 826264: 0.1% 98952: 0.0% 4247 toplev.c:1538 (realloc_for_line_map) 0: 0.0%1310720: 0.1%1316864: 0.1% 555008: 0.1% 7 ggc-common.c:187 (ggc_calloc) 134478488:12.0% 188112: 0.0% 134356240:14.6% 18504: 0.0% 2913 cp/decl.c:4683 (reshape_init_array_1) 0: 0.0% 374786120:20.5% 373090856:40.6% 211006352:43.0% 22 cp/parser.c:14709 (cp_parser_initializer_list)373090856:33.3% 374786120:20.5% 88: 0.0% 211006360:43.0% 23 tree.c:1004 (build_int_cst_wide) 8640: 0.0% 0: 0.0% 402626592:43.8% 0: 0.0%8388234 convert.c:752 (convert_to_integer)603950328:54.0% 0: 0.0% 0: 0.0% 67105592:13.7%8388199 Total1118959027 1826757514 919671455491189724 16977745 source location GarbageFreed Leak OverheadTimes to: cp/lex.c:511 (build_lang_decl)94176: 0.0% 116432: 0.0% 826264: 0.1% 98952: 0.0% 4247 toplev.c:1538 (realloc_for_line_map) 0: 0.0%1310720: 0.1%1316864: 0.1% 555008: 0.1% 7 ggc-common.c:187 (ggc_calloc) 134478488:26.1% 188112: 0.0% 134356240:14.6% 18504: 0.0% 2913 cp/decl.c:4683 (reshape_init_array_1) 0: 0.0% 374786120:20.5% 373090856:40.6% 211006352:49.8% 22 cp/parser.c:14709 (cp_parser_initializer_list)373090856:72.4% 374786120:20.5% 88: 0.0% 211006360:49.8% 23 tree.c:1004 (build_int_cst_wide) 8640: 0.0% 0: 0.0% 402626592:43.8% 0: 0.0%8388234 Total 515008771 1826757514 919671455424084140 8589547 source location GarbageFreed Leak OverheadTimes so saving about 0.5GB of RAM and speeding up correspondingly too. We can still improve but this seems low hanging fruit. Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug c++/14179] [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers
--- Comment #50 from steven at gcc dot gnu dot org 2009-02-22 13:39 --- Honza, you realize that the numbers are completely unreadable in bugzilla, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug c++/22635] OVERLOAD should not be a linked list of trees
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-22 14:01 ---
Trees were refactored, and we currently have:
struct tree_base
{
ENUM_BITFIELD(tree_code) code : 16;
/* 48 bits for various bitfield flags */
union tree_ann_d *ann;
} /* So on a 64-bit host this is 128bits = 16 bytes */
struct tree_common
{
struct tree_base; /* 16 bytes */
tree chain; /* 8 bytes */
tree type; /* 8 bytes */
} /* So on a 64-bit host, tree_common is 32 bytes */
struct tree_overload
{
struct tree_common; /* 32 bytes */
tree function; /* 8 bytes */
}
So in total 40 bytes per tree_overload. If a single linked list would really
be sufficient, then the ideal tree_overload would be 16 bytes (two pointers).
In reality, there are a few flags used on tree_overload, so two pointers is not
enough. Let's say we use 4 bytes for that. Then we have an overhead of
(40/(16+4))*100% = 100% overhead.
In any normal engineering project, 100% overhead would be reason for distress.
However, as long as the G++ front end are comfortable using trees instead of
front-end specific structures in the parser, we can't do any better at this
point. The overhead is much less than it was in the past. It was 3% before
the tree refactoring, so it will be much less now. And like Gaby already said:
If there are not so many of them (tree_overload objects) then it is not very
important (to squeeze out every last bit of overhead).
Therefore, closing as FIXED by Dan's refactoring.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22635
[Bug other/26327] memory leaks
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-22 14:06 --- All leaks from the posted patch were plugged. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26327
[Bug middle-end/29376] Internal error: Killed
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-22 14:11 --- Test case has disappeared, and should have been in bugzilla anyway instead of on a website -> INVALID. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29376
[Bug middle-end/29885] compiling takes very long time during -O3 compile
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-22 14:14 --- I can't reproduce this on i686-cygwin, i686-linux, and x86_64-linux with GCC 4.3.3 and with current trunk (r144372). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29885
[Bug middle-end/12392] very long optimized compile
--- Comment #22 from steven at gcc dot gnu dot org 2009-02-22 14:15 --- "Last modified" is long ago. Richi, you added it to the daily testers. How is it doing there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
[Bug other/29442] insn-attrtab has grown too large
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-22 14:19 --- What happened with the alloca patch? Looks like it was never committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
[Bug fortran/39266] New: Size of 'put' argument of 'random_seed' intrinsic at (1) too small in Debian 5.0 Sparc
I built gfortran 4.4 on a Sparc workstation running Debian Linux 5.0. I attempted to compile the following program: PROGRAM test INTEGER, DIMENSION(8) :: count CALL RANDOM_SEED(PUT=count) END PROGRAM test I got the message: CALL RANDOM_SEED(PUT=count) 1 Error: Size of 'put' argument of 'random_seed' intrinsic at (1) too small (8/12) The error does not occur when gfortran built on Sparc (or any other architecture) running Debian Linux 4.0. -- Summary: Size of 'put' argument of 'random_seed' intrinsic at (1) too small in Debian 5.0 Sparc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov GCC build triplet: sparc-unknown-linux-gnu GCC host triplet: sparc-unknown-linux-gnu GCC target triplet: sparc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39266
[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-02-22 14:22 --- Created an attachment (id=17340) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17340&action=view) Dump of block structure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug tree-optimization/23940] SSA_NAMEs are not released after no longer being used.
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-22 14:23 --- Re. Comment #14 -- Fixed on AIB? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-22 14:23 --- Created an attachment (id=17341) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17341&action=view) Little dumping facility -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug middle-end/23163] internal error compiling cbtt80
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 14:27 --- Works for me on a machine limited to 512MB (tops at <300MB, which is unfortunately a small footprint by GCC's current standard). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23163
[Bug fortran/39266] Size of 'put' argument of 'random_seed' intrinsic at (1) too small in Debian 5.0 Sparc
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-22 14:32 --- If it works with one debian version, but not another, isn't it something you should report to debian as their problem, then? It is impossible to tell what is going on without knowing/understanding the difference between the two systems... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39266
[Bug c++/22406] -Weffc++ warns about missing op= and copy ctor, even when base classes have already disabled these
--- Comment #4 from Jason dot A dot Wilkins at gmail dot com 2009-02-22 14:43 --- (In reply to comment #3) It is my understanding that constructors are not inherited so a derived class really does not declare or define a copy constructor. -- Jason dot A dot Wilkins at gmail dot com changed: What|Removed |Added CC||Jason dot A dot Wilkins at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22406
[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-02-22 14:46 --- There are obviously giant trees of blocks that have all variables unused and no statements in them coming from the early inliner. I am getting convinced we can safely prune those even at -g3: user can not breakpoint into the block in any way and can't ask for the value So I guess we could be at -g eliminating inner blocks with no used variables and no statements just keeping around blocks with statements including the unused vars so we can get proper "optimized out" debugger info. I will prepare patch for this. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug c++/14179] [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers
--- Comment #51 from hubicka at ucw dot cz 2009-02-22 14:47 --- Subject: Re: [4.2/4.3/4.4 Regression] out of memory while parsing array with many initializers > Honza, you realize that the numbers are completely unreadable in bugzilla, > right? THey need some care to read, the columns are still intact, just interleaved... I wonder why bugzilla insists on the linebreaks? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
[Bug bootstrap/39262] [miro] - Revision 144368 - Werror in ../miro/gcc/genconstants.c
--- Comment #5 from sebpop at gmail dot com 2009-02-22 14:55 --- Subject: Re: [miro] - Revision 144368 - Werror in ../miro/gcc/genconstants.c I will fix this with the attached patch when approved. --- Comment #6 from sebpop at gmail dot com 2009-02-22 14:55 --- Created an attachment (id=17342) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17342&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39262
[Bug web/39265] [miro] branch listed as active development branch appears to be dead
--- Comment #6 from spop at gcc dot gnu dot org 2009-02-22 15:03 --- MIRO is an inactive development branch. I will fix the svn.html page. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug web/39265] [miro] branch listed as active development branch appears to be dead
--- Comment #7 from rob1weld at aol dot com 2009-02-22 15:12 --- (In reply to comment #6) > MIRO is an inactive development branch. I will fix the svn.html page. Thanks, that is all that is needed. Rob BTW: I was only going to run quickly through the code and check that the 'New and Improved' mudflaps worked on Solaris (seems to be OK so far). Since it was listed as "Active" and seems "Completed" (finished) I though it might be on the list for merging - so as the "OpenSolaris 2009.06 guy" (and one of the few submitting Testsuite Results) I thought I would do my part to help. I've received flames in other threads about this, very unneccesary. Don't invite people to help ( see http://gcc.gnu.org/svn.html#devbranches _before_ it is changed) and then get annoyed that the page they read is wrong (and it is their fault). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39265
[Bug target/39261] _mm256_set_epi64x failed on 32bit
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-22 15:28 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39261
[Bug fortran/39266] Size of 'put' argument of 'random_seed' intrinsic at (1) too small in Debian 5.0 Sparc
--- Comment #2 from kargl at gcc dot gnu dot org 2009-02-22 16:05 --- Please see the Standard's description of RANDOM_SEED. In particular, what does program duh integer how_many call random_seed(size=how_many) print '(I0)', how_many end program duh do on each system? More importantly, what does program doh real(16) x ! real(10) x print '(I0)', precision(x) end program doh return? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39266
[Bug fortran/39266] Size of 'put' argument of 'random_seed' intrinsic at (1) too small in Debian 5.0 Sparc
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2009-02-22 16:21 --- On Debian 5.0 they return: mrich...@msc3035298w:~$ gfortran duh.f90 mrich...@msc3035298w:~$ ./a.out 12 mrich...@msc3035298w:~$ gfortran doh.f90 mrich...@msc3035298w:~$ ./a.out 33 I overwrote Debian 4.0 when I built 5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39266
[Bug target/15780] bootstrap fails on crtstuff
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 16:21 --- Works with gcc 4.3, 4.4. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15780
[Bug c++/23227] SFINAE bug
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-22 16:29 --- >3 years of inaction. What is going to be done about this? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug tree-optimization/23347] PRE produces type mismatch in PHIs when compiling java from bytecode
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-22 16:31 --- Is this still an issue, with a new Java front end and a new PRE implementation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
[Bug tree-optimization/23347] PRE produces type mismatch in PHIs when compiling java from bytecode
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
[Bug target/24500] Libjava failure: FAIL: ExtraClassLoader execution - gij test
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-22 16:32 --- Don't see that failure here: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02195.html FIXED? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24500
[Bug other/20939] ld segmentation fault linking libgfortran.sl.0.0
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 16:34 --- Probably a linker bug -> INVALID (and also no progress for 3 years anyway) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20939
[Bug middle-end/24932] GCC segfault's on strcmp in tree.c:annotate_with_file_line
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-22 16:36 --- Locations are now handled differently (mapped locations). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24932
[Bug middle-end/25622] undefined reference to `_gfortran_st_set_nml_var_dim'
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-22 16:37 --- Three years, no progress... Is this still an issue? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25622
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #18 from steven at gcc dot gnu dot org 2009-02-22 16:38 --- Orphaned bug. HJ? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug c++/23227] SFINAE bug
--- Comment #10 from paolo dot carlini at oracle dot com 2009-02-22 16:38 --- CC-ing Jason seems a good idea... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug target/24500] Libjava failure: FAIL: ExtraClassLoader execution - gij test
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-22 16:43 --- Fixed in 4.4.0. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24500
[Bug target/24419] ix86 prologue clobbers memory when it shouldn't
--- Comment #19 from hjl dot tools at gmail dot com 2009-02-22 16:52 --- Created an attachment (id=17343) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17343&action=view) The current patch for gcc 4.4.0 revision 144367 -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #10023|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24419
[Bug fortran/39266] Size of 'put' argument of 'random_seed' intrinsic at (1) too small in Debian 5.0 Sparc
--- Comment #4 from kargl at gcc dot gnu dot org 2009-02-22 16:53 --- (In reply to comment #3) > On Debian 5.0 they return: > > mrich...@msc3035298w:~$ gfortran duh.f90 > mrich...@msc3035298w:~$ ./a.out > 12 > mrich...@msc3035298w:~$ gfortran doh.f90 > mrich...@msc3035298w:~$ ./a.out > 33 > > I overwrote Debian 4.0 when I built 5.0. This system has a 113-bit significand floating point type. The random number generator requires 12 integers to seed the 3 internal and independent KISS generators (each KISS requires 4 seeds). The first KISS generator produces the first 32-bits of the significand, the 2nd KISS prng gives the next set of 32 bits, and the last KISS prng provides the remaining bits. The only portable way to seed random_number is to do something like integer, allocatable :: seeds(:) call random_seed(size=i) allocate(seeds(i)) ! ! Set seeds(i) here ! seeds = (/ (j, j=1, i) /)! Obviously, there are better choices! call random_seed(put=seeds) deallocate(seeds) A few other points. gfortran will mix your seeds with some system entropy to try to limit/prevent a bad choice of seeds. Additionally, if you harvest a real(4), reseed the generator, and then harvest a real(8). The first 24 bits of the real(8) will match the 24 bits of the real(4). If you have other questions about random_seed or random_harvest, it may be best to ask on the fort...@gcc.gnu.org list. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39266
[Bug java/22377] BC compilation fails to detect abstract instantiation
--- Comment #6 from tromey at gcc dot gnu dot org 2009-02-22 17:04 --- I'm not sure that suggestion will work. My recollection is that the order of checks is specified, and that allocating memory before the abstract-ness check would be incorrect. I didn't confirm this with the spec though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22377
[Bug preprocessor/39080] -MF writes dependencies for last file only
--- Comment #1 from tromey at gcc dot gnu dot org 2009-02-22 17:12 --- This is not really a bug. In this scenario, cc1 is executed multiple times. Each invocation overwrites the -MF file. A fix is not to pass multiple .c files to a given invocation of gcc. Perhaps we should note this in the documentation. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39080
[Bug tree-optimization/23347] PRE produces type mismatch in PHIs when compiling java from bytecode
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-22 18:46 --- (In reply to comment #1) > Is this still an issue, with a new Java front end This was compiling with a .class file and there was no new java front-end only the .java front-end was ripped out. > and a new PRE implementation? That I don't know, I have to retest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #29 from hubicka at gcc dot gnu dot org 2009-02-22 18:46
---
I mean aligned(64).
I guess something like this then?
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 144373)
+++ config/i386/i386.c (working copy)
@@ -19351,6 +19351,12 @@ unsigned int
ix86_local_alignment (tree type, enum machine_mode mode,
unsigned int align)
{
+ /* We don't want to align DImode to 64bit for compilation with
+ -mpreferred-stack-boundary=2 to not enforce dynamic stack alignment
+ prologue. */
+ if (mode == DImode && !TARGET_64BIT && ix86_preferred_stack_boundary < 64)
+align = 32;
+
/* If TYPE is NULL, we are allocating a stack slot for caller-save
register in MODE. We will return the largest alignment of XF
and DF. */
@@ -19360,6 +19366,12 @@ ix86_local_alignment (tree type, enum ma
align = GET_MODE_ALIGNMENT (DFmode);
return align;
}
+ if (!TARGET_64BIT
+ && align == 64
+ && ix86_preferred_stack_boundary < 64
+ && (mode == DImode || (type && TYPE_MODE (type) == DImode))
+ && (!type || !TYPE_USER_ALIGN (type)))
+align = 32;
/* x86-64 ABI requires arrays greater than 16 bytes to be aligned
to 16byte boundary. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays
--- Comment #43 from rguenther at suse dot de 2009-02-22 19:03 --- Subject: Re: [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays On Sun, 22 Feb 2009, hubicka at gcc dot gnu dot org wrote: > Actual representation of constructor don't seem to be major problem here. > > We seem to build _a lot_ (117MB) of CONVERT exprs just to call fold on it and > convert integer to proper type, so counting in INTEGER_CSTs should be just > slightly less than half of memory needed. This seems quite silly. > > The patch to not use HOST_WIDE_INT or similar for counting should save another > 70MB of garbage (and speed up compilation), so perhaps you could dig it out? > :)) > > Following patch: > Index: convert.c > === > --- convert.c (revision 144352) > +++ convert.c (working copy) > @@ -749,6 +749,11 @@ convert_to_integer (tree type, tree expr > break; > } > > + /* When parsing long initializers, we might end up with a lot of casts. > + Shortcut this. */ > + if (TREE_CODE (expr) == INTEGER_CST) > + return fold_unary (CONVERT_EXPR, type, expr); fold_convert (). But maybe not valid to do here for C std reasons, who knows. > + >return build1 (CONVERT_EXPR, type, expr); And probably just generally using fold_convert () would be ok as well. Maybe they are there to make sure to build rvalues. > case REAL_TYPE: > > Cuts gabrage production in half: > c-typeck.c:6472 (output_init_element) 0: 0.0% > 47910400:100.0% 45541112:23.7% 26342936:99.5% 19 > ggc-common.c:187 (ggc_calloc) 67094608:46.1% 0: > 0.0% 67162736:34.9% 1088: 0.0% 58 > tree.c:1004 (build_int_cst_wide) 78264768:53.8% 0: > 0.0% 78266496:40.7% 0: 0.0%3261068 > Total 145570627 47910416 > > 192171521 26481588 3275033 > source location GarbageFreed > > Leak OverheadTimes > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug tree-optimization/23940] SSA_NAMEs are not released after no longer being used.
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-02-22 19:05 --- Yes indeed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-07-15 12:38:41 |2009-02-22 19:05:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
[Bug tree-optimization/13962] [tree-ssa] make "fold" use alias information to optimize pointer comparisons
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-22 19:09 --- Richi, this may be easy to fix on the AIB... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962
[Bug tree-optimization/14442] missed sib if conversion optimization on the tree level (PHI-OPT misses that !(a == 0) is just a != 0)
--- Comment #13 from steven at gcc dot gnu dot org 2009-02-22 19:13 --- Works on the trunk. The .final_cleanup dumps are the same for f and f1, and so is the asm output. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14442
[Bug target/39258] No ABI warnings on __m128i when SSE is disabled
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-22 19:21 ---
The ABI warnings are inconsistent:
bash-3.2$ cat u3.i
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
__m128i
bar2 (void)
{
__m128i x = (__m128i) { 0, 0 };
return x;
}
bash-3.2$ gcc -S -mno-sse u3.i
u3.i: In function bar2:
u3.i:5: error: SSE register return with SSE disabled
bash-3.2$ gcc -S -mno-sse u3.i -m32
bash-3.2$
construct_container has
/* We allowed the user to turn off SSE for kernel mode. Don't crash if
some less clueful developer tries to use floating-point anyway. */
But we issue an error.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39258
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #30 from hjl dot tools at gmail dot com 2009-02-22 19:28
---
(In reply to comment #29)
> I mean aligned(64).
> I guess something like this then?
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c (revision 144373)
> +++ config/i386/i386.c (working copy)
> @@ -19351,6 +19351,12 @@ unsigned int
> ix86_local_alignment (tree type, enum machine_mode mode,
> unsigned int align)
> {
> + /* We don't want to align DImode to 64bit for compilation with
> + -mpreferred-stack-boundary=2 to not enforce dynamic stack alignment
> + prologue. */
> + if (mode == DImode && !TARGET_64BIT && ix86_preferred_stack_boundary < 64)
> +align = 32;
> +
It will always align DI to 4 byte in 32bit mode. Did you mean to
replace it with the code below?
>/* If TYPE is NULL, we are allocating a stack slot for caller-save
> register in MODE. We will return the largest alignment of XF
> and DF. */
> @@ -19360,6 +19366,12 @@ ix86_local_alignment (tree type, enum ma
> align = GET_MODE_ALIGNMENT (DFmode);
>return align;
> }
> + if (!TARGET_64BIT
> + && align == 64
> + && ix86_preferred_stack_boundary < 64
> + && (mode == DImode || (type && TYPE_MODE (type) == DImode))
> + && (!type || !TYPE_USER_ALIGN (type)))
> +align = 32;
>
TYPE_USER_ALIGN isn't set on DImode due to canonical type:
Breakpoint 5, ix86_local_alignment (type=0x77ed2900, mode=VOIDmode,
align=256) at /export/gnu/src/gcc-work/gcc/gcc/config/i386/i386.c:19433
19433 if (!type)
(gdb) call debug_tree (type)
constant 64>
unit size constant 8>
align 64 symtab 0 alias set -1 canonical type 0x77ed2900 precision 64
min max
pointer_to_this >
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug tree-optimization/13962] [tree-ssa] make "fold" use alias information to optimize pointer comparisons
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-22 20:20 --- Easy but dangerous ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-13 04:44:24 |2009-02-22 20:20:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962
[Bug bootstrap/39262] [miro] - Revision 144368 - Werror in ../miro/gcc/genconstants.c
--- Comment #7 from rob1weld at aol dot com 2009-02-22 20:39 --- (In reply to comment #5) > Subject: Re: [miro] - Revision 144368 - Werror in > ../miro/gcc/genconstants.c > > I will fix this with the attached patch when approved. > Thanks kindly, great results are here: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02215.html . I will post no more about 'miro' other than a hope it is merged someday ... I will now try 'lto' since that seems to have flame-retarder built-in :) . Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39262
[Bug target/39258] No ABI warnings on __m128i when SSE is disabled
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-22 22:04 --- On 32bit, -mno-avx/-mno-sse/-mno-mmx changes ABI for 1. Vector returns. 2. Vector parameters without varargs. On 64bit, 1. -mno-avx/-mno-sse changes ABI for a. Float/Vector and aggregate with float/vector returns. b. Float/Vector and aggregate with float/vector parameters. 2. -mno-i387 changes ABI for a. long double and aggregates with long double returns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39258
[Bug libfortran/36044] user-requested backtrace
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-02-22 22:33
---
(In reply to comment #3)
> Try abort(). (Though I do not recall whether it works, I think it does.)
Does not work. abort() raises a SIGABRT, and we only catch SIGSEGV, SIGBUS,
SIGILL and SIGFPE.
>> Anyway I'm looking for a solution that keeps the
>> program running after the backtrace.
One such solution that I can see (other than adding a new intrinsic) is to
modify the library to also catch SIGUSR2 and generate a backtrace when it's
received (untested patch below); that way, a backtrace can be emitted without
the code stopping, either
-- programmaticaly by calling the KILL and GETPID intrinsics, or the POSIX
functions via ISO_C_BINDING
-- by the user sending the signal from another terminal, to know where his
program is stuck
The only issue I see with that is that SIGUSR2 is a symbolic constant, not
available in Fortran code, so that the user needs to know what (potentialy
nonportable) signal number it corresponds to.
diff -rpu libgfortran/runtime/compile_options.c
libgfortran.new/runtime/compile_options.c
--- libgfortran/runtime/compile_options.c 2009-02-22 23:25:25.0
+0100
+++ libgfortran.new/runtime/compile_options.c 2009-02-22 23:30:20.0
+0100
@@ -73,6 +73,13 @@ handler (int signum)
desc = "Floating-point exception";
break;
#endif
+
+#if defined(SIGUSR2)
+ case SIGUSR2:
+ name = "SIGUSR2";
+ desc = "User-defined signal";
+ break;
+#endif
}
if (name)
@@ -80,6 +87,16 @@ handler (int signum)
else
st_printf ("\nProgram received signal %d.\n", signum);
+#if defined(SIGUSR2)
+ if (signum == SIGUSR2
+ && (options.backtrace == 1
+ || (options.backtrace == -1 && compile_options.backtrace == 1)))
+ {
+show_backtrace ();
+return;
+ }
+#endif
+
sys_exit (5);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug debug/39267] New: gdb testusite regressions
We seem to regress in gdb testsuite relative to gcc-4.1.0: @@ -3622,7 +3622,7 @@ PASS: gdb.base/maint.exp: maint internal-error PASS: gdb.base/maint.exp: internal-error resync Running ../../../gdb/testsuite/gdb.base/mips_pro.exp ... -PASS: gdb.base/mips_pro.exp: backtrace +FAIL: gdb.base/mips_pro.exp: running to middle in runto Running ../../../gdb/testsuite/gdb.base/miscexprs.exp ... PASS: gdb.base/miscexprs.exp: up from marker1 PASS: gdb.base/miscexprs.exp: print value of &ibig.i[0] @@ -3649,7 +3649,7 @@ PASS: gdb.base/miscexprs.exp: print value of lbig.l[333] >> 6 Running ../../../gdb/testsuite/gdb.base/multi-forks.exp ... PASS: gdb.base/multi-forks.exp: Break at exit -FAIL: gdb.base/multi-forks.exp: follow child, print pids (timeout) +PASS: gdb.base/multi-forks.exp: follow child, print pids PASS: gdb.base/multi-forks.exp: Break at exit PASS: gdb.base/multi-forks.exp: follow parent, print pids PASS: gdb.base/multi-forks.exp: help set detach @@ -6349,35 +6349,35 @@ PASS: gdb.base/store.exp: tbreak add_charest PASS: gdb.base/store.exp: continue to add_charest PASS: gdb.base/store.exp: upvar charest l; up -PASS: gdb.base/store.exp: upvar charest l; print old l, expecting -1 .* +FAIL: gdb.base/store.exp: upvar charest l; print old l, expecting -1 .* PASS: gdb.base/store.exp: upvar charest l; print old r, expecting -2 .* PASS: gdb.base/store.exp: upvar charest l; set l to 4 PASS: gdb.base/store.exp: upvar charest l; print new l, expecting 4 ..004. PASS: gdb.base/store.exp: tbreak add_short PASS: gdb.base/store.exp: continue to add_short PASS: gdb.base/store.exp: upvar short l; up -PASS: gdb.base/store.exp: upvar short l; print old l, expecting -1 +FAIL: gdb.base/store.exp: upvar short l; print old l, expecting -1 PASS: gdb.base/store.exp: upvar short l; print old r, expecting -2 PASS: gdb.base/store.exp: upvar short l; set l to 4 PASS: gdb.base/store.exp: upvar short l; print new l, expecting 4 PASS: gdb.base/store.exp: tbreak add_int PASS: gdb.base/store.exp: continue to add_int PASS: gdb.base/store.exp: upvar int l; up -PASS: gdb.base/store.exp: upvar int l; print old l, expecting -1 +FAIL: gdb.base/store.exp: upvar int l; print old l, expecting -1 PASS: gdb.base/store.exp: upvar int l; print old r, expecting -2 PASS: gdb.base/store.exp: upvar int l; set l to 4 PASS: gdb.base/store.exp: upvar int l; print new l, expecting 4 PASS: gdb.base/store.exp: tbreak add_long PASS: gdb.base/store.exp: continue to add_long PASS: gdb.base/store.exp: upvar long l; up -PASS: gdb.base/store.exp: upvar long l; print old l, expecting -1 +FAIL: gdb.base/store.exp: upvar long l; print old l, expecting -1 PASS: gdb.base/store.exp: upvar long l; print old r, expecting -2 PASS: gdb.base/store.exp: upvar long l; set l to 4 PASS: gdb.base/store.exp: upvar long l; print new l, expecting 4 PASS: gdb.base/store.exp: tbreak add_longest PASS: gdb.base/store.exp: continue to add_longest PASS: gdb.base/store.exp: upvar longest l; up -PASS: gdb.base/store.exp: upvar longest l; print old l, expecting -1 +FAIL: gdb.base/store.exp: upvar longest l; print old l, expecting -1 PASS: gdb.base/store.exp: upvar longest l; print old r, expecting -2 PASS: gdb.base/store.exp: upvar longest l; set l to 4 PASS: gdb.base/store.exp: upvar longest l; print new l, expecting 4 @@ -6398,7 +6398,7 @@ PASS: gdb.base/store.exp: tbreak add_doublest
[Bug tree-optimization/39268] New: printf changes fstrict-aliasing behaviour
It is strange that using printf that doesn't use any variables disables abort.
$ cat test2.c
#include
#include
int
main (void)
{
int a = 0x12345678;
short *b = (short *) &a;
b[1] = 0;
printf("\n");
if (a == 0x12345678)
abort();
exit(0);
}
$ gcc -fstrict-aliasing -O2 -Wall test2.c
test2.c: In function main:
test2.c:8: warning: likely type-punning may break strict-aliasing rules: object
*{unknown} of main type short int is referenced at or around test2.c:8 and
may be aliased to object a of main type int which is referenced at or
around test2.c:6.
$ ./a.out
$
The conditional jump is activated when printf is using:
@@ -7,9 +7,16 @@
.LFB20:
subq$24, %rsp
.LCFI0:
+ movl$10, %edi
movl$305419896, 20(%rsp)
movw$0, 22(%rsp)
+ callputchar
+ cmpl$305419896, 20(%rsp)
+ jne .L2
callabort
+.L2:
+ xorl%edi, %edi
+ callexit
.LFE20:
.size main, .-main
.section.eh_frame,"a",@progbits
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
--
Summary: printf changes fstrict-aliasing behaviour
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anvoebugz at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39268
[Bug tree-optimization/39268] printf changes fstrict-aliasing behaviour
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-22 23:38 --- Yes this is expected because the compiler does not fully know that printf has no side effects to local variables. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39268
[Bug c++/36411] [4.4 regression] ICE with invalid template template parameter
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-22 23:59 --- Created an attachment (id=17344) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17344&action=view) A patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36411
[Bug c++/37789] [4.4 regression] ICE with __FUNCTION__
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-22 23:59 --- Created an attachment (id=17345) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17345&action=view) A patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37789
[Bug tree-optimization/39268] printf changes fstrict-aliasing behaviour
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-23 00:41 --- In fact, with glibc, printf may have side effects to local variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39268
[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build
--- Comment #1 from rob1weld at aol dot com 2009-02-23 01:21 --- Confirmed on i386-pc-solaris2.11 (OpenSolaris 2009.06). We are advised to use libelf v0.8.10, which (by default) installs in /usr/local but the lto configury uses /usr/include/libelf.h . +1 for "--with-libelf=/usr/local" . # gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: i386-pc-solaris2.11 Configured with: ../lto_trunk/configure --prefix=/usr/local/lto --enable-languages=lto,c++ --enable-shared --disable-static --enable-multilib --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.0 20090218 (experimental) [lto revision 144375] (lto merged with rev 144262) Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-23 02:36 --- Created an attachment (id=17346) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17346&action=view) A patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #31 from Joey dot ye at intel dot com 2009-02-23 03:15 ---
How about this patch?
1. Only reduce DI mode when -Os
2. Ignore TYPE_USER_ALIGN, so that stack realign happens for case in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137#c28, which IMHO is
acceptable.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 5221)
+++ config/i386/i386.c (working copy)
@@ -19607,6 +19607,13 @@
ix86_local_alignment (tree type, enum machine_mode mode,
unsigned int align)
{
+ /* We don't want to align DImode to 64bit for compilation with
+ -mpreferred-stack-boundary=2 to not enforce dynamic stack alignment
+ prologue. */
+ if (mode == DImode && !TARGET_64BIT && ix86_preferred_stack_boundary < 64
+ && optimize_function_for_size_p (cfun))
+align = 32;
+
/* If TYPE is NULL, we are allocating a stack slot for caller-save
register in MODE. We will return the largest alignment of XF
and DF. */
@@ -19616,6 +19623,12 @@
align = GET_MODE_ALIGNMENT (DFmode);
return align;
}
+ if (!TARGET_64BIT
+ && optimize_function_for_size_p (cfun)
+ && align == 64
+ && ix86_preferred_stack_boundary < 64
+ && (mode == DImode || (type && TYPE_MODE (type) == DImode)))
+align = 32;
/* x86-64 ABI requires arrays greater than 16 bytes to be aligned
to 16byte boundary. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug c++/39269] New: Invalid template friend declaration accepted
This code has erroneously been accepted since at least gcc 2.95:
--
namespace NS {
template class X {};
}
class Y {
template friend class NS::X;
};
--
Note the wrong number of template arguments in the friend declaration.
The code is correctly rejected if X is not in a namespace.
W.
--
Summary: Invalid template friend declaration accepted
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39269
[Bug bootstrap/39019] Solaris and IRIX libelf cause trouble for build
--- Comment #2 from rob1weld at aol dot com 2009-02-23 03:51 --- Rainer, while we wait for the patch did you wish to try this: 1. Edit the gcc/configure (Line 9562) and reverse the detection order: - for ac_header in gelf.h libelf/gelf.h + for ac_header in libelf/gelf.h gelf.h 2. Edit lto_plugin/lto_plugin.c and lto_plugin/lto-symtab.c and both add in ../gcc/auto-host.h and change the define testing order: #undef PACKAGE_NAME #undef PACKAGE_STRING #undef PACKAGE_TARNAME #undef PACKAGE_VERSION #include "../gcc/auto-host.h" #ifdef__COMMENT__ #ifdef HAVE_GELF_H # include #else # if defined(HAVE_LIBELF_GELF_H) # include # else # error "gelf.h not available" # endif #endif #endif /* __COMMENT__ */ #if defined(HAVE_LIBELF_GELF_H) # include #else # ifdef HAVE_GELF_H # include # else # error "gelf.h not available" # endif #endif You can hand-compile to fix the 'Werror" that will remain: cc1: warnings being treated as errors ../../lto_trunk/lto-plugin/lto-plugin.c: In function onload: ../../lto_trunk/lto-plugin/lto-plugin.c:670: error: implicit declaration of function mkdtemp ../../lto_trunk/lto-plugin/lto-plugin.c:670: error: assignment makes pointer from integer without a cast gmake[3]: *** [lto-plugin.lo] Error 1 That fixes it for me. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39019
[Bug libfortran/36044] user-requested backtrace
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-02-23 04:37 --- If anyone is looking into this, please let me know if there are any specific posix calls needed that I should put into the gfc_posix module. ( Priority wise.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug c++/39270] New: Explicit instantiation rejected
Hello.
The following does not compile:
-
class A
{
public:
class B {};
template void x(X a) {}
template void x(int a);
};
template
void A::x (int a)
{ }
template void A::x (int a);
--
Namely, the explicit instantiation on the last line is rejected with the error:
test.cc:13: error: ambiguous template specialization x for void
A::x(int)
i.e. not even recognized as an explicit instantiation.
Implicit instantiation seems to work fine.
cheers
gcc config:
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE
Linux)
--
Summary: Explicit instantiation rejected
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: highegg at gmail dot com
GCC target triplet: Target: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
[Bug c++/39271] New: 64 bit memory allocation possible error
Subject: Possible error with C++ compilers on 64 bit PC running
SUSE 10.3 with memory allocation
In C++ you can request space with the new command but if you
repeatedly do this then it should eventually fail. The following
program is designed to illustrate this by first repeatedly asking
for 1Mbyte until the requests fails. This is then done again
with blocks of double the size etc.
On 32 bit PCs the program behaves as expected and the output
is shown below. However on a 64 bit PC with g++ version 4.2.1
and with the Sun linux compiler CC and with the intel compiler
icc no failure is ever reported. This suggests a serious bug
in some aspect of the 64 bit system or have I made a mistake
myself?
The 64 bit PC with 4GB of RAM often runs very slowly and is
sometimes the slowest PC that I have had for many years with
many of the applications that I regularly run.
Could the above be the reason for the PC sometimes being so slow?
Any help in resolving the bug with the 64 bit system will be
appreciated. My only solution at the moment is abandon the
use of the 64 bit operating system in favour of the 32 bit
version.
..c++ program err64.cpp follows
#include
#include
using namespace std;
int main()
{
char *c;
char *a[11][8192];
int b[11];
int i, j, k, m=1024*1024;
// .. request m bytes until the request fails
for(j=0; j<11; j++)
{
for(i=0; i<8192; i++)
{
c=new (nothrow) char[m];
if(c==NULL)break;
a[j][i]=c;
}
// .. release the space
for(k=0; khttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=39271
