[Bug c++/34103] [4.3 regression] ICE with invalid variadic template functions
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34103
[Bug c++/34102] New: [4.3 regression] ICE with invalid inheritance of variadic templates
The following invalid testcase triggers an ICE on mainline: struct A {}; templatetypename struct B : virtual A {}; templatetypename...T struct C : BT {}; bug.cc:5: error: parameter packs not expanded with `...': bug.cc:5: note: 'T' bug.cc: In instantiation of 'Bexpression error ': bug.cc:5: instantiated from here bug.cc:3: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] The bug appeared between 2007-11-03 and 2007-11-06. -- Summary: [4.3 regression] ICE with invalid inheritance of variadic templates Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
[Bug c++/34102] [4.3 regression] ICE with invalid inheritance of variadic templates
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34102
[Bug fortran/34092] Should warn about unused private variables
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-15 08:31 --- Duplicate of PR 31124 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34092
[Bug c++/34100] [4.3 regression] ICE with vector attribute
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34100
[Bug c++/34099] optimizer problem
--- Comment #1 from rwgk at yahoo dot com 2007-11-15 06:56 --- Created an attachment (id=14554) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14554action=view) reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug c++/34101] New: [4.3 regression] ICE with argument deduction of variadic template function
The following valid testcase triggers an ICE on mainline: templatetypename struct A {}; templatetemplatetypename class... struct B {}; templatetemplatetypename class T void foo(const BT); void bar() { foo(BA()); } bug.cc: In function 'void bar()': bug.cc:9: internal compiler error: in arg_assoc_type, at cp/name-lookup.c:4626 Please submit a full bug report, [etc.] -- Summary: [4.3 regression] ICE with argument deduction of variadic template function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34101
[Bug c++/34101] [4.3 regression] ICE with argument deduction of variadic template function
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34101
[Bug libstdc++/34105] New: [4.3 Regression] Confusing error message with missing #include algorithm
For #include vector #include string int main() { std::vectorstd::string x; std::string s(hello); return std::find(x.begin(), x.end(), s) - x.begin(); } we now get interesting linker errors with trunk: g++-4.3 -o t t.C /tmp/cc3Vq2t8.o: In function `main': t.C:(.text+0x65): undefined reference to `__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar std::find__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, std::basic_stringchar, std::char_traitschar, std::allocatorchar (__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: ld returned 1 exit status where it is not exactly obvious that just the #include algorithm is missing here. With 4.2 and 4.2 at least the program linked fine (I guess algorithm was pulled in anyway). Can we improve this situation by not making algorithm half-way available so we can raise a meaningful error instead? -- Summary: [4.3 Regression] Confusing error message with missing #include algorithm Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug c++/34104] New: auto_ptr error catching
#include memory int main(int argc, char* argv[]) { int* intptr; std::auto_ptrint i; i = std::auto_ptrint (intptr); return 0; } - code above compiles but fails run ~/tests$ g++ -Wall auto_ptr.cpp ~/tests$ ./a.out *** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0x080485a9 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7d2792b] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7eecd81] ./a.out[0x804857d] ./a.out[0x80484b3] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7cd0050] ./a.out[0x80483d1] === Memory map: 08048000-08049000 r-xp 08:03 6389816/home/dkorah/tests/a.out 08049000-0804a000 rw-p 08:03 6389816/home/dkorah/tests/a.out 0804a000-0806b000 rw-p 0804a000 00:00 0 [heap] b7cb9000-b7cba000 rw-p b7cb9000 00:00 0 b7cba000-b7dfe000 r-xp 08:01 32593 /lib/tls/i686/cmov/libc-2.6.1.so b7dfe000-b7dff000 r--p 00143000 08:01 32593 /lib/tls/i686/cmov/libc-2.6.1.so b7dff000-b7e01000 rw-p 00144000 08:01 32593 /lib/tls/i686/cmov/libc-2.6.1.so b7e01000-b7e04000 rw-p b7e01000 00:00 0 b7e04000-b7e0e000 r-xp 08:01 2394403/lib/libgcc_s.so.1 b7e0e000-b7e0f000 rw-p a000 08:01 2394403/lib/libgcc_s.so.1 b7e0f000-b7e1 rw-p b7e0f000 00:00 0 b7e1-b7e33000 r-xp 08:01 32597 /lib/tls/i686/cmov/libm-2.6.1.so b7e33000-b7e35000 rw-p 00023000 08:01 32597 /lib/tls/i686/cmov/libm-2.6.1.so b7e35000-b7f1d000 r-xp 08:01 1337854/usr/lib/libstdc++.so.6.0.9 b7f1d000-b7f2 r--p 000e8000 08:01 1337854/usr/lib/libstdc++.so.6.0.9 b7f2-b7f22000 rw-p 000eb000 08:01 1337854/usr/lib/libstdc++.so.6.0.9 b7f22000-b7f28000 rw-p b7f22000 00:00 0 b7f3c000-b7f3e000 rw-p b7f3c000 00:00 0 b7f3e000-b7f58000 r-xp 08:01 2394896/lib/ld-2.6.1.so b7f58000-b7f5a000 rw-p 00019000 08:01 2394896/lib/ld-2.6.1.so bf9f2000-bfa07000 rw-p bf9f2000 00:00 0 [stack] e000-f000 r-xp 00:00 0 [vdso] Aborted (core dumped) -- Summary: auto_ptr error catching Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dckorah+gcc at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34104
[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-15 09:46 --- The patch below fixes the reported bug. I am going to check to see what needs to be done to extend this to generic interfaces and operators. Paul Index: gcc/fortran/module.c === *** gcc/fortran/module.c(révision 130174) --- gcc/fortran/module.c(copie de travail) *** find_symtree_for_symbol (gfc_symtree *st *** 3492,3497 --- 3492,3522 } + /* A recursive function to look for a spefici symbol by name and by +module. Whilst several symtrees might point to one symbol, its +is sufficient for the purposes here than one exist. */ + static gfc_symtree * + find_symbol (gfc_symtree *st, const char *name, const char *module) + { + int c; + gfc_symtree *retval; + + if (st == NULL || st-n.sym == NULL) + return NULL; + + c = strcmp (name, st-n.sym-name); + if (c == 0 strcmp (module, st-n.sym-module) == 0) + return st; + + retval = find_symbol (st-left, name, module); + + if (retval == NULL) + retval = find_symbol (st-right, name, module); + + return retval; + } + + /* Read a module file. */ static void *** read_module (void) *** 3616,3621 --- 3641,3655 continue; } + /* If a symbol of the same name and module exists already, +this symbol, which is not in an ONLY clause, must not be +added to the namespace(11.3.2). Note that find_symbol +only returns the first occurrence that it finds. */ + if (p == name strcmp (name, module_name) != 0 +find_symbol (gfc_current_ns-sym_root, name, + module_name)) + continue; + st = gfc_find_symtree (gfc_current_ns-sym_root, p); if (st != NULL) *** read_module (void) *** 3627,3632 --- 3661,3674 } else { + st = gfc_find_symtree (gfc_current_ns-sym_root, name); + + /* Make symtree inaccessible by renaming if the symbol has +been added by a USE statement without an ONLY(11.3.2). */ + if (st st-name == st-n.sym-name + strcmp (st-n.sym-module, module_name) == 0) + st-name = gfc_get_string (hidden.%s, name); + /* Create a symtree node in the current namespace for this symbol. */ st = check_unique_name (p) Index: gcc/testsuite/gfortran.dg/use_only_1.f90 === *** gcc/testsuite/gfortran.dg/use_only_1.f90(révision 0) --- gcc/testsuite/gfortran.dg/use_only_1.f90(révision 0) *** *** 0 --- 1,31 + ! { dg-do run } + ! { dg-options -O1 } + ! Checks the fix for PR33541, in which a requirement + ! of F95 11.3.2 was not being met: The local names + ! 'x' and 'y' coming from the USE statements without + ! an ONLY clause should not survive in the presence + ! of the locally renamed versions. + ! + ! Reported by Reported by John Harper in + ! http://gcc.gnu.org/ml/fortran/2007-09/msg00397.html + ! + MODULE xmod + integer(4) :: x = -666 + END MODULE xmod + + MODULE ymod + integer(4) :: y = -666 + END MODULE ymod + + PROGRAM test2uses + USE xmod + USE xmod, ONLY: xrenamed = x + USE ymod, ONLY: yrenamed = y + USE ymod + implicit integer(2) (a-z) + x = 666 ! These assignments should generate implicitly typed + y = 666 ! local variable 'x' and 'y'. + if (kind(xrenamed) == kind(x)) call abort () + if (kind(yrenamed) == kind(y)) call abort () + END PROGRAM test2uses + ! { dg-final { cleanup-modules xmod ymod } } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541
[Bug libstdc++/33491] parallel v3: add some documentation
-- singler at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |singler at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-19 16:58:05 |2007-11-15 10:05:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33491
[Bug libstdc++/34106] New: [parallel mode] Atomic operations compatibility layer needs cleanup
In compatibility.h, there are a lot of compiler- and architecture dependent switches. Relying on the GCC atomic operations would make this much cleaner. -- Summary: [parallel mode] Atomic operations compatibility layer needs cleanup Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: singler at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106
[Bug libstdc++/33892] [libstdc++ v3 parallel mode] Parallel mode algorithms use critical sections with global scope
--- Comment #8 from singler at gcc dot gnu dot org 2007-11-15 10:10 --- Closing this bug, the compatibility.h issues are tracked in PR 34106. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33892
[Bug libstdc++/34106] [parallel mode] Atomic operations compatibility layer needs cleanup
-- singler at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |singler at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 10:11:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34106
[Bug libstdc++/33490] parallel v3: std::accumulate assumes iterators have std::iterator_traits declared
-- singler at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33490
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-15 10:21 --- Confirmed. Shorter testcase: #include complex #include iostream typedef std::complexdouble NumType; void multiply(NumType a, NumType b, unsigned ac, NumType ab) { NumType s; for (unsigned j=0; jac; j++) s = a * b; ab = s; } int main() { NumType a(1,2), b(3,-2), c; multiply(a, b, 1, c); std::cout c std::endl; return 0; } Looks like another SRA problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.0 Known to work||4.2.2 Last reconfirmed|-00-00 00:00:00 |2007-11-15 10:21:31 date|| Summary|optimizer problem |[4.3 Regression] optimizer ||problem Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug fortran/34107] New: seg fault when writing into character variable when code compiled with -maling-double
I'm using the latest (precompiled) version of gfortran (GNU Fortran (GCC) 4.3.0 20071105 (experimental) [trunk revision 129892]). The following code: program test integer :: pid character (len=10) :: chpid pid=12345 write(chpid,'(i10)')pid write(*,*)chpid is ,chpid end program test when compiled with: gfortran -o test.gfortran90 -g -malign-double ./test.f90 on my ubuntu box (Ubuntu 6.06.1 LTS, Intel(R) Pentium(R) 4 CPU 2.80GHz), seg faults as shown below: Program received signal SIGSEGV, Segmentation fault. 0xb7f86f46 in next_char (fmt=0x8050528, literal=0) at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:91 91 /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c: No such file or directory. in /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c (gdb) bt #0 0xb7f86f46 in next_char (fmt=0x8050528, literal=0) at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:91 #1 0xb7f86fb1 in format_lex (fmt=0x8050528) at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:181 #2 0xb7f87c65 in *_gfortrani_parse_format (dtp=0xbfbc1aa8) at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/format.c:981 #3 0xb7f91e69 in data_transfer_init (dtp=0xbfbc1aa8, read_flag=0) at /home/fx/gfortran_nightbuild/trunk/libgfortran/io/transfer.c:1802 #4 0x08048616 in test () at ./test.f90:7 If I remove the -malign-double flag, the code runs fine. The same code in FORTRAN77 format works fine with g77 (with the -malign-double flag), but also crashes gfortran. -- Summary: seg fault when writing into character variable when code compiled with -maling-double Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j dot m dot h dot thomas at dl dot ac dot uk GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107
[Bug fortran/31124] Warn of unused PRIVATE module variables/procedures
--- Comment #2 from terry at chem dot gu dot se 2007-11-15 10:19 --- *** Bug 34092 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124
[Bug fortran/34092] Should warn about unused private variables
--- Comment #2 from terry at chem dot gu dot se 2007-11-15 10:19 --- (In reply to comment #1) Duplicate of PR 31124 ? Yar. I was misled the last time by the fact that PR 31129 also existed. The parameter case has been fixed, but not the private case. *** This bug has been marked as a duplicate of 31124 *** -- terry at chem dot gu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34092
[Bug fortran/31124] Warn of unused PRIVATE module variables/procedures
--- Comment #3 from terry at chem dot gu dot se 2007-11-15 10:27 --- (In reply to comment #2) *** Bug 34092 has been marked as a duplicate of this bug. *** So, to summarise: Unused parameters have been fixed in general, but unused private module entities remain undetected (as of 4.3.0 20071109). (There must surely be a piece of code excluding module variables from unused warnings? That needs to be taught about the private attribute.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31124
[Bug libstdc++/33893] [parallel mode] Algorithms rely on omp_set_dynamic(false)
-- singler at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |singler at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 10:11:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33893
[Bug c++/34100] [4.3 regression] ICE with vector attribute
--- Comment #1 from jakub at gcc dot gnu dot org 2007-11-15 11:17 --- Testing a fix. -- 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-11-15 11:17:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34100
[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed
--- Comment #4 from pault at gcc dot gnu dot org 2007-11-15 11:16 --- (In reply to comment #3) Bother, the patch causes some regressions (interface_[3-5].f90)... Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541
[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double
--- Comment #3 from pault at gcc dot gnu dot org 2007-11-15 11:58 --- (In reply to comment #2) -malign-double changes the ABI. You need to rebuild libgfortran with that option. Ah! Thanks, Richard. For that, I'll take a look at achar_4.f90 for you:) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #1 from pcarlini at suse dot de 2007-11-15 11:59 --- Note that the issue is unrelated to the header optimization work: is caused by algorithmfwd.h, added in the occasion of the parallel STL work. I'm going to look a bit into it, anyway, if a simple solution I have in mind will not work, will forward to Benjamin. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 11:59:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #5 from eres at il dot ibm dot com 2007-11-15 12:04 --- It seems that verify_flow_info complains about the following note, which is generated in the partitioning phase: (note 234 232 172 11 NOTE_INSN_SWITCH_TEXT_SECTIONS) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug fortran/34108] New: ICE: Segmentation fault occurs by write(*,0) statement
I use gfortran on cygwin. % wget http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.3-Cygwin-i686.tar.bz2 % tar fjx gfortran-4.3-Cygwin-i686.tar.bz2 -C / I get a segmentation fault when compiling program contains a simple write statement. % cat zerolabel.f95 write(*,0) % /usr/local/gfortran/bin/gfortran.exe -v zerolabel.f95 Driving: /usr/local/gfortran/bin/gfortran -v zerolabel.f95 -lgfortranbegin -lgfortran Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc43/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp : (reconfigured) ../gcc43/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --disable-bootstrap --enable-threads=posix --enable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-nls --disable-libmudflap --disable-shared --disable-win32-registry --with-system-zlib --enable-checking=release --enable-werror --without-included-gettext --without-x --enable-libgomp Thread model: posix gcc version 4.3.0 20071005 (experimental) [trunk revision 127783] (GCC) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' /usr/local/gfortran/libexec/gcc/i686-pc-cygwin/4.3.0/f951.exe zerolabel.f95 -quiet -dumpbase zerolabel.f95 -mtune=generic -auxbase zerolabel -version -fintrinsic-modules-path /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.3.0/finclude -o /tmp/ccbbRPye.s GNU F95 (GCC) version 4.3.0 20071005 (experimental) [trunk revision 127783] (i686-pc-cygwin) compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 zerolabel.f95:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: Segmentation fault occurs by write(*,0) statement Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fujimura at giga dot it dot okayama-u dot ac dot jp GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34108
[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double
--- Comment #1 from pault at gcc dot gnu dot org 2007-11-15 10:54 --- Jens, I cannot reproduce this bug, even with the same flags that you are using, under Cygwin_NT and last night's build. I will check on a Linux system tonight. I have downrated the severity because critical refers to bugs that prevent the gcc build. I assure you that the gfortran maintainers will take the report just as seriously. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-15 12:21 --- I can't reproduce this on x86*. Again, please attach the profile information and state the exact compiler revision you used to generate this profile information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #7 from eres at il dot ibm dot com 2007-11-15 12:29 --- (In reply to comment #6) I can't reproduce this on x86*. Again, please attach the profile information and state the exact compiler revision you used to generate this profile information. Sorry - I am working on r129702. What do you mean by profile information (a dump file)? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug fortran/33917] Rejects valid PROCEDURE declarations
--- Comment #9 from patchapp at dberlin dot org 2007-11-15 12:35 --- Subject: Bug number PR33917 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00842.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #5 from pcarlini at suse dot de 2007-11-15 13:10 --- I meant bits/stl_algobase.h, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-15 11:26 --- -malign-double changes the ABI. You need to rebuild libgfortran with that option. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #3 from pcarlini at suse dot de 2007-11-15 13:06 --- Something like the attached (lightly tested) fixed the problem for normal mode, the error becomes: 34105.cc: In function int main(): 34105.cc:8: error: find is not a member of std however, it doesn't for parallel mode. I think it's better if Benjamin looks into those headers... -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #4 from pcarlini at suse dot de 2007-11-15 13:09 --- By the way, while we are talking about those QoI issues, I think it's in any case better not including something like algorithmfwd.h in algobase.h: it's relatively big and we are doing our best to keep algobase.h, the core algorithmic facilities optimized for internal use, as minimal as possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug java/21206] gcj seems not to pass the option to ld correctly
--- Comment #18 from tom_francen at midtechcorp dot com 2007-11-15 13:46 --- Subject: Re: gcj seems not to pass the option to ld correctly thank you wilson ... i just tried suggestion #6 ... and it WORKED!! thank you very much!! tjf --- Thomas James Francen Midwest Technologies Corporation http://www.midtechcorp.com - website +1.303.898.6300 - Cell / Voicemail +1.610.887.5155 - Fax --- [EMAIL PROTECTED] wrote: From: wilson at tuliptree dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug java/21206] gcj seems not to pass the option to ld correctly Date: 14 Nov 2007 23:46:07 - --- Comment #17 from wilson at tuliptree dot org 2007-11-14 23:46 --- Subject: Re: gcj seems not to pass the option to ld correctly On Wed, 2007-11-14 at 23:16 +, tom_francen at midtechcorp dot com wrote: i'm receiving a very similar error under solaris 2.10, binutils and core utils (latest versions), gnu make, etc. gcc 4.1.2 built fine ... gcc 4.2.1 and 4.2.2 fail with the same error below ... You can try the workaround I gave in comment #6. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206
[Bug c++/34104] auto_ptr error catching
--- Comment #1 from pcarlini at suse dot de 2007-11-15 13:32 --- intptr is not initialized: when i is destructed it calls delete on the owned pointer, that is intptr, and anything can happen. Just initialize intptr to zero or to a value returned by new. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34104
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #8 from eres at il dot ibm dot com 2007-11-15 14:17 --- When disabling rest_of_handle_reorder_blocks (bbro) the ICE disappears. (it seems that it is not caused due to the partitioning - bbpart) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #2 from pcarlini at suse dot de 2007-11-15 13:04 --- Created an attachment (id=14555) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14555action=view) Draft patch for normal mode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #9 from steven at gcc dot gnu dot org 2007-11-15 14:49 --- I mean the files you generate with -fprofile-generate. I expect this to be fully blamable on the partitioning code, and I would like to work in fixing this. But you have to attach the profile information you have generated, or no-one can debug this unless he/she has access to POWER. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #11 from eres at il dot ibm dot com 2007-11-15 15:05 --- Created an attachment (id=14556) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14556action=view) File generated by -fprofile-generate -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-15 14:56 --- Uhm, this goes wrong in CCP. (w/o SRA the failure doesn't trigger though) Before CCP we have: void multiply(NumType, NumType, unsigned int, NumType) (a, b, ac, ab) { double s$_M_value$real; double s$_M_value$imag; double b$_M_value$real; double b$_M_value$imag; double a$_M_value$imag; double a$_M_value$real; complex double __t; complex double D.26933; complex double D.26932; double D.26931; double D.26929; unsigned int j; bb 2: # VUSE SFT.90_33(D) a$_M_value$real_21 = REALPART_EXPR a._M_value; # VUSE SFT.91_34(D) a$_M_value$imag_22 = IMAGPART_EXPR a._M_value; # VUSE SFT.93_35(D) b$_M_value$imag_23 = IMAGPART_EXPR b._M_value; # VUSE SFT.92_36(D) b$_M_value$real_24 = REALPART_EXPR b._M_value; s$_M_value$real_25 = 0.0; s$_M_value$imag_26 = 0.0; goto bb 4; bb 3: D.26929_10 = IMAGPART_EXPR __t_6(D); __t_11 = COMPLEX_EXPR b$_M_value$real_24, D.26929_10; D.26931_13 = REALPART_EXPR __t_11; __t_14 = COMPLEX_EXPR D.26931_13, b$_M_value$imag_23; D.26932_15 = COMPLEX_EXPR a$_M_value$real_21, a$_M_value$imag_22; D.26933_16 = __t_14 * D.26932_15; s$_M_value$imag_17 = IMAGPART_EXPR D.26933_16; s$_M_value$real_18 = REALPART_EXPR D.26933_16; j_4 = j_1 + 1; bb 4: # s$_M_value$real_20 = PHI s$_M_value$real_25(2), s$_M_value$real_18(3) # s$_M_value$imag_19 = PHI s$_M_value$imag_26(2), s$_M_value$imag_17(3) # j_1 = PHI 0(2), j_4(3) if (j_1 ac_3(D)) goto bb 3; else goto bb 5; bb 5: # SMT.98_38 = VDEF SMT.98_37(D) IMAGPART_EXPR ab_5(D)-_M_value = s$_M_value$imag_19; # SMT.98_39 = VDEF SMT.98_38 REALPART_EXPR ab_5(D)-_M_value = s$_M_value$real_20; return; } where I can see nothing wrong. Now CCP propagates s$_M_value$real_25 and s$_M_value$imag_26 into the PHI nodes, but somehow does not simulate BB3: Visiting PHI node: s$_M_value$real_20 = PHI s$_M_value$real_25(2), s$_M_value$real_18(3) Argument #0 (2 - 4 executable) s$_M_value$real_25 Value: CONSTANT 0.0 Argument #1 (3 - 4 executable) s$_M_value$real_18 Value: UNDEFINED PHI node value: CONSTANT 0.0 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug fortran/33541] gfortran wrongly imports renamed-use-associated symbol unrenamed
--- Comment #5 from pault at gcc dot gnu dot org 2007-11-15 15:19 --- (In reply to comment #4) (In reply to comment #3) Bother, the patch causes some regressions (interface_[3-5].f90)... Paul These were easily fixed - also nested_modules_1.f90 was not standard compliant in this regard. It now regtests with find_symbol modified to: c = strcmp (name, st-n.sym-name); if (c == 0 st-n.sym-module strcmp (module, st-n.sym-module) == 0) return st; Off to generics and operators now! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541
[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-15 15:10 --- See also: http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html and for the patch: http://gcc.gnu.org/ml/fortran/2007-11/msg00093.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 15:10:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-15 15:08 --- This looks like this old bug that evaluate_stmt() sets results to UNDEFINED. As we visit D.26933_16 = __t_14 * D.26932_15; the result should become VARYING, but we make it UNDEFINED. Because also likely_value () returns UNDEFINED for it. Because in the process of setting __t we use undefined operands (but those get overwritten). D.26929_10 = IMAGPART_EXPR __t_6(D); __t_11 = COMPLEX_EXPR b$_M_value$real_24, D.26929_10; D.26931_13 = REALPART_EXPR __t_11; __t_14 = COMPLEX_EXPR D.26931_13, b$_M_value$imag_23; D.26932_15 = COMPLEX_EXPR a$_M_value$real_21, a$_M_value$imag_22; D.26933_16 = __t_14 * D.26932_15; so at least has_constant_operand = false; FOR_EACH_SSA_TREE_OPERAND (use, stmt, iter, SSA_OP_USE | SSA_OP_VUSE) { prop_value_t *val = get_value (use); if (val-lattice_val == UNDEFINED) return UNDEFINED; if (val-lattice_val == CONSTANT) has_constant_operand = true; } doesn't look conservatively correct, because we pro-actively prefer UNDEFINED here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug middle-end/20675] Small targets without 64 bit long long support are can't bootstrap GCC.
--- Comment #8 from manu at gcc dot gnu dot org 2007-11-15 15:39 --- What happened to this patch? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20675
[Bug fortran/33917] Rejects valid PROCEDURE declarations
--- Comment #11 from burnus at gcc dot gnu dot org 2007-11-15 15:18 --- FIXED on the trunk (4.3.0) [is not part of any branch]. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED GCC build triplet|x86_64-unknown-linux-gnu| Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-15 15:40 --- That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the constraint that if one operand is UNDEFINED the result is UNDEFINED as well. For example MIN_EXPR INT_MIN, UNDEFINED, or MAX_EXPR INT_MAX, UNDEFINED are of such kind as well. No idea if we want a white-list here instead. BIT_AND_EXPR UNDEFINED, 0 is also not UNDEFINED. (all of the above not with actual constants as defined arg, but VARYING ones) I have a patch. -- 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|2007-11-15 10:21:31 |2007-11-15 15:40:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #7 from rguenther at suse dot de 2007-11-15 15:51 --- Subject: Re: [4.3 Regression] optimizer problem On Thu, 15 Nov 2007, ebotcazou at gcc dot gnu dot org wrote: --- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-15 15:44 --- That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the constraint that if one operand is UNDEFINED the result is UNDEFINED as well. Is the problem somehow related to PR middle-end/33088? It looks like so, but I cannot reproduce the problem in PR33088. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug fortran/34107] seg fault when writing into character variable when code compiled with -maling-double
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-15 14:57 --- There is a good chance that if you try to build the runtime library with malign-double that you will break it. My recommendation is don't use -malign-double for I/O related things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34107
[Bug middle-end/33088] [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-15 15:53 --- I cannot reproduce this problem with any of 4.1, 4.2 or 4.3. But the issues raised look related the CCP problem in PR34099. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
[Bug rtl-optimization/34085] ICE with -freorder-blocks-and-partition
--- Comment #10 from eres at il dot ibm dot com 2007-11-15 15:02 --- (In reply to comment #9) I mean the files you generate with -fprofile-generate. I expect this to be fully blamable on the partitioning code, and I would like to work in fixing this. But you have to attach the profile information you have generated, or no-one can debug this unless he/she has access to POWER. Sure, I'll attached the gcno file. Please let me know if you need more information to retore the ICE. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-15 16:04 --- Which doesn't work :( Unassigning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-15 16:06 --- Created an attachment (id=14557) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14557action=view) broken patch It miscompiles gengtype. I remember problems with changing likely_value in similar ways back in time. The other option is to not ignore UNDEFINED lattice values in ccp_lattice_meet but do any M UNDEFINED = VARYING instead of any M UNDEFINED = any -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-15 16:08 --- Created an attachment (id=14558) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14558action=view) new broken patch Err, that was an old patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #14557|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug fortran/33917] Rejects valid PROCEDURE declarations
--- Comment #10 from burnus at gcc dot gnu dot org 2007-11-15 15:12 --- Subject: Bug 33917 Author: burnus Date: Thu Nov 15 15:12:03 2007 New Revision: 130202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130202 Log: 2007-11-15 Tobias Burnus [EMAIL PROTECTED] PR fortran/33917 * decl.c (match_procedure_decl): Pre-resolve interface. * resolve.c (resolve_symbol): Reject interfaces later declared in procedure statements. 2007-11-15 Tobias Burnus [EMAIL PROTECTED] PR fortran/33917 * gfortran.dg/proc_decl_11.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33917
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-15 15:44 --- That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the constraint that if one operand is UNDEFINED the result is UNDEFINED as well. Is the problem somehow related to PR middle-end/33088? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug bootstrap/34110] New: gcc fails to build on i686
SVN head does not build due to a warning that is treated as error. gcc.build.lnx/./prev-gcc/xgcc -B/gcc-b98ac6987827a195a1492167a9a158bf/gcc.build.lnx/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror-DHAVE_CONFIG_H -I. -I. -I../../gcc-svn/gcc -I../../gcc-svn/gcc/. -I../../gcc-svn/gcc/../include -I../../gcc-svn/gcc/../libcpp/include -I../../gcc-svn/gcc/../libdecnumber -I../../gcc-svn/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc-svn/gcc/regclass.c -o regclass.o cc1: warnings being treated as errors ../../gcc-svn/gcc/reg-stack.c: In function 'swap_to_top': cc1: error: array subscript is below array bounds make[3]: *** [reg-stack.o] Error 1 -- Summary: gcc fails to build on i686 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: us15 at os dot inf dot tu-dresden dot de GCC build triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34110
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 16:19 --- Is this still a valid bug? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug c/34109] New: Incorrect code for tail calls with a structure as 4th argument
In the following code, the tail call in g() is compiled incorrectly on ARM with -O2 or higher (and -fno-inline): #include stdio.h struct s { int x, y, z; }; int f(int a, int b, int c, struct s d, int e) { printf(%d %d %d\n, d.x, d.y, d.z); return 0; } int g(int a, int b, int c, int d, struct s e, int h) { return f(a, b, c, e, h); } int main(void) { f(0, 0, 0, (struct s){ 42, 69, 105 }, 7); g(0, 0, 0, 0, (struct s){ 42, 69, 105 }, 7); return 0; } With -O1 and lower, the result is correct: 42 69 105 42 69 105 With -O2 and higher, it prints: 42 69 105 69 69 7 Inspecting the output of gcc -O3 -fno-inline -S shows that gcc is shifting the arguments on the stack downwards for the tail call. However, it starts at the top, rather than at the bottom. So it writes over two arguments (e.z and e.x) before loading them. This has been broken since 4.1.1 (possibly earlier), and is still broken in 4.2.2. -- Summary: Incorrect code for tail calls with a structure as 4th argument Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: narge-gcc at derrin dot id dot au GCC target triplet: arm-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109
[Bug c++/21393] Internal error: Segmentation Fault (program cc1plus) on a very long cout ... command
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-15 16:39 --- It also works in GCC 4.3.0. If you still experience this issue, please, don't hesitate to reopen the bug. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21393
[Bug c++/21146] unable to resolve visible symbol
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-15 16:30 --- So, is this a bug or not? Do we know how icc resolves the ambiguity? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21146
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-11-15 16:38 --- Oh, trivial error. Looking again tomorrow. -- 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|2007-11-15 15:40:13 |2007-11-15 16:38:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug c++/34111] New: new oveload resolution error
this used to work a few days ago still: -- Summary: new oveload resolution error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mueller at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug driver/26016] using -S on a .S file does not work properly
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-15 17:16 --- Confirmed. Probably some issue with the default specs. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 17:16:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26016
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-11-15 17:17 --- I think this has been caused by the fix for PR29738. Author: rakdver Date: Thu Nov 9 00:09:43 2006 New Revision: 118602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118602 Log: PR tree-optimization/29738 * tree-ssa-ccp.c: Remove UNKNOWN_VAL from comments. (ccp_lattice_t): Remove UNKNOWN_VAL. (dump_lattice_value, ccp_lattice_meet, ccp_visit_phi_node): Do not handle UNKNOWN_VAL. (get_default_value): Set initial value of virtual operands to VARYING. (get_value): Always use get_default_value on uninitialized operands. (set_value_varying, surely_varying_stmt_p): New functions. (set_lattice_value): Do not pass argument to get_value. Do not handle UNKNOWN_VAL. (likely_value): Follow the semantics described in the comment. (ccp_initialize): Use surely_varying_stmt_p. Do not mark phi nodes DONT_SIMULATE_AGAIN. (ccp_fold): Do not pass argument to get_value. (fold_const_aggregate_ref, visit_assignment): Ditto. Do not handle UNKNOWN_VAL. * gcc.dg/tree-ssa/ssa-ccp-14.c: New test. * gcc.dg/tree-ssa/ssa-ccp-15.c: New test. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||29738 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug c++/21361] sizeof() packed structs potential errors
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 16:45 --- Closing then. (The link you gave is broken. A more stable link is http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html ) -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21361
[Bug middle-end/21474] missed optimizations when comparing address to NULL
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-15 17:03 --- I think it is odd that if you call subr(i,0), it doesn't crash, that is (p-a) does not actually dereferences p. Nonetheless, I agree that the behaviour seems inconsistent. A nice little project for someone. As they say, patches welcome! -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-11-15 17:03:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474
[Bug c++/21603] C++ front-end accepts new with VLAs
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 17:05 --- This is confirmed. -- manu 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-11-15 17:05:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21603
[BUG] GCC 4.1 bug - Optimization breaks variables of type double
Hi, When I compile my program without optimization (-O2 or -O3), it works normally. However when I compile the code with -O2 or -O3 (GCC version 4.1), my program output wrong data. In addition, I did not see this problem when I used GCC 3.4.6. Information regarding my GCC: OS: Centos 5 (a clone of Redhat Enterprise 5) GCC: 4.1.1 20070105 (Red Hat 4.1.1-52) Command: gcc -g -Wall gensvmparams.c -lm -o gensvmparams gcc -g -Wall -O2 gensvmparams -c -lm -o gensvmparams My code: #include stdio.h #include stdlib.h #include math.h int main() { double g = pow(2, -7); double c = 2; double cc = 1; double gg = -7; double cMax; cMax = pow(2,5); cMax = cMax + 0.01; double gMax; gMax = pow(2,-3); gMax = gMax + 0.01; while (c cMax) //gcc -O2 change the cMax to something different than 32 { gg = -7; g = pow(2, -7); while (g gMax) { printf(5 %lf %lf\n, c, g); gg = gg + 0.25; g = pow(2, gg); } cc = cc + 0.25; c = pow(2, cc); } return 0; } P.S: When I add volatile to the declaration of cMax and gMax, my program works correctly for all cases. Thanks, Regards, Le Thanh Trung
[Bug c++/34111] new oveload resolution error
--- Comment #1 from mueller at gcc dot gnu dot org 2007-11-15 16:55 --- Created an attachment (id=14559) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14559action=view) the preprocessed source .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
[Bug fortran/34079] Bind(C): Don't pass the string length as argument (for STDCALL)
--- Comment #4 from patchapp at dberlin dot org 2007-11-15 15:10 --- Subject: Bug number PR34079 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00851.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34079
[Bug middle-end/20983] [4.0/4.1/4.2/4.3 Regression] varargs functions force va_list variable to stack unnecessarily
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-15 17:42 --- Testing a patch which addresses the simple pointer va_list targets (i386, non-v4-abi ppc{,64}, etc.). -- 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|NEW |ASSIGNED Last reconfirmed|2006-07-05 09:23:01 |2007-11-15 17:42:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20983
[Bug fortran/34108] ICE: Segmentation fault occurs by write(*,0) statement
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-15 16:40 --- Confirmed on x86_64-linux, where it triggers (with valgrind): ==2841== Conditional jump or move depends on uninitialised value(s) ==2841==at 0x43550B: next_char (io.c:141) ==2841==by 0x435616: next_char_not_space (io.c:183) ==2841==by 0x4356C1: format_lex (io.c:221) ==2841==by 0x435A5D: check_format (io.c:467) ==2841==by 0x4369B5: match_io (io.c:927) ==2841==by 0x44D8A9: match_word (parse.c:64) ==2841==by 0x44E078: decode_statement (parse.c:296) ==2841==by 0x44EA84: next_statement (parse.c:505) ==2841==by 0x451EC4: gfc_parse_file (parse.c:3320) ==2841==by 0x479B64: gfc_be_parse_file (f95-lang.c:258) ==2841==by 0x6E901C: toplev_main (toplev.c:1042) ==2841==by 0x4B3B4C9: (below main) (in /usr/lib/debug/libc-2.3.6.so) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC host triplet|i686-pc-cygwin | GCC target triplet|i686-pc-cygwin | Keywords||ice-on-invalid-code Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-11-15 16:40:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34108
[Bug other/19180] How to Add New GCC option
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 17:41 --- *** Bug 26168 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||phr-gcc at nightsong dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180
[Bug driver/26168] improve comment about adding command line options
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 17:41 --- *** This bug has been marked as a duplicate of 19180 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26168
[Bug driver/26016] using -S on a .S file does not work properly
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 17:35 --- This patch is just a guess but it seems to fix this: Index: gcc/gcc.c === --- gcc/gcc.c (revision 130174) +++ gcc/gcc.c (working copy) @@ -841,9 +841,9 @@ static const char *invoke_as = #ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT -%{!S:-o %|.s |\n as %(asm_options) %|.s %A }; +%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n as %(asm_options) %|.s %A }; #else -%{!S:-o %|.s |\n as %(asm_options) %m.s %A }; +%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n as %(asm_options) %m.s %A }; #endif /* Some compilers have limits on line lengths, and the multilib_select @@ -1029,12 +1029,12 @@ #ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT %(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\ %{E|M|MM:%(cpp_debug_options)}\ - %{!M:%{!MM:%{!E:%{!S:-o %|.s |\n\ + %{!M:%{!MM:%{!E:%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n\ as %(asm_debug) %(asm_options) %|.s %A #else %(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\ %{E|M|MM:%(cpp_debug_options)}\ - %{!M:%{!MM:%{!E:%{!S:-o %|.s |\n\ + %{!M:%{!MM:%{!E:%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %|.s |\n\ as %(asm_debug) %(asm_options) %m.s %A #endif , 0, 1, 0}, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26016
[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-15 19:25 --- For stdcall and @n decoration, see also PR 31073. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112
[Bug c/34113] New: ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746
while compiling xorg-server-1.4 with GCC trunk rev 130172. x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I../include -I../include -I../Xext -I../composite -I../damageext -I../xfixes -I../Xi -I../mi -I../miext/shadow -I../miext/damage -I../render -I../randr -I../fb -O2 -g -march=native -fomit-frame-pointer -pipe -MT access.lo -MD -MP -MF .deps/access.Tpo -c access.c -fPIC -DPIC -o .libs/access.o access.c: In function 'siHostnameAddrMatch': access.c:2115: warning: assignment from incompatible pointer type access.c: In function 'InvalidHost': access.c:1767: warning: 'addr' may be used uninitialized in this function access.c: In function 'DefineSelf': access.c:718: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1746 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [access.lo] Error 1 # gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.0_pre20071113/work/gcc-4.3.0-20071113/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-pre20071113 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.3.0-pre20071113 (experimental) (GCC) -- Summary: ICE in get_addr_dereference_operands, at tree-ssa- operands.c:1746 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirtyepic at gentoo dot org GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #8 from pcarlini at suse dot de 2007-11-15 19:07 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug bootstrap/34110] gcc fails to build on i686
--- Comment #1 from mueller at gcc dot gnu dot org 2007-11-15 18:21 --- temp_stack.reg[i_90] is the access, compare_for_stack_reg is the function, and i_90 has the VRP determined range [-1, 2147483646]. it shouldn't warn for that. I'll work on a patch. -- mueller 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-11-15 18:21:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34110
[Bug fortran/34112] New: Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL
32bit Windows uses a different calling convention (called procedure pops the stack, not caller) with a symbol name _name@n, where n is the number of bytes to pop off. See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58 http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html As the standard makes not provisions and !DEC$ (*DEC$, cDEC$) is widely used, gfortran should accept the following: function CallWndRetProc(nCode, wParam, lParam) !DEC$ ATTRIBUTES STDCALL,DECORATE, ALIAS: 'CallWndRetProc' :: CallWndRetProc end function Documentation: http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattcst.htm http://www.intel.com/software/products/compilers/docs/fmac/doc_files/source/extfile/lref_for/source_files/rfattrib.htm They seem to map to (http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html): STDCALL - __attribute__(stdcall) ALIAS- __attribute__(alias(name)) DECORATE - ? The problem with decorate is that its meaning depends on the platform. It may decorate the name of alias with a _ prefix and @n postfix or only with a _ prefix. Maybe one should start with STDCALL and ALIAS. For alias one should do something as in c-pragma.c's apply_pragma_weak: decl_attributes (decl, build_tree_list (get_identifier (alias), build_tree_list (NULL, value)), 0); -- Summary: Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement 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=34112
[Bug c/34113] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746
--- Comment #1 from dirtyepic at gentoo dot org 2007-11-15 19:34 --- Created an attachment (id=14560) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14560action=view) access-min.i preprocessed source reduced by delta. # gcc -v -O2 access-min.i Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.0_pre20071113/work/gcc-4.3.0-20071113/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.0-pre20071113 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.0-pre20071113/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.3.0-pre20071113 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-mtune=generic' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.0-pre20071113/cc1 -fpreprocessed access-min.i -quiet -dumpbase access-min.i -mtune=generic -auxbase access-min -O2 -version -o /tmp/cc45MInZ.s GNU C (GCC) version 4.3.0-pre20071113 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 4.3.0-pre20071113 (experimental), GMP version 4.2.2, MPFR version 2.3.0-p3. GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128180 Compiler executable checksum: bdea9186cf5370f8e72d4207bcebdb8c access-min.i:38: warning: data definition has no type or storage class access-min.i:152: warning: 'struct stat64' declared inside parameter list access-min.i:152: warning: its scope is only this definition or declaration, which is probably not what you want access-min.i:155: warning: 'struct stat64' declared inside parameter list access-min.i:183: warning: '__transparent_union__' attribute ignored access-min.i:320: warning: 'struct cmsghdr' declared inside parameter list access-min.i:322: warning: 'struct cmsghdr' declared inside parameter list access-min.i:325: warning: 'struct cmsghdr' declared inside parameter list access-min.i:355: warning: 'struct rpcent' declared inside parameter list access-min.i:357: warning: 'struct rpcent' declared inside parameter list access-min.i:381: warning: 'struct protoent' declared inside parameter list access-min.i:405: warning: parameter names (without types) in function declaration access-min.i:483: warning: parameter names (without types) in function declaration access-min.i:502: warning: parameter names (without types) in function declaration access-min.i: In function 'ResetHosts': access-min.i:610: warning: assignment makes pointer from integer without a cast access-min.i:611: warning: assignment makes pointer from integer without a cast access-min.i: In function 'siTypeAdd': access-min.i:736: warning: incompatible implicit declaration of built-in function 'strlen' access-min.i: In function 'siCheckAddr': access-min.i:747: warning: incompatible implicit declaration of built-in function 'strlen' access-min.i: In function 'siHostnameAddrMatch': access-min.i:760: warning: assignment makes pointer from integer without a cast access-min.i: In function 'siLocalCredGetId': access-min.i:798: warning: initialization makes pointer from integer without a cast access-min.i:804: warning: initialization makes pointer from integer without a cast access-min.i: In function 'AccessUsingXdmcp': access-min.i:560: internal compiler error: in get_addr_dereference_operands, at tree-ssa-operands.c:1746 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113
[Bug tree-optimization/34099] [4.3 Regression] optimizer problem
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-11-15 17:10 --- Trivial testcase we get wrong with the current scheme: int foo (int b, int c) { int x; if (b) return x c; else return 1; } extern void abort (void); int main() { if (foo(1, 0) != 0) abort (); return 0; } because we say that x c is UNDEFINED (and so ignore its value in the otherwise CONSTANT PHI). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34099
[Bug middle-end/26544] printf calls optimized at -O0
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 17:43 --- This is either a bug or not. I think that if it is not mere constant folding and it takes some effort, we should not do it. So let's decide so we can either confirm it or close it as invalid. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26544
[Bug other/19180] How to Add New GCC option
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-15 17:40 --- From bug 26168: gcc/gcc.c has a comment at the top that's a guide to adding a command line option. It's incomplete: it should say to add the new option to c.opt and rebuild the compiler, and then describe how the variable OPT_whatever gets created by the awk scripts during the build process, so you can then check for the option elsewhere in the compiler. That mechanism doesn't appear documented at all, and took me a while to figure out through code tracing. Some description in the comment would have been a big help. Also, the comment at the top of the automatically-generated options.c file says it's generated by opts.sh rather than by those awk scripts. That's a minor thing but updating it wouldn't hurt. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180
[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-15 18:53 --- I think this is already fixed in 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34109
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #7 from paolo at gcc dot gnu dot org 2007-11-15 19:05 --- Subject: Bug 34105 Author: paolo Date: Thu Nov 15 19:05:17 2007 New Revision: 130207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130207 Log: 2007-11-15 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/34105 * include/bits/stl_algobase.h: Do not include bits/algorithmfwd.h. (lexicographical_compare(const unsigned char*, const unsigned char*, const unsigned char*, const unsigned char*), lexicographical_compare(const char*, const char*, const char*, const char*)): Move to namespace (std, _GLIBCXX_STD_P). * include/parallel/algobase.h: Do not include bits/algorithmfwd.h. (equal): Move after mismatch. * include/bits/stl_heap.h (is_heap, is_heap_until): Reorder. * include/bits/char_traits.h: Include bits/stl_algobase.h instead of bits/algorithmfwd.h. * include/bits/stl_algo.h: Include first bits/algorithmfwd.h. * include/bits/algorithmfwd.h (lexicographical_compare): Do not declare overloads. * include/parallel/partition.h: Include parallel/random_number.h. * testsuite/util/testsuite_abi.cc: Include algorithm. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/algorithmfwd.h trunk/libstdc++-v3/include/bits/char_traits.h trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h trunk/libstdc++-v3/include/bits/stl_heap.h trunk/libstdc++-v3/include/parallel/algobase.h trunk/libstdc++-v3/include/parallel/partition.h trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug middle-end/23848] [4.0/4.1/4.2 Regression] stack deallocation can be more efficient
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-15 19:37 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |stack deallocation can be |stack deallocation can be |more efficient |more efficient http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848
[Bug c/34114] New: Missed optimization: cannot determine loop termination
As far as I can see the loop in the function f() always terminates without the loop counter overflowing, but GCC cannot tell that it does. $ g++-4.3-20070907 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907 --enable-language=c,c++ --prefix=/home/jack/opt --with-mpfr=/home/jack/opt Thread model: posix gcc version 4.3.0 20070907 (experimental) (GCC) $ cat no_loop_opt.c void f(unsigned int in) { unsigned int rnd_to_2 = (in - (in % 2)); unsigned int i; for(i = 0; i != rnd_to_2; i += 2) ; } $ gcc-4.3-20070907 -O2 -Wall -Wextra -Wunsafe-loop-optimizations -c no_loop_opt.c no_loop_opt.c: In function f: no_loop_opt.c:7: warning: cannot optimize loop, the loop counter may overflow -- Summary: Missed optimization: cannot determine loop termination Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lloyd at randombit dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
[Bug c/34113] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746
--- Comment #2 from dirtyepic at gentoo dot org 2007-11-15 20:06 --- Created an attachment (id=14561) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14561action=view) access-mini.i further reduced. -- dirtyepic at gentoo dot org changed: What|Removed |Added Attachment #14560|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #6 from pcarlini at suse dot de 2007-11-15 18:14 --- I'm finishing testing a complete patch. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug tree-optimization/34113] [4.3 Regression] ICE in get_addr_dereference_operands, at tree-ssa-operands.c:1746
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in |[4.3 Regression] ICE in |get_addr_dereference_operand|get_addr_dereference_operand |s, at tree-ssa- |s, at tree-ssa- |operands.c:1746 |operands.c:1746 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113
[Bug c++/34094] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #3 from simon_baldwin at yahoo dot com 2007-11-15 19:55 --- The definition's really there in 4.2.1, absent in 4.1.1: $ 4.2.1/g++ -S ns1.cc c++filt ns1.s | grep B::x movl$0, (anonymous namespace)::B::x .local (anonymous namespace)::B::x .comm (anonymous namespace)::B::x,4,4 $ 4.1.1/g++ -S ns1.cc c++filt ns1.s | grep B::x movl$0, (anonymous namespace)::B::x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug target/11787] always call memcpy for block move in mips16
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-11-15 20:52 --- Fixed on mainline, and not appropriate for backporting. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11787
[Bug middle-end/23848] [4.0/4.1/4.2/4.3 Regression] stack deallocation can be more efficient
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-15 19:03 --- Subject: Bug 23848 Author: jakub Date: Thu Nov 15 19:02:54 2007 New Revision: 130206 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130206 Log: PR middle-end/23848 * tree-ssa-ccp.c (optimize_stack_restore): New function. (execute_fold_all_builtins): Call optimize_stack_restore for BUILT_IN_STACK_RESTORE. * gcc.dg/tree-ssa/pr23848-1.c: New test. * gcc.dg/tree-ssa/pr23848-2.c: New test. * gcc.dg/tree-ssa/pr23848-3.c: New test. * gcc.dg/tree-ssa/pr23848-4.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23848-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23848
[Bug c++/5310] Weird warnings about using (int)NULL
--- Comment #8 from patchapp at dberlin dot org 2007-11-15 20:05 --- Subject: Bug number PR c++/5310 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00865.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5310
[Bug libstdc++/34105] [4.3 Regression] Confusing error message with missing #include algorithm
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-11-15 21:54 --- Awesome. Looks good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
[Bug c/34115] New: atomic builtins not supported on i686?
Linking fails for the program below, with the error: undefined reference to `___sync_val_compare_and_swap_4' // gcc -Wall atomic.c int main() { int *a, b, c; return __sync_val_compare_and_swap(a, b, c); } According to the atomic builtins docs (), Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type. If CAS is not supported, how come I don't get a warning? Why would i686 *not* support compare and swap? The cmpxchg instruction has been around since 80486, according to the intel IA-32 processor manual. Also, does an unsupported builtin mean the user is responsible to write that function, or simply that the compiler must make a function call to synthesize its behavior? FWIW, my x86_64 cross-compile gcc 4.2.0 handles it fine, emitting a lock+cmpxchg pair. -- Summary: atomic builtins not supported on i686? Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scovich at gmail dot com GCC host triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115