[Bug preprocessor/40376] GCC defines UNICODE instead of _UNICODE for -municode
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-09 06:52 ---
(In reply to comment #4)
Subject: Re: GCC defines UNICODE instead of _UNICODE
for -municode
UNICODE is in the user's namespace; it should not be predefined if
flag_iso (if you have to use specs rather than hooks, you need
%{!ansi:%{!std=i*:%{!std=c*:-DUNICODE}}} to detect the various conformance
options). We should not add to the instances of bug 545 that are still
present. If the MinGW headers use a macro in the user's namespace as a
feature test macro of some sort, they are buggy and should be fixed (with
fixincludes if necessary for existing installations).
It is right that _UNICODE and UNICODE are in user name space defined and are
controlling which API (wide/or ascii) has to be used.
UNICODE is used in windows headers itself (see msdn for documentation).
_UNICODE is used in CRT (and inspecial in tchar.h header) only. (This is also
documented in msdn).
I agree, that these two different macro names are a bit annoying, but for sure
they are platform specific stuff and are for sure absolutely unrelated to ISO.
Therefore to introduce a relationship to ISO defines is contradictive and
wrong. Those macros are controling behaviour of runtime. By the windows
specific switch -municode the windows runtime is controlled.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40376
[Bug c++/40381] [4.4/4.5 Regression] ICE with defaulted functions
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug c++/40381] New: [4.4/4.5 Regression] ICE with defaulted functions
The following invalid code snippet triggers an ICE since GCC 4.4.0:
==
struct A
{
templatetypename T void foo(T) = delete;
};
templatetypename T void A::foo(T) {}
void bar()
{
A().foo(0);
}
==
bug.cc:6:27: error: redefinition of 'void A::foo(T)'
bug.cc:3:29: error: 'void A::foo(T)' previously declared here
bug.cc: In function 'void bar()':
bug.cc:3:29: error: deleted function 'void A::foo(T) [with T = int]'
bug.cc:10:12: error: used here
bug.cc: In member function 'void A::foo(T) [with T = int]':
bug.cc:10:12: instantiated from here
bug.cc:6:38: internal compiler error: in finish_function, at cp/decl.c:12250
Please submit a full bug report, [etc.]
By modifying the definition of foo, I can provoke crashes in different parts
of the compiler:
templatetypename T void A::foo(T) { A(); }
yields
bug.cc:6:39: internal compiler error: in poplevel, at cp/decl.c:536
and
templatetypename T void A::foo(T) { return; }
yields
bug1C.cc:6:39: internal compiler error: Segmentation fault
This is a regression as the compiler crashes even without -std=gnu++0x.
--
Summary: [4.4/4.5 Regression] ICE with defaulted functions
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug c++/40382] New: Useless instructions in destructor
Compile following simple class with -O2 -Os -mthumb -fpic
class base {
virtual ~base();
};
base::~base()
{
}
The destructor of this class should do nothing, just return is enough. But gcc
generats following codes for D1 version destructor:
ldr r3, .L3
ldr r1, .L3+4
add r3, pc
ldr r2, [r3, r1]
add r2, r2, #8
str r2, [r0]
bx lr
.L3:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word _ZTV4base(GOT)
--
Summary: Useless instructions in destructor
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40382
[Bug c++/40382] Useless instructions in destructor
--- Comment #1 from carrot at google dot com 2009-06-09 07:35 ---
Created an attachment (id=17969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17969action=view)
simple class with empty virtual destructor
Some tree dump result
1. The tree dump of early stage:
cat test_class.cpp.003t.original
;; Function virtual base::~base() (null)
;; enabled by -tree-original
{
cleanup_point Unknown tree: expr_stmt
(void) (((struct base *) this)-_vptr.base = _ZTV4base + 8)
;
}
D.1756:;
if ((bool) (__in_chrg 1))
{
cleanup_point Unknown tree: expr_stmt
operator delete ((void *) this)
;
}
return this;
2. The tree dump of late stage, the reset of vptr is redundant.
cat test_class.cpp.130t.final_cleanup
;; Function base::~base() (_ZN4baseD2Ev)
base::~base() (struct base * const this)
{
bb 2:
this-_vptr.base = _ZTV4base[2];
return this;
}
;; Function virtual base::~base() (_ZN4baseD1Ev)
virtual base::~base() (struct base * const this)
{
bb 2:
this-_vptr.base = _ZTV4base[2];
return this;
}
;; Function virtual base::~base() (_ZN4baseD0Ev)
virtual base::~base() (struct base * const this)
{
bb 2:
this-_vptr.base = _ZTV4base[2];
operator delete (this);
return this;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40382
[Bug fortran/40383] New: [4.5 Regression] incorrect bounds checking with optional character arguments
trunk has been broken with CP2K since some time, which I believed to be a side effect of PR40332, but the following is a stand-alone reduced testcase: vond...@pcihopt3:/data03/vondele/bug gfortran -fbounds-check -g test.f90 vond...@pcihopt3:/data03/vondele/bug ./a.out At line 8 of file test.f90 Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'a' (0/80) vond...@pcihopt3:/data03/vondele/bug cat test.f90 MODULE M1 INTEGER, PARAMETER :: default_string_length=80 END MODULE M1 MODULE M2 USE M1 IMPLICIT NONE CONTAINS FUNCTION F1(a,b,c,d) RESULT(RES) CHARACTER(LEN=default_string_length), OPTIONAL :: a,b,c,d LOGICAL :: res END FUNCTION F1 END MODULE M2 MODULE M3 USE M1 USE M2 IMPLICIT NONE CONTAINS SUBROUTINE S1 CHARACTER(LEN=default_string_length) :: a,b LOGICAL :: L1 INTEGER :: i DO I=1,10 L1=F1(a,b) ENDDO END SUBROUTINE END MODULE M3 USE M3 CALL S1 END this is likely related to the optional arguments. -- Summary: [4.5 Regression] incorrect bounds checking with optional character arguments Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
[Bug fortran/40383] [4.5 Regression] incorrect bounds checking with optional character arguments
--- Comment #1 from jv244 at cam dot ac dot uk 2009-06-09 07:44 --- I'm guessing due to : 2009-04-11 Daniel Kraft d...@domob.eu PR fortran/37746 -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #3 from jv244 at cam dot ac dot uk 2009-06-09 08:34 --- Jakub, the error message I get below is new with gcc 4.5, and is still present as of revision 148276 (20090608). Is there any info I can provide (e.g. attach the object file?) that could help in getting this resolved as either a gcc or a binutils issue. Joost -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug target/40375] redundant register move with -mthumb
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-09 08:34 --- Hmm, I was under the impression that postreload-cse could move instructions too, but that was just wishful thinking. I don't really see how the scheduler can solve this. The scheduler would have to know what the live ranges of r0 and r133 overlap, but we don't have an interference graph in the scheduler. Maybe calculating conflicts locally and adjusting scheduling priorities based on that? What improvement to pre-RA scheduling do you have in mind? Perhaps an easier solution would be to change the order of the parameter loads or stores. Right now GCC does this from this pre-RA to post-RA: (set (reg:SI 133) (reg:SI r0)) (set (reg:SI 134) (reg:SI r1)) (set (reg:SI r0) (const_int 0)) (set (reg:SI r1) (reg:SI r133)) (set (reg:SI r2) (reg:SI r134)) (call foo) == (set (reg:SI r3) (reg:SI r0)) (set (reg:SI r2) (reg:SI r1)) (set (reg:SI r0) (const_int 0)) (set (reg:SI r1) (reg:SI r3)) (set (reg:SI r2) (reg:SI r2)) // NOP move, so eliminated (call foo) == (set (reg:SI r3) (reg:SI r0)) (set (reg:SI r2) (reg:SI r1)) (set (reg:SI r0) (const_int 0)) (set (reg:SI r1) (reg:SI r3)) (call foo) There is always going to be a conflict if GCC generate the above RTL before register allocation, so maybe the generated RTL should be changed. If GCC would emit the parameter stores before the call in reverse order, then the conflicts would go away too: (set (reg:SI 133) (reg:SI r0)) (set (reg:SI 134) (reg:SI r1)) (set (reg:SI r2) (reg:SI r134)) (set (reg:SI r1) (reg:SI r133)) (set (reg:SI r0) (const_int 0)) (call foo) == (set (reg:SI r0) (reg:SI r0)) // NOP move, so eliminated (set (reg:SI r2) (reg:SI r1)) (set (reg:SI r2) (reg:SI r2)) // NOP move, so eliminated (set (reg:SI r1) (reg:SI r0)) (set (reg:SI r0) (const_int 0)) (call foo) == (set (reg:SI r2) (reg:SI r1)) (set (reg:SI r1) (reg:SI r0)) (set (reg:SI r0) (const_int 0)) (call foo) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-09 08:34:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #4 from jakub at gcc dot gnu dot org 2009-06-09 08:38 --- Start with trying newer binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #5 from jv244 at cam dot ac dot uk 2009-06-09 08:54 --- (In reply to comment #4) Start with trying newer binutils. same error with : /data03/vondele/binutils-2.19.1/build/bin/ld: error in /data03/vondele/clean/cp2k/src/../lib/Linux-x86-64-gfortran/sdbg/libcp2k_lib.a(ep_methods.o)(.eh_frame); no .eh_frame_hdr table will be created. make[2]: Leaving directory `/data03/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sdbg' make[1]: Leaving directory `/data03/vondele/clean/cp2k/src' vond...@pcihopt3:/data03/vondele/clean/cp2k/src ld -v GNU ld (GNU Binutils) 2.19.1 vond...@pcihopt3:/data03/vondele/clean/cp2k/src gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ Thread model: posix gcc version 4.5.0 20090608 (experimental) [trunk revision 148276] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #6 from jakub at gcc dot gnu dot org 2009-06-09 09:36 --- Couldn't reproduce (just built cp2k on x86_64-linux with trunk gfortran and .eh_frame_hdr has been created just fine). I'm using binutils 2.19.51.0.2. Anyway, you should probably just tar up the .a library and other things you are linking together and with that report it in binutils bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug fortran/40383] [4.5 Regression] incorrect bounds checking with optional character arguments
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-09 10:02:18 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
[Bug c++/34949] Dead code in empty destructors.
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-09 10:18 --- *** Bug 40382 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||carrot at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
[Bug c++/40382] Useless instructions in destructor
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-09 10:18 --- *** This bug has been marked as a duplicate of 34949 *** -- 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=40382
[Bug middle-end/40384] New: [4.5 regression] Revision 148277 failed 148277
Revision 148277: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00257.html caused: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00257.html We no longer generate prefetch. -- Summary: [4.5 regression] Revision 148277 failed 148277 Product: gcc Version: 4.5.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=40384
[Bug middle-end/40384] [4.5 regression] Revision 148277 failed 148277
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-09 10:24 --- Caused: FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch Issued prefetch 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40384
[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #7 from jv244 at cam dot ac dot uk 2009-06-09 10:26 --- (In reply to comment #6) Couldn't reproduce (just built cp2k on x86_64-linux with trunk gfortran and .eh_frame_hdr has been created just fine). I'm using binutils 2.19.51.0.2. Anyway, you should probably just tar up the .a library and other things you are linking together and with that report it in binutils bugzilla. It seems to depend on the compilation options as well. The sopt compile (in my case : FCFLAGS = -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form $(DFLAGS) -I$(GFORTRAN_INC) goes fine, while a -O0 compile (sdbg compile with flags: -O0 -g -ffree-form $(DFLAGS) -I$(GFORTRAN_INC) -fbounds-check ) produces warnings. In fact, the number of errors depends on the precise options. With -fbounds-check present, there are more errors than without the flag. Any chance you could try that ? make distclean make ARCH=... VESION=sdbg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug fortran/40383] [4.5 Regression] incorrect bounds checking with optional character arguments
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-09 10:29 --- I think the patch for PR fortran/37746 is OK, but something else goes wrong: f1 (character(kind=1)[1:80] * a, character(kind=1)[1:80] * b, character(kind=1)[1:80] * c, character(kind=1)[1:80] * d, integer(kind=4) _a, integer(kin d=4) _b, integer(kind=4) _c, integer(kind=4) _d) if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (_d = 79 (_d != 0 || a != 0B)), 0)) The the check itself is OK, but it should be _a and not _d: (_a = 79 (_a != 0 || a != 0B)) For some reason the length of the last string is always used. The source looks OK: fsym = formal-sym; cl = fsym-ts.cl; cond = fold_build2 (comparison, boolean_type_node, cl-passed_length, cl-backend_decl); Thus somehow cl-backend_decl is wrong. That is probably a side effect of all having the same length. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
[Bug boehm-gc/40385] New: [4.5 regression] Revision 148285 caused many failures
On Linux/ia64, revision 148285: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00265.html caused: FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is %.1f FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern test, is %.1f FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is %.1f FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is %.1f FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is %.1f FAIL: libffi.call/err_bad_abi.c -O0 -W -Wall execution test FAIL: libffi.call/err_bad_abi.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/err_bad_abi.c -O2 execution test FAIL: libffi.call/err_bad_abi.c -O3 execution test FAIL: libffi.call/err_bad_abi.c -Os execution test FAIL: libffi.call/err_bad_typedef.c -O0 -W -Wall execution test FAIL: libffi.call/err_bad_typedef.c -O2 -fomit-frame-pointer execution test FAIL: libffi.call/err_bad_typedef.c -O2 execution test FAIL: libffi.call/err_bad_typedef.c -O3 execution test FAIL: libffi.call/err_bad_typedef.c -Os execution test -- Summary: [4.5 regression] Revision 148285 caused many failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: boehm-gc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug boehm-gc/40385] [4.5 regression] Revision 148285 caused many failures
--- Comment #1 from aph at gcc dot gnu dot org 2009-06-09 10:38 --- These are new tests, and real bugs. They are not regressions, and may be XFAILed on ia64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug target/40332] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #8 from jv244 at cam dot ac dot uk 2009-06-09 10:52 --- (In reply to comment #6) Anyway, you should probably just tar up the .a library and other things you are linking together and with that report it in binutils bugzilla. filed this PR for binutiles, http://sourceware.org/bugzilla/show_bug.cgi?id=10255 and made the object files/libraries available (with README) http://www.pci.uzh.ch/vandevondele/tmp/PR40332.tgz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug c++/40381] [4.4/4.5 Regression] Revision 142379 caused ICE with deleted functions
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-09 11:39 --- This is caused by revision 142379: http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00077.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-09 11:39:33 date|| Summary|[4.4/4.5 Regression] ICE|[4.4/4.5 Regression] |with deleted functions |Revision 142379 caused ICE ||with deleted functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug fortran/40386] New: wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
I'm observing a wrong code generation bug with the 189.lucas benchmark in SPEC CPU2000. When the Fortran benchmark is being compiled with -O1 -fno-ira-share-spill-slots, the benchmark outputs the following: iteration= 2 000E iteration= 3 00C2 iteration= 4 9302 iteration= 5 546B4C02 iteration= 6 1BD696D9F03D3002 M75460003 Roundoff warning on iteration 7 maxerr = 0.49970088 FATAL ERROR...Halting execution. When compiled with -O1, this is (part of) the output (which is correct, as specified by the CPU2000 framework): iteration= 2 000E iteration= 3 00C2 iteration= 4 9302 iteration= 5 546B4C02 iteration= 6 1BD696D9F03D3002 iteration= 7 8CC88407A9F4C002 iteration= 8 55599F9D37D30002 snip iteration= 122 E9639F5835FD3C2C exponent residue 75460003 DDD9C8B13BCB64AE I'm sorry I'm unable to provide a self-contained testcase for this, but I know little about Fortran. I hope someone else can jump in and provide a testcase for me. -- Summary: wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kenneth dot hoste at elis dot ugent dot be GCC build triplet: linux, x86-64 GCC host triplet: linux, x86-64 GCC target triplet: linux, x86-64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug fortran/40383] [4.5 Regression] incorrect bounds checking with optional character arguments
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-09 12:09 ---
The problem is that fsym-ts.cl of all of a, b, c and d to the same
struct:
(gdb) p sym-formal-sym-name
$17 = 0x2ab31ec8 a
(gdb) p sym-formal-sym-ts
$18 = {... cl = 0x12b6da0 ...}
(gdb) p sym-formal-next-sym-name
$19 = 0x2ab31ed0 b
(gdb) p sym-formal-next-sym-ts
$20 = {... cl = 0x12b6da0 ...}
Thus f-sym-ts.cl-passed_length = length; in create_function_arglist does
not do what one expects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40383
[Bug middle-end/40386] wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-09 12:24 --- Richard, can you try to reproduce this? I don't have SPEC and anyhow it sounds like a middle-end problem. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug c++/40387] New: verify_cgraph_node failed with -O3
I just tried to compile the Suse Factory package Botan-1.6.4-4.48 with the GNU g++ version 4.5 snapshot 20090604. The compiler said modules/es_unix/es_unix.cpp:106:1: error: missing callgraph edge for call stmt: # VUSE .MEM_16 retval.72_11 = Unix_Program_Cmp (__val_10(D), __next$_M_current_3); void std::__unguarded_linear_insert(_RandomAccessIterator, _Tp, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iteratorBotan::Unix_Program*, std::vectorBotan::Unix_Program , _Tp = Botan::Unix_Program, _Compare = bool (*)(const Botan::Unix_Program, const Botan::Unix_Program)]/473(-1) @0x2ba81fb0d000 (inline copy in void std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iteratorBotan::Unix_Program*, std::vectorBotan::Unix_Program , _Compare = bool (*)(const Botan::Unix_Program, const Botan::Unix_Program)]/558) (clone of void std::__unguarded_linear_insert(_RandomAccessIterator, _Tp, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iteratorBotan::Unix_Program*, std::vectorBotan::Unix_Program , _Tp = Botan::Unix_Program, _Compare = bool (*)(const Botan::Unix_Program, const Botan::Unix_Program)]/482) availability:local 390 time, 17 benefit 29 size, 8 benefit body local finalized inlinable called by: void std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iteratorBotan::Unix_Program*, std::vectorBotan::Unix_Program , _Compare = bool (*)(const Botan::Unix_Program, const Botan::Unix_Program)]/558 (21.97 per call) (inlined) (can throw external) calls: std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::assign(const std::basic_string_CharT, _Traits, _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]/707 (21.97 per call) (nested in 1 loops) (can throw external) std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::assign(const std::basic_string_CharT, _Traits, _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]/707 (100.00 per call) (nested in 2 loops) (can throw external) modules/es_unix/es_unix.cpp:106:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required. -- Summary: verify_cgraph_node failed with -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40387
[Bug c++/40387] verify_cgraph_node failed with -O3
--- Comment #1 from dcb314 at hotmail dot com 2009-06-09 12:56 --- Created an attachment (id=17970) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17970action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40387
[Bug c++/40388] New: another null pointer in remove_unreachable_regions
I just tried to compile the Suse Factory package blocxx-2.1.0.342-124.7 with the GNU g++ version 4.5 snapshot 20090604. The compiler said SecureRand.cpp: In function 'voidunnamed::rand_init_impl()': SecureRand.cpp:667:7: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. Here is valgrind helping out with a stack backtrace ==8611== Invalid read of size 8 ==8611==at 0x6EE6FF: remove_unreachable_regions (bitmap.h:225) ==8611== Address 0x0 is not stack'd, malloc'd or (recently) free'd This bug seems to be different to # 40163. -- Summary: another null pointer in remove_unreachable_regions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40388
[Bug c++/40387] verify_cgraph_node failed with -O3
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-09 13:18 --- I can't reproduced it with revision 148309. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40387
[Bug fortran/40349] compiler crash with -O3
--- Comment #3 from pierphil at xs4all dot nl 2009-06-09 13:25 --- (In reply to comment #2) Also works for me on newer versions. This is very likely PR 36817. Please try a more recent compiler and reopen this bug if it persists. I managed to install the 4.4.0 version and that fixed it. Thanks. -- pierphil at xs4all dot nl changed: What|Removed |Added CC||pierphil at xs4all dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40349
[Bug middle-end/40386] wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
--- Comment #2 from kenneth dot hoste at elis dot ugent dot be 2009-06-09 13:35 --- I did some more experiments, and have some more details to share. It seems the problem with lucas only occurs with the SVN head of the 4.4 branch I'm working on (r148268), and not with the 4.4.0 release. However, a similar problem is occuring with the 172.mgrid benchmark, and this _is_ occuring both with the 4.4.0 release and with revision 148268 of the 4.4 branch. Again, -O1 -fno-ira-share-spill-slots leads to a binary not producing correct output (but there's not noticeable crash of the benchmark this time). Using -O1 yields no problems though. The SPEC framework reports the below as a diff between the expected and observed output for mgrid, and considers the difference to be serious enough to report the run to be invalid. 0019: 0.103090E-02 -0.907513E-03 ^ 0020: 0.103090E-02 -0.907513E-03 ^ 0021: 0.184495E-02 0.261074E-02 ^ 0022: 0.184495E-02 0.261074E-02 ^ 0023: 0.366257E-03 -0.677032E-04 ^ 0024: 0.366257E-03 -0.677032E-04 ^ 0025: 0.436098E-03 0.179609E-03 ^ 0026: 0.436098E-03 0.179609E-03 ^ 0027: 0.442029E-03 0.212079E-03 ^ 0028: 0.442029E-03 0.212079E-03 ^ 0029: 0.442962E-03 0.217171E-03 ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug target/40375] redundant register move with -mthumb
--- Comment #6 from carrot at google dot com 2009-06-09 13:52 --- (In reply to comment #5) Hmm, I was under the impression that postreload-cse could move instructions too, but that was just wishful thinking. I will look into postreload-cse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug middle-end/40386] wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
--- Comment #3 from kenneth dot hoste at elis dot ugent dot be 2009-06-09 14:12 --- Same problem with 187.facerec, 173.applu and 301.apsi: runs correctly at -O1, wrong code at -O1 -fno-ira-share-spill-slots. All these benchmarks are written Fortran (both F77 and F90), so it seems this might be Fortran related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug c++/40381] [4.4/4.5 Regression] Revision 142379 caused ICE with deleted functions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug tree-optimization/40384] [4.5 regression] Revision 148277 failed gcc.dg/tree-ssa/prefetch-5.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |tree-optimization Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40384
[Bug libffi/40385] [4.5 regression] Revision 148285 caused many failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug middle-end/40386] wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-09 14:22 --- Are you running in 32bit mode? Vlad, what does this IRA option do? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug middle-end/40102] [4.5 Regression] Revision 147294 caused ICE: verify_cgraph_node
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-09 14:24 --- *** Bug 40387 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40102
[Bug c++/40387] verify_cgraph_node failed with -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-09 14:24 --- *** This bug has been marked as a duplicate of 40102 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40387
[Bug middle-end/40388] [4.5 Regression] another null pointer in remove_unreachable_regions
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-09 14:27 --- Can you attach preprocessed source? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c++ |middle-end Keywords||ice-on-valid-code Summary|another null pointer in |[4.5 Regression] another |remove_unreachable_regions |null pointer in ||remove_unreachable_regions Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40388
[Bug middle-end/40386] wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
--- Comment #5 from kenneth dot hoste at elis dot ugent dot be 2009-06-09 14:30 --- (In reply to comment #4) Are you running in 32bit mode? No, I'm not. Using either -m32 or -m64 makes no difference for lucas, and if I'm either m32 or m64, then I still obtain a 64-bit binary (when not using -fno-ira-share-spill-slots), so definitely 64-bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug target/40375] redundant register move with -mthumb
--- Comment #7 from ramana at gcc dot gnu dot org 2009-06-09 14:32 --- (In reply to comment #6) (In reply to comment #5) Hmm, I was under the impression that postreload-cse could move instructions too, but that was just wishful thinking. I will look into postreload-cse. I've looked at this superficially and something that I noticed was that in the ARM case (i.e !-mthumb) there aren't any redundant moves - It works fine in the Register allocator but the only difference that I can see / think of is that we support sibling calls for ARM mode. We don't have sibling calls supported for Thumb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40375
[Bug middle-end/40386] wrong code generation for SPEC CPU2000's 189.lucas with -O1 -fno-ira-share-spill-slots
--- Comment #6 from kenneth dot hoste at elis dot ugent dot be 2009-06-09 14:51 --- Some more related details which might help shed light on the cause behind this. The 178.galgel benchmark (again, Fortran), is also being miscompiled, but now using -ffixed-form -fno-ira-share-spill-slots -fno-tree-loop-im in combination with -O3 or -Os. Note that -O1 and -O2 are working fine with these options specified. (-ffixed-form is always needed to compile galgel, so this one is probably of minor importance here) On top of this, additionally specifying -fno-tree-dominator-opts resolves the issue at -O3 (corrext code is being emitted), but this is not the case at -Os, where the miscompile still occurs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug c++/40365] g++ template expansion bug
--- Comment #2 from oleg_dolomanov at hotmail dot com 2009-06-09 15:04 --- This is the version info: o...@q4:/work/olex/svn/olex2/trunk g++ -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) and command line and error (fails on random functions): scons: Building targets ... g++ -o build/scons/release/generic/sfutil.o -c -D__WXWIDGETS__ -D_UNICODE -DUNICODE -pthread -exceptions -O3 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -Ialglib -Isdl -Iglib -Igxlib -Irepository -Ixlib -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -I/usr/include/python2.6 xlib/sfutil.cpp xlib/sfutil.h: In member function ‘void xlib::SF_Utilsg::Calculate(double, const xlib::TRefList, const esdl::mat3d, esdl::TArrayListesdl::TEComplexdouble , const esdl::TPtrListxlib::cm_Element, const xlib::TCAtomPList, const double*, bool) const [with sg = xlib::FastSG_P2_a]’: xlib/sfutil.h:249: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40365
[Bug middle-end/39284] Computed gotos combined too aggressively
--- Comment #11 from hubicka at gcc dot gnu dot org 2009-06-09 15:18
---
Hmm, it is not exactly load. In first case I get:
(code_label 12524 16482 12523 70 1249 [4 uses])
(note 12523 12524 149 70 [bb 70] NOTE_INSN_BASIC_BLOCK)
(insn:TI 149 12523 13690 70 ../src/Include/ceval-vm.i:47 (set (mem/c:SI
(plus:SI (reg/f:SI 6 bp)
(const_int -64 [0xffc0])) [72 %sfp+-40 S4 A32])
(const_int 1 [0x1])) 47 {*movsi_1} (expr_list:REG_EQUAL (const_int 1
[0x1])
(nil)))
(insn 13690 149 1351 70 (set (reg/v:SI 0 ax [orig:155 why ] [155])
(const_int 1 [0x1])) 47 {*movsi_1} (nil))
(code_label 1351 13690 1352 71 382 [0 uses])
(note 1352 1351 1353 71 [bb 71] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 1353 1352 1354 71 ../src/Python/ceval.c:1000 (set (pc)
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -60 [0xffc4])) [72 %sfp+-36 S4 A32]))
640 {*indirect_jump} (nil))
(barrier 1354 1353 1477)
So there are 4 edges reaching WHY set. In the second case it is move of WHY to
1:
(code_label 1363 1365 1349 150 384 [127 uses])
(note 1349 1363 1350 150 [bb 150] NOTE_INSN_BASIC_BLOCK)
(insn:TI 1350 1349 19980 150 ../src/Python/ceval.c:1000 (set (reg/v:SI 0 ax
[orig:155 why ] [155])
(const_int 1 [0x1])) 47 {*movsi_1} (nil))
(note 19980 1350 19979 151 [bb 151] NOTE_INSN_BASIC_BLOCK)
(jump_insn 19979 19980 19982 151 ../src/Python/ceval.c:1000 (set (pc)
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -60 [0xffc4])) [72 %sfp+-36 S4 A32]))
640 {*indirect_jump} (nil))
(barrier 19982 19979 1373)
that prevents duplicating. Probably ordirnary bb-reorder should be convincable
to handle this well?
This don't seem to happen at 64bit compilation.
I also posted the patch fixing optimize_for_size check
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39284
[Bug c++/40365] g++ template expansion bug
--- Comment #3 from oleg_dolomanov at hotmail dot com 2009-06-09 15:21 --- g++ (GCC) 4.1.3 20080612 (prerelease) (SUSE Linux) from time to time gives these kind of messages: internal compiler error: in var_ann, at tree-flow-inline.h:128 internal compiler error: in symbol_marked_for_renaming, at tree-into-ssa.c:456 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40365
[Bug c++/40389] New: optimizer bug (possibly)
After compiling a particular C++ program (see attachment) both with and without the -O option, the program produces different results. When compiled with -O, the program produces the output (nil), whereas when compiled without any options, the program prints a non-null pointer (which may of course vary between runs). The program is only 121 lines long, and was obtained by reducing an initial set of over 30.000 lines of code until no further reduction seemed to be possible without suppressing the problem. For example, by moving the static variable fs_active_handle into the main function, the problem magically disappears. Also, when adding printf-statements to the functions, or by manually inlining certain constructs, the problem disappears. Due to the immense reduction of the code, the semantics of the code may not seem clear anymore (that is, I am myself not sure what this program is supposed to do anymore), but the problem with the optimizer clearly shows. I have tried to use the tool valgrind to see if something illegal is happening wrt copy-constructors/assignment operators (despite close inspection), but this does not seem to be the case. -- Summary: optimizer bug (possibly) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: keesjan at cobalt dot et dot tudelft dot nl GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug c++/40389] optimizer bug (possibly)
--- Comment #1 from keesjan at cobalt dot et dot tudelft dot nl 2009-06-09 15:49 --- Created an attachment (id=17971) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17971action=view) The source code and compiler output, and a small script which reproduces the bug. Please see the script reproduce.sh, which reproduces the bug and writes a log to info.txt. The particular output on my system can be found in that same log file. The last few lines of this log file clearly indicate a difference between the optimized and non-optimized code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-09 16:53 --- Subject: Bug 40351 Author: jamborm Date: Tue Jun 9 16:52:57 2009 New Revision: 148315 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148315 Log: 2009-06-09 Martin Jambor mjam...@suse.cz PR tree-optimization/40351 * tree-sra.c (propagate_subacesses_accross_link): Check that a refrence to a potential artifical subaccess can be constructed. * testsuite/gcc.c-torture/compile/pr40351.c: New file. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40351.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug middle-end/40379] Extremely long compiling time of gcc optimization mode
--- Comment #2 from qingning dot huo at barcap dot com 2009-06-09 17:02 --- I will try to use a newer compiler version to see whether this is fixed. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40379
[Bug c++/40389] optimizer bug (possibly)
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-09 17:11 ---
Confirmed. Shorter testcase:
template typename V struct S
{
V *f, *l;
__attribute__ ((noinline)) S (void) { f = 0, l = 0; }
void foo (V *x)
{
if (x-p != 0)
x-p-n = x-n;
else
f = x-n;
if (x-n != 0)
x-n-p = x-p;
else
l = x-p;
}
__attribute__ ((noinline)) void bar (V *x)
{
x-n = 0;
x-p = l;
if (l != 0)
l-n = x;
else
f = x;
l = x;
}
};
struct H;
struct A
{
S H k;
};
struct H
{
A *a;
H *p, *n;
__attribute__ ((noinline)) H (void) { p = 0, n = 0, a = 0; }
__attribute__ ((noinline)) H (A *b) : a (b)
{
p = 0;
n = 0;
if (a != 0)
a-k.bar (this);
}
__attribute__ ((noinline)) H (const H h) : a (h.a)
{
p = 0;
n = 0;
if (a != 0)
a-k.bar (this);
}
~H (void) { if (a != 0) a-k.foo (this); }
H operator= (const H o)
{
if (a != 0 || o == this)
__builtin_abort ();
a = o.a;
if (a != 0)
a-k.bar (this);
return *this;
}
};
__attribute__ ((noinline))
H baz (void)
{
return H (new A);
}
H g;
int
main (void)
{
g = baz ();
if (g.a-k.f != g)
__builtin_abort ();
return 0;
}
doesn't fail with -O -fno-tree-sra, fails with -O. I've added a few noinline
attributes to make the debugging easier. Seems values from baz returned object
are cached in local variables across the bar call which modifies them. Likely
gcc doesn't consider this object as having address taken, even when it is
returned by invisible reference.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-06-09 17:11:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready
--- Comment #5 from spop at gcc dot gnu dot org 2009-06-09 17:25 --- I just committed the patch from Ian to the CLooG-PPL git repository. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40103
[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready
--- Comment #6 from spop at gcc dot gnu dot org 2009-06-09 17:30 --- Subject: Bug 40103 Author: spop Date: Tue Jun 9 17:30:23 2009 New Revision: 148318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148318 Log: 2009-06-09 Sebastian Pop sebastian@amd.com PR bootstrap/40103 * graphite.c: Remove pragma GCC diagnostic warning -Wc++-compat. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40103
[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready
--- Comment #7 from joseph at codesourcery dot com 2009-06-09 17:42 --- Subject: Re: CLooG header files are not -Wc++-compat ready On Tue, 9 Jun 2009, spop at gcc dot gnu dot org wrote: 2009-06-09 Sebastian Pop sebastian@amd.com PR bootstrap/40103 * graphite.c: Remove pragma GCC diagnostic warning -Wc++-compat. I think you should allow more time for people to update after preparing a fixed tarball for the infrastructure directory; won't this have broken bootstrap for everyone using any existing cloog-ppl release tarball (as referenced in install.texi on trunk)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40103
[Bug bootstrap/40103] CLooG header files are not -Wc++-compat ready
--- Comment #8 from sebpop at gmail dot com 2009-06-09 18:17 --- Subject: Re: CLooG header files are not -Wc++-compat ready On Tue, Jun 9, 2009 at 12:42, joseph at codesourcery dot comgcc-bugzi...@gcc.gnu.org wrote: I think you should allow more time for people to update after preparing a fixed tarball for the infrastructure directory; won't this have broken bootstrap for everyone using any existing cloog-ppl release tarball (as referenced in install.texi on trunk)? Yes, this would break the bootstrap unless you update the cloog sources from cloog-ppl git. I will revert this patch. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40103
[Bug c++/40381] [4.4/4.5 Regression] Revision 142379 caused ICE with deleted functions
--- Comment #2 from jason at gcc dot gnu dot org 2009-06-09 18:19 --- Subject: Bug 40381 Author: jason Date: Tue Jun 9 18:18:45 2009 New Revision: 148319 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148319 Log: PR c++/40381 * decl2.c (mark_used): Return after complaining about deleted fn. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug c++/40381] [4.4/4.5 Regression] Revision 142379 caused ICE with deleted functions
--- Comment #3 from jason at gcc dot gnu dot org 2009-06-09 18:20 --- Subject: Bug 40381 Author: jason Date: Tue Jun 9 18:20:29 2009 New Revision: 148320 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148320 Log: PR c++/40381 * decl2.c (mark_used): Return after complaining about deleted fn. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/defaulted10.C - copied unchanged from r148319, trunk/gcc/testsuite/g++.dg/cpp0x/defaulted10.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/decl2.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug c++/40381] [4.4/4.5 Regression] Revision 142379 caused ICE with deleted functions
--- Comment #4 from jason at gcc dot gnu dot org 2009-06-09 18:21 --- Fixed for 4.4.1 and 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40381
[Bug c/40390] New: possible integer wrong code bug
I believe that the program below is well-formed and that it is miscompiled by
r148318 at -Os.
reg...@john-home:~$ cat foo.c
#include stdio.h
int foo(int y)
{
return (((unsigned short)y*(unsigned short)-2)=(y?0:y));
}
int main (void)
{
printf (%d\n, foo(-2));
return 0;
}
reg...@john-home:~$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r148318-install
--program-prefix=r148318- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090609 (experimental) (GCC)
reg...@john-home:~$ current-gcc -Os foo.c -o foo
reg...@john-home:~$ ./foo
1
reg...@john-home:~$ current-gcc -O0 foo.c -o foo
reg...@john-home:~$ ./foo
0
reg...@john-home:~$ gcc-4.1 -Os foo.c -o foo
reg...@john-home:~$ ./foo
0
reg...@john-home:~$ gcc-4.2 -Os foo.c -o foo
reg...@john-home:~$ ./foo
0
reg...@john-home:~$ icc -Os foo.c -o foo
reg...@john-home:~$ ./foo
0
--
Summary: possible integer wrong code bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah 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=40390
[Bug c/40390] possible integer wrong code bug
--- Comment #1 from joseph at codesourcery dot com 2009-06-09 18:34 ---
Subject: Re: New: possible integer wrong code bug
On Tue, 9 Jun 2009, regehr at cs dot utah dot edu wrote:
reg...@john-home:~$ cat foo.c
#include stdio.h
int foo(int y)
{
return (((unsigned short)y*(unsigned short)-2)=(y?0:y));
This involves a signed integer overflow, 65534*65534. -Wstrict-overflow=3
warns you about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40390
[Bug c++/40391] New: Segfault with -O, iostream, anonymous namespace on PPC
When compiling the attached code with gcc 4.2.1 with -O, the result fails on PPC linux: host ppc86xx-linux-c++ -O -g -o iostest iostest.cxx target ./iostest Segmentation fault The code works fine: - When built without optimization - On x86 linux (also using gcc 4.2.1) - With #define WORKAROUND (to avoid using an anonymous namespace) -- Summary: Segfault with -O, iostream, anonymous namespace on PPC Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fp at mc dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-timesys-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug c++/40391] Segfault with -O, iostream, anonymous namespace on PPC
--- Comment #1 from fp at mc dot com 2009-06-09 19:05 --- Created an attachment (id=17972) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17972action=view) iostest.zip ZIP file containing source and preprocessed code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug c/40390] possible integer wrong code bug
--- Comment #2 from regehr at cs dot utah dot edu 2009-06-09 19:10 ---
Ah.. promotion to int trumps the casts to unsigned. Thanks and sorry for the
spurious report.
(In reply to comment #1)
Subject: Re: New: possible integer wrong code bug
On Tue, 9 Jun 2009, regehr at cs dot utah dot edu wrote:
reg...@john-home:~$ cat foo.c
#include stdio.h
int foo(int y)
{
return (((unsigned short)y*(unsigned short)-2)=(y?0:y));
This involves a signed integer overflow, 65534*65534. -Wstrict-overflow=3
warns you about this.
--
regehr at cs dot utah dot edu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40390
[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-09 19:12 --- anonymous namespaces enable more inlining so ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #12 from js-gcc at webkeks dot org 2009-06-09 19:17 ---
Any news? I even tried this now, which still produced an .a file:
../gcc-4.3.0-20080502/configure -v --prefix=/usr --libexecdir=/usr/lib \
--program-prefix=mingw32- --target=mingw32 --with-headers=/usr/mingw32/include
--disable-nls --enable-shared --enable-languages=objc
make configure-target-libobjc
make all-target-libobjc
make install-target-libobjc
Note the --enable-shared, which is _DEFINITELY_ being passed to configure
(quoting Makefile in builddir):
maybe-configure-target-libobjc: configure-target-libobjc
configure-target-libobjc:
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
echo Checking multilib configuration for libobjc...; \
$(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libobjc ; \
$(CC_FOR_TARGET) --print-multi-lib
$(TARGET_SUBDIR)/libobjc/multilib.tmp 2 /dev/null ; \
if test -r $(TARGET_SUBDIR)/libobjc/multilib.out; then \
if cmp -s $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; then \
rm -f $(TARGET_SUBDIR)/libobjc/multilib.tmp; \
else \
rm -f $(TARGET_SUBDIR)/libobjc/Makefile; \
mv $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; \
fi; \
else \
mv $(TARGET_SUBDIR)/libobjc/multilib.tmp
$(TARGET_SUBDIR)/libobjc/multilib.out; \
fi; \
test ! -f $(TARGET_SUBDIR)/libobjc/Makefile || exit 0; \
$(SHELL) $(srcdir)/mkinstalldirs $(TARGET_SUBDIR)/libobjc ; \
$(NORMAL_TARGET_EXPORTS) \
echo Configuring in $(TARGET_SUBDIR)/libobjc; \
cd $(TARGET_SUBDIR)/libobjc || exit 1; \
case $(srcdir) in \
/* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
*) topdir=`echo $(TARGET_SUBDIR)/libobjc/ | \
sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
esac; \
srcdiroption=--srcdir=$${topdir}/libobjc; \
libsrcdir=$$s/libobjc; \
rm -f no-such-file || : ; \
CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
$(TARGET_CONFIGARGS) --build=${build_alias} --host=${target_alias} \
--target=${target_alias} $${srcdiroption} \
|| exit 1
And TARGET_CONFIGARS is:
TARGET_CONFIGARGS = --cache-file=./config.cache --enable-multilib
--with-cross-host=i686-pc-linux-gnu '-v' '--prefix=/usr'
'--libexecdir=/usr/lib' '--with-headers=/usr/mingw32/include' '--disable-nls'
'--enable-shared' '--enable-languages=c,objc'
--program-transform-name='s,^,mingw32-,'
--with-target-subdir=$(TARGET_SUBDIR)
As you can see, --enable-shared is listed there, so libobjc's configure is
simply ignoring --enable-shared it seems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #13 from js-gcc at webkeks dot org 2009-06-09 19:27 --- Oh, for the record: cygwin now has gcc4 imported and they have libobjc as a shared .dll file. Using their dll, it works. So this means libobjc works with dll files if it is a dll file itself. But unfortunately, it's not possible to build it as a dll for mingw32 it seems. Still, I think there should be either both (.dll and .a) or the .a file should be able to load other dlls. Having only a .dll would mean that every app depends on libobjc.dll, which most likely no windows user will have. That's as if every C++ app would require gcc's libstdc++.dll on Windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug target/39545] Structures with flexible array member passed/returned incorrectly
--- Comment #10 from hjl dot tools at gmail dot com 2009-06-09 20:00 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39545
[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-09 20:11 --- GCC 4.2 is no longer maintained, and GCC 4.2.4 is the latest bugfix release from the 4.2 series. Please reproduce with at least GCC 4.3.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40391
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #11 from daney at gcc dot gnu dot org 2009-06-09 20:12 --- This is essentially __builtin_unreachable() for which I am working on a patch. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00787.html -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug c/39252] Request new feature __builtin_not_reached();
--- Comment #12 from daney at gcc dot gnu dot org 2009-06-09 20:16 --- (In reply to comment #6) Wouldn't be a special noreturn clobber in inline asm better suited for this then? See: http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html for an opposing opinion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39252
[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.
--- Comment #10 from jb at gcc dot gnu dot org 2009-06-09 20:29 --- Subject: Bug 40334 Author: jb Date: Tue Jun 9 20:29:33 2009 New Revision: 148324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148324 Log: PR libfortran/40334 backspace regression Added: trunk/gcc/testsuite/gfortran.dg/backspace_11.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
[Bug c++/40389] optimizer bug (possibly)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-09 20:25 --- Hm, I don't see how it should make the decl addressable. But I also don't see what is wrong with what esra performs on trunk ... I guess you refer to @@ -1193,45 +374,45 @@ SH::bar (D.2441_15, g); bb 6: - D.2453_16 = D.2275.a; + D.2453_16 = SR.101_9; if (D.2453_16 != 0B) ? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to fail|4.4.0 |4.4.0 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #13 from jb at gcc dot gnu dot org 2009-06-09 20:56 --- Subject: Bug 40330 Author: jb Date: Tue Jun 9 20:55:53 2009 New Revision: 148326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148326 Log: PR libfortran/40330 Use heap memory for format cache Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #14 from jb at gcc dot gnu dot org 2009-06-09 20:57 --- Closing as fixed. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug tree-optimization/40351] [4.5 Regression] ice in generate_subtree_copies for Linux kernel build
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-09 20:59 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40351
[Bug c++/40389] optimizer bug (possibly)
--- Comment #4 from jakub at gcc dot gnu dot org 2009-06-09 21:21 --- IMHO either we need to handle gimple_call_return_slot_opt_p cals in the middle-end as taking address of the call's lhs, or the frontend needs to expand it not as D.2275 = baz (); [return slot optimization] but as baz (D.2275); Doing the latter can be problematic on targets which have special calling conventions for the returns by invisible reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug c++/40389] optimizer bug (possibly)
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-09 21:27 --- I don't see why this is an issue at all - in fact the address does not escape(?) but instead the assignment is inside the callee. So bb 2: D.2275 = baz (); [return slot optimization] SR.101_9 = D.2275.a; SR.102_11 = D.2275.p; SR.103_3 = D.2275.n; as it looks like on trunk is still correct, no? Which means, I still don't see where it goes wrong ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug c++/40389] optimizer bug (possibly)
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-09 21:31 ---
I think this code is undefined as there is an address of a local variable being
taken and stored (explicitly when doing:
__attribute__ ((noinline)) H (A *b) : a (b)
{
p = 0;
n = 0;
if (a != 0)
a-k.bar (this);
}
this is an address of a local variable (the temp in baz).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug c++/40389] optimizer bug (possibly)
--- Comment #7 from jakub at gcc dot gnu dot org 2009-06-09 21:44 --- CCing Jason on the validity of the testcase. I don't see anything wrong with remembering this pointer for the duration of the object, assuming the pointer is gone from the list in the destructor (that's what the testcase does). And, assuming the testcase is valid, the pointer to the temporary really escapes. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389
[Bug target/40327] Use less instructions to add some constants to register
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-06-09 22:06 --- Working on a patch -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-03 10:36:14 |2009-06-09 22:06:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40327
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #15 from jv244 at cam dot ac dot uk 2009-06-09 22:14 --- (In reply to comment #14) Closing as fixed. I'm testing now 4.4 which includes your fix, but I still see CP2K's restarts failing. This looks like a second issue, different from what you've fixed so far. The testcase of comment #5 is working fine, with the update 4.4.1, but CP2K runs still shows a valgrind warning: ==11664== ==11664== Invalid read of size 1 ==11664==at 0x4BE3C4C: formatted_transfer (transfer.c:874) ==11664==by 0x6312C5: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664==by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664==by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664==by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664==by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664==by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664==by 0x403EBF: MAIN__ (cp2k.F:272) ==11664==by 0x2CFF029: main (fmain.c:21) ==11664== Address 0x6ada7c6 is 6 bytes inside a block of size 640 free'd ==11664==at 0x4A2196E: free (vg_replace_malloc.c:323) ==11664==by 0x631306: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664==by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664==by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664==by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664==by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664==by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664==by 0x403EBF: MAIN__ (cp2k.F:272) ==11664==by 0x2CFF029: main (fmain.c:21) ==11664== ==11664== Invalid read of size 1 ==11664==at 0x4BE3C60: formatted_transfer (transfer.c:878) ==11664==by 0x6312C5: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664==by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664==by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664==by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664==by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664==by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664==by 0x403EBF: MAIN__ (cp2k.F:272) ==11664==by 0x2CFF029: main (fmain.c:21) ==11664== Address 0x6ada7c7 is 7 bytes inside a block of size 640 free'd ==11664==at 0x4A2196E: free (vg_replace_malloc.c:323) ==11664==by 0x631306: __input_section_types_MOD_section_vals_write (input_section_types.F:2040) ==11664==by 0x632964: __input_section_types_MOD_section_vals_write (input_section_types.F:2083) ==11664==by 0xF10D05: __replica_types_MOD_rep_env_create (replica_types.F:278) ==11664==by 0x11996B9: __vibrational_analysis_MOD_vb_anal (vibrational_analysis.F:143) ==11664==by 0x40E83A: __cp2k_runs_MOD_cp2k_run (cp2k_runs.F:385) ==11664==by 0x404E93: __cp2k_runs_MOD_run_input (cp2k_runs.F:1095) ==11664==by 0x403EBF: MAIN__ (cp2k.F:272) ==11664==by 0x2CFF029: main (fmain.c:21) linking to the 4.3.2 runtime still solves the issue. I hope you can have a look at what might be wrong with these traces above, I don't have a testcase other than CP2K right now, and the code is tricky to reduce at that point. If you happen to have CP2K around, this is the testcase for the trace: cp2k/tests/Fist/regtest-5 valgrind --tool=memcheck ../../../exe/Linux-x86-64-gfortran/cp2k.sdbg wat_freq.inp -- jv244 at cam dot ac dot uk changed: What|Removed |Added Severity|normal |critical Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug lto/40392] New: ICE in lto_end_uncompression, at lto-compress.c:282
$ cat hw.c
int main() {
printf(hello world\n);
}
r...@ryan:~/gcc/lto/arm-build/gcc$ ./xgcc -B. -flto hw.c
hw.c: In function 'main':
hw.c:2:3: warning: incompatible implicit declaration of built-in function
'printf'
lto1: internal compiler error: in lto_end_uncompression, at lto-compress.c:282
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: ././xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status
r...@ryan:~/gcc/lto/arm-build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnu
Configured with: ../configure --target=arm-unknown-linux-gnu
--prefix=/home/ryan/cross/arm-unknown-linux-gnu
--with-headers=/home/ryan/cross/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include
--with-local-prefix=/home/ryan/cross/arm-unknown-linux-gnu/arm-unknown-linux-gnu
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
--enable-lto
Thread model: posix
gcc version 4.5.0 20090605 (experimental) (lto merged with rev 148228)
--
Summary: ICE in lto_end_uncompression, at lto-compress.c:282
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug tree-optimization/40384] [4.5 regression] Revision 148277 failed gcc.dg/tree-ssa/prefetch-5.c
--- Comment #2 from gshobaki at gcc dot gnu dot org 2009-06-09 22:37 --- The new cost model added in revision 148277 supresses prefetching in a loop when it is unlikely to be profitable. One such non-profitable case is a loop with an unknown trip count and a high prefeching cost. The prefetching cost is modeled by the ratio between the prefetch count and the total instruction count in a loop. When this ratio is greater than 1/10 in a loop with an unknown trip count, prefetching is considered non-profitable and no prefetches are issued. The first two loops in this test case fall under this category, where the trip count is not known and the prefetch-to-insn ratio is 1/5. Possible fixes are: 1. Add more computation to the loop bodies in the test case to reduce the prefetch-to-insn ratios and hence make the loops profitable from the cost model's point of view. 2. Use a commad line option to set the maximum profitable prefetch-to-insn ratio to 1/5. The syntax is --param min-insn-to-prefetch-ratio=5 3. Change the expected output such that it does not expect prefetches in this case. Any feedback on which one is the preferred solution? Thanks -Ghassan -- gshobaki at gcc dot gnu dot org changed: What|Removed |Added CC||gshobaki at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40384
[Bug c/40393] New: cos gets replaced by sincos somehow, which doesn't exist on system
When I compiling lcms or ncurses I get: undefined reference to `sincos' I've searched the header files of the entire system and all of the source code for ANY references to sincos and none exist. sincos() is simply not on my system. As far as I can tell, this happens only when cos() exists in the source code of some. When cos() is removed, the sincos() linker error vanishes. I believe it has something to do with gcc-4.4.0 because I have not seen this problem until I switched to gcc-4.4.0 from gcc-4.1.2 on a clean bootstrapped system. This can be triggered consistently with the ncurses test program: ncurses-5.7/test/tclock.c (during the standard ./configure make process) -- gcc-4.4.0 uClibc-0.9.28.3 or uClibc-0.30.1 binutils 2.19.1 configure options: --enable-languages=c,c++ --enable-clocale --enable-__cxa_atexit --with-system-zlib --enable-multilib --enable-threads=posix --disable-libstdcxx-pch --enable-ssp --enable-wchar_t --enable-long-long -- Summary: cos gets replaced by sincos somehow, which doesn't exist on system Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thekevinday at gmail dot com 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=40393
[Bug middle-end/40393] cos gets replaced by sincos somehow, which doesn't exist on system
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-10 00:11 --- It does exist in glibc. If you use uclibc you need to configure GCC for uclibc by default or use the muclibc option. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40393
[Bug middle-end/40393] cos gets replaced by sincos somehow, which doesn't exist on system
--- Comment #2 from joseph at codesourcery dot com 2009-06-10 00:58 --- Subject: Re: New: cos gets replaced by sincos somehow, which doesn't exist on system On Tue, 9 Jun 2009, thekevinday at gmail dot com wrote: When I compiling lcms or ncurses I get: undefined reference to `sincos' uClibc-0.9.28.3 or uClibc-0.30.1 GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu i686-pc-linux-gnu is not correct for a uClibc system; you should be using i686-pc-linux-uclibc. linux.h correctly defines TARGET_HAS_SINCOS to (OPTION_GLIBC) to disable use of sincos if you have a toolchain correctly configured for uClibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40393
[Bug middle-end/18927] O(n^2) compile time with -O0 (n= number of basic blocks) in local alloc
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-10 01:53 --- Hmm, I wonder what are the numbers are for 4.4 with IRA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18927
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-06-10 02:18 --- The two locations referenced by valgrind in transfer.c is in code that is unchanged from 4.3, so I don't think that is where the problem is. However, looking at the CP2K code line involved: WRITE(unit=unit_nr,fmt=(//TRIM(myfmt)//,a,' '),advance=NO) TRIM(keyword%names(1)) Points to fmt or advance=NO logic. I am building cp2k with format caching removed to see if we still get this error. Joost, can you explain what the following means? CP2K| condition FAILED at line 195 CP2K| Abnormal program termination, stopped by process number 0 Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
[Bug libfortran/40330] [4.4 Regression] incorrect IO
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2009-06-10 03:11 --- I was able to do a regression hunt. Going to r145209 just before the big I/O patch eliminates the error. I then moved forward to r145636 and confirmed the breakage. I then manually removed the use of the format caching in io/format.c and confirmed that the problem goes away. I suggest that I manually revert this portion of the IO patches from 4.4 if we do not fix it very soon. I plan to get ready for this partial revert on 4.4. Then I will proceed to crack the problem on trunk. If we can not fix in time for 4.4.1 I will do the revert. Janne or Tobias, if you prefer I revert now, just let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330
