[Bug fortran/45117] [4.3/4.4/4.5/4.6 Regression] Segfault in resolve_array_bound
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-29 06:34 --- For completeness: The code is invalid - which gfortran also properly diagnoses before segfaulting. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.3.4 4.4.0 4.5.1 4.6.0 Known to work||4.2.1 4.1.2 Last reconfirmed|-00-00 00:00:00 |2010-07-29 06:34:01 date|| Summary|Segfault in |[4.3/4.4/4.5/4.6 Regression] |resolve_array_bound |Segfault in ||resolve_array_bound http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45117
[Bug fortran/41059] -fwhole-file and error messages
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-29 08:11 --- Close as WONTFIX as suggested by Dominique. The trunk now uses -fwhole-file and some of the warning messages have been fixed while others have been added as dg-warning. The commit was Rev.162491: http://gcc.gnu.org/viewcvs?view=revisionrevision=162491 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41059
[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return stdin
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-29 08:26 ---
The committed patch has added:
+#ifdef HAVE_TTYNAME
+ if (u-unit_number == options.stdin_unit
+ || u-unit_number == options.stdout_unit
+ || u-unit_number == options.stderr_unit)
+ {
+ char * tmp = ttyname (((unix_stream *) u-s)-fd);
+ if (tmp != NULL)
+ {
+ int tmplen = strlen (tmp);
+ fstrcpy (iqp-name, iqp-name_len, tmp, tmplen);
+ }
+ else /* If ttyname does not work, go with the default. */
+ fstrcpy (iqp-name, iqp-name_len, u-file, u-file_len);
+ }
+ else
+#endif
+ fstrcpy (iqp-name, iqp-name_len, u-file, u-file_len);
+}
For MINGW I would suggest to remove the last three lines and add the following:
+ fstrcpy (iqp-name, iqp-name_len, u-file, u-file_len);
+ #elif defined __MINGW32__
+ switch (u-unit_number)
+{
+case options.stdin_unit:
+ fstrcpy (iqp-name, iqp-name_len, conin$, sizeof(conin$));
+ break;
+case options.stdout_unit:
+ fstrcpy (iqp-name, iqp-name_len, conout$, sizeof(conout$));
+ break;
+case options.stderr_unit:
+ fstrcpy (iqp-name, iqp-name_len, conerr$, sizeof(conerr$));
+ break;
+default:
+ fstrcpy (iqp-name, iqp-name_len, u-file, u-file_len);
+}
+#else
+ fstrcpy (iqp-name, iqp-name_len, u-file, u-file_len);
+#endif
+}
Note: This was written as is - there might be typos and it might not be even
compile.
Note 2: Kai says that on MINGW, HAVE_TTYNAME is not defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44931
[Bug debug/45124] New: No DW_AT_accessibility for public DIEs in DW_TAG_class_type
Dwarf 3 and 4 state that if DW_AT_accessibility is missing, the default is DW_ACCESS_private in DW_TAG_class_type and DW_ACCESS_public otherwise. Unfortunately dwarf2out.c assumes the default is DW_ACCESS_public always. Not sure if GDB (or other dwarf consumers) makes the same assumption. If not, then we can add DW_ACCESS_public DW_AT_accessibility in DW_TAG_class_type for everything that didn't have it till now and drop DW_ACCESS_private accessibility, if yes, then I'm afraid all we can do for the time being is just add DW_ACCESS_public accessibility and keep DW_ACCESS_private accessibility too. -- Summary: No DW_AT_accessibility for public DIEs in DW_TAG_class_type Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124
[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-29 08:55 --- Looking at GDB: /* Handle accessibility and virtuality of field. The default accessibility for members is public, the default accessibility for inheritance is private. */ if (die-tag != DW_TAG_inheritance) new_field-accessibility = DW_ACCESS_public; else new_field-accessibility = DW_ACCESS_private; i.e. it seems to match what GCC (wrongly) does. I'm afraid we need to live with some extra DW_AT_accessibility attributes for compatibility. -- 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 |2010-07-29 08:55:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124
[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-29 08:58 --- Created an attachment (id=21346) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21346action=view) gcc46-pr45124.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45124
[Bug debug/45110] GCC does not emit DW_AT_object_pointer
--- Comment #1 from jakub at gcc dot gnu dot org 2010-07-29 08:58 --- Created an attachment (id=21347) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21347action=view) gcc46-pr45110.patch Untested 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45110
[Bug fortran/45117] [4.3/4.4/4.5/4.6 Regression] Segfault in resolve_array_bound
--- Comment #2 from domob at gcc dot gnu dot org 2010-07-29 09:07 --- Subject: Bug 45117 Author: domob Date: Thu Jul 29 09:06:53 2010 New Revision: 162670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162670 Log: 2010-07-29 Daniel Kraft d...@domob.eu PR fortran/45117 * array.c (resolve_array_bound): Fix error message to properly handle non-variable expressions. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45117
[Bug c/45102] mm/page-writeback.c:820: internal compiler error: Segmentation fault
--- Comment #3 from jakub at gcc dot gnu dot org 2010-07-29 09:20 --- Please provide also gcc command line options used to trigger the ICE on page-writeback.i. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
[Bug c/45123] -pedantic warning about string inside __asm
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-29 09:37 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-07-29 09:37:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45123
[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-29 09:40 --- Confirmed. In the original code b doesn't overflow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-29 09:40:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
[Bug c++/45121] [4.6 Regression] c-c++-common/uninit-17.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-29 09:40:46 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45121
[Bug fortran/45125] New: ICE with -fwhole-file
As reported by Dominique, the patch for PR 45087, http://gcc.gnu.org/ml/fortran/2010-07/msg00430.html, causes an ICE for attachment 20927 (= PR 43945 comment 19 and PR 44936 comment 1). pr44936_1.f90: In function 'd_coo_err': pr44936_1.f90:198:0: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1048 -- Summary: ICE with -fwhole-file Product: gcc Version: 4.6.0 Status: UNCONFIRMED 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=45125
[Bug tree-optimization/45120] [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/pta-field-2.c execution
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-29 10:01 ---
Confirmed, mine.
We generate wrong constraints for
bar (int * * x)
{
int * D.2737;
bb 2:
D.2737_3 = MEM[(struct Foo *)x_1(D) + -8B].p;
*D.2737_3 = 0;
return;
}
Generating constraints for bar (bar)
bar.arg0 = NONLOCAL
D.2737_3 = *bar.arg0
bar.use = bar.arg0
bar.clobber = D.2737_3
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|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-29 10:01:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45120
[Bug fortran/45117] [4.3/4.4/4.5/4.6 Regression] Segfault in resolve_array_bound
--- Comment #3 from domob at gcc dot gnu dot org 2010-07-29 10:03 --- Fixed on trunk, closing. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45117
[Bug bootstrap/45119] [4.6 Regression] Bootstrap went to infinite loop
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45119
[Bug fortran/45125] ICE with -fwhole-file
--- Comment #1 from mikael at gcc dot gnu dot org 2010-07-29 10:25 ---
Confirmed.
Workaround:
trans-decl.c b/trans-decl.c
index d5be2e4..14e78a4 100644
--- a/trans-decl.c
+++ b/trans-decl.c
@@ -1457,7 +1457,10 @@ gfc_get_extern_function_decl (gfc_symbol * sym)
/* Avoid problems of double deallocation of the backend declaration
later in gfc_trans_use_stmts; cf. PR 45087. */
if (sym-attr.if_source != IFSRC_DECL sym-attr.use_assoc)
- sym-attr.use_assoc = 0;
+ {
+ sym-attr.use_assoc = 0;
+ sym-attr.referenced = 1;
+ }
return sym-backend_decl;
}
PS: no need to open a PR as long as the patch is not committed ;-)
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-07-29 10:25:54
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45125
[Bug fortran/45087] -fwhole-program: Miscompiled due to wrong decls
--- Comment #7 from mikael at gcc dot gnu dot org 2010-07-29 10:26 --- (In reply to comment #6) Patch: http://gcc.gnu.org/ml/fortran/2010-07/msg00430.html Regressing, see PR45125. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45087
[Bug c/45102] mm/page-writeback.c:820: internal compiler error: Segmentation fault
-- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45102
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] safe conversion from unsigned to signed char gives broken code
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-07-29 11:00 --- Subject: Bug 45034 Author: rguenth Date: Thu Jul 29 10:59:54 2010 New Revision: 162673 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162673 Log: 2010-07-29 Richard Guenther rguent...@suse.de PR middle-end/45034 * convert.c (convert_to_integer): Always use an unsigned type for narrowed negate and bitwise not. * gcc.c-torture/execute/pr45034.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr45034.c Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug tree-optimization/45034] [4.3/4.4/4.5 Regression] safe conversion from unsigned to signed char gives broken code
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-07-29 11:00 --- Fixed on the trunk sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.2 |4.1.2 4.6.0 Summary|[4.3/4.4/4.5/4.6 Regression]|[4.3/4.4/4.5 Regression] |safe conversion from |safe conversion from |unsigned to signed char |unsigned to signed char |gives broken code |gives broken code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug c/45126] New: volatile lost in optimization
Hi, When -O -ftree-vrp optimizations are used the volatileness seems to be lost. Even though this test relies upon undefined behaviour according to the C99 spec the result is different with optimizations on or off. I think that even when both accesses of vus are in the same expression it should still be read twice and no assumption should be made to its value. Maarten Brock Developer of SDCC, Small Device C Compiler, http://sdcc.sourceforge.net Here is the compiler output: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -E -quiet -v vus.c -D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -ftree-vrp -O -fpch-preprocess -fstack-protector -o vus.i ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.4.1/include /usr/lib/gcc/i486-linux-gnu/4.4.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -fpreprocessed vus.i -quiet -dumpbase vus.c -mtune=generic -march=i486 -auxbase vus -O -version -ftree-vrp -fstack-protector -o vus.s GNU C (Ubuntu 4.4.1-4ubuntu9) version 4.4.1 (i486-linux-gnu) compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1-p2. GGC heuristics: --param ggc-min-expand=61 --param ggc-min-heapsize=59624 Compiler executable checksum: 8f30a5fdc2c06e07cc337ee4c8f69ccf COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus' '-mtune=generic' '-march=i486' as -V -Qy -o vus.o vus.s GNU assembler version 2.20 (i486-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.20 COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus' '-mtune=generic' '-march=i486' /usr/lib/gcc/i486-linux-gnu/4.4.1/collect2 --build-id --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o vus -z relro /usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.4.1/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.4.1 -L/usr/lib/gcc/i486-linux-gnu/4.4.1 -L/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.1/../../.. -L/usr/lib/i486-linux-gnu vus.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.1/crtend.o /usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crtn.o And the preprocessed file: # 1 vus.c # 1 built-in # 1 command-line # 1 vus.c # 1 /usr/include/assert.h 1 3 4 # 37 /usr/include/assert.h 3 4 # 1 /usr/include/features.h 1 3 4 # 313 /usr/include/features.h 3 4 # 1 /usr/include/bits/predefs.h 1 3 4 # 314 /usr/include/features.h 2 3 4 # 346 /usr/include/features.h 3 4 # 1 /usr/include/sys/cdefs.h 1 3 4 # 353 /usr/include/sys/cdefs.h 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 354 /usr/include/sys/cdefs.h 2 3 4 # 347 /usr/include/features.h 2 3 4 # 378 /usr/include/features.h 3 4 # 1 /usr/include/gnu/stubs.h 1 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 5 /usr/include/gnu/stubs.h 2 3 4 # 1 /usr/include/gnu/stubs-32.h 1 3 4 # 8 /usr/include/gnu/stubs.h 2 3 4 # 379 /usr/include/features.h 2 3 4 # 38 /usr/include/assert.h 2 3 4 # 68 /usr/include/assert.h 3 4 extern void __assert_fail (__const char *__assertion, __const char *__file, unsigned int __line, __const char *__function)
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-07-29 11:15 --- On x86_64-apple-darwin10, these failures at -m32 and -m64 appear to be suppressed when building with --enable-checking=release and reappear when building with --enable-checking=yes. http://gcc.gnu.org/ml/gcc-testresults/2010-07/msg02700.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug fortran/44064] [OOP] ICE with file containing two modules and one program
--- Comment #7 from mikael at gcc dot gnu dot org 2010-07-29 11:23 --- Subject: Bug 44064 Author: mikael Date: Thu Jul 29 11:22:40 2010 New Revision: 162674 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162674 Log: 2010-07-29 Mikael Morin mik...@gcc.gnu.org PR fortran/42051 PR fortran/44064 * class.c (gfc_find_derived_vtab): Accept or discard newly created symbols before returning. 2010-07-29 Mikael Morin mik...@gcc.gnu.org PR fortran/42051 PR fortran/44064 * gfortran.dg/pr42051.f03: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr42051.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #18 from mikael at gcc dot gnu dot org 2010-07-29 11:23 --- Subject: Bug 42051 Author: mikael Date: Thu Jul 29 11:22:40 2010 New Revision: 162674 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162674 Log: 2010-07-29 Mikael Morin mik...@gcc.gnu.org PR fortran/42051 PR fortran/44064 * class.c (gfc_find_derived_vtab): Accept or discard newly created symbols before returning. 2010-07-29 Mikael Morin mik...@gcc.gnu.org PR fortran/42051 PR fortran/44064 * gfortran.dg/pr42051.f03: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr42051.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug c/45126] volatile lost in optimization
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-07-29 11:25 --- Possible values for vus are [0, 65535], volatileness does not change that. Multiplying this as int is always positive (overflow is undefined), so we can change the test to (vus * vus) != 0. -- 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=45126
[Bug middle-end/44121] [4.6 Regression] multiple char-related fails.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-29 11:28:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
[Bug bootstrap/43795] gcc-4.5.0, pb installation
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-29 11:34 --- Thus, invalid. -- 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=43795
[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
--- Comment #19 from mikael at gcc dot gnu dot org 2010-07-29 11:52 --- Backport on 4.5 pending... -- mikael at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
[Bug fortran/44064] [OOP] ICE with file containing two modules and one program
--- Comment #8 from mikael at gcc dot gnu dot org 2010-07-29 11:55 --- With the link error being tracked as PR44065, I'm tempted to say that this is a duplicate of PR42051. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
[Bug c/45126] volatile lost in optimization
--- Comment #2 from majbrock at dse dot nl 2010-07-29 12:00 --- Ok, that is a choice. But even then vus is read only once, where it appeared twice in the expression. What about the possible side-effects of reading a volatile? -- majbrock at dse dot nl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
[Bug fortran/45125] ICE with -fwhole-file
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-29 12:19 --- The patch in comment #1 fixes the ICE, but AFAICT (due to other patches in my tree) make an error message to disappear in pr44348, pr44614, and pr44616: [macbook] f90/bug% cat pr44614.f90 module factory_pattern implicit none type, abstract :: Connection contains procedure(generic_desc), deferred :: description end type Connection abstract interface subroutine generic_desc(self) !import class(Connection) :: self end subroutine generic_desc end interface end module factory_pattern end [macbook] f90/bug% gfc pr44614.f90 pr44614.f90:12.33: class(Connection) :: self 1 Error: the type of 'self' at (1) has not been declared within the interface [macbook] f90/bug% gfcp pr44614.f90 pr44614.f90:12.33: class(Connection) :: self 1 Error: the type of 'self' at (1) has not been declared within the interface pr44614.f90:6.27: procedure(generic_desc), deferred :: description 1 Error: Non-polymorphic passed-object dummy argument of 'generic_desc' at (1) gfc patched r162674, gfcp r162490. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45125
[Bug c/45126] volatile lost in optimization
--- Comment #3 from schwab at linux-m68k dot org 2010-07-29 12:21 --- That does not change the fact that vus*vus can be assumed to be non-negative. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
[Bug tree-optimization/45120] [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/pta-field-2.c execution
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-29 12:30 --- Subject: Bug 45120 Author: rguenth Date: Thu Jul 29 12:30:09 2010 New Revision: 162676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162676 Log: 2010-07-29 Richard Guenther rguent...@suse.de PR tree-optimization/45120 * tree-ssa-structalias.c (get_constraint_for_component_ref): Handle offset in DEREFs properly. (get_constraint_for_1): Handle MEM_REF offset properly. * gcc.dg/ipa/ipa-pta-15.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45120
[Bug tree-optimization/45120] [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/pta-field-2.c execution
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-07-29 12:31 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45120
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #6 from bernds at gcc dot gnu dot org 2010-07-29 12:40 --- Subject: Bug 42575 Author: bernds Date: Thu Jul 29 12:39:57 2010 New Revision: 162678 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162678 Log: PR rtl-optimization/42575 * dce.c (word_dce_process_block): Renamed from byte_dce_process_block. Argument AU removed. All callers changed. Ignore artificial refs. Use return value of df_word_lr_simulate_defs to decide whether an insn is necessary. (fast_dce): Rename arg to WORD_LEVEL. (run_word_dce): Renamed from rest_of_handle_fast_byte_dce. No longer static. (pass_fast_rtl_byte_dce): Delete. * dce.h (run_word_dce): Declare. * df-core.c (df_print_word_regset): Renamed from df_print_byteregset. All callers changed. Simplify code to only deal with two-word regs. * df.h (DF_WORD_LR): Renamed from DF_BYTE_LR. (DF_WORD_LR_BB_INFO): Renamed from DF_BYTE_LR_BB_INFO. (DF_WORD_LR_IN): Renamed from DF_BYTE_LR_IN. (DF_WORD_LR_OUT): Renamed from DF_BYTE_LR_OUT. (struct df_word_lr_bb_info): Renamed from df_byte_lr_bb_info. (df_word_lr_mark_ref): Declare. (df_word_lr_add_problem, df_word_lr_mark_ref, df_word_lr_simulate_defs, df_word_lr_simulate_uses): Declare or rename from byte variants. (df_byte_lr_simulate_artificial_refs_at_top, df_byte_lr_simulate_artificial_refs_at_end, df_byte_lr_get_regno_start, df_byte_lr_get_regno_len, df_compute_accessed_bytes): Delete declarations. (df_word_lr_get_bb_info): Rename from df_byte_lr_get_bb_info. (enum df_mm): Delete. * df-byte-scan.c: Delete file. * df-problems.c (df_word_lr_problem_data): Renamed from df_byte_lr_problem_data, all members deleted except for WORD_LR_BITMAPS, which is renamed from BYTE_LR_BITMAPS. Uses changed. (df_word_lr_expand_bitmap, df_byte_lr_simulate_artificial_refs_at_top, df_byte_lr_simulate_artificial_refs_at_end, df_byte_lr_get_regno_start, df_byte_lr_get_regno_len, df_byte_lr_check_regs, df_byte_lr_confluence_0): Delete functions. (df_word_lr_free_bb_info): Renamed from df_byte_lr_free_bb_info; all callers changed. (df_word_lr_alloc): Renamed from df_byte_lr_alloc; all callers changed. Don't initialize members that were deleted, don't try to discover data about registers. Ignore hard regs. (df_word_lr_reset): Renamed from df_byte_lr_reset; all callers changed. (df_word_lr_mark_ref): New function. (df_word_lr_bb_local_compute): Renamed from df_byte_bb_lr_local_compute; all callers changed. Use df_word_lr_mark_ref. Assert that artificial refs don't include pseudos. Ignore hard registers. (df_word_lr_local_compute): Renamed from df_byte_lr_local_compute. Assert that exit block uses don't contain pseudos. (df_word_lr_init): Renamed from df_byte_lr_init; all callers changed. (df_word_lr_confluence_n): Renamed from df_byte_lr_confluence_n; all callers changed. Ignore hard regs. (df_word_lr_transfer_function): Renamed from df_byte_lr_transfer_function; all callers changed. (df_word_lr_free): Renamed from df_byte_lr_free; all callers changed. (df_word_lr_top_dump): Renamed from df_byte_lr_top_dump; all callers changed. (df_word_lr_bottom_dump): Renamed from df_byte_lr_bottom_dump; all callers changed. (problem_WORD_LR): Renamed from problem_BYTE_LR; uses changed; confluence operator 0 set to NULL. (df_word_lr_add_problem): Renamed from df_byte_lr_add_problem; all callers changed. (df_word_lr_simulate_defs): Renamed from df_byte_lr_simulate_defs. Return bool, true if bitmap changed or insn otherwise necessary. All callers changed. Simplify using df_word_lr_mark_ref. (df_word_lr_simulate_uses): Renamed from df_byte_lr_simulate_uses; all callers changed. Simplify using df_word_lr_mark_ref. * lower-subreg.c: Include dce.h (decompose_multiword_subregs): Call run_word_dce if df available. * Makefile.in (lower-subreg.o): Adjust dependencies. (df-byte-scan.o): Delete. * timevar.def (TV_DF_WORD_LR): Renamed from TV_DF_BYTE_LR. Removed: trunk/gcc/df-byte-scan.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/dce.c trunk/gcc/dce.h trunk/gcc/df-core.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/lower-subreg.c trunk/gcc/timevar.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug c/45126] volatile lost in optimization
--- Comment #4 from majbrock at dse dot nl 2010-07-29 12:41 --- Andreas said: That does not change the fact that vus*vus can be assumed to be non-negative. And then this bug was closed again. So because one part of my report is dismissed you also dismiss the other part? I already confirmed that you can choose to assume vus*vus to be non-negative. But still I sustain that vus should read TWICE and it isn't. And thus I conclude that its volatileness is lost. Before you close it again can you please explain to me on what grounds vus should not be read twice? -- majbrock at dse dot nl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
[Bug c/45126] volatile lost in optimization
--- Comment #5 from schwab at linux-m68k dot org 2010-07-29 12:55 --- Works fine here with gcc 4.4.4. movzwl vus, %eax movzwl vus, %edx -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
[Bug c/45127] New: Out-of-order execution
This program is written for AT91SAM9260. It is on compiled with yagarto with GCC 4.5.0. on win xp sp2. The prog reads 10 dwords from address 0 and sends them through uart. Adress 0 (on '9260) can either be ROM or SRAM, depending on REMAP settings. The prog first does a REMAP, then reads 10 dwords. However, generated code first reads ptr[0], does REMAP, then reads ptr[1-9], which means that the first dword will be read from ROM, and all others from SRAM. MATRIX_MRCR is volatile, so it should be executed first, IMHO. It can be fixed by: 1. add volatile to ptr definition (line 31). 2. instead of linking with libarm.a, change lines 7 (#if 1) and 40 (SendDword2). This method, however, produces less readable LSS file. I've included two LSS files: original.lss and method2.lss Original.lss is generated with the as is src.c. Methot2.lss is generated after changing lines 7 40. -- Summary: Out-of-order execution Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aleksazr at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug c/45127] Out-of-order execution
--- Comment #1 from aleksazr at gmail dot com 2010-07-29 13:13 --- Created an attachment (id=21348) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21348action=view) all sources unpack to c:\ so that you have c:\00 folder -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug c/45126] volatile lost in optimization
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-29 13:27 --- And with all other versions I tried (4.3 and 4.5) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
[Bug c/45127] Out-of-order execution
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-07-29 13:30 --- rar is not a portable archive format. Please use tar instead together with gzip (or zip). You might want to try -fno-delete-null-pointer-checks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug c/45126] volatile lost in optimization
--- Comment #7 from majbrock at dse dot nl 2010-07-29 13:30 --- Thank you both for looking into it and explaining the behaviour. I feel stupid and apologize, because I was certain that it was not read twice. Yet now I can no longer reproduce that, so I guess I was wrong after all. Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45126
[Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c
--- Comment #15 from bernds at gcc dot gnu dot org 2010-07-29 13:49 --- Created an attachment (id=21349) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21349action=view) Potential fix Could you verify that this fixes it? -- bernds at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bernds at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063
[Bug fortran/45128] New: Segmentation fault with -fwhole-file
The following code (from pr40737)
! { dg-do compile }
module testmod
implicit none
type VARIABLES_MAILLE
real :: cell_var
end type VARIABLES_MAILLE
type (VARIABLES_MAILLE), pointer, dimension( :) :: Hydro_vars
real, pointer, dimension(:) :: Ro
end module testmod
program TF_AD_SPLITTING_DRIVER_PLANE
use testmod
implicit none
Ro = Hydro_vars(1:2)%cell_var
end program
gives a Segmentation fault when compiled with -fwhole-file. The backtrace is
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0018
0x0001000d1d38 in gfc_trans_pointer_assignment (expr1=0x14191a3f0,
expr2=0x141919960) at ../../work/gcc/fortran/trans-expr.c:4768
4768 gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp);
(gdb) bt
#0 0x0001000d1d38 in gfc_trans_pointer_assignment (expr1=0x14191a3f0,
expr2=0x141919960) at ../../work/gcc/fortran/trans-expr.c:4768
#1 0x0001000a9ae6 in trans_code (code=0x14191a960, cond=0x0) at
../../work/gcc/fortran/trans.c:1109
#2 0x0001000c7bd2 in gfc_generate_function_code (ns=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4495
#3 0x00010006b0bd in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4253
#4 0x0001000a496c in gfc_be_parse_file (set_yydebug=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:241
#5 0x0001006990da in toplev_main (argc=2, argv=0x7fff5fbfd9d8) at
../../work/gcc/toplev.c:945
#6 0x00011154 in start ()
--
Summary: Segmentation fault with -fwhole-file
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128
[Bug fortran/45129] New: I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
The following field is too small for the E edit descriptor: print '(e4.2)', 1.0 end Expected: Print a warning like ifort: test.f90(1): warning #6894: The field width is too small for the number of fractional digits. [2] print '(e4.2)', 1.0 ---^ For that example at least 7 digits are needed (e7.2) - otherwise instead of .10E+01 is printed - to be precise 5+e where e is given exponential width. For F, one needs at least p+1, i.e. F2.2 is too small while F3.2 can be enough (0 = |values| 1). -- Summary: I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: diagnostic 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=45129
[Bug rtl-optimization/45130] New: -fcompare-debug failure with -Os -fsched-spec-load -fschedule-insns
Command line: $ gcc -Os -fsched-spec-load -fschedule-insns -fcompare-debug testcase.c Valgrind output: $ valgrind --trace-children=yes --track-origins=yes -q /mnt/svn/gcc-trunk/binary-162653-lto-fortran-checking-yes-rtl-df/bin/gcc -Os -fsched-spec-load -fschedule-insns -fcompare-debug testcase.c ==14681== Conditional jump or move depends on uninitialised value(s) ==14681==at 0x70F09B: walk_gimple_stmt (gimple.c:1627) ==14681==by 0x95F153: dump_enumerated_decls (tree-ssa-live.c:1264) ==14681==by 0x901718: execute_cleanup_cfg_post_optimizing (tree-optimize.c:214) ==14681==by 0x7BD3EB: execute_one_pass (passes.c:1564) ==14681==by 0x7BD684: execute_pass_list (passes.c:1619) ==14681==by 0x9020A5: tree_rest_of_compilation (tree-optimize.c:452) ==14681==by 0xAB96E5: cgraph_expand_function (cgraphunit.c:1643) ==14681==by 0xABC579: cgraph_optimize (cgraphunit.c:1722) ==14681==by 0xABCB6A: cgraph_finalize_compilation_unit (cgraphunit.c:1185) ==14681==by 0x4DF86E: c_write_global_declarations (c-decl.c:9698) ==14681==by 0x8AB075: toplev_main (toplev.c:957) ==14681==by 0x6589BBC: (below main) (in /lib64/libc-2.11.2.so) ==14681== Uninitialised value was created by a stack allocation ==14681==at 0x95F0A0: dump_enumerated_decls (tree-ssa-live.c:1251) ==14681== ==15989== Conditional jump or move depends on uninitialised value(s) ==15989==at 0x70F09B: walk_gimple_stmt (gimple.c:1627) ==15989==by 0x95F153: dump_enumerated_decls (tree-ssa-live.c:1264) ==15989==by 0x901718: execute_cleanup_cfg_post_optimizing (tree-optimize.c:214) ==15989==by 0x7BD3EB: execute_one_pass (passes.c:1564) ==15989==by 0x7BD684: execute_pass_list (passes.c:1619) ==15989==by 0x9020A5: tree_rest_of_compilation (tree-optimize.c:452) ==15989==by 0xAB96E5: cgraph_expand_function (cgraphunit.c:1643) ==15989==by 0xABC579: cgraph_optimize (cgraphunit.c:1722) ==15989==by 0xABCB6A: cgraph_finalize_compilation_unit (cgraphunit.c:1185) ==15989==by 0x4DF86E: c_write_global_declarations (c-decl.c:9698) ==15989==by 0x8AB075: toplev_main (toplev.c:957) ==15989==by 0x6589BBC: (below main) (in /lib64/libc-2.11.2.so) ==15989== Uninitialised value was created by a stack allocation ==15989==at 0x95F0A0: dump_enumerated_decls (tree-ssa-live.c:1251) ==15989== gcc: error: testcase.c: -fcompare-debug failure I don't know if the uninitialised read has anything to do with this problem. Tested revisions: r162653 - fail r162456 - OK -- Summary: -fcompare-debug failure with -Os -fsched-spec-load - fschedule-insns Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz 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=45130
[Bug rtl-optimization/45130] -fcompare-debug failure with -Os -fsched-spec-load -fschedule-insns
--- Comment #1 from zsojka at seznam dot cz 2010-07-29 13:59 --- Created an attachment (id=21350) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21350action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45130
[Bug middle-end/45131] New: [4.6 regression] New test failures configured with --with-cpu=atom
On Linux/x86-64, when configured with --with-cpu=atom --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld -with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse revision 162667 gave FAIL: gfortran.dg/inquire_size.f90 -O0 execution test FAIL: gfortran.dg/inquire_size.f90 -O1 execution test FAIL: gfortran.dg/inquire_size.f90 -O2 execution test FAIL: gfortran.dg/inquire_size.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/inquire_size.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/inquire_size.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/inquire_size.f90 -O3 -g execution test FAIL: gfortran.dg/inquire_size.f90 -Os execution test FAIL: gfortran.dg/streamio_10.f90 -O0 execution test FAIL: gfortran.dg/streamio_10.f90 -O1 execution test FAIL: gfortran.dg/streamio_10.f90 -O2 execution test FAIL: gfortran.dg/streamio_10.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/streamio_10.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/streamio_10.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/streamio_10.f90 -O3 -g execution test FAIL: gfortran.dg/streamio_10.f90 -Os execution test FAIL: gfortran.dg/streamio_15.f90 -O0 execution test FAIL: gfortran.dg/streamio_15.f90 -O1 execution test FAIL: gfortran.dg/streamio_15.f90 -O2 execution test FAIL: gfortran.dg/streamio_15.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/streamio_15.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/streamio_15.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/streamio_15.f90 -O3 -g execution test FAIL: gfortran.dg/streamio_15.f90 -Os execution test FAIL: gfortran.dg/streamio_16.f90 -O0 execution test FAIL: gfortran.dg/streamio_16.f90 -O1 execution test FAIL: gfortran.dg/streamio_16.f90 -O2 execution test FAIL: gfortran.dg/streamio_16.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/streamio_16.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/streamio_16.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/streamio_16.f90 -O3 -g execution test FAIL: gfortran.dg/streamio_16.f90 -Os execution test FAIL: gfortran.dg/streamio_8.f90 -O0 execution test FAIL: gfortran.dg/streamio_8.f90 -O1 execution test FAIL: gfortran.dg/streamio_8.f90 -O2 execution test FAIL: gfortran.dg/streamio_8.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/streamio_8.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/streamio_8.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/streamio_8.f90 -O3 -g execution test FAIL: gfortran.dg/streamio_8.f90 -Os execution test FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O0 FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O1 FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O2 -fbounds-check FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O2 -fomit-frame-pointer -finline-functions FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -Os FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O2 -ftree-vectorize -msse2 FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O0 FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O1 FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O2 FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O2 -fbounds-check FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O3 -g FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -Os FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O2 -ftree-vectorize -msse2 Revision 162619 is OK. -- Summary: [4.6 regression] New test failures configured with -- with-cpu=atom Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom
--- Comment #1 from hjl dot tools at gmail dot com 2010-07-29 14:12 --- It may be caused by revision 162653: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01007.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||davidxl at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom
--- Comment #2 from hjl dot tools at gmail dot com 2010-07-29 14:16 --- It happened between revision 162661 and revision 162667. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|davidxl at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom
--- Comment #3 from hjl dot tools at gmail dot com 2010-07-29 14:19 --- It is caused by revision 162667: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01021.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug bootstrap/45119] [4.6 Regression] Bootstrap went to infinite loop
--- Comment #3 from hjl at gcc dot gnu dot org 2010-07-29 14:31 --- Subject: Bug 45119 Author: hjl Date: Thu Jul 29 14:30:18 2010 New Revision: 162683 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162683 Log: Revert change in revision 162652. 2010-07-29 Xinliang David Li davi...@google.com PR bootstrap/45119 * tree-ssa-loop-ivopts.c (get_address_cost): Revert change in revision 162652. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45119
[Bug fortran/45125] ICE with -fwhole-file
--- Comment #3 from burnus at gcc dot gnu dot org 2010-07-29 14:40 ---
The segfault occurs for:
l.4768 gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp);
It seems as if GFC_DECL_SPAN(decl) access a NULL pointer. That's
decl-decl_common.lang_specific-span
where lang_specific == NULL.
While the dump has:
tf_ad_splitting_driver_plane ()
{
extern integer(kind=8) span.0 = 0;
[...]
span.0 = 4;
the span variable does not really exist globally but is only created when
needed, cf.
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/trans-decl.c;hb=HEAD#l1243
gfc_get_symbol_decl:
1243 else if (sym-attr.subref_array_pointer)
1245 /* We need the span for these beasts. */
1246 gfc_allocate_lang_decl (decl);
1249 if (sym-attr.subref_array_pointer)
1261 GFC_DECL_SPAN (decl) = span;
If one now recycles the definition for the array descriptor desc this
information is not present. I think the real solution is the new array
descriptor. I do not know how to fix this otherwise - except by always
generating a span variable.
Paul - any progress from the array-descriptor front?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45125
[Bug fortran/45125] ICE with -fwhole-file for subref_array_pointer
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-29 14:42 --- Sorry that comment 3 and the change was supposed to go to PR 45128. I think the PR here is relatively easily fixable. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC|pault at gcc dot gnu dot org| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45125
[Bug fortran/45128] Segmentation fault with -fwhole-file for subref_array_pointer
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-29 14:44 ---
Carry over the comment from PR 45125, where I had posted it initially (and
accidentally).
The segfault occurs for:
l.4768 gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp);
It seems as if GFC_DECL_SPAN(decl) access a NULL pointer. That's
decl-decl_common.lang_specific-span
where lang_specific == NULL.
While the dump has:
tf_ad_splitting_driver_plane ()
{
extern integer(kind=8) span.0 = 0;
[...]
span.0 = 4;
the span variable does not really exist globally but is only created when
needed, cf.
http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/trans-decl.c;hb=HEAD#l1243
gfc_get_symbol_decl:
1243 else if (sym-attr.subref_array_pointer)
1245 /* We need the span for these beasts. */
1246 gfc_allocate_lang_decl (decl);
1249 if (sym-attr.subref_array_pointer)
1261 GFC_DECL_SPAN (decl) = span;
If one now recycles the definition for the array descriptor desc this
information is not present. I think the real solution is the new array
descriptor. I do not know how to fix this otherwise - except by always
generating a span variable.
Paul - any progress from the array-descriptor front?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2010-07-29 14:44:16
date||
Summary|Segmentation fault with - |Segmentation fault with -
|fwhole-file |fwhole-file for
||subref_array_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45128
[Bug c++/45132] New: Inconsistant function overloading between template and non-template functions
Consider following test-case:
$ cat templorder.cc
#include iostream
struct Foo {
int a;
char b;
};
templatetypename T inline int match(const T x)
{
return 23;
}
template typename T inline int not_match(const T x)
{
return match(x) + 1;
}
template inline int matchint(const int x)
{
return 42;
}
inline int match(const Foo x)
{
return 52;
}
inline int match(const double d)
{
return 62;
}
#define CHECK_EQ(A, B) if (!((A) == (B))) { ++r; std::cerr Error: (A)
!= (B) '\n'; }
int main()
{
int r = 0;
int i = 0;
CHECK_EQ(not_match(i), 43);
char c = 0;
Foo f;
CHECK_EQ(not_match(f), 53);
double d = 0;
// BANG
CHECK_EQ(not_match(d), 63);
return r;
}
$ g++ temporder.cc
$ ./a.out
Error: 24 != 63
This behavior is inconsistant, because either 'CHECK_EQ(not_match(f), 53)'
should fail, too or 'CHECK_EQ(not_match(d), 63)' should not fail.
I would expect that 'CHECK_EQ(not_match(d), 63)' should not fail. But perhaps I
am missing some rule in the C++ standard.
Compiling the test case with the C++ Sun Workshop Pro CC and executing prints
no errors.
$ cat /etc/issue
Ubuntu 10.04.1 LTS
But I got the same output with g++ under the previous two Ubuntu versions.
--
Summary: Inconsistant function overloading between template and
non-template functions
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: g_sauthoff at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45132
[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom
--- Comment #4 from burnus at gcc dot gnu dot org 2010-07-29 14:55 --- HJ, as it works on most systems, can you do some debugging? a) Does the system has HAVE_TTYNAME defined for libgfortran/ ? b) If it fails in the library, how? Otherwise: Which of the asserts fails in the test case? Can you replace for the failing line the call abort() by print *, variable name I assume, all the failures have the same cause thus it should be sufficient to only analyze one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug target/45127] Out-of-order execution
--- Comment #3 from aleksazr at gmail dot com 2010-07-29 14:56 --- Created an attachment (id=21351) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21351action=view) all sources -- aleksazr at gmail dot com changed: What|Removed |Added Attachment #21348|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #47 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-29 15:05 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap On Mon, 19 Jul 2010, dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #33 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-19 14:31 --- Subject: Re: [4.6 regression] Revision 162270 failed to bootstrap This patch (with/without the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/txt00119.txt) does not fix the bootstrap failure on x86_64-apple-darwin10.4. Same on hppa64-hp-hpux11.11. With the rc-fix4.diff and entrymode.diff patches, we still fail compiling libgcc in stage2, although at a slightly different spot: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/g cc-4.6.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11 /lib/ -isystem /opt/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/include -isystem /op t/gnu64/gcc/gcc-4.6.0/hppa64-hp-hpux11.11/sys-include-g -O2 -O2 -g -O2 -DIN _GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-protot ypes -Wold-style-definition -isystem ./include -fPIC -Dpa64=1 -DELF=1 -mlong-c alls -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I.. /.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/.. /gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o __gcc_bcmp. o -MT __gcc_bcmp.o -MD -MP -MF __gcc_bcmp.dep -DL__gcc_bcmp -c ../../../gcc/libg cc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__gcc_bcmp': ../../../gcc/libgcc/../gcc/libgcc2.c:1979:1: internal compiler error: Segmentati It appears cfg.c is being miscompiled. Replacing stage2 version with stage1 version results in the above compilation completing successfully. This is the backtrace as much as can be trusted: Program received signal SIGSEGV, Segmentation fault. find_edge (pred=0x83fffdf8e750, succ=0x0) at ../../gcc/gcc/cfganal.c:492 492 if (EDGE_COUNT (pred-succs) = EDGE_COUNT (succ-preds)) (gdb) bt #0 find_edge (pred=0x83fffdf8e750, succ=0x0) at ../../gcc/gcc/cfganal.c:492 #1 0x402ba014 in redirect_edge_succ_nodup (e=0x83fffdcd1f00, new_succ=0x0) at ../../gcc/gcc/cfg.c:398 #2 0x40749f1c in ssa_redirect_edge (e=0x83fffdcd1f00, dest=0x0) at ../../gcc/gcc/tree-ssa.c:207 #3 0x405f2330 in gimple_redirect_edge_and_branch ( e=0x83fffdcd1f00, dest=0x0) at ../../gcc/gcc/tree-cfg.c:4951 #4 0x405f29d4 in gimple_redirect_edge_and_branch_force ( e=value optimized out, dest=value optimized out) at ../../gcc/gcc/tree-cfg.c:4973 #5 0x402cf08c in redirect_edge_and_branch_force ( e=0x83fffdcd1f00, dest=0x0) at ../../gcc/gcc/cfghooks.c:400 #6 0x402d3aa4 in copy_bbs (bbs=0x80010014f820, n=value optimized out, new_bbs=value optimized out, edges=0x83fffdff1578, num_edges=1, new_edges=0x83fffdff15e8, base=value optimized out, after=value optimized out) at ../../gcc/gcc/cfglayout.c:1452 Attached cfg.i and cfg.s from stage2, and cc1 command. Dave --- Comment #48 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-29 15:05 --- Created an attachment (id=21352) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21352action=view) --- Comment #49 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-29 15:05 --- Created an attachment (id=21353) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21353action=view) --- Comment #50 from dave at hiauly1 dot hia dot nrc dot ca 2010-07-29 15:05 --- Created an attachment (id=21354) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21354action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug c++/45132] Inconsistant function overloading between template and non-template functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-07-29 15:17 --- But perhaps I am missing some rule in the C++ standard. Yes you are. You are missing that fundamental types in C++ don't have an associated namespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45132
[Bug c++/45132] Inconsistant function overloading between template and non-template functions
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-07-29 15:19 --- *** This bug has been marked as a duplicate of 29131 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45132
[Bug c++/29131] [DR 225] Bad name lookup for templates due to fundamental types namespace for ADL.
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-07-29 15:19 --- *** Bug 45132 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||g_sauthoff at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131
[Bug fortran/45131] [4.6 regression] New Fortran test failures
--- Comment #5 from hjl dot tools at gmail dot com 2010-07-29 15:47 --- (In reply to comment #4) HJ, as it works on most systems, can you do some debugging? Trunk was broken since yesterday and was fixed a while ago. a) Does the system has HAVE_TTYNAME defined for libgfortran/ ? Yes. b) If it fails in the library, how? Otherwise: Which of the asserts fails in the test case? Can you replace for the failing line the call abort() by print *, variable name [...@gnu-1 gfortran]$ cat inquire_3.f90 ! pr14836 OPEN(UNIT=9, ACCESS='DIRECT', RECL=80, FORM='UNFORMATTED') INQUIRE(UNIT=9,NEXTREC=NREC) WRITE(UNIT=9,REC=5) 1 INQUIRE(UNIT=9,NEXTREC=NREC) PRINT*,NREC IF (NREC.NE.6) CALL ABORT READ(UNIT=9,REC=1) MVI INQUIRE(UNIT=9,NEXTREC=NREC) PRINT*,NREC IF (NREC.NE.2) CALL ABORT CLOSE(UNIT=9,STATUS='DELETE') END [...@gnu-1 gfortran]$ /export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../gfortran -B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../ inquire_3.f90 -w -O0 -B/export/gnu/import/svn/gcc-test/bld/i686-linux/./libgfortran/.libs -L/export/gnu/import/svn/gcc-test/bld/i686-linux/./libgfortran/.libs -L/export/gnu/import/svn/gcc-test/bld/i686-linux/./libgfortran/.libs -L/export/gnu/import/svn/gcc-test/bld/i686-linux/./libiberty -lm -static [...@gnu-1 gfortran]$ ./a.out 1 Aborted [...@gnu-1 gfortran]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.6 regression] New test |[4.6 regression] New Fortran |failures configured with -- |test failures |with-cpu=atom | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45131
[Bug libstdc++/45133] New: [c++0x] std::future will crash with NULL deref if get() is called twice
The following quick snippet crashes with GCC 4.5.0, on the second call to
get():
#include future
int make_int() { return 52; }
int main()
{
std::futureint future_in = std::async(make_int);
printf(%d\n, future_in.get());
printf(%d\n, future_in.get());
}
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00401c3f in std::__future_base::_State::wait (this=0x0) at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:281
281 _M_run_deferred();
(gdb) backtrace
#0 0x00401c3f in std::__future_base::_State::wait (this=0x0) at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:281
#1 0x00402e9d in std::__basic_futureint::_M_get_result
(this=0x7fffd880)
at /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:515
#2 0x00402560 in std::futureint::get (this=0x7fffd880) at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0/include/g++-v4/future:594
#3 0x004017a2 in main () at promise.cpp:10
Obviously this is not a valid operation, since get() moves the result and then
zaps itself (and valid() returns false after get() is called). However from a
usability standpoint this doesn't seem ideal. It looks like adding a check in
__basic_future::_M_get_result that ensures that _M_state is not NULL would be
sufficient to catch this case.
I would assume the result of doing a get() when !valid() is undefined, so
throwing an exception when someone does this would be conforming, and a lot
more obvious and friendly. If for some reason this couldn't work, even just an
assertion fail would be more informative than a NULL pointer deref.
--
Summary: [c++0x] std::future will crash with NULL deref if get()
is called twice
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
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=45133
[Bug target/45127] Out-of-order execution
--- Comment #4 from rearnsha at gcc dot gnu dot org 2010-07-29 16:29 --- Volatile alone won't prevent re-ordering of non-volatile memory operations. The volatile keyword only applies to that particular location (requiring the compiler not to remove it, or change the number of accesses). In this case you need to emit a memory barrier to prevent the compiler from re-arranging the code. A simple way to do this is to create an empty asm block that clobbers memory, for example: asm ( : : : memory); this will cause the compiler to force out all pending memory operations before the barrier and not to move later operations earlier. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug fortran/45077] ICE with -fwhole-file in fold_convert_loc, at fold-const.c:2021
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-29 17:00 --- (In reply to comment #4) Fixed for the unmodified example in comment 1 - and also for PR 40011 comment 47. However, the following remains to be done: It still fails if one moves module iso_red into a separate file (cf. PR 44945). The reason is that then gsym will come up as NULL and every module user uses a different decl. The challenge to handle truly external procedures correctly is to use - if possible - the correct interface. For EXTERNAL this is not quite possible - but one should try to merge the different declarations while one parses the file, e.g. when one encounters EXTERNAL one generates a GSYM - which later gets updated with the interface (if present somewhere), by procedure usage (call), or by the actual external procedure if it comes later in the file. At the same time, a consistency check for type and arguments can be done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45077
[Bug c++/45121] [4.6 Regression] c-c++-common/uninit-17.c
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-07-29 17:21 --- Fixed in r162687 -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45121
[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
-- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-29 17:25:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129
[Bug libstdc++/45133] [c++0x] std::future will crash with NULL deref if get() is called twice
--- Comment #1 from paolo dot carlini at oracle dot com 2010-07-29 17:34 --- Jon, can you have a look? Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45133
[Bug fortran/45004] [OOP] Segfault with allocatable scalars and move_alloc
--- Comment #5 from janus at gcc dot gnu dot org 2010-07-29 18:14 --- Subject: Bug 45004 Author: janus Date: Thu Jul 29 18:14:16 2010 New Revision: 162688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162688 Log: 2010-07-29 Janus Weil ja...@gcc.gnu.org PR fortran/45004 * trans-stmt.h (gfc_trans_class_init_assign): New prototype. (gfc_trans_class_assign): Modified prototype. * trans.h (gfc_conv_intrinsic_move_alloc): New prototype. * trans-expr.c (gfc_trans_class_init_assign): Split off from ... (gfc_trans_class_assign): ... here. Modified actual arguments. * trans-intrinsic.c (gfc_conv_intrinsic_move_alloc): New function to handle the MOVE_ALLOC intrinsic with scalar and class arguments. * trans.c (trans_code): Call 'gfc_conv_intrinsic_move_alloc'. 2010-07-29 Janus Weil ja...@gcc.gnu.org PR fortran/45004 * gfortran.dg/move_alloc_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/move_alloc_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45004
[Bug fortran/45004] [OOP] Segfault with allocatable scalars and move_alloc
--- Comment #6 from janus at gcc dot gnu dot org 2010-07-29 18:18 --- Fixed with r162688. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45004
[Bug bootstrap/45134] New: [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495
At revision 162686 boostrapping fails on powerpc-apple-darwin9 with /opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.6w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.6w/powerpc-apple-darwin9/sys-include-c -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.6-work/gcc -I../../gcc-4.6-work/gcc/. -I../../gcc-4.6-work/gcc/../include -I../../gcc-4.6-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.6-work/gcc/../libdecnumber -I../../gcc-4.6-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -DCLOOG_PPL_BACKEND../../gcc-4.6-work/gcc/cfg.c -o cfg.o ../../gcc-4.6-work/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type': ../../gcc-4.6-work/gcc/cfg.c:1109:1: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 (see also http://gcc.gnu.org/ml/gcc-regression/2010-07/msg00302.html ). -- Summary: [4.6 Regression] Bootstrap failure for powerpc-apple- darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug rtl-optimization/45135] New: DCE ICE on PPC
The DCE patch for PR rtl-optimization/42575 appears to have introduced a bootstrap failure on PowerPC targets: /farm/dje/src/src/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type': /farm/dje/src/src/gcc/cfg.c:1109:1: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 -- Summary: DCE ICE on PPC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45135
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #1 from dje at gcc dot gnu dot org 2010-07-29 18:32 --- This fails on powerpc-ibm-aix as well: /farm/dje/src/src/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type': /farm/dje/src/src/gcc/cfg.c:1109:1: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin9 |*-*-* GCC host triplet|powerpc-apple-darwin9 |*-*-* GCC target triplet|powerpc-apple-darwin9 |powerpc-*-* Keywords||build, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-07-29 18:32:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug rtl-optimization/45135] DCE ICE on PPC
--- Comment #1 from dje at gcc dot gnu dot org 2010-07-29 18:33 --- *** This bug has been marked as a duplicate of 45134 *** -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45135
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #2 from dje at gcc dot gnu dot org 2010-07-29 18:33 --- *** Bug 45135 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #3 from bergner at gcc dot gnu dot org 2010-07-29 18:57 --- Ditto for powerpc64-linux: /home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c: In function read_module: /home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c:4542:1: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 -- bergner at gcc dot gnu dot org changed: What|Removed |Added CC||bergner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-*-*: ICE: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #4 from dominiq at lps dot ens dot fr 2010-07-29 19:07 --- Adjust summary. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Summary|[4.6 Regression] Bootstrap |[4.6 Regression] Bootstrap |failure for powerpc-apple- |failure for powerpc-*-*: |darwin9: internal compiler |ICE: in |error: in |delete_corresponding_reg_eq_ |delete_corresponding_reg_eq_|notes, at dce.c:495 |notes, at dce.c:495 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug tree-optimization/45022] No prefetch for the vectorized loop
--- Comment #4 from changpeng dot fang at amd dot com 2010-07-29 19:14 --- (In reply to comment #1) The misaligned indirect-refs will vanish soon. I saw your patch that remove ALIGNED_INDIRECT_REF. Do you also plan to remove MISALIGNED_INDIRECT_REF? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45022
[Bug target/45127] Out-of-order execution
--- Comment #5 from aleksazr at gmail dot com 2010-07-29 19:19 --- Thank you for a good explanation. Cheers! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45127
[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-29 19:33 --- Created an attachment (id=21355) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21355action=view) Draft patch Jerry, what do you think? Note: The smallest width is actually 3 also for D and E: That's enough to fit INF or NAN - but the smallest useful width is slightly larger - and tested for. I also added a check for the E* and D edit descriptor that d is positive; it is not explicitly written in the standard, but it does not make sense to allow 0. ifort is strictly standard conform - and prints always '' while NAG and gfortran always give a run time error. Thus, I think it is sensible to check whether d is positive - and print an error otherwise. (Again with d == 0 one could fit a NAN and INF in there, thus, strictly speaking one should allow it - but I maintain that no sensible user will ever need this - and gfortran lacks the run-time support for it.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-29 19:36 --- Here is a reduced/modified version of the code in comment #0, which also exhibits a runtime segfault, although the code seems to be valid: module polynomial implicit none private type, public :: polynom complex, allocatable, dimension(:) :: a integer :: n contains procedure :: init_from_coeff procedure :: get_degree procedure :: add_poly end type polynom contains subroutine init_from_coeff(self, coeff) class(polynom), intent(inout) :: self complex, dimension(:), intent(in) :: coeff self%n = size(coeff) - 1 allocate(self%a(self%n + 1)) self%a = coeff print *,ifc:,self%a end subroutine init_from_coeff function get_degree(self) result(n) class(polynom), intent(in) :: self integer :: n print *,gd n = self%n end function get_degree subroutine add_poly(self) class(polynom), intent(in) :: self integer :: s print *,ap s = self%get_degree() fails here end subroutine end module polynomial program test_poly use polynomial type(polynom) :: p1 call p1%init_from_coeff([(1,0),(2,0),(3,0)]) call p1%add_poly() end program test_poly After being compiled with gfortran r162688 on x86_64-unknown-linux-gnu, it prints the following output: ifc: ( 1.000, 0.000) ( 2.000, 0.000) ( 3.000, 0.000) ap Segmentation fault Valgrind says: ==25251== Invalid read of size 8 ==25251==at 0x400A02: __polynomial_MOD_init_from_coeff (c0.f90:42) ==25251==by 0x400950: __polynomial_MOD_add_poly (c0.f90:36) ==25251==by 0x400DCF: MAIN__ (c0.f90:47) ==25251==by 0x400E30: main (c0.f90:42) ==25251== Address 0x1c is not stack'd, malloc'd or (recently) free'd ==25251== ==25251== ==25251== Process terminating with default action of signal 11 (SIGSEGV) ==25251== Access not within mapped region at address 0x1C ==25251==at 0x400A02: __polynomial_MOD_init_from_coeff (c0.f90:42) ==25251==by 0x400950: __polynomial_MOD_add_poly (c0.f90:36) ==25251==by 0x400DCF: MAIN__ (c0.f90:47) ==25251==by 0x400E30: main (c0.f90:42) This is a very strange error. It seems init_from_coeff is called from add_poly, although this is definitely not the case in the Fortran code. Maybe something goes wrong in the vtab, like PPCs having wrong addresses, etc. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-29 19:36:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-*-*: ICE: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #5 from bergner at gcc dot gnu dot org 2010-07-29 19:37 ---
Debugger info:
#0 fancy_abort (file=0x112a7098
/home/bergner/gcc/gcc-mainline-base/gcc/dce.c, line=495,
function=0x112a7180 delete_corresponding_reg_eq_notes) at
/home/bergner/gcc/gcc-mainline-base/gcc/diagnostic.c:879
#1 0x10e5ad5c in delete_corresponding_reg_eq_notes
(insn=0xfffb1d4c840) at /home/bergner/gcc/gcc-mainline-base/gcc/dce.c:495
#2 0x10e5af24 in delete_unmarked_insns () at
/home/bergner/gcc/gcc-mainline-base/gcc/dce.c:549
#3 0x10e5cd04 in fast_dce (word_level=1 '\001') at
/home/bergner/gcc/gcc-mainline-base/gcc/dce.c:1003
#4 0x10e5cf6c in run_word_dce () at
/home/bergner/gcc/gcc-mainline-base/gcc/dce.c:1031
#5 0x10ec41f8 in decompose_multiword_subregs () at
/home/bergner/gcc/gcc-mainline-base/gcc/lower-subreg.c:1096
#6 0x10ec5750 in rest_of_handle_lower_subreg2 () at
/home/bergner/gcc/gcc-mainline-base/gcc/lower-subreg.c:1349
#7 0x10620104 in execute_one_pass (pass=0x1132a090) at
/home/bergner/gcc/gcc-mainline-base/gcc/passes.c:1564
#8 0x1062074c in execute_pass_list (pass=0x1132a090) at
/home/bergner/gcc/gcc-mainline-base/gcc/passes.c:1619
#9 0x10620778 in execute_pass_list (pass=0x11321868) at
/home/bergner/gcc/gcc-mainline-base/gcc/passes.c:1620
#10 0x108358d8 in tree_rest_of_compilation (fndecl=0xfffb5cad400) at
/home/bergner/gcc/gcc-mainline-base/gcc/tree-optimize.c:452
#11 0x10b65b5c in cgraph_expand_function (node=0xfffb5cbb160) at
/home/bergner/gcc/gcc-mainline-base/gcc/cgraphunit.c:1643
#12 0x10b65eec in cgraph_expand_all_functions () at
/home/bergner/gcc/gcc-mainline-base/gcc/cgraphunit.c:1722
#13 0x10b668b8 in cgraph_optimize () at
/home/bergner/gcc/gcc-mainline-base/gcc/cgraphunit.c:1978
#14 0x10b63618 in cgraph_finalize_compilation_unit () at
/home/bergner/gcc/gcc-mainline-base/gcc/cgraphunit.c:1185
#15 0x100c4260 in c_write_global_declarations () at
/home/bergner/gcc/gcc-mainline-base/gcc/c-decl.c:9698
#16 0x10778eb0 in compile_file () at
/home/bergner/gcc/gcc-mainline-base/gcc/toplev.c:957
#17 0x1077c778 in do_compile () at
/home/bergner/gcc/gcc-mainline-base/gcc/toplev.c:2295
#18 0x1077c8ac in toplev_main (argc=29, argv=0xfffef28) at
/home/bergner/gcc/gcc-mainline-base/gcc/toplev.c:2336
#19 0x101c6650 in main (argc=29, argv=0xfffef28) at
/home/bergner/gcc/gcc-mainline-base/gcc/main.c:36
(gdb) pr insn
(insn 1826 1025 1026 117 (set (reg:DI 903 [+72 ])
(reg:DI 903 [+72 ])) 378 {*movdi_internal64}
(nil))
(gdb) p regno
$2 = 903
(gdb) pr noted_insn
(insn 1031 1028 1033 118 (parallel [
(set (reg:DI 726)
(and:DI (reg:DI 903 [+72 ])
(reg:DI 957)))
(clobber (scratch:CC))
]) /home/bergner/gcc/gcc-mainline-base/gcc/fortran/module.c:3913 340
{anddi3_mc}
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #51 from bernds at gcc dot gnu dot org 2010-07-29 19:46 --- Thanks. I can more-or-less produce the same assembly with a cross compiler, but just from looking at the assembly and the debugging dumps I can't quite figure out which function is being miscompiled. Can you produce a good (not miscompiled) .s file with a working cc1 and attach that as well for comparison? It would help massively if you could do a search similar to that for the miscompiled .o file, this time to find the miscompiled function. That can be done by replacing those functions that differ in the assembly files one by one and then compiling the modified assembly file to .o and producing a cc1 binary as previously. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug debug/45110] GCC does not emit DW_AT_object_pointer
--- Comment #2 from jakub at gcc dot gnu dot org 2010-07-29 19:47 --- Subject: Bug 45110 Author: jakub Date: Thu Jul 29 19:47:02 2010 New Revision: 162691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162691 Log: PR debug/45110 * dwarf2out.c (dwarf_attr_name): Handle DW_AT_object_pointer. (gen_formal_types_die): Add DW_AT_object_pointer in methods. (gen_subprogram_die): Likewise. Remove it when removing declaration's formal parameters. (gen_decl_die): Change return type to dw_die_ref, return what gen_formal_parameter_die returned. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45110
[Bug rtl-optimization/45136] New: -fcompare-debug failure with -Os -fschedule-insns
Output: $ gcc -Os -fschedule-insns -fcompare-debug testcase.c gcc: error: testcase.c: -fcompare-debug failure Tested revisions: r162653 - fail r161170 - fail r153685 - fail -- Summary: -fcompare-debug failure with -Os -fschedule-insns Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz 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=45136
[Bug rtl-optimization/45136] -fcompare-debug failure with -Os -fschedule-insns
--- Comment #1 from zsojka at seznam dot cz 2010-07-29 20:21 --- Created an attachment (id=21356) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21356action=view) reduced testcase Valgrind doesn't report any invalid/uninitialised read while compiling this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45136
[Bug fortran/44962] [OOP] ICE with specification expression SIZE(CLASS)
--- Comment #1 from janus at gcc dot gnu dot org 2010-07-29 20:59 --- Subject: Bug 44962 Author: janus Date: Thu Jul 29 20:58:57 2010 New Revision: 162695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162695 Log: 2010-07-29 Janus Weil ja...@gcc.gnu.org PR fortran/44962 * resolve.c (resolve_fl_derived): Call gfc_resolve_array_spec. 2010-07-29 Janus Weil ja...@gcc.gnu.org PR fortran/44962 * gfortran.dg/typebound_proc_17.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_proc_17.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44962
[Bug fortran/44962] [OOP] ICE with specification expression SIZE(CLASS)
--- Comment #2 from janus at gcc dot gnu dot org 2010-07-29 21:01 --- Fixed with r162695. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44962
[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-29 21:07 --- For completeness, the current patch has failures for for following test cases. In particular: - Reading - here, the d == 0 does not harm (e.g. fmt_bz_bn.f). - FMT_G: Here, the the width check is wrong (e.g. transpose_reshape_r10.f90) - For writing, for 1P it might be zero, cf. fmt_zero_digits.f90 Thus, the simple check does not make much sense. Probably, one should just remove it and leave only warning part in - with a fix for Gw.d? For read, more is possible - but I think the fields are small enough that one could still warn - or should one restrict the warning to WRITE/PRINT - and not include READ/FORMAT? gfortran.dg/fmt_bz_bn.f gfortran.dg/fmt_read_bz_bn.f90 gfortran.dg/fmt_zero_digits.f90 gfortran.dg/fmt_zero_precision.f90 gfortran.dg/io_constraints_4.f90 gfortran.dg/past_eor.f90 gfortran.dg/read_infnan_1.f90 gfortran.dg/transpose_reshape_r10.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129
[Bug fortran/45125] ICE with -fwhole-file
--- Comment #5 from burnus at gcc dot gnu dot org 2010-07-29 21:07 --- Subject: Bug 45125 Author: burnus Date: Thu Jul 29 21:07:34 2010 New Revision: 162696 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162696 Log: 2010-07-29 Tobias Burnus bur...@net-b.de PR fortran/45087 PR fortran/45125 * trans-decl.c (gfc_get_extern_function_decl): Correctly handle external procedure declarations in modules. (gfc_get_symbol_decl): Modify assert. 2010-07-29 Tobias Burnus bur...@net-b.de PR fortran/45087 PR fortran/45125 * gfortran.dg/whole_file_25.f90: New. * gfortran.dg/whole_file_26.f90: New. * gfortran.dg/whole_file_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_25.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_26.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45125
[Bug fortran/45087] -fwhole-program: Miscompiled due to wrong decls
--- Comment #8 from burnus at gcc dot gnu dot org 2010-07-29 21:07 --- Subject: Bug 45087 Author: burnus Date: Thu Jul 29 21:07:34 2010 New Revision: 162696 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162696 Log: 2010-07-29 Tobias Burnus bur...@net-b.de PR fortran/45087 PR fortran/45125 * trans-decl.c (gfc_get_extern_function_decl): Correctly handle external procedure declarations in modules. (gfc_get_symbol_decl): Modify assert. 2010-07-29 Tobias Burnus bur...@net-b.de PR fortran/45087 PR fortran/45125 * gfortran.dg/whole_file_25.f90: New. * gfortran.dg/whole_file_26.f90: New. * gfortran.dg/whole_file_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_25.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_26.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45087
[Bug fortran/45087] -fwhole-program: Miscompiled due to wrong decls
--- Comment #9 from burnus at gcc dot gnu dot org 2010-07-29 21:08 --- FIXED on the trunk (4.6). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45087
[Bug fortran/45125] ICE with -fwhole-file
--- Comment #6 from burnus at gcc dot gnu dot org 2010-07-29 21:08 --- FIXED on the trunk (4.6). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45125
[Bug fortran/44912] [OOP] Segmentation fault on TBP
--- Comment #2 from burnus at gcc dot gnu dot org 2010-07-29 21:13 --- (In reply to comment #1) Here is a reduced/modified version of the code in comment #0, which also exhibits a runtime segfault, although the code seems to be valid: [...] it prints the following output: ifc: ( 1.000, 0.000) ( 2.000, 0.000) ( 3.000, 0.000) ap Segmentation fault For completeness: With NAG f95 v5.1, ifort, and crayftn it prints: ifc: (1.,0.), (2.,0.), (3.,0.) ap gd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44912
[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use
-- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-29 21:19:52 date|| Summary|gfortran.dg/dynamic_dispatch|[OOP] |_6.f03 ICEs with -fprofile- |gfortran.dg/dynamic_dispatch |use |_6.f03 ICEs with -fprofile- ||use http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45076
[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros
--- Comment #10 from sje at cup dot hp dot com 2010-07-29 21:32 --- I have posted a patch for this bug to gcc-patches. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02302.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
[Bug target/43941] Impossible to build any version beyond 4.2.4
--- Comment #6 from sje at cup dot hp dot com 2010-07-29 21:50 --- Because the ia64-hp-hpux11.31 compiler generates 32 bit code by default you cannot do a bootstrap build in 64 bit mode. From install.texi: Note that the bootstrap compiler and the resulting GCC must be link compatible, else the bootstrap will fail with linker errors about incompatible object file formats. Since the resulting GCC generates 32 bit code and the bootstrap compiler you are using generates 64 bit code they are not link compatible. Note that you can build GCC in 32 bit mode and still use the resulting compiler to compile programs in 64 bit mode by using the -mlp64 option. -- sje at cup dot hp dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43941
[Bug c++/45121] [4.6 Regression] c-c++-common/uninit-17.c
--- Comment #4 from hjl dot tools at gmail dot com 2010-07-29 22:30 --- It isn't fixed. Revision 162688 gave FAIL: c-c++-common/uninit-17.c (test for warnings, line 14) FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14) -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45121
