[Bug java/26538] 'make install' to non-standard prefix fails with java enabled
--- Comment #1 from ayqazi at yahoo dot co dot uk 2006-03-03 06:49 --- Created an attachment (id=10958) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10958&action=view) Log of just the 'make install' command make install executed separately again, and its complete output logged, bzip2'ed, and attached here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26538
[Bug java/26538] New: 'make install' to non-standard prefix fails with java enabled
Hi, I am using Gentoo Linux. I followed the following steps: Make directory ~/src/packages/gcc-4.1-svn Change directory to ~/src/packages/gcc-4.1-svn Get sources via "svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch gcc-4.1-branch" make directory ~/src/packages/gcc-4.1-svn/test_build change to directory ~/src/packages/gcc-4.1-svn/test_build run bash -c '../gcc-4.1-branch/configure --prefix=/home/ayqazi/src/packages/gcc-4.1-svn/test_root --disable-nls --enable-version-specific-runtime-libs --enable-__cxa_atexit --enable-languages=c,c++,java --with-system-zlib --enable-java-awt=gtk --enable-gtk-cairo && nice make profiledbootstrap && make install' &> ../test_build.log & Here is the end of the file test_build.log: make[3]: Entering directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linu x-gnu/libjava/libltdl' make[4]: Entering directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linu x-gnu/libjava/libltdl' test -z "/home/ayqazi/src/packages/gcc-4.1-svn/test_root/lib" || mkdir -p -- "/home/ayqazi /src/packages/gcc-4.1-svn/test_root/lib" test -z "/home/ayqazi/src/packages/gcc-4.1-svn/test_root/include" || mkdir -p -- "/home/ay qazi/src/packages/gcc-4.1-svn/test_root/include" make[4]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linux -gnu/libjava/libltdl' make[3]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linux -gnu/libjava/libltdl' Making install in gcj make[3]: Entering directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linu x-gnu/libjava/gcj' make[4]: Entering directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linu x-gnu/libjava/gcj' make[4]: Nothing to be done for `install-exec-am'. test -z "/include/c++/gcj" || mkdir -p -- "/include/c++/gcj" mkdir: cannot create directory `/include': Permission denied make[4]: *** [install-gcjHEADERS] Error 1 make[4]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linux -gnu/libjava/gcj' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linux -gnu/libjava/gcj' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build/i686-pc-linux -gnu/libjava' make[1]: *** [install-target-libjava] Error 2 make[1]: Leaving directory `/home/ayqazi/src/packages/gcc-4.1-svn/test_build' make: *** [install] Error 2 Full build log (contents of 'test_build.log') available on request. -- Summary: 'make install' to non-standard prefix fails with java enabled Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ayqazi at yahoo dot co dot uk GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26538
[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2006-03-03 06:04 --- Fixed on 4.1.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2006-03-03 06:03 --- Subject: Bug 26136 Author: jvdelisle Date: Fri Mar 3 06:03:01 2006 New Revision: 111673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111673 Log: 2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26136 * gfortran.dg/namelist_23.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_23.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2006-03-03 06:00 --- Subject: Bug 26136 Author: jvdelisle Date: Fri Mar 3 06:00:08 2006 New Revision: 111672 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111672 Log: 2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26136 * io/io.h: Add flag for reading from line_buffer. * io/list_read.c (l_push_char): New function to save namelist input when reading logicals. (free_line): New function to free line_buffer memory. (next_char): Added feature to read from line_buffer. (read_logical): Use new functions to test for '=' after reading a logical value, checking for possible variable name. (namelist_read): Use free_line when all done. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/io.h branches/gcc-4_1-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
[Bug fortran/26107] ICE after error message on invalid code
--- Comment #3 from patchapp at dberlin dot org 2006-03-03 05:50 --- Subject: Bug number PR26107 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/2006-03/msg00186.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26107
[Bug libfortran/26464] Runtime I/O error/invald argument on READ
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-03 05:44 --- Fixed now in 4.1.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26464
[Bug libfortran/26464] Runtime I/O error/invald argument on READ
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-03-03 05:21 --- Subject: Bug 26464 Author: jvdelisle Date: Fri Mar 3 05:21:52 2006 New Revision: 111670 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111670 Log: 2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26464 * gfortran.dg/backspace_5.f: New test. * gfortran.dg/backspace_6.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/backspace_5.f branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/backspace_6.f Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26464
[Bug libfortran/26464] Runtime I/O error/invald argument on READ
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-03-03 05:13 --- Subject: Bug 26464 Author: jvdelisle Date: Fri Mar 3 05:13:06 2006 New Revision: 111669 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111669 Log: 2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26464 * io/file_pos.c (st_backspace): Flush and truncate file when in AFTER_ENDFILE condition. * io/transfer.c (st_read_done): Remove flush, no longer needed. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/file_pos.c branches/gcc-4_1-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26464
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-03 02:17 --- Can either one of you try the patch in PR 26015? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-03-03 02:17 --- Fixed on 4.1.1 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-03-03 02:16 --- Subject: Bug 26423 Author: jvdelisle Date: Fri Mar 3 02:16:06 2006 New Revision: 111665 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111665 Log: 2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26423 * gfortran.dg/read_many_1.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/read_many_1.f Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-03-03 02:16 --- (In reply to comment #18) > Right, the copying happens in .bbro (as shown in PR26537). > gcc-4.0 did the same kind of copying in .bbro, but it did not generate the > redundant mov. And that is because load PRE happened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #18 from dann at godzilla dot ics dot uci dot edu 2006-03-03 02:14 --- (In reply to comment #17) > (In reply to comment #5) > > It's strange that the load(*) does not get optimized, given that it's in the > > same BB as the store that precedes it... > > > >movl%eax, result.1282 > > (*)movlresult.1282, %eax > > This is because the copying of the trace is happening at the very end of the > optimization phase so it does not optimized at all. Right, the copying happens in .bbro (as shown in PR26537). gcc-4.0 did the same kind of copying in .bbro, but it did not generate the redundant mov. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug libfortran/26423] [4.1/4.2 Regression] Error on binary I/O for large array
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-03-03 02:11 --- Subject: Bug 26423 Author: jvdelisle Date: Fri Mar 3 02:11:07 2006 New Revision: 111664 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111664 Log: 2006-03-02 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26423 * io/unix.c (fd_seek): Revert change from 25949. (fd_read): Same. (fd_write): Same. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-03-03 02:10 --- (In reply to comment #5) > It's strange that the load(*) does not get optimized, given that it's in the > same BB as the store that precedes it... > >movl%eax, result.1282 > (*)movlresult.1282, %eax This is because the copying of the trace is happening at the very end of the optimization phase so it does not optimized at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug rtl-optimization/26537] Basic block reordering inserts redundant instruction
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-03 02:08 --- The problem has nothing to do with basic block reordering anyways. It is just copying instructions and not optimizing them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26537
[Bug middle-end/23488] [4.1/4.2 Regression] GCSE load PRE does not work with non sets
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-03-03 02:05 --- *** Bug 26537 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
[Bug rtl-optimization/26537] Basic block reordering inserts redundant instruction
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-03 02:05 --- This was already reported once before, this is a dup of bug 23488. *** This bug has been marked as a duplicate of 23488 *** -- 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=26537
[Bug rtl-optimization/26537] New: Basic block reordering inserts redundant instruction
This code:
extern char *nl_langinfo (int) __attribute__ ((__nothrow__));
char *
xtermEnvEncoding(void)
{
static char *result;
if (result == 0)
result = nl_langinfo(50);
return result;
}
gets compile by gcc-4.1.0 -march=i686 -mtune=i686 to:
xtermEnvEncoding:
[snip]
.L6:
movl$50, (%esp)
callnl_langinfo
movl%eax, result.1281
movlresult.1281, %eax < note this
leave
ret
Note the redundant mov instruction. 4.0 does not generate that extra
instruction.
The extra instruction seems to be generated by the bbro pass. Here is the RTL
dump for the .44.rnreg pass: nothing unusual
(call_insn:HI 17 16 19 1 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("nl_langinfo") [flags 0x41]
) [0 S1 A8])
(const_int 4 [0x4]))) 531 {*call_value_0} (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
(insn:HI 19 17 20 1 (set (mem/f/c/i:SI (symbol_ref:SI ("result.1281") [flags
0x2] ) [2 result+0 S4 A32])
(reg:SI 0 ax [orig:58 D.1283 ] [58])) 34 {*movsi_1}
(insn_list:REG_DEP_TRUE 18 (nil
))
(expr_list:REG_DEAD (reg:SI 0 ax [orig:58 D.1283 ] [58])
(nil)))
but the next dump, .45.bbro shows that an extra move instruction has been
inserted.
(call_insn:HI 17 16 19 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI ("nl_langinfo") [flags 0x41]
) [0 S1 A8])
(const_int 4 [0x4]))) 531 {*call_value_0} (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
(insn:HI 19 17 54 2 (set (mem/f/c/i:SI (symbol_ref:SI ("result.1281") [flags
0x2] ) [2 result+0 S4 A32])
(reg:SI 0 ax [orig:58 D.1283 ] [58])) 34 {*movsi_1}
(insn_list:REG_DEP_TRUE 18 (nil
))
(expr_list:REG_DEAD (reg:SI 0 ax [orig:58 D.1283 ] [58])
(nil)))
(insn 54 19 55 2 (set (reg/f:SI 0 ax [orig:61 result ] [61])
(mem/f/c/i:SI (symbol_ref:SI ("result.1281") [flags 0x2] ) [2 result+0 S4 A32])) 34 {*movsi_1} (nil)
(nil))
This problem is one of the causes for PR23153.
--
Summary: Basic block reordering inserts redundant instruction
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26537
[Bug libfortran/26499] gfortran - End of File incorrectly positioned after binary I/O.
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-03-03 01:51 --- Add a flush just before the truncate in st_write_done and comment seven is fixed.I had it in there at first, then I took it out to see if things would still work, and they did with the cases I had. A revised patch has been submitted for review. Dale, I also copied you on this new patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26499
[Bug c++/26536] wrong name lookup in a class template in presence of namespaces
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-03 00:52 --- *** Bug 26535 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26536
[Bug c++/26535] wrong name lookup in clas
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-03 00:52 --- *** This bug has been marked as a duplicate of 26536 *** *** This bug has been marked as a duplicate of 26536 *** -- 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=26535
[Bug c++/26536] wrong name lookup in a class template in presence of namespaces
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-03 00:51 ---
No this should not compile and here is why:
class Rational {
public:
Rational& negate() { return *this; }
};
namespace pm {
Rational& inv_sign(Rational& x) { return x.negate(); }
}
Rational is in the toplevel namespace so that is the only place where argument
dependent lookup will look to find the function inv_sign. Argument dependent
lookup will not relook into the namespace pm.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26536
[Bug c++/26536] wrong name lookup in a class template in presence of namespaces
--- Comment #1 from gawrilow at math dot tu-berlin dot de 2006-03-03 00:47 --- Created an attachment (id=10957) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10957&action=view) this testcase should compile without diagnostics -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26536
[Bug c++/26536] New: wrong name lookup in a class template in presence of namespaces
This bug seems to be marked as "closed" under the Id 2922. However, the attached testcase can be successfully compiled by gcc 3.3.5 and 3.4,5, while the brand new gcc 4.1.0 rejects it. If one puts everything in the global namespace, it compiles again. I fear, this issue is still far from being closed. -- Summary: wrong name lookup in a class template in presence of namespaces Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gawrilow at math dot tu-berlin dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26536
[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)
--- Comment #3 from patchapp at dberlin dot org 2006-03-03 00:40 --- Subject: Bug number PR 16136 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/2006-03/msg00173.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16136
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-03-03 00:37 --- The problem appears to be in error.c and occurs with file or internal I/O. error.c returns as soon as it finds a match to END condition and never looks for ERR. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-03 00:37:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug c++/26535] New: wrong name lookup in clas
-- Summary: wrong name lookup in clas Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gawrilow at math dot tu-berlin dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26535
[Bug bootstrap/26478] [4.2 Regression] bootstrap fails with readonly source directory
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-03-03 00:31 --- Subject: Bug 26478 Author: jsm28 Date: Fri Mar 3 00:31:38 2006 New Revision: 111662 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111662 Log: PR bootstrap/26478 * Makefile.in (stmp-int-hdrs): Remove include/unwind.h before copying over it. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26478
[Bug tree-optimization/26524] [4.1 Regression] ICE when compiling with -ffast-math and -O3 clatm5.f (lapack)
--- Comment #8 from roger at eyesopen dot com 2006-03-02 21:39 --- I think I've found the problem. On mainline, its in tree-scalar-evolution.c at around line 1652, where where handle NEGATE_EXPR in interpret_rhs_modify_expr. The code checks whether the type is SCALAR_FLOAT_TYPE_P, in which case it uses build_real, otherwise it calls build_int_cst_type. Unfortunately, with a complex type, we end up generating a (const_int (complex4) -1) which is very broken. I believe a suitable fix would be to replace this logic with something like fold_convert (type, integer_minus_one_node), which will produce the correct result for integers, reals and complex numbers. My change to fold-const.c just has stricter error checking and refuses to fold operations of mismatched types, and return NULL_TREE instead. It wasn't a fix, it just hid the problem which is still present but latent on mainline. I think. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26524
[Bug tree-optimization/26534] [4.1/4.2 Regression] bitfield wrong optimize
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 21:35 --- Confirmed, I don't know if this really a front-end issue or a tree opt issue as we get in cpp: x.a = 63; D.2483_3 = x.a; And then in FRE: x.a = 63; D.2483_3 = 63; But x.a is not a full integer (there should be an and somewhere). Note this does not have a problem in 4.0.x because FRE did not exist (well it did) and PRE did not do stuff based on loads. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-03-02 21:35:03 date|| Summary|bitfield wrong optimize |[4.1/4.2 Regression] ||bitfield wrong optimize Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug tree-optimization/26524] [4.1 Regression] ICE when compiling with -ffast-math and -O3 clatm5.f (lapack)
--- Comment #7 from janis at gcc dot gnu dot org 2006-03-02 21:25 --- The test started failing on mainline (before the 4.1 branch) with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=103109 r103109 | spop | 2005-08-15 12:26:12 + (Mon, 15 Aug 2005) | 8 lines PR 23391 * Makefile.in (tree-chrec.o): Depends on real.h. * tree-chrec.c: Include real.h. (chrec_fold_plus_poly_poly, chrec_fold_multiply_poly_poly, chrec_fold_plus_1): Use build_real for SCALAR_FLOAT_TYPE_P. * tree-scalar-evolution.c (add_to_evolution_1, interpret_rhs_modify_expr): Ditto. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26524
[Bug c++/26534] New: bitfield wrong optimize
#include
struct X
{
unsigned a:4;
};
int main()
{
struct X x = { 63u };
printf("%u\n", x.a);
return 0;
}
// end.
result:
g++bug.cpp; ./a
15
g++ -O bug.cpp; ./a
63
wrong result!!
--
Summary: bitfield wrong optimize
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
[Bug c/26533] error: invalid use of void expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 21:14 --- The first one is ok C even though it is not OK C89 but it is fine C99. The second one is not ok C at all, since you are deferencing a void pointer. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26533
[Bug c/26533] New: error: invalid use of void expression
This is probably pretty dodgy C code, but I
find it strange that program foo.c compiles
while program bar.c gives an error. Is this
a bug?
--- foo.c --
#include
int main()
{
int ii;
ii = 276;
void *vv = (void *)ⅈ
}
--- foo.c --
--- bar.c --
#include
int main()
{
int ii;
void *vv;
ii = 276;
*vv = (void *)ⅈ
}
--- bar.c --
% gcc -o foo foo.c
% gcc -o bar bar.c
bar.c: In function ESC)B?main?:
bar.c:10: warning: dereferencing ESC)B?void *? pointer
bar.c:10: error: invalid use of void expression
%
For completeness on this report, this was on
% gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /usr/local/gcc-4.0.2/src/gcc-4.0.2/configure
--enable-languages=c --prefix=/usr/local/gcc-4.0.2/x86-Linux
Thread model: posix
gcc version 4.0.2
%
--
Summary: error: invalid use of void expression
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kminola at eng dot umd dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26533
[Bug tree-optimization/14703] Inadequate optimization of inline templated functions
--- Comment #6 from eric-gcc at omnifarious dot org 2006-03-02 20:25 --- I'm pleased that I came up with such a difficult test case for the optimizer. I never thought it'd be that hard. :-) I don't know anything about the internals, but... The compiler has to generate everything down to the fibconst<0> and fibconst<1> specializations anyway. So why can't it memoize and filter the optimization up? Say it generates fibconst<1> and fibconst<2> in order to generate fibconst<3>, then it discovers that fibconst<3> can be optimized to return plain old '3'. It can save that, and then when it comes down again needing fibconst<2> and fibconst<3> in order to generate fibconst<4>, it can see the already optimized version of fibconst<3> and generate an optimized version of fibconst<4> that just returns plain old '5'. Maybe I have things totally wrong and there's no way to do anything like that with the code. Or maybe it would turn out that that way of doing things is so special case that it's not worth bothering with. But, I just wonder if memoizing some sort of optimized version of a function would help with a lot of things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14703
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #5 from wilbur dot harvey at spirentcom dot com 2006-03-02 20:01 --- Subject: Re: compute_frame_pointer_to_cfa_displacement erro r for avr target with --with-dwarf2 I gave up and deleted everything related. I will see if I can re-create the environment again. Wilbur pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:29 > --- > Can you attach the preprocessed source? > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug target/26427] Regressions with -fsection-anchors with zero sized structs
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-03-02 19:44 --- I said: > I'm considering adding equivalent code to varasm.c. This will fix > an inconsistency in the handling of zero-sized decls: sometimes > they get a byte of storage allocated to them (giving them a unique > address) and sometimes they don't. I'm no longer sure that's a good idea. I suspect some users of zero-sized structs really do want them to take zero size in the object, and know which incantation they need to get that. I'll have to leave the darwin.h ASM_DECLARE_OBJECT_NAME() issue to someone with access to Darwin. Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug target/26532] New: [4.1]: libmudflap failures on ia64
From
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00084.html
there are
=== libmudflap tests ===
Running target unix
FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx compilation failed to produce
executable
FAIL: libmudflap.c++/pass41-frag.cxx (-O) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-O) compilation failed to produce
executable
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-O2) compilation failed to produce
executable
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-O3) compilation failed to produce
executable
FAIL: ctors-12 linkage
FAIL: ctors-21 linkage
WARNING: program timed out.
FAIL: ctors-12 execution
WARNING: program timed out.
FAIL: ctors-21 execution
FAIL: ctors-12 linkage -static
FAIL: ctors-21 linkage -static
WARNING: program timed out.
FAIL: ctors-12 execution -static
WARNING: program timed out.
FAIL: ctors-21 execution -static
FAIL: ctors-12 linkage -O2
FAIL: ctors-21 linkage -O2
WARNING: program timed out.
FAIL: ctors-12 execution -O2
WARNING: program timed out.
FAIL: ctors-21 execution -O2
FAIL: ctors-12 linkage -O3
FAIL: ctors-21 linkage -O3
WARNING: program timed out.
FAIL: ctors-12 execution -O3
WARNING: program timed out.
FAIL: ctors-21 execution -O3
But Linux/x86 and Linux/x86-64 have no problems. The error message looks like
pass41-frag.o: In function `global constructors keyed to
0_main':/net/gnu-13/export/gnu/src/gcc-4.1-blended/gcc/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx:13:
undefined reference to `std::ios_base::_S_local_word_size'
:/net/gnu-13/export/gnu/src/gcc-4.1-blended/gcc/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx:13:
undefined reference to `std::ios_base::_S_local_word_size'
:/net/gnu-13/export/gnu/src/gcc-4.1-blended/gcc/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx:13:
undefined reference to `std::__ios_flags::_S_trunc'
:/net/gnu-13/export/gnu/src/gcc-4.1-blended/gcc/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx:13:
undefined reference to `std::__ios_flags::_S_trunc'
:/net/gnu-13/export/gnu/src/gcc-4.1-blended/gcc/libmudflap/testsuite/libmudflap.c++/pass41-frag.cxx:13:
undefined reference to `std::__ios_flags::_S_out'
...
Those undefined symbols are from things like:
struct __ios_flags
{
typedef short __int_type;
static const __int_type _S_boolalpha = 0x0001;
static const __int_type _S_dec = 0x0002;
static const __int_type _S_fixed = 0x0004;
...
Mudflap generates
.mii
addl r35 = @ltoffx(_ZNSt11__ios_flags12_S_boolalphaE#), r1
addl r38 = @ltoffx(.LC72), r1
;;
nop 0
.mmb
ld8.mov r35 = [r35], _ZNSt11__ios_flags12_S_boolalphaE#
ld8.mov r38 = [r38], .LC72
br.call.sptk.many b0 = __mf_register#
I don't see why it should even bother. This problem doesn't exist in 4.2. Does
anyone know which patch fixes it?
--
Summary: [4.1]: libmudflap failures on ia64
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26532
[Bug tree-optimization/26524] [4.1 Regression] ICE when compiling with -ffast-math and -O3 clatm5.f (lapack)
--- Comment #6 from janis at gcc dot gnu dot org 2006-03-02 19:10 --- The test case starts passing on mainline with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=109088 r109088 | sayle | 2005-12-27 23:27:34 + (Tue, 27 Dec 2005) | 11 lines * fold-const.c (int_const_binop): Return NULL_TREE when an expression can't be evaluated at compile-time (instead of calling abort). Return NULL_TREE for division (and modulus) by zero. (const_binop): Return NULL_TREE for floating point operators that aren't handled by real_arithmetic. (fold_binary): Eliminate "wins" variable, and "binary" label, by folding operators with constant operands early. Assert that operands are non-NULL. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||sayle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26524
Re: error building 4.1 on Solaris 9
Martin Sebor wrote: Andrew Pinski wrote: On Mar 1, 2006, at 7:48 PM, Martin Sebor wrote: Is there a recommended version of GNU binutils for 4.1? I have been using 2.13 but the latest compiler doesn't seem to be happy with it. I tried the latest, 2.16.1, but I get the same error with it as well. I don't see anything about this in INSTALL/specific.html. You did not follow directions. Guilty as charged. I guess I never have and I've just been getting away with it (that is, until now). From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13486: - You must tell the configure script that you use GNU binutils and not the Sun tools. See http://gcc.gnu.org/install/configure.html Thank you. Using the options --with-gnu-as --with-gnu-ld fixed the error. But only to build the compiler, not when running the installed gcc. I see I still missed something: the rules for finding the assembler and linker used by the installed compiler. It seems that the rules to find these utilities are different when building than when using the compiler. When building gcc, it looks for them in PATH. When using gcc, it considers system directories first. Btw., is there a way to switch between the native and GNU assembler and linker without rebuilding the compiler? It seems that 4.1 with the GNU utilities is a lot slower than 4.0.2 was when using the native ones (I wasn't actually using the GNU utilities with 4.0.2 despite what I said before). Martin
[Bug c++/26531] Use of templates in macro expansion confuses pre-processor
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 18:27 ---
This is not a bug.
There are two arguments passed to the macro MYMACRO, "{\nSomeClass test;\n }".
the only way to force an argument passed to the preprocessor macros is to wrap
them in parentheses.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26531
[Bug c++/26531] New: Use of templates in macro expansion confuses pre-processor
Given the following code:
BEGIN CODE
template
class SomeClass
{
};
#define MYMACRO(BLOCK) \
{ \
BLOCK\
} \
int
main(void)
{
MYMACRO({
SomeClass test;
});
}
END CODE
gcc (3.3.5 on Debian sarge, 3.4.4 on FreeBSD 6.0 from base and 4.2.0 on FreeBSD
frmo ports) fails to compile it, complaining that MYMACRO was given too many
arguments. For example, with 4.2.0:
BEGIN COMPILER OUTPUT
% g++42 -v -save-temps -o macroarg macroarg.cc
Using built-in specs.
Target: i386-portbld-freebsd6.0
Configured with: ./..//gcc-4.2-20060218/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/loca
ib/gcc/i386-portbld-freebsd6.0/4.2.0/include/c++/
--infodir=/usr/local/info/gcc42 --disable-shared --disable-libgcj
--prefix=/usr/local i386-portbld-freebsd6.0
Thread model: posix
gcc version 4.2.0 20060218 (experimental)
/usr/local/libexec/gcc/i386-portbld-freebsd6.0/4.2.0/cc1plus -E -quiet -v
macroarg.cc -mtune=i386 -fpch-preprocess -o macroarg.ii
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-portbld-freebsd6.0/4.2.0/gcc/i386-portbld-freebsd6.0/4.2.0/../../../../i386-portbld-freebsd6.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/i386-portbld-freebsd6.0/4.2.0/include/c++/
/usr/local/lib/gcc/i386-portbld-freebsd6.0/4.2.0/include/c++//i386-portbld-freebsd6.0
/usr/local/lib/gcc/i386-portbld-freebsd6.0/4.2.0/include/c++//backward
/usr/local/include
/usr/local/lib/gcc/i386-portbld-freebsd6.0/4.2.0/gcc/i386-portbld-freebsd6.0/4.2.0/include
/usr/include
End of search list.
macroarg.cc:16:4: error: macro "MYMACRO" passed 2 arguments, but takes just 1
END COMPILER OUTPUT
For completeness since it is asked for, following is the pre-processor file
which is incomplete for obvious reasons:
=== BEGIN PRE-PROCESSOR OUTPUT ===
# 1 "macroarg.cc"
# 1 ""
# 1 ""
# 1 "macroarg.cc"
template
class SomeClass
{
};
int
main(void)
{
MYMACRO;
}
=== END PRE-PROCESSOR OUTPUT ===
It seems to be triggered when the type is parameterized on at least two types.
Removing the MYMACRO({...}) wrapping makes it compile. Putting just about
anything except certain template heavy stuff inside it also compiles.
(The above is obviously a contrived example to trigger the issue; my real usage
is a macro for critical sections with guaranteed mutex cleanup.)
--
Summary: Use of templates in macro expansion confuses pre-
processor
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter dot schuller at infidyne dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26531
[Bug target/26508] 4.1.0 doesn't build in 64bit on PA-RISC
--- Comment #9 from steven at gcc dot gnu dot org 2006-03-02 17:47 --- Not being able to use the HP assembler is definitely not a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26508
[Bug target/26530] -Os size optimization causes segfault for exception thrown
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 16:32 --- This works in 4.1.0 and above. Closing as fixed since this is not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.0.3 4.0.0 3.4.4 3.3.6 Known to work||4.1.0 4.2.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26530
[Bug c++/26530] New: -Os size optimization causes segfault for exception thrown
The following code will segfault when saying:
g++ -Os test.cpp -o test && ./test
but not with any other -O? options such as
g++ -O3 test.cpp -o test && ./test
preprocessed source:
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "test.cpp"
int main()
{
try{
throw 8;
}catch(...){}
}
--
Summary: -Os size optimization causes segfault for exception
thrown
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: M dot Schouten at phys dot uu dot nl
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=26530
[Bug testsuite/25177] [4.1/4.2 Regression] gcc.target/powerpc/pr18096-1.c fails on PPC
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 16:27 --- This also happens on the 4.1 branch too, I did not notice it until today. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 Regression]|[4.1/4.2 Regression] |gcc.target/powerpc/pr18096- |gcc.target/powerpc/pr18096- |1.c fails on PPC |1.c fails on PPC Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25177
[Bug ada/26529] [4.1/4.2 Regression] Compiler crash when 'use' clause for ADA record is defined
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 16:19 --- __builtin_memcpy (&_init->protocol_characteristics.F, &T52s.F, 30); Reduced testcase: package DATA is type UNSIGNED_8 is new INTEGER range 0 .. (2 ** 8) - 1; for UNSIGNED_8'SIZE use 8; type ADDRESS_T is array (1 .. 4) of UNSIGNED_8; type IPM_PROTOCOL_CHARACTERISTICS_T is record IPM_ADDRESS_1: ADDRESS_T; end record; for IPM_PROTOCOL_CHARACTERISTICS_T use record IPM_ADDRESS_1 at 0 range 0 .. 4 * 8 - 1; end record; type PROTOCOL_T is (LLC, IPM); type PROTOCOL_CHARACTERISTICS_T (PROTOCOL : PROTOCOL_T := IPM) is record case PROTOCOL is when LLC => MULTICAST_ADDRESS_1 : STRING(1 .. 14); when IPM => IPM_PROTOCOL_CHARACTERISTICS : IPM_PROTOCOL_CHARACTERISTICS_T; end case; end record; type DATA_T is record PROTOCOL_CHARACTERISTICS : PROTOCOL_CHARACTERISTICS_T; end record; for DATA_T use record PROTOCOL_CHARACTERISTICS at 0 range 0 .. 33 * 8 - 1; end record; end DATA; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.0 4.2.0 Known to work||4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-03-02 16:19:25 date|| Summary|Compiler crash when 'use' |[4.1/4.2 Regression] |clause for ADA record is|Compiler crash when 'use' |defined |clause for ADA record is ||defined Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26529
[Bug ada/26529] Compiler crash when 'use' clause for ADA record is defined
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-02 16:12 --- gcc_assert (! DECL_BIT_FIELD (field)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26529
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-02 16:10 --- aermod of Polyhedron has the same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-02 16:10 --- (In reply to comment #7) > On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Has VRP > become more aggressive, or might it have a new bug? VRP has become more aggressive or it might be still a bug. There is not enough information in the bug report to tell. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #4 from bjkeen at super dot org 2006-03-02 16:06 --- I have this same problem, only with Fedora Core 2/x86, building the cross-compiler for AVR as well. gcc4.1 and gcc 4.03 both stop with this error. I have attached the preprocessed source file resulting from the following command. bash-2.05b$ /scr/gcc41avrbld/./gcc/xgcc -B/scr/gcc41avrbld/./gcc/ -B/u03/bjkeen/local/avr/bin/ -B/u03/bjkeen/local/avr/lib/ -isystem /u03/bjkeen/local/avr/include -isystem /u03/bjkeen/local/avr/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.1.0/gcc -I../../gcc-4.1.0/gcc/. -I../../gcc-4.1.0/gcc/../include -I../../gcc-4.1.0/gcc/../libcpp/include -DL_fixunssfsi -c ../../gcc-4.1.0/gcc/libgcc2.c -o libgcc/./_fixunssfsi.o -save-temps ../../gcc-4.1.0/gcc/libgcc2.c: In function '__fixunssfsi': ../../gcc-4.1.0/gcc/libgcc2.c:1499: internal compiler error: in compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10445 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug bootstrap/23927] --enable-intermodule is broken on targets with mutlilibs even with --disable-multilib
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 16:04 --- Fixed for 4.2.0 by enabling of toplevel bootstrap. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23927
[Bug ada/26529] New: Compiler crash when 'use' clause for ADA record is defined
When moving from gcc 3.4.3 to 4.1.0, I found a record definition, that causes a compiler crash: 4.1.0 (i686-pc-linux-gnu) in get_memory_rtx, at builtins.c:1086 raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 The compiler has been compiled from source without any special settings, i.e. > configure --prefix=/opt/gcc-4.1.0 --enable-languages=ada,c > make bootstrap > make install The problem can be reproduced by compiling the source file below, using the following command line: gcc -c -O data.ads When the marked use clause is removed, gcc 4.1.0 does not crash. This simplified example is also compiling, when the -O is omitted, however this did not help in the original context. data.ads: == package DATA is type UNSIGNED_8 is new INTEGER range 0 .. (2 ** 8) - 1; for UNSIGNED_8'SIZE use 8; type UNSIGNED_16 is new INTEGER range 0 .. (2 ** 16) - 1; for UNSIGNED_16'SIZE use 16; type ADDRESS_T is array (1 .. 4) of UNSIGNED_8; type IPM_PROTOCOL_CHARACTERISTICS_T is record IPM_SOCKET_1_AVAILABLE : BOOLEAN; IPM_SOCKET_2_AVAILABLE : BOOLEAN; IPM_SOCKET_3_AVAILABLE : BOOLEAN; IPM_SOCKET_4_AVAILABLE : BOOLEAN; IPM_PORT_1 : UNSIGNED_16; IPM_PORT_2 : UNSIGNED_16; IPM_PORT_3 : UNSIGNED_16; IPM_PORT_4 : UNSIGNED_16; IPM_ADDRESS_1: ADDRESS_T; IPM_ADDRESS_2: ADDRESS_T; IPM_ADDRESS_3: ADDRESS_T; IPM_ADDRESS_4: ADDRESS_T; end record; for IPM_PROTOCOL_CHARACTERISTICS_T use record IPM_ADDRESS_1 at 0 range 0 .. 4 * 8 - 1; IPM_ADDRESS_2 at 4 range 0 .. 4 * 8 - 1; IPM_ADDRESS_3 at 8 range 0 .. 4 * 8 - 1; IPM_ADDRESS_4 at 12 range 0 .. 4 * 8 - 1; IPM_PORT_1 at 16 range 0 .. 2 * 8 - 1; IPM_PORT_2 at 18 range 0 .. 2 * 8 - 1; IPM_PORT_3 at 20 range 0 .. 2 * 8 - 1; IPM_PORT_4 at 22 range 0 .. 2 * 8 - 1; IPM_SOCKET_1_AVAILABLE at 24 range 0 .. 1 * 8 - 1; IPM_SOCKET_2_AVAILABLE at 25 range 0 .. 1 * 8 - 1; IPM_SOCKET_3_AVAILABLE at 26 range 0 .. 1 * 8 - 1; IPM_SOCKET_4_AVAILABLE at 27 range 0 .. 1 * 8 - 1; end record; for IPM_PROTOCOL_CHARACTERISTICS_T'Size use 28 * 8; type PROTOCOL_T is (LLC, IPM); for PROTOCOL_T use ( LLC => 1, IPM => 2 ); type PROTOCOL_CHARACTERISTICS_T (PROTOCOL : PROTOCOL_T := IPM) is record case PROTOCOL is when LLC => SAP_NUMBER : STRING(1 .. 3); MULTICAST_ADDRESS_1 : STRING(1 .. 14); MULTICAST_ADDRESS_2 : STRING(1 .. 14); when IPM => IPM_PROTOCOL_CHARACTERISTICS : IPM_PROTOCOL_CHARACTERISTICS_T; end case; end record; for PROTOCOL_CHARACTERISTICS_T use record PROTOCOL at 0 range 0 .. 7; SAP_NUMBERat 2 range 0 .. 3 * 8 - 1; MULTICAST_ADDRESS_1 at 2 + 3 range 0 .. 14 * 8 - 1; MULTICAST_ADDRESS_2 at 2 + 3 + 14 range 0 .. 14 * 8 - 1; IPM_PROTOCOL_CHARACTERISTICS at 2 range 0 .. 28 * 8 - 1; end record; type DATA_T is record PROTOCOL_CHARACTERISTICS : PROTOCOL_CHARACTERISTICS_T; end record; -- Disable this use clause to get it compiled for DATA_T use record PROTOCOL_CHARACTERISTICS at 0 range 0 .. 33 * 8 - 1; end record; end DATA; == -- Summary: Compiler crash when 'use' clause for ADA record is defined Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus dot heichel at comsoft dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26529
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #3 from bjkeen at super dot org 2006-03-02 16:03 --- Created an attachment (id=10956) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10956&action=view) compute_frame_pointer_to_cfa_displacement internal error source trigger -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug fortran/25953] Help on the solution for the large file unit numbers problem
--- Comment #5 from luiscasinhas at mail dot telepac dot pt 2006-03-02 15:03 --- Sure! Please feel free to change the current bug status to whatever status you may see fit. Best regards -- luiscasinhas at mail dot telepac dot pt changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25953
[Bug target/26457] -fstack-protector leaks the upper bits of RAX
--- Comment #5 from jakub at gcc dot gnu dot org 2006-03-02 14:48 ---
(define_insn "*movdi_xor_rex64"
[(set (match_operand:DI 0 "register_operand" "=r")
(match_operand:DI 1 "const0_operand" "i"))
(clobber (reg:CC FLAGS_REG))]
"TARGET_64BIT && (!TARGET_USE_MOV0 || optimize_size)
&& reload_completed"
"xor{l}\t{%k0, %k0|%k0, %k0}"
[(set_attr "type" "alu1")
(set_attr "mode" "SI")
(set_attr "length_immediate" "0")])
and say:
long foo (void) { return 0; }
with -m64 -O2 gives:
xorl%eax, %eax
ret
If xorl %eax, %eax did not zero extend to 64-bits, GCC compiled code wouldn't
really work.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
[Bug target/26457] -fstack-protector leaks the upper bits of RAX
--- Comment #4 from pluto at agmk dot net 2006-03-02 14:32 --- http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24592.pdf page 33: [ Zero-Extension of 32-Bit Results. ] (...) when performing 32-bit operations with a GPR destination in 64-bit mode, the processor zero-extends the 32-bit result into the full 64-bit destination. 8-bit and 16-bit operations on GPRs preserve all unwritten upper bits of the destination GPR. This is consistent with legacy 16-bit and 32-bit semantics for partial-width results. Software should explicitly sign-extend the results of 8-bit, 16- bit, and 32-bit operations to the full 64-bit width before using the results in 64-bit address calculations. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-02 14:29 --- (In reply to comment #6) > If I understand correctly, this is most likely a bug in FFTW, right? If so, > I'll report it to FFTW people. On the other hand, gcc 4.1 also has VRP, but it seems to work fine. Has VRP become more aggressive, or might it have a new bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug debug/26330] [4.0 only] gcc generates code that does not allow retrieval of struct arguments with debugger
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-debug Known to fail|4.0.3 4.1.0 |4.0.3 Summary|gcc generates code that does|[4.0 only] gcc generates |not allow retrieval of |code that does not allow |struct arguments with |retrieval of struct |debugger|arguments with debugger Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
[Bug debug/26330] gcc generates code that does not allow retrieval of struct arguments with debugger
--- Comment #3 from randolph at tausq dot org 2006-03-02 14:27 --- Subject: Re: gcc generates code that does not allow retrieval of struct arguments with debugger pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:37 > --- > According to known to fail, it fails in 4.1.0 but Jim's comment suggest > otherwise, hmm. > Yes, with latest gcc-4.1 the problem is gone. Can the relevant patch be backported to gcc-4.0? thanks, randolph -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
[Bug tree-optimization/15826] don't use "if" to extract a single bit bit-field.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 14:24 --- This is interesting, we now get BIT_FIELD_REF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
[Bug middle-end/18908] Missed folding opportunities with bools
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-02 14:21 --- (In reply to comment #9) > Acutally f3 is not fixed but I don't understand how not. No f3 is fine, f4 is broken still. *p = (int) *p != -1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
[Bug bootstrap/26053] [4.1/4.2 Regression] Misdetection of COMDAT group support with GNU as and non-GNU ld
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-03-02 14:15 --- *** Bug 24345 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||bugzilla-gcc at ||thewrittenword dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26053
[Bug libstdc++/24345] libstdc++ build failure with IRIX ld(1)
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-03-02 14:15 --- *** This bug has been marked as a duplicate of 26053 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24345
[Bug target/26146] [4.2 Regression] Bootstrapping mainline on Solaris 10/x86 fails
--- Comment #6 from brett dot albertson at stratech dot com 2006-03-02 14:15 --- (In reply to comment #5) > A real patch for 4.2 is posted at > > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00094.html > I can confirm that this patch allows me to bootstrap again. I'm running the testsuite now just to check for any regressions, but I don't expect any. I'm not 100% certain that the configuration machinery is determining the architecture correctly on Solaris x86 since I am actually running on AMD64 CPU's in 64 bit mode. However, this didn't cause or fix that problem. thanks HJ! Brett Albertson -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146
[Bug libfortran/26499] gfortran - End of File incorrectly positioned after binary I/O.
--- Comment #7 from dir at lanl dot gov 2006-03-02 14:02 --- Hi Jerry, As you may have guessed, I added this problem to the things that my program looks for. You got that one and all the ones like it, but here is another one from a slightly different class (rewind after reading a eof instead of a backspace after reading a eof) - [dranta:~/tests/gfortran-D] dir% gfortran -o write28 write28.f [dranta:~/tests/gfortran-D] dir% write28 Abort [dranta:~/tests/gfortran-D] dir% cat write28.f program test dimension idata(1011) open(unit=11,form='unformatted') write(11)idata write(11)idata read(11,end=1000 )idata call abort() 1000 continue rewind 11 write(11)idata close(11,status='keep') open(unit=11,form='unformatted') rewind 11 read(11)idata read(11, end=250)idata call abort() 250 continue close(11,status='delete') stop end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26499
[Bug target/26457] -fstack-protector leaks the upper bits of RAX
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 14:00 --- CCing Honza, maybe he knows the answer but I cannot find it in the ISA documention. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26457
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-03-02 13:52 --- (In reply to comment #5) > Can you try "-O3 -fwrapv"? It might be the source have undefined code in it > for signed overflow and changes to VRP exposed it. Bingo! Thanks for this hint, I wouldn't have found that alone! > Also do you know which file is being miscompiled? If so can you attach the > dump generated by doing -O3 -fdump-tree-vrp-details? Unfortunately I don't know which file causes the problem. I'm not a FFTW developer, I just stumbled on this by accident. If I understand correctly, this is most likely a bug in FFTW, right? If so, I'll report it to FFTW people. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-02 13:40 --- (In reply to comment #4) > "-O1 -ftree-vrp -finline-functions". > More to come... Can you try "-O3 -fwrapv"? It might be the source have undefined code in it for signed overflow and changes to VRP exposed it. Also do you know which file is being miscompiled? If so can you attach the dump generated by doing -O3 -fdump-tree-vrp-details? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug tree-optimization/25623] jump threading messes up "incoming frequencies" for some BBs
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-02 13:00 --- 4.1.0 has also after dom2: Invalid sum of incoming frequencies 673, should be 21 :; __builtin_abort (); Invalid sum of incoming frequencies 9327, should be 9979 :; return; 4.0.2 has even different mismatched frequencies. So at least not a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25623
[Bug tree-optimization/25623] jump threading messes up "incoming frequencies" for some BBs
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-02 12:57 --- Confirmed. It's dom2 messing up. -- 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 |2006-03-02 12:57:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25623
[Bug tree-optimization/25623] jump threading messes up "incoming frequencies" for some BBs
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:53 --- This still happens as of today. with the C testcase from comment #1, we get: Invalid sum of incoming frequencies 894, should be 9 :; __builtin_abort (); Invalid sum of incoming frequencies 9106, should be 9991 :; return; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25623
[Bug debug/26330] gcc generates code that does not allow retrieval of struct arguments with debugger
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:37 --- According to known to fail, it fails in 4.1.0 but Jim's comment suggest otherwise, hmm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-02 12:29 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|compute_frame_pointer_to_cfa|compute_frame_pointer_to_cfa |_displacement error for avr |_displacement error for avr |target |target with --with-dwarf2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug target/26146] [4.2 Regression] Bootstrapping mainline on Solaris 10/x86 fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-02 12:29:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146
[Bug c++/26291] [3.4/4.0/4.1/4.2 regression] Invalid ellipsis in operator not diagnosed
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-03-02 12:22 --- Now also fixed on the 4.1 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.1 regression] Invalid|[3.4/4.0/4.1/4.2 regression] |ellipsis in operator not|Invalid ellipsis in operator |diagnosed |not diagnosed Target Milestone|4.1.1 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
[Bug c++/26291] [4.1 regression] Invalid ellipsis in operator not diagnosed
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-03-02 12:20 --- Subject: Bug 26291 Author: reichelt Date: Thu Mar 2 12:20:52 2006 New Revision: 111637 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111637 Log: PR c++/26291 * decl.c (grok_op_properties): Check for ellipsis in arguments of operators. * g++.dg/other/ellipsis1.C: New test. * g++.dg/parse/operator4.C: Adjust error marker. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/other/ellipsis1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/operator4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #4 from martin at mpa-garching dot mpg dot de 2006-03-02 12:18 --- (In reply to comment #3) > Do you have a simple testcase? I wish I had :( At the moment I'm trying to find out which optimisation flags are causing the trouble. The current minimum set of flags to reproduce it is "-O1 -ftree-vrp -finline-functions". More to come... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug middle-end/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-02 12:15 --- Do you have a simple testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug c/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #2 from martin at mpa-garching dot mpg dot de 2006-03-02 11:01 --- (In reply to comment #1) > I just checked that > > CFLAGS="-O3" ./configure --enable-portable-binary > > fails, but > > CFLAGS="-O3" ./configure --enable-portable-binary Sorry for the typo here. I meant, of course, CFLAGS="-O2" ./configure --enable-portable-binary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug c/26528] [4.2 regression] gcc miscompiles FFTW 3.1
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-03-02 11:00 --- I just checked that CFLAGS="-O3" ./configure --enable-portable-binary fails, but CFLAGS="-O3" ./configure --enable-portable-binary works as it should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
[Bug fortran/26500] [4.2 Regression] info/gfortran.info is no longer being installed
--- Comment #2 from bonzini at gnu dot org 2006-03-02 10:47 --- Recategorizing to bootstrap since it is a build system bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
[Bug fortran/26500] [4.2 Regression] info/gfortran.info is no longer being installed
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-02 10:45:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE
--- Comment #10 from aph at gcc dot gnu dot org 2006-03-02 10:31 --- No, that patch doesn't help. Still get the same result at -O2: [EMAIL PROTECTED] eclipse]$ /home/aph/gcc/install/bin/gcj -c -O2 -g -fPIC -findirect-dispatch -fjni AbstractCommentParser.class org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser.java: In class 'org.eclipse.jdt.internal.compiler.parser.AbstractCommentParser': org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser.java: In method 'org.eclipse.jdt.internal.compiler.parser.AbstractCommentParser.commentParse()': org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser.java:0: error: control flow in the middle of basic block 32 org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser.java:0: error: control flow in the middle of basic block 32 org/eclipse/jdt/internal/compiler/parser/AbstractCommentParser.java:0: internal compiler error: verify_flow_info failed 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=26447
[Bug libstdc++/26526] [4.1/4.2 Regression] std::__copy_streambufs link failure when _GLIBCXX_DEBUG is defined
--- Comment #2 from pcarlini at suse dot de 2006-03-02 10:24 --- Benjamin, can you have a look? The issue seems simple, in its essence: on 64-bit machines the recently added __copy_streambufs export is wrong - in fact we are not exporting anything - because it reads everywhere: _ZSt17__copy_streambufsI[cw]St11char_traitsI[cw]EEiPSt15basic_streambuf* and should be, on 64-bit machines, note l, not i, after the EE: _ZSt17__copy_streambufsI[cw]St11char_traitsI[cw]EElPSt15basic_streambuf* The only problem now is doing the right thing wrt the library abi, i.e., I'm not sure we can simply adjust now the export @GLIBCXX_3.4.6... -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26526
[Bug target/26511] Using -O3, doesn't assign in a pointer to a global structure
--- Comment #4 from wielemak at science dot uva dot nl 2006-03-02 10:08 --- Oops, must be ./configure --enable-mt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26511
[Bug fortran/15335] runtime error "Attempt to allocate a negative amount of memory"
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2006-03-02 09:37 --- (In reply to comment #17) > For i=3 or greater, gfortran and ifort agree on the value of b. However, for > the above, gfortran now gives 0, whilst ifort gives 1. I happen to think that > 0 makes more sense but does anybody know the accepted result? I think this is PR 25378. The correct answer is undefined as per F95, and is 1 as per F2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15335
[Bug target/26511] Using -O3, doesn't assign in a pointer to a global structure
--- Comment #3 from wielemak at science dot uva dot nl 2006-03-02 09:24 --- Andrew, If you think this is a real and still present bug I could try to add a little main() to the file and turn the file into a stand-alone program. I guess it is pretty likely it depends on nasty details in the structure definitions and it will be a lot of work to cut down the headers and still be able to compile the program and reproduce the bug. If you simply want to reproduce, fetch pl-5.6.6.tar.gz from http://gollem.science.uva.nl/cgi-bin/nph-download/SWI-Prolog/pl-5.6.6.tar.gz Unpack, goto pl-5.6.6/src, type ./configure, add -g to COFLAGS in Makefile, make (few warnings, these are fixed already but do not affect this problem), abort Prolog which will be crashing in a loop using ^\. Now gdb pl (gdb) break initPrologThreads (gdb) run (gdb) finish (gdb) print *info And you see the problem. The nasty thing is that if you add a print-statement reading the info->pl_tid, it is compiled correctly. It gives the impression that somehow gcc thinks the value is never used and it thus can ignore the assignment. As the structure is in global memory (part of the threads[] array) and it *is* used, this is of course completely wrong. Cheers --- Jan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26511
[Bug middle-end/4210] should not warning with dead code
--- Comment #17 from mattias at virtutech dot se 2006-03-02 09:22 --- We have resorted to case-by-case workarounds, usually a cast which would have been an identity operation had the condition been true. That is, if (sizeof x == 8) return x << 32 | x; would have its second line mutated to return (unsigned long long)x << 32 | x; The cast is always a no-op unless it occurs in dead code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
[Bug c/26528] New: [4.2 regression] gcc miscompiles FFTW 3.1
Current mainline gcc appears to miscompile FFTW: wget http://fftw.org/fftw-3.1.tar.gz tar xvzf fftw-3.1.tar.gz cd fftw-3.1 /scratch/fftw-3.1> gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,fortran --with-gmp=/usr/local/appl/gmp-4.1.4 --enable-checking=release --without-makeinfo Thread model: posix gcc version 4.2.0 20060301 (experimental) /scratch/fftw-3.1> ./configure --enable-portable-binary [...] /scratch/fftw-3.1> make check [...] Executing "/scratch/fftw-3.1/tests/bench --verbose=1 --verify ok12o10x6e10x11o00v7 --verify ik12o10x 6e10x11o00v7 --verify obr3v79 --verify ibr3v79 --verify ofr3v79 --verify ifr3v79 --verify //obc3v79 -- verify //ibc3v79 --verify //ofc3v79 --verify //ifc3v79 --verify obc3v79 --verify ibc3v79 --verify ofc3 v79 --verify ifc3v79 --verify ok2hx5e00x3e10x7o11*6 --verify ik2hx5e00x3e10x7o11*6 --verify //obr10x8x 33 --verify //ofr10x8x33 --verify obr10x8x33 --verify ibr10x8x33 --verify ofr10x8x33 --verify ifr10x8x 33 --verify //obc10x8x33 --verify //ibc10x8x33 --verify //ofc10x8x33 --verify //ifc10x8x33 --verify ob c10x8x33 --verify ibc10x8x33 --verify ofc10x8x33 --verify ifc10x8x33 --verify ok11o00*45 --verify ik11 o00*45 --verify obr6x4v7 --verify ibr6x4v7 --verify ofr6x4v7 --verify ifr6x4v7 --verify //obc6x4v7 --v erify //ibc6x4v7 --verify //ofc6x4v7 --verify //ifc6x4v7 --verify obc6x4v7 --verify ibc6x4v7 --verify ofc6x4v7 --verify ifc6x4v7" 2.65417e-16 4.02852e-15 3.09912e-16 2.76156e-16 2.52972e-15 2.83568e-16 2.17601e-16 3.37283e-16 2.97118e-16 2.03315e-16 3.37283e-16 2.49555e-16 2.33093e-16 1.49904e-16 3.95845e-16 2.09027e-16 1.49904e-16 3.70199e-16 1.94987e-16 2.24855e-16 4.92525e-16 1.97747e-16 2.24855e-16 5.28462e-16 1.71722e-16 2.24855e-16 4.74119e-16 2.0242e-16 2.24855e-16 5.51321e-16 1.85902e-16 2.24855e-16 4.94966e-16 2.13346e-16 2.24855e-16 4.9348e-16 2.12188e-16 2.24855e-16 5.26624e-16 2.12652e-16 2.24855e-16 4.99894e-16 2.75703e-16 2.60691e-15 2.91529e-16 4.46832e-16 4.43175e-15 3.46477e-16 FAILED /scratch/fftw-3.1/tests/bench: --verify ok12o10x6e10x11o00v7 --verify ik12o10x6e10x11o00v7 --v erify obr3v79 --verify ibr3v79 --verify ofr3v79 --verify ifr3v79 --verify //obc3v79 --verify //ibc3v79 --verify //ofc3v79 --verify //ifc3v79 --verify obc3v79 --verify ibc3v79 --verify ofc3v79 --verify ifc 3v79 --verify ok2hx5e00x3e10x7o11*6 --verify ik2hx5e00x3e10x7o11*6 --verify //obr10x8x33 --verify //of r10x8x33 --verify obr10x8x33 --verify ibr10x8x33 --verify ofr10x8x33 --verify ifr10x8x33 --verify //ob c10x8x33 --verify //ibc10x8x33 --verify //ofc10x8x33 --verify //ifc10x8x33 --verify obc10x8x33 --verif y ibc10x8x33 --verify ofc10x8x33 --verify ifc10x8x33 --verify ok11o00*45 --verify ik11o00*45 --verify obr6x4v7 --verify ibr6x4v7 --verify ofr6x4v7 --verify ifr6x4v7 --verify //obc6x4v7 --verify //ibc6x4v7 --verify //ofc6x4v7 --verify //ifc6x4v7 --verify obc6x4v7 --verify ibc6x4v7 --verify ofc6x4v7 --verif y ifc6x4v7 received signal 11 make[2]: *** [check-local] Error 1 make[2]: Leaving directory `/scratch/fftw-3.1/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/scratch/fftw-3.1/tests' make: *** [check-recursive] Error 1 The current 4.1 and 4.0 branches pass the FFTW tests. Gomp-branch fails. I know that this is not a very useful bug report, but I have no idea how to reduce the problem. A regression hunt might at least localise the problematic commit and help to decide whether gcc or FFTW is to blame. -- Summary: [4.2 regression] gcc miscompiles FFTW 3.1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26528
