[Bug fortran/34532] Doc error or rej.valid vendor extension: Integer as logical in IF expressions
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-20 07:57 --- FX wrote: > > http://gcc.gnu.org/onlinedocs/gfortran/Implicitly-convert-LOGICAL-and... > I think this is only true for assignments, ie you can assign a logical > value to an integer lhs and the other way around. The doc needs fixing. And Steve Lionel of Intel wrote: > Although the Intel compiler allows this (it is an extension dating > back at least to VAX FORTRAN V1 in 1978 if not earlier), this is a > VERY bad idea. The value of .TRUE. could be anything when converted > to integer, and different compilers use different values. I know you > were just trying things, but please don't write code like this for > real. I would not encourage gfortran to pick up this extension - I'm > lobbying to have it give a warning by default in ifort. If gfortran > wants to pick it up, please make it off by default. I agree that we should change only the documentation. gfortran supports - as FX wrote: logical l integer i i = .true. l = 1 end It prints by default a warning and rejects it with -std=f*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34532
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #43 from stevenb dot gcc at gmail dot com 2007-12-20 06:15 --- Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions I did not mean more bitmaps but more elements per bitmap, obviously. I know the effect of the patch, or I wouldn't have written it ;-) I tried to add something like df_hack2 to the reaching defs problem, but I didn't succeed the first time. It is indeed harder. If you could work in it, that would be terrific. I will work on some tools to investigate DF memory usage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #4 from tbm at cyrius dot com 2007-12-20 05:07 --- I marked it as a 4.3 regression because I believe 4.2 was able to compile the code. If you think it applies to 4.2, maybe it would be a good idea to apply the patch there as well. BTW, it might be a good idea to check in the testcase you came up with. Thanks for fixing this so quickly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52 --- Created an attachment (id=14799) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799&action=view) memory details for an unpatched mainline Here is the same information without Steven's two patches for mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work
--- Comment #9 from spop at gcc dot gnu dot org 2007-12-20 03:46 --- Fixed. -- 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=34413
[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work
--- Comment #8 from spop at gcc dot gnu dot org 2007-12-20 03:42 --- Subject: Bug 34413 Author: spop Date: Thu Dec 20 03:42:17 2007 New Revision: 131097 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131097 Log: 2007-12-19 Sebastian Pop <[EMAIL PROTECTED]> PR tree-optimization/34413 * tree-data-ref.c (affine_fn_op, analyze_ziv_subscript, analyze_siv_subscript_cst_affine, analyze_miv_subscript, omega_setup_subscript): Use long_integer_type_node instead of integer_type_node. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #41 from zadeck at naturalbridge dot com 2007-12-20 03:06 --- Subject: Re: Inordinate compile times on large routines lucier at math dot purdue dot edu wrote: > --- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29 > --- > Created an attachment (id=14798) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14798&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14798&action=view) > detailed memory usage report > > I rebuilt mainline with --enable-gather-detailed-mem-stats and this is the > output for the run in comment 38. > > > you should look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400#c42 kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug fortran/34532] Doc error or rej.valid vendor extension: Integer as logical in IF expressions
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-20 02:33 --- I think it should continue to be rejected. We don't need to encourage mushy typing in fortran code. I vote fix the documentation if needed. The user should do: if (i /= 0) print *, "whatever you think you need to do." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34532
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29 --- Created an attachment (id=14798) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14798&action=view) detailed memory usage report I rebuilt mainline with --enable-gather-detailed-mem-stats and this is the output for the run in comment 38. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug c++/34513] static variable not found for C++ OpenMP
--- Comment #7 from hailijuan at gmail dot com 2007-12-20 02:21 --- fixed in revision 131059 -- hailijuan at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug rtl-optimization/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-12-20 02:08 --- This was introduced by the change to rs6000_legitimate_offset_address_p which was done by: PR target/18506 * config/rs6000/altivec.md (vec_init): New. (vec_set): New. (vec_extract): New. * config/rs6000/rs6000.c (rs6000_expand_vector_init): New. (rs6000_expand_vector_set): New. (rs6000_expand_vector_extract): New. (rs6000_legitimate_offset_address_p): Offset addresses are valid for Altivec modes before reload. (altivec_expand_vec_init_builtin): New. (get_element_number): New. (altivec_expand_vec_set_builtin): New. (altivec_expand_vec_ext_builtin): New. (altivec_expand_builtin): Expand vec_init, vec_set, and vec_ext builtins. (altivec_init_builtins): Init vec_init, vec_set, and vec_ext builtins. * config/rs6000/rs6000.h (rs6000_builtins): Add ALTIVEC_BUILTIN_VEC_INIT_, ALTIVEC_BUILTIN_VEC_SET_, ALTIVEC_BUILTIN_VEC_EXT_. * config/rs6000/rs6000-protos.h: Declare new functions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #42 from zadeck at naturalbridge dot com 2007-12-20 01:56 --- Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions steven at gcc dot gnu dot org wrote: > --- Comment #41 from steven at gcc dot gnu dot org 2007-12-19 23:57 > --- > Patches attached to this bug report address more general issues, namely: > > 1. The LIVE problem allocates too many bitmaps (xf. df_hack2.diff) > 2. Large and very connected CFGs are a time problem > > Bug 26854 is another example of bad DF behavior, without SJLJ exceptions. I'm > making this bug depend on bug 26854 because bug 26854 shows there is more work > to do than just fixing the above mentioned two issues. > > I suspect other problems than LIVE also allocate too many bitmaps. We badly > need a mechanism to track memory usage of DF. > > > The df_hack2.diff actually allocates 1 more bitmap than without it. the space difference comes from the fact that a large number of the bitmaps have fewer bits. Remember that the implementation of bitmaps allocates a block of memory for each 64 bit unit that contains some ones, so there is a price paid in time and space for having more 1's in your maps. the implementation of df actually uses 2 different memory allocation frameworks. The local data structures are based on alloc_pools and i do not think that it would be hard to add a little code to this say how many pools had been allocated. However the bitmaps use obstacks which are a completely different beast. It would probably be best to just convert bitmaps to use alloc pools since these seem to be better than obstacks, but either way makes the accounting of space complex. I can work on the an addition to df_hack2.diff that does the same thing for the reaching defs problem. It will be a more tricky patch, but the space gains may be even more significant because there are a lot more 1 bits flying thru the air in this problem. As far as the time, doing this will not make that much difference unless you are at -O2 or higher since this is rarely (if at all) used at -O1. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #3 from danglin at gcc dot gnu dot org 2007-12-20 01:42 ---
Fixed by change.
What are the reasons this was marked as a 4.3 regression? I'm interested
when the regression occurred since the backend has never forced function
labels to memory in this code.
A simpler testcase is:
[EMAIL PROTECTED]:~/gcc_test$ less pr34525.c
extern void tramp_r ();
int is_trampoline_r (void* function)
{
void *tramp_r_address = &tramp_r;
if (!(((long)function & 3) == 2))
return 0;
return
long *) ((char*)function - 2))[0] == ((long *)
((char*)tramp_r_address-2)
)[0])
&& long *) ((char*)function - 2))[2]) == (long)((char*)function - 2 +
16
))
? 1 : 0
);
}
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug debug/34535] [4.3 Regression] FAIL: libmudflap.c++/fail24-frag.cxx ICE
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-20 01:21 --- Confirmed. > I think these were caused by: > http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00728.html Actually it is obvious it was caused by that patch based on the backtrace. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-20 01:21:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34535
[Bug debug/34535] [4.3 Regression] FAIL: libmudflap.c++/fail24-frag.cxx ICE
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 01:20 --- I get these failures too on powerpc-linux-gnu. I think these were caused by: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00728.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34535
[Bug target/34525] [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
--- Comment #2 from danglin at gcc dot gnu dot org 2007-12-20 01:18 --- Subject: Bug 34525 Author: danglin Date: Thu Dec 20 01:17:57 2007 New Revision: 131096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131096 Log: PR target/34525 * pa.c (legitimize_pic_address): Force function labels into memory. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
[Bug debug/34535] New: [4.3 Regression] FAIL: libmudflap.c++/fail24-frag.cxx ICE
/home/dave/gnu/gcc-4.3/objdir/./gcc/include-fixed /home/dave/opt/gnu/include /usr/include End of search list. GNU C++ (GCC) version 4.3.0 20071219 (experimental) [trunk revision 131051] (hppa-linux) compiled by GNU C version 4.3.0 20071219 (experimental) [trunk revision 131051], GMP version 4.2.2, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 options passed: -nostdinc++ -nostdinc++ -v -I/home/dave/gnu/gcc-4.3/gcc/libmudflap/testsuite -I/home/dave/gnu/gcc-4.3/gcc/libmudflap/testsuite/.. -I.. -I/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/util -iprefix /home/dave/gnu/gcc-4.3/objdir/gcc/../lib/gcc/hppa-linux/4.3.0/ -isystem /home/dave/gnu/gcc-4.3/objdir/./gcc/include -isystem /home/dave/gnu/gcc-4.3/objdir/./gcc/include-fixed -D_GNU_SOURCE -DDEBUG_ASSERT -D_GLIBCXX_ASSERT -D_GNU_SOURCE -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include /home/dave/gnu/gcc-4.3/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx -D_MUDFLAP -include mf-runtime.h -ggdb3 -g -g -O2 -O2 -fmessage-length=0 -ffunction-sections -fdata-sections -fmudflap -fno-builtin -fno-merge-constants options enabled: -falign-functions -falign-jumps -falign-labels -fargument-alias -fauto-inc-dec -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdata-sections -fdefer-pop -fdelayed-branch -fdelete-null-pointer-checks -fearly-inlining -feliminate-unused-debug-types -fexceptions -fexpensive-optimizations -fforward-propagate -ffunction-cse -ffunction-sections -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion -fif-conversion2 -finline-functions-called-once -finline-small-functions -fipa-pure-const -fipa-reference -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmove-loop-invariants -fmudflap -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls -fpeephole -fpeephole2 -freg-struct-return -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2 -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-pre -ftree-reassoc -ftree-salias -ftree-scev-cprop -ftree-sink -ftree-sra -ftree-store-ccp -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fvar-tracking -fzero-initialized-in-bss -mbig-switch -mgas -mglibc -mno-space-regs Compiler executable checksum: 04ed41a4bed3a85281869562079411b0 int vprintf(const char*, void*) int getchar() int fgetc_unlocked(FILE*) int getc_unlocked(FILE*) int getchar_unlocked() int putchar(int) int fputc_unlocked(int, FILE*) int putc_unlocked(int, FILE*) int putchar_unlocked(int) __ssize_t getline(char**, size_t*, FILE*) int feof_unlocked(FILE*) int ferror_unlocked(FILE*) double atof(const char*) int atoi(const char*) long int atol(const char*) long long int atoll(const char*) unsigned int gnu_dev_major(long long unsigned int) unsigned int gnu_dev_minor(long long unsigned int) long long unsigned int gnu_dev_makedev(unsigned int, unsigned int) int main() Analyzing compilation unit Performing interprocedural optimizations Assembling functions: int main() Program received signal SIGSEGV, Segmentation fault. 0x0002055c in cp_classify_record (type=) at ../../gcc/gcc/cp/cp-lang.c:162 162 if (CLASSTYPE_DECLARED_CLASS (type)) (gdb) disass 0x0002054c 0x0002056c Dump of assembler code from 0x2054c to 0x2056c: 0x0002054c : ldw,s ret0(r19),r20 0x00020550 : cmpib,<> 2,r20,0x20578 0x00020554 : ldo 40(sp),sp 0x00020558 : ldw 60(r26),r26 0x0002055c : ldw 0(r26),ret0 0x00020560 : cmpib,<=,n 0,ret0,0x20598 0x00020564 : ldw 4(r26),ret0 0x00020568 : ldw -54(sp),rp End of assembler dump. (gdb) p/x $r26 $1 = 0x0 (gdb) bt #0 0x0002055c in cp_classify_record (type=) at ../../gcc/gcc/cp/cp-lang.c:162 #1 0x0028e950 in record_type_tag (type=0x0) at ../../gcc/gcc/dwarf2out.c:11923 #2 0x002a4734 in gen_type_die_with_usage (type=0x400d36e8, context_die=0x400dfc78, usage=) at ../../gcc/gcc/dwarf2out.c:13144 #3 0x002ad504 in gen_array_type_die (type=0x400d37b8, context_die=0x400dfc78) at ../../gcc/gcc/dwarf2out.c:11697 #4 0x002a3950 in gen_type_die_with_usage (type=0x400d37b8, context_die=0x400dfc78, usage=DINFO_USAGE_DIR_USE) at ../../gcc/gcc/dwarf2out.c:13
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #7 from dsanderson at panasas dot com 2007-12-20 00:17 --- Note that my originally stated workaround -- to compile with -maix64 -- doesn't really work beyond helping the compile to succeed. Using -maix64 gives you a 64-bit executable (e.g. with 64-bit pointers and a 64-bit off_t) that can't access large files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug tree-optimization/34534] New: Multiple gcc.dg/struct/wo_prof_xxxx execution failures
On Linux/ia64, I saw FAIL: gcc.dg/struct/wo_prof_global_var.c execution test FAIL: gcc.dg/struct/wo_prof_local_var.c execution test FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c execution test FAIL: gcc.dg/struct/wo_prof_two_strs.c execution test They are run-time failures. -- Summary: Multiple gcc.dg/struct/wo_prof_ execution failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug tree-optimization/34472] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #5 from hjl at lucon dot org 2007-12-20 00:15 --- (In reply to comment #4) > Thank you for debugging! Now I see approximately where it fails. Although I am > not sure that the following patch solves the issue, please try it, and let me > know whether it helps. > > Thank you a lot, > Olga > > Index: ipa-struct-reorg.c > === > --- ipa-struct-reorg.c (revision 130906) > +++ ipa-struct-reorg.c (working copy) > @@ -3068,6 +3068,17 @@ >dump_access_sites (str->accs); > } Yes, it works for me on both Intel64 and ia64. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #6 from tcoleman at autowares dot com 2007-12-20 00:06 --- The test program will compile if you comment out the #undefs in cstdio. //#undef fgetpos //#undef fopen //#undef freopen //#undef fsetpos I've wrestled with this problem with G++ on AIX for years. In desparation I just had our admin load the IBM 4.0.0 RPMs - same problem! This is the second time this error has prevented me from porting a relatively simple application to AIX. This particular problem has gone on long enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #39 from steven at gcc dot gnu dot org 2007-12-20 00:02 --- We badly need a way to track memory in DF. Because DF uses alloc_pools for almost all its data structures, the memory statistics are only recorded if you configure with --gather-detailed-mem-stats. I think it would be good if the DF problems would report an estimate of their memory usage in the dump files, or if a function would be available that you can call from GDB to give such an estimate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #41 from steven at gcc dot gnu dot org 2007-12-19 23:57 --- Patches attached to this bug report address more general issues, namely: 1. The LIVE problem allocates too many bitmaps (xf. df_hack2.diff) 2. Large and very connected CFGs are a time problem Bug 26854 is another example of bad DF behavior, without SJLJ exceptions. I'm making this bug depend on bug 26854 because bug 26854 shows there is more work to do than just fixing the above mentioned two issues. I suspect other problems than LIVE also allocate too many bitmaps. We badly need a mechanism to track memory usage of DF. -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26854 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #38 from lucier at math dot purdue dot edu 2007-12-19 23:31 --- Subject: Re: Inordinate compile times on large routines On Dec 19, 2007, at 5:13 PM, steven at gcc dot gnu dot org wrote: > This may be asking a lot, but could you do something for me > please? Could you > install the patches df_hack2.diff and > df_double_queue_worklist.diff, and redo > the timings? Both patches are attached to bug 34400. Your patches definitely help, for some value of "help". The top memory usage (just from watching "top") went from 9998 MB to 6803MB (of course I could have missed the peak memory usage of both jobs), and the CPU time went down, too. Here are details. Before your patches: euler-32% /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-checking=release --with-gmp=/pkgs/ gmp-4.2.2 --with-mpfr=/pkgs/gmp-4.2.2 Thread model: posix gcc version 4.3.0 20071219 (experimental) [trunk revision 131091] (GCC) euler-33% /pkgs/gcc-mainline/bin/gcc -O1 -fno-math-errno -fschedule- insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame- pointer -fPIC -fno-common -ftime-report -fmem-report -c all.i Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 4096 16 120 1672k 18k 1584 128 2144k 2135k 29k 256 40961536 56 512 40961024 56 1024 112k110k 1568 2048 28k 22k392 4096 76k 76k 1064 8192 48k 48k336 16384 32k 32k112 32768 32k 32k 56 131072256k256k112 262144512k512k112 524288 1024k 1024k112 1048576 2048k 2048k112 192 616k300k 8624 144 20k 3024 280 160 132k115k 1848 432 28k 21k392 9615M 14M215k 48 2136k 1171k 33k 208 420k375k 5880 64 1288k 1237k 20k 32 164k 64k 2952 8029M 2060k417k Total 56M 25M741k String pool entries 159286 identifiers 159286 (100.00%) slots 262144 bytes 1995k (171k overhead) table size 2048k coll/search 0.9209 ins/search 0.2067 avg. entry 12.83 bytes (+/- 7.80) longest entry 67 ??? tree nodes created (No per-node statistics) Type hash: size 2039, 920 elements, 0.86 collisions DECL_DEBUG_EXPR hash: size 16381, 0 elements, 1.332565 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions Execution times (seconds) garbage collection: 1.05 ( 0%) usr 0.00 ( 0%) sys 1.06 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 0.79 ( 0%) usr 0.09 ( 1%) sys 0.89 ( 0%) wall 31928 kB ( 4%) ggc callgraph optimization: 1.02 ( 0%) usr 0.00 ( 0%) sys 1.03 ( 0%) wall 6 kB ( 0%) ggc ipa reference : 0.21 ( 0%) usr 0.03 ( 0%) sys 0.24 ( 0%) wall 7 kB ( 0%) ggc cfg cleanup : 2.16 ( 1%) usr 0.00 ( 0%) sys 2.16 ( 1%) wall 164 kB ( 0%) ggc trivially dead code : 0.35 ( 0%) usr 0.01 ( 0%) sys 0.35 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 9.53 ( 4%) usr 3.29 (20%) sys 12.83 ( 5%) wall 0 kB ( 0%) ggc df live regs : 8.09 ( 3%) usr 0.01 ( 0%) sys 8.11 ( 3%) wall 0 kB ( 0%) ggc df live&initialized regs: 98.09 (41%) usr 2.81 (17%) sys 100.95 (39%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 8.16 ( 3%) usr 2.38 (15%) sys 10.53 ( 4%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.95 ( 0%) usr 0.00 ( 0%) sys 0.95 ( 0%) wall 10801 kB ( 1%) ggc register information : 0.52 ( 0%) usr 0.01 ( 0%) sys 0.51 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.85 ( 0%) usr 0.01 ( 0%) sys 0.87 ( 0%) wall7168 kB ( 1%) ggc register scan : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 4 kB ( 0%) ggc rebuild jump labels : 0.33 ( 0%) usr 0.00 ( 0%) sys 0.33 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.68 ( 0%) usr 0.90 ( 6%) sys 1.66 ( 1%) wall2918 kB ( 0%) ggc lexical analysis : 0.55 ( 0%) usr 1.97 (12%) sys 2.18 ( 1%) wall 0 kB ( 0%) ggc parser: 1.29 ( 1%) usr 0.90 ( 6%) sys 2.45 ( 1%) wall 66023 kB ( 8%) ggc inline heuristics : 0.66 ( 0%) usr 0.15 ( 1%) sys 0.82 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 1.08 ( 0%) u
[Bug rtl-optimization/34529] [4.1/4.2/4.3 Regression] Wrong code with altivec stores and offsets
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-19 23:01 --- I should note this is a reduced testcase from a much bigger testcase and that I could not provide that non reduced testcase as it is part of some PS3 video game. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #40 from steven at gcc dot gnu dot org 2007-12-19 22:49 --- The issue with tree PRE is probably the quadratic behavior of insert(). Easily tested by lowering the maximum number of basic blocks from 4000 to 2000 (even though that's obviously not an actual fix for this problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug fortran/34533] New: DTIME returns total process time and not since last invocation
Found by Dominique. For the first call, DTIME and ETIME (should) behave identical: The elapsed time since invocation should be returned. (This works.) ETIME does this also for the following calls, but DTIME shall do the following: "Subsequent invocations of DTIME return values accumulated since the previous invocation." However, gfortran currently calls _gfortran_etime_sub for both, which in turn calls getrusage. Thus ETIME is ok, but for DTIME the wrong result is returned. Documentation: http://gcc.gnu.org/onlinedocs/gfortran/DTIME.html http://gcc.gnu.org/onlinedocs/gfortran/ETIME.html -- Summary: DTIME returns total process time and not since last invocation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
gcc-bugs@gcc.gnu.org
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-19 22:33 --- Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00245.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #37 from steven at gcc dot gnu dot org 2007-12-19 22:13 --- Brad, I am looking at your dump and your backtraces (many many thanks!!!) and I think I have an idea how to improve the situation a bit here: > Program received signal SIGINT, Interrupt. > 0x004687c9 in bitmap_elt_insert_after (head=0x963b0f0, > elt=0xd30a7a70, indx=561) at ../../../mainline/gcc/bitmap.c:203 > 203 if (element->next) > (gdb) where > #0 0x004687c9 in bitmap_elt_insert_after (head=0x963b0f0, > elt=0xd30a7a70, indx=561) at ../../../mainline/gcc/bitmap.c:203 > #1 0x0046a19b in bitmap_ior_into (a=0x963b0f0, b=Variable > "b" is not available. > ) at ../../../mainline/gcc/bitmap.c:913 > #2 0x004adce6 in df_worklist_dataflow (dataflow=0x7829f20, > blocks_to_consider=0x9c1f250, blocks_in_postorder=0x2ab81c6010, > n_blocks=Variable "n_blocks" is not available. > ) > at ../../../mainline/gcc/df-core.c:875 > #3 0x004acd7e in df_analyze_problem (dflow=0x7829f20, blocks_to_consider=0x9c1f250, postorder=0x2ab81c6010, n_blocks=59465) > at ../../../mainline/gcc/df-core.c:1060 ... and ... > df live&initialized regs: 93.27 (37%) usr 2.67 (16%) sys 204.59 (41%) wall 0 kB ( 0%) ggc I have seen this before :-) In fact, I already attached a patch implementing this idea in another bug report, bug 34400. This may be asking a lot, but could you do something for me please? Could you install the patches df_hack2.diff and df_double_queue_worklist.diff, and redo the timings? Both patches are attached to bug 34400. If adding the patches I mentioned does not help, could you try to interrupt gdb a few times more, and then look a few times in df_analyze_problem which problem dflow is? I.e. "p dflow" or "p (timevar_id_t) dflow->tv_id", or whatever works to see which problem we are in? I suspect we may be creating dataflow problems that are too large to handle. Many thanks for your help! -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/23835] [4.1/4.2/4.3 Regression] case where gcc 4.1/4.2/4.3.0 -O3 compile takes two times longer earlier versions
--- Comment #27 from ubizjak at gmail dot com 2007-12-19 22:02 --- (In reply to comment #26) > Bring back on the radar for the release manager. > New timings would be much appreciated. Anyone? Attached preprocessed source doesn't compile out-of-the-box with gcc-4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
[Bug tree-optimization/26854] Inordinate compile times on large routines
--- Comment #36 from lucier at math dot purdue dot edu 2007-12-19 21:48 --- I changed the "reported against" field to 4.3.0 (see my previous comments). -- lucier at math dot purdue dot edu changed: What|Removed |Added Version|4.1.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug ada/23583] invalid implemenation of Ada Monotonic_Clock
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-19 20:55 --- This will probably never be fixed in a generic way. Systems which require this (legit) behaviour will have non-backward-jumping clocks anyway. Letting open, but changing priority. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P2 |P5 Last reconfirmed|-00-00 00:00:00 |2007-12-19 20:55:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23583
[Bug ada/34510] Legal program rejected, explicit type conversion between two unrelated class-wide types, RM 4.6(21/2,23.1/2)
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-19 20:52 --- Compiles fine on trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34510
[Bug c++/34459] [4.1/4.3 Regression] incorrect code when compiled with optimization (-O1)
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-19 20:49 ---
I have bootstrapped/regtested this patch on x86_64-linux with:
{
record_voperand_set (dse_gd->stores, &bd->stores, ann->uid);
return;
}
replaced with gcc_unreachable () to see where it hits. It bootstrapped fine,
the
only regression was the newly added tests (which works with the original patch,
obviously with that gcc_unreachable () ICEs) and gcc.dg/uninit-E.c reports
the warning on line 8 rather than expected 7 (because the i = i; statement
is optimized out by the gimplify.c hunk). So perhaps the gimplify.c hunk in
that patch isn't a good idea and we should eliminate the nop moves later on
(either during DCE, or some other pass, suggestions? But that can be left
for a separate patch, keeping just tree-ssa-dse.c (dse_optimize_stmt) hunk
together with the new 20071219-1.c test as the fix for this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
[Bug ada/34509] Bug box in expand_expr_real_1, at expr.c:6711 on legal program
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-19 20:49 --- Already fixed in trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34509
[Bug fortran/34532] Doc error or rej.valid vendor extension: Integer as logical in IF expressions
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-19 20:48 --- See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/30039cbb71280a3b/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34532
[Bug fortran/34532] New: Doc error or rej.valid vendor extension: Integer as logical in IF expressions
http://gcc.gnu.org/onlinedocs/gfortran/Implicitly-convert-LOGICAL-and-INTEGER-values.html INTEGER :: i = 1 IF (i) PRINT *, 'True' The program is rejected here with gfortran 4.1, 4.2 and 4.3 using -std=legacy. -- Summary: Doc error or rej.valid vendor extension: Integer as logical in IF expressions Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34532
[Bug ada/34149] GNAT crash - deeply inrerited function
-- sam at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #9 from sam at gcc dot gnu dot org 2007-12-19 20:38 --- Fixed by Arnaud's commit. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug ada/34149] GNAT crash - deeply inrerited function
--- Comment #4 from sam at gcc dot gnu dot org 2007-12-19 20:37 --- Fixed by Arnaud's commit. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
gcc-bugs@gcc.gnu.org
--- Comment #1 from dominiq at lps dot ens dot fr 2007-12-19 19:19 --- The bug is present in gcc version 4.3.0 20071125 (experimental) (GCC). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
[Bug tree-optimization/34472] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work
--- Comment #4 from olga at gcc dot gnu dot org 2007-12-19 18:57 ---
Thank you for debugging! Now I see approximately where it fails. Although I am
not sure that the following patch solves the issue, please try it, and let me
know whether it helps.
Thank you a lot,
Olga
Index: ipa-struct-reorg.c
===
--- ipa-struct-reorg.c (revision 130906)
+++ ipa-struct-reorg.c (working copy)
@@ -3068,6 +3068,17 @@
dump_access_sites (str->accs);
}
+/* Auxiliary data structure for safe_cond_expr_check callback function. */
+struct cond_check_data
+{
+ /* Structure declaration. */
+ tree type;
+
+ /* Vector of unsuitable types. If the type participates in unsafe
+ conditional expression, it will be added to this vector. */
+ VEC (tree, heap) **unsuitable_types;
+};
+
/* This function checks whether an access statement, pointed by SLOT,
is a condition we are capable to transform. If not, it removes
the structure with index, represented by DATA, from the vector
@@ -3077,6 +3088,7 @@
safe_cond_expr_check (void **slot, void *data)
{
struct access_site *acc = *(struct access_site **) slot;
+ struct cond_check_data dt = *(struct cond_check_data *) data;
if (TREE_CODE (acc->stmt) == COND_EXPR)
{
@@ -3087,7 +3099,7 @@
fprintf (dump_file, "\nUnsafe conditional statement ");
print_generic_stmt (dump_file, acc->stmt, 0);
}
- remove_structure (*(unsigned *) data);
+ add_unsuitable_type (dt.unsuitable_types, dt.type);
}
}
return 1;
@@ -3541,10 +3553,23 @@
{
d_str str;
unsigned i;
+ VEC (tree, heap) *unsuitable_types = VEC_alloc (tree, heap,
+ VEC_length (structure,
+ structures));
+ struct cond_check_data data;
+ data.type = NULL_TREE;
+ data.unsuitable_types = &unsuitable_types;
+
for (i = 0; VEC_iterate (structure, structures, i, str); i++)
if (str->accs)
- htab_traverse (str->accs, safe_cond_expr_check, &i);
+ {
+ data.type = str->decl;
+ htab_traverse (str->accs, safe_cond_expr_check, &data);
+ }
+
+ remove_unsuitable_types (unsuitable_types);
+ VEC_free (tree, heap, unsuitable_types);
}
/* We exclude from non-field accesses of the structure
@@ -3848,6 +3873,9 @@
gcov_type hotest = 0;
unsigned i;
d_str str;
+ VEC (tree, heap) *unsuitable_types = VEC_alloc (tree, heap,
+ VEC_length (structure,
+ structures));
/* We summarize counts of fields of a structure into the structure count.
*/
for (i = 0; VEC_iterate (structure, structures, i, str); i++)
@@ -3863,8 +3891,11 @@
print_generic_expr (dump_file, str->decl, 0);
fprintf (dump_file, " is cold.");
}
- remove_structure (i);
+ add_unsuitable_type (&unsuitable_types, str->decl);
}
+
+ remove_unsuitable_types (unsuitable_types);
+ VEC_free (tree, heap, unsuitable_types);
}
/* This function decomposes original structure into substructures,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
[Bug fortran/34528] Document internal structure of arrays
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-19 18:52:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34528
[Bug c++/34531] local typedef conflicts with global definition of a type having the same name
--- Comment #3 from rbuergel at web dot de 2007-12-19 18:50 --- If the error is correct, then at least the error message is confusing. It complains that Y::X redeclares ::X, although the real cause of the error is, that it may not be clear to that compiler what X refers to -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
[Bug target/34526] no-altivec ABI should be fixed or no longer be the default
--- Comment #1 from janis at gcc dot gnu dot org 2007-12-19 18:50 --- I'd like to see -mabi=altivec be the default for -m32, with -mabi=no-altivec available for the rare cases when it's needed. Would changing the default cause any problems? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
[Bug c++/34531] local typedef conflicts with global definition of a type having the same name
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-19 17:40 --- Actually the error message is correct. Use ::X instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
gcc-bugs@gcc.gnu.org
-- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-19 17:39:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
[Bug c++/34459] [4.1/4.3 Regression] incorrect code when compiled with optimization (-O1)
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-19 17:03 --- Created an attachment (id=14797) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14797&action=view) gcc43-pr34459.patch Untested patch. The gimplify.c part is there just as an optimization, isn't strictly necessary to fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
[Bug c++/34531] local typedef conflicts with global definition of a type having the same name
--- Comment #1 from rbuergel at web dot de 2007-12-19 16:55 --- It fails only on 4.3.0: gcc version 4.3.0 20071214 (experimental) (GCC) -- rbuergel at web dot de changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.2 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #8 from charlet at adacore dot com 2007-12-19 16:50 --- Subject: Re: Illegal program not detected, RM 8.3(19) > for traceability purpose, I would appreciate to be credited in the ChangeLog > as > well for this change as I am the one who submitted the patch for sem_ch3.adb > (Check_For_Premature_Usage procedure and Access_Subprogram_Declaration change) > that you committed (after some reformatting). Sure, I understand. Actually it was more than reformatting, we changed the error message also and a few other things. But you definitely deserve to get your name as well on this patch, now added. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #7 from sam at gcc dot gnu dot org 2007-12-19 16:46 --- Arnaud, for traceability purpose, I would appreciate to be credited in the ChangeLog as well for this change as I am the one who submitted the patch for sem_ch3.adb (Check_For_Premature_Usage procedure and Access_Subprogram_Declaration change) that you committed (after some reformatting). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug c++/34531] New: local typedef conflicts with global definition of a type having the same name
template class X {};
class Y {
typedef X X;
};
produces the following error:
redef.cpp:4: error: declaration of 'typedef class X Y::X'
redef.cpp:1: error: changes meaning of 'X' from 'class X'
I don't think, that the error is correct, because as the typedef is inside a
class-definition, X is only shadowed, not redeclared.
The typedef'd type can be referred as Y::X, while the globel would be ::X.
--
Summary: local typedef conflicts with global definition of a type
having the same name
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
[Bug ada/33688] Ada package Gnat.Sockets missing constant for IP_PKTINFO (patch)
--- Comment #5 from charlet at gcc dot gnu dot org 2007-12-19 16:26 --- Subject: Bug 33688 Author: charlet Date: Wed Dec 19 16:25:58 2007 New Revision: 131084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131084 Log: 2007-12-19 Thomas Quinot <[EMAIL PROTECTED]> Part of PR ada/33688 * gen-soccon.c: Add constant IP_PKTINFO to allow getting ancillary datagram info on Linux. Modified: trunk/gcc/ada/gen-soccon.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33688
[Bug ada/34149] GNAT crash - deeply inrerited function
--- Comment #3 from charlet at gcc dot gnu dot org 2007-12-19 16:25 --- Subject: Bug 34149 Author: charlet Date: Wed Dec 19 16:25:18 2007 New Revision: 131082 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131082 Log: 2007-12-19 Gary Dismukes <[EMAIL PROTECTED]> PR ada/34149 * sem_disp.adb (Check_Dispatching_Call): Augment existing test for presence of a statically tagged operand (Present (Static_Tag)) with test for Indeterm_Ancestor_Call when determining whether to propagate the static tag to tag-indeterminate operands (which forces dispatching on such calls). (Check_Controlling_Formals): Ada2005, access parameters can have defaults. (Add_Dispatching_Operation, Check_Operation_From_Private_View): do not insert subprogram in list of primitive operations if already there. Modified: trunk/gcc/ada/sem_disp.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #6 from charlet at gcc dot gnu dot org 2007-12-19 16:24 --- Subject: Bug 15803 Author: charlet Date: Wed Dec 19 16:24:34 2007 New Revision: 131079 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131079 Log: 2007-12-19 Ed Schonberg <[EMAIL PROTECTED]> Gary Dismukes <[EMAIL PROTECTED]> PR ada/15803, ada/15805 * sem_ch6.adb, sem_ch3.adb (Constrain_Access): In Ada2005, diagnose illegal access subtypes when there is a constrained partial view. (Check_For_Premature_Usage): New procedure inside Access_Subprogram_Declaration for checking that an access-to-subprogram type doesn't reference its own name within any formal parameters or result type (including within nested anonymous access types). (Access_Subprogram_Declaration): Add call to Check_For_Premature_Usage. (Sem_Ch3.Analyze_Object_Declaration, Sem_ch6.Process_Formals): if the context is an access_to_variable, the expression cannot be an access_to_constant. Modified: trunk/gcc/ada/sem_ch3.adb trunk/gcc/ada/sem_ch6.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
for-loop iterate condition optimized away
dear all,
i am turning to the email since it would be almost impossible to make a
regular bug report.
we are building a large c++ software for the international pierre auger
collaboration which has build the world's largest cosmic ray detector.
more than a year ago we have come across a bug (on i386 linux platforms)
but lately with gcc versions > 4 this bug seems to be occuring only on
amd64 platforms and ONLY with the -O2 level of optimization (it goes
away with -O1).
trying out a small program that supposedly captures the situation does
not reproduce it, but what is interesting it always appears in the same
context of our iterators. example:
class Foo;
class FooIterator;
class FooConstIterator;
class FooContainer {
public:
FooIterator Begin();
FooConstIterator Begin() const;
FooIterator End();
FooConstIterator End() const;
};
void
test(const FooContainer& foo)
{
for (FooConstIterator it = foo.Begin();
it != foo.End(); ++it) {
// print the condition
cout << (it != foo.End()) << endl;
...
}
}
calling test prints out
0
0
0
1
0
segfault crash etc..
it seems that with -O2 and when foo is const class, the (it !=
foo.End()) is optimized away as also const (equal true) and the loop
does not end, runs over and (usually) produces segfault...
can we do something? as i mentioned. a small prove-of-bug program is
almost impossible to construct since it appears only in large contexts...
please let me know how we can proceed.
best,
--
darko.
doc.dr. Darko Veberic --
Forschungszentrum Karlsruhe _|
Institut fuer Kernphysik |
Bau 425, POB 3640 |
D-76021 Karlsruhe, Germany_
mobile: +49 1515 99 55087 |
.phone: +49 7247 82 3870 |
...fax: +49 7247 82 4075
Laboratory for Astroparticle Physics
University of Nova Gorica
Vipavska 13, POB 301
SI-5001 Nova Gorica, Slovenia
mobile: +386 41 860 861
.phone: +386 5 3315 255
...fax: +386 5 3315 385
[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include
--- Comment #5 from haubi at gentoo dot org 2007-12-19 15:57 --- Created an attachment (id=14796) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14796&action=view) the effect fixincludes could have on aix5.2/aix5.3 When applying this patch to (already fixed) stdio.h on aix5.2/aix5.3, compiling "#include " with -D_LARGE_FILES works. But I have no clue on how to create entries with this effect in inclhack.def, or if this is the way to go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
[Bug c++/34459] [4.1/4.3 Regression] incorrect code when compiled with optimization (-O1)
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-19 15:31 ---
extern void abort (void);
extern void *memset (void *s, int c, __SIZE_TYPE__ n);
struct S
{
char s[25];
};
struct S *p;
void __attribute__((noinline))
foo (struct S *x, int set)
{
int i;
for (i = 0; i < sizeof (x->s); ++i)
if (x->s[i] != 0)
abort ();
else if (set)
x->s[i] = set;
p = x;
}
int
main ()
{
struct S a;
memset (&a.s, '\0', sizeof (a.s));
foo (&a, 0);
struct S b = a;
foo (&b, 1);
b = a;
b = *p;
foo (&b, 0);
return 0;
}
fails on the trunk too at -O2 (succeeds with -O2 -fno-tree-dse). Here we have:
# VUSE { aD.1560 }
# bD.1561_21 = VDEF { bD.1561 }
bD.1561 = aD.1560;
# VUSE { pD.1547 }
p.2D.1562_1 = pD.1547;
# VUSE { aD.1560 bD.1561 SMT.28D.1593 }
# bD.1561_22 = VDEF { bD.1561 }
bD.1561 = *p.2D.1562_1;
at dce4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
[Bug tree-optimization/34355] ICE: invariant not recomputed when ADDR_EXPR changed with -ftree-parallelize-loops
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-19 15:01 --- Subject: Bug 34355 Author: rakdver Date: Wed Dec 19 15:01:19 2007 New Revision: 131063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131063 Log: PR tree-optimization/34355 * tree-parloops.c (take_address_of): Handle expresions instead of just variables. (eliminate_local_variables_1): Force whole invariant address to ssa name. * g++.dg/tree-ssa/pr34355.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr34355.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34355
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #23 from jakub at gcc dot gnu dot org 2007-12-19 14:48 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #22 from bonzini at gnu dot org 2007-12-19 14:28 --- Subject: Bug 30572 Author: bonzini Date: Wed Dec 19 14:28:32 2007 New Revision: 131062 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131062 Log: 2007-12-19 Etsushi Kato <[EMAIL PROTECTED]> Paolo Bonzini <[EMAIL PROTECTED]> PR target/30572 * Makefile.in: Use @shlib_slibdir@ substitution to get correct install name on darwin. * config/t-slibgcc-darwin: Use @shlib_slibdir@ for -install_name. Modified: trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/config/t-slibgcc-darwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug rtl-optimization/6585] Redundant store/load instruction pairs on ix86
--- Comment #18 from rask at gcc dot gnu dot org 2007-12-19 14:15 --- Created an attachment (id=14795) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14795&action=view) (u)mulsidi3 patch This patch (in testing) improves the register allocation, removing the last redundant movl instructions: mul: pushl %ebx# 40*pushsi2[length = 1] movl8(%esp), %ebx # 28*movsi_1/1 [length = 4] movl16(%esp), %eax # 30*movsi_1/1 [length = 4] movl20(%esp), %ecx # 37*movsi_1/1 [length = 4] movl12(%esp), %edx # 38*movsi_1/1 [length = 4] imull %ebx, %ecx # 7 *mulsi3_1/3 [length = 3] imull %eax, %edx # 8 *mulsi3_1/3 [length = 3] addl%edx, %ecx # 9 *addsi_1/1 [length = 2] mull%ebx# 33*umulsidi3 [length = 2] popl%ebx# 43popsi1 [length = 1] leal(%ecx,%edx), %edx # 39*lea_1 [length = 3] ret # 44return_internal [length = 1] -- rask at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org |dot org | Status|RESOLVED|ASSIGNED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585
gcc-bugs@gcc.gnu.org
Hi, namelist read was broken between GNU Fortran (GCC) 4.3.0 20071216 (experimental) [trunk revision 130986] (works) GNU Fortran (GCC) 4.3.0 20071217 (experimental) [trunk revision 131004] (fails). This is likely due to the patch for PR34427. Example: the code below now gives At line 17 of file gfcbug77.f90 (unit = 10, file = 'gfcbug77.nml') Fortran runtime error: Cannot match namelist object name ! Backtrace for this error: + function translate_error (0x804A2A1) at line 311 of file error.c + function finalize_transfer (0x804DF79) at line 2626 of file transfer.c + function gfcbug77 (0x804983C) at line 17 of file gfcbug77.f90 + /lib/libc.so.6(__libc_start_main+0xe0) [0x40071fe0] % cat gfcbug77.f90 program gfcbug77 implicit none character(len=128) :: file = "" logical:: default namelist /BLACKLIST/ file, default integer, parameter :: nnml = 10 open (nnml, file='gfcbug77.nml') write(nnml,*) "&blacklist " ! The trailing space breaks gfortran write(nnml,*) " ! This is a comment within the namelist" write(nnml,*) " file= 'myfile'" write(nnml,*) " default = F" write(nnml,*) "/" rewind(nnml) read (nnml, nml=BLACKLIST) close(nnml) write (*,nml=BLACKLIST) end program gfcbug77 Removing the marked whitespace or removing the comment line within the namelist lets the program run. Cheers, -ha -- Summary: [4.3 regression] namelist read broken when whitespace after &namelist Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #39 from bonzini at gnu dot org 2007-12-19 13:57 --- Yes, we need a no-checking comparison. And this might be a PR of its own, for example: tree PRE : 7.94 (15%) usr 0.10 (32%) sys 8.04 (15%) wall 1687 kB ( 2%) ggc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #26 from bonzini at gnu dot org 2007-12-19 13:53 --- I'm starting a SPEC run on the overall patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #25 from bonzini at gnu dot org 2007-12-19 13:50 --- Note that "fwprop" is not an exact term, because there *is* a memory load in each multiplication, and propagating a second memory operand will create an invalid insn. You may try to add a split from reg=op(mem1, mem2) to reg=mem1;reg=reg*mem2, but anyway, it won't help propagating into the mull, since it is not LOG_LINKS-related to the load. The problem is that we end up with having to reload *anyway*. If we had a way to express the relationship between operands 0 and 1 of the multiplication *before reload*, probably the RTL optimizations could do much more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #24 from steven at gcc dot gnu dot org 2007-12-19 13:48 --- The patch in comment #23 might even be suitable for GCC 4.3 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #23 from bonzini at gnu dot org 2007-12-19 13:36 --- Created an attachment (id=14794) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14794&action=view) teach combine that reg = op(reg, mem) is better Since combine operates on the whole pattern, it can be taught the trick that swap_commutative_operands_with_target does in optabs.c. This is the "right way" to do the hack Uros proposed in comment #18. Note that optabs.c does not get it because it creates reg=subreg*subreg. Then CSE creates SImode memory loads from the subreg, and combine creates reg=mem*reg. With this patch, combine creates reg=reg*mem instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #22 from ubizjak at gmail dot com 2007-12-19 13:11 --- (In reply to comment #21) > Indeed, if I only use the regclass.c and local-alloc.c hunks, I get only one > spill! > > pushl %ebx > movl8(%esp), %edx > movl16(%esp), %eax > movl20(%esp), %ecx > imull %edx, %ecx > movl12(%esp), %ebx > imull %eax, %ebx > addl%ebx, %ecx > mull%edx > leal(%ecx,%edx), %edx > popl%ebx > > and no reg-reg move. Excellent! I think that we should fwprop stack arguments into the insns to further optimize the code. According to pentopt.pdf, there is no penalty at all (at least for P4+) when one of the insn operands is a memory reference. This would relieve register pressure considerably. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug c++/34513] static variable not found for C++ OpenMP
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-19 13:01 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-19 13:01:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug c++/34513] static variable not found for C++ OpenMP
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-19 12:58 --- Subject: Bug 34513 Author: jakub Date: Wed Dec 19 12:58:32 2007 New Revision: 131059 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131059 Log: PR c++/34513 * parser.c (cp_parser_omp_parallel): For non-combined parallel call cp_parser_statement rather than cp_parser_already_scoped_statement. * testsuite/libgomp.c/pr34513.c: New test. * testsuite/libgomp.c++/pr34513.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr34513.C trunk/libgomp/testsuite/libgomp.c/pr34513.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #21 from bonzini at gnu dot org 2007-12-19 12:43 --- Created an attachment (id=14793) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14793&action=view) two hunks only from the previous patch Indeed, if I only use the regclass.c and local-alloc.c hunks, I get only one spill! pushl %ebx movl8(%esp), %edx movl16(%esp), %eax movl20(%esp), %ecx imull %edx, %ecx movl12(%esp), %ebx imull %eax, %ebx addl%ebx, %ecx mull%edx leal(%ecx,%edx), %edx popl%ebx and no reg-reg move. With Uros' patch it does use memory imull's, but also adds reg-reg moves. The next step should be to figure out why (with my patch and without his) reload feels the need to put the memory operands from insns 7 and 8 into regs. -- bonzini at gnu dot org changed: What|Removed |Added Attachment #14792|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #20 from bonzini at gnu dot org 2007-12-19 12:32 --- There is a big catch-22. When GCC ties one of regs 64/66 with reg 61, it enlarges reg 61's live range to cover the live range of the tied range. When it does this, it basically locks up %edx for the whole live range of reg 61. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #19 from bonzini at gnu dot org 2007-12-19 12:13 --- Created an attachment (id=14792) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14792&action=view) patch to almost fix the bug With this patch: 1) local-alloc first tries to allocate registers that go into small classes 2) regclass tries to use the same class for an output and an input that dies 3) i386 modes_tiable_p allows tying SImode with DImode (but not vice versa) I get now this: pushl %esi pushl %ebx movl12(%esp), %ecx movl20(%esp), %eax movl24(%esp), %ebx imull %ecx, %ebx movl16(%esp), %esi imull %eax, %esi addl%esi, %ebx mull%ecx leal(%ebx,%edx), %edx popl%ebx popl%esi which has no moves. It still spills two registers because it is not able to use %edx (I'll look into it later). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #18 from ubizjak at gmail dot com 2007-12-19 12:11 ---
Another baby step can be performed by:
Index: optabs.c
===
--- optabs.c(revision 131053)
+++ optabs.c(working copy)
@@ -1245,7 +1245,7 @@ expand_doubleword_mult (enum machine_mod
return NULL_RTX;
}
- adjust = expand_binop (word_mode, smul_optab, op0_high, op1_low,
+ adjust = expand_binop (word_mode, smul_optab, op1_low, op0_high,
NULL_RTX, 0, OPTAB_DIRECT);
if (!adjust)
return NULL_RTX;
@@ -1274,7 +1274,7 @@ expand_doubleword_mult (enum machine_mod
return NULL_RTX;
}
- temp = expand_binop (word_mode, smul_optab, op1_high, op0_low,
+ temp = expand_binop (word_mode, smul_optab, op0_low, op1_high,
NULL_RTX, 0, OPTAB_DIRECT);
if (!temp)
return NULL_RTX;
This patch generates (note mem operands to imull):
test:
subl$8, %esp
movl%ebx, (%esp)
movl12(%esp), %ebx
movl%esi, 4(%esp)
movl20(%esp), %esi
movl%ebx, %ecx
movl%esi, %eax
imull 24(%esp), %ecx
imull 16(%esp), %eax
addl%eax, %ecx
movl%esi, %eax
mull%ebx
movl(%esp), %ebx
leal(%ecx,%edx), %esi
movl%esi, %edx
movl4(%esp), %esi
addl$8, %esp
ret
but since mulsi3 is defined as:
(define_insn "*mulsi3_1"
[(set (match_operand:SI 0 "register_operand" "=r,r,r")
(mult:SI (match_operand:SI 1 "nonimmediate_operand" "%rm,rm,0")
(match_operand:SI 2 "general_operand" "K,i,mr")))
(clobber (reg:CC FLAGS_REG))]
the question is, why didn't RA perform operand reversal by itself. Currently it
converts _both_ SI multiplies from:
(insn:HI 8 7 9 2 m.c:14 (parallel [
(set (reg:SI 63)
(mult:SI (mem/c/i:SI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [2 a+4 S4 A32])
(reg:SI 66 [ b ])))
(clobber (reg:CC 17 flags))
]) 214 {*mulsi3_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
into
--cut here--
(insn 35 7 8 2 m.c:14 (set (reg:SI 0 ax [63])
(mem/c/i:SI (plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])) [2 a+4 S4 A32])) 41 {*movsi_1} (nil))
(insn:HI 8 35 9 2 m.c:14 (parallel [
(set (reg:SI 0 ax [63])
(mult:SI (reg:SI 0 ax [63])
(reg:SI 4 si [orig:66 b ] [66])))
(clobber (reg:CC 17 flags))
]) 214 {*mulsi3_1} (nil))
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug rtl-optimization/34456] MIPS: Flaw in branch delay optimization (patch included).
--- Comment #10 from rsandifo at gcc dot gnu dot org 2007-12-19 10:08 --- Thanks for the patch. Now applied to 4.1 and 4.2. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
[Bug rtl-optimization/34456] MIPS: Flaw in branch delay optimization (patch included).
--- Comment #9 from rsandifo at gcc dot gnu dot org 2007-12-19 10:06 --- Subject: Bug 34456 Author: rsandifo Date: Wed Dec 19 10:05:47 2007 New Revision: 131058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131058 Log: gcc/ 200x-xx-xx Kaz Kylheku <[EMAIL PROTECTED]> PR rtl-optimization/34456 * resource.c (mark_set_resources): Use regs_invalidated_by_call rather than call_used_regs and global_regs. gcc/testsuite/ PR rtl-optimization/34456 * gcc.c-torture/execute/pr34456.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr34456.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/resource.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #7 from hainque at adacore dot com 2007-12-19 10:06 --- Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug Olivier Hainque wrote: > We can definitely resubmit the current version we have (I copied the > author). Thanks again for your feedback, Actually, there was another related submission at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00099.html There was an interesting exchange with Richard Guenther there, which didn't quite reach a conclusion at the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug rtl-optimization/34456] MIPS: Flaw in branch delay optimization (patch included).
--- Comment #8 from rsandifo at gcc dot gnu dot org 2007-12-19 10:04 --- Subject: Bug 34456 Author: rsandifo Date: Wed Dec 19 10:04:28 2007 New Revision: 131057 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131057 Log: gcc/ 200x-xx-xx Kaz Kylheku <[EMAIL PROTECTED]> PR rtl-optimization/34456 * resource.c (mark_set_resources): Use regs_invalidated_by_call rather than call_used_regs and global_regs. gcc/testsuite/ PR rtl-optimization/34456 * gcc.c-torture/execute/pr34456.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr34456.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/resource.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34456
[Bug rtl-optimization/17236] inefficient code for long long multiply on x86
--- Comment #17 from bonzini at gnu dot org 2007-12-19 09:49 ---
With this patch, GCC gets the preferences right, but it does not affect code
generation.
Index: regclass.c
===
--- regclass.c (revision 130928)
+++ regclass.c (working copy)
@@ -1651,9 +1651,15 @@ record_reg_classes (int n_alts, int n_op
[(unsigned char) reg_pref[REGNO (op)].prefclass]
[(int) classes[i]]);
- if (REGNO (ops[i]) != REGNO (ops[j])
- && ! find_reg_note (insn, REG_DEAD, op))
- alt_cost += 2;
+ if (REGNO (ops[i]) != REGNO (ops[j]))
+ {
+ /* If the pseudo dies, tying it to the duplicate
+operand can be advantageous. */
+ if (find_reg_note (insn, REG_DEAD, op))
+ pp->cost[classes[j]]--;
+ else
+ alt_cost += 2;
+ }
/* This is in place of ordinary cost computation
for this operand, so skip to the end of the
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-19 09:46 --- We could even TODO_rebuild_alias only if vectorizer changed anything... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #3 from dorit at gcc dot gnu dot org 2007-12-19 09:38 --- > This is a vectorizer vs not being able to run may_alias after it can you please remind me why we can't run may_alias after the vectorizer? (and what do you think can be done about it?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed
--- Comment #3 from bonzini at gnu dot org 2007-12-19 09:37 --- Makes a lot of sense. I made the patch only to test that it would not crash, or something like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
[Bug rtl-optimization/34522] inefficient code for long long multiply when only low bits are needed
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-19 09:08 --- Shouldn't tmode be only used if GET_MODE_CLASS (tmode) == MODE_INT && GET_MODE_CLASS (mode) == MODE_INT && GET_MODE_BITSIZE (tmode) < GET_MODE_BITSIZE (mode), to make sure we optimize only narrow, never widen, and that float etc. multiplication is not affected? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #6 from hainque at adacore dot com 2007-12-19 08:30 --- Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug Hi Steven, steven at gcc dot gnu dot org wrote: > xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html > > I was wrong to object to this patch No problem, and many thanks for getting back to us on this issue. What really matters is feedback/discussion IMO, and your comments had us look for better ways to perform the task. This is a positive outcome even if we haven't (yet) pushed further for an inclusion into the FSF tree. > there really doesn't seem to be any other way. It's funny, on the > one hand we complain about the code quality of -O0, but on the other > we have to do quite silly things such as adding jumps to jumps to > keep rather important debug information around... Right. We have several constraints at play (want to debug, want the ability to debug (-g) not to modify the generated code, and want to limit generated code bloats), and it's not always possible to progress on one aspect without effects on the others. I like the recently suggested "-Og" idea because it offers a way through. > Olivier, any chance someone at AdaCore can pick this up and re-submit it to > gcc-patches? We can definitely resubmit the current version we have (I copied the author). Thanks again for your feedback, Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
