[Bug c/41367] gcc: segmentation fault (Program cc1)
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-16 06:48 --- This is a forum to report bugs on existing releases of GCC or the current development version. Queries regarding porting GCC should be taken on g...@gcc.gnu.org. In this case you might find it useful to look at some of the pointers with respect to debugging GCC using GDB on the wiki. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41367
[Bug c/41366] Very inefficient code generated
--- Comment #1 from ramana at gcc dot gnu dot org 2009-09-16 07:08 --- The problem occurs with 4.4.x branch r 151319. The problem is evident if you have -march=armv5te or earlier, but not with -march=armv6 or later. This is the code I get with armv6 foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. mov r2, #0 orr r2, r2, r0 mov r0, r2 bx lr Conversely with -mthumb any option less than -march=armv6 gives the following code. foo: @ sp needed for prologue bx lr and a -mcpu=cortex-a8 gives the following code. movsr2, #0 orrsr2, r2, r0 mov r0, r2 bx lr The same problem occurs on trunk. -- ramana 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-09-16 07:08:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41366
[Bug fortran/41369] New: Empty derived-type wrongly rejected as function return type
(Motivated but independent from http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/817234ccd2b3ae1b#) The following program is rejected in gfortran until one adds a component. I agree that it is not particularly useful but I think it is standard conform. In any case the error message is bogus: type(t) function foo() 1 Error: The type for function 'foo' at (1) is not accessible module m type t end type t end module type(t) function foo() use m foo = t() end function foo -- Summary: Empty derived-type wrongly rejected as function return type Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41369
[Bug fortran/41370] New: Function return-type declaration with specification expression rejected
In the same c.l.f thread as PR 41369: The following program, based on a post by Jim Xia does not compile with gfortran (nor with NAG f95, ifort, openf95); I think it is standard conform (CHECK before fixing!) - and it works with g95. character(len=mt%i) function foo(mt) 1 Error: Syntax error in CHARACTER declaration at (1) module m type t integer,pointer :: i end type t end module character(len=mt%i) function foo(mt) use m type(t), intent(in) :: mt end function foo See: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/817234ccd2b3ae1b -- Summary: Function return-type declaration with specification expression rejected Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41370
[Bug fortran/41370] Function return-type declaration with specification expression rejected
--- Comment #1 from burnus at gcc dot gnu dot org 2009-09-16 07:41 --- Hmm, I think it might be invalid. The follwing program is rejected as well and avoids one potential problem. Xia had some other examples which should also be checked after PR 41369 and - if valid - this PR is fixed. module m type t integer,pointer :: i end type t contains character(len=mt%i) function foo(mt) type(t), intent(in) :: mt end function foo end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41370
[Bug middle-end/41365] [4.5 Regression] gcc.dg/vect/vect-cond-[123].c abort due to bad code generation at -O1 and above
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|gcc.dg/vect/vect-cond- |[4.5 Regression] |[123].c abort due to bad|gcc.dg/vect/vect-cond- |code generation at -O1 and |[123].c abort due to bad |above |code generation at -O1 and ||above Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41365
[Bug c++/41368] Erroneous aliasing rules violation messages are issued
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-16 08:02 ---
The compiler warns for the store in
D.1845_1 = (struct F *) eee.[0];
D.1854_8 ={v} 0B-D.1740.[0];
D.1845_1-ppp1 = D.1854_8;
because that stores to eee. (type char) via a pointer to type F which
is invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug fortran/41369] Empty derived-type wrongly rejected as function return type
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-16 08:45 --- The test is also rejected by g95 and ifort, the latter gives: error #7128: A derived-type-def must have at least one component-def-stmt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41369
[Bug tree-optimization/34011] Memory load is not eliminated from tight vectorized loop
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-16 08:50 --- Subject: Bug 34011 Author: rguenth Date: Wed Sep 16 08:50:46 2009 New Revision: 151740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151740 Log: 2009-09-16 Richard Guenther rguent...@suse.de PR middle-end/34011 * tree-flow-inline.h (may_be_aliased): Compute readonly variables as non-aliased. * gcc.dg/tree-ssa/ssa-lim-7.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow-inline.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34011
[Bug c++/41371] New: compiler hang for C++ code
I just tried to compile the Suse Linux package krename-3.9.3-1.33 with the gcc 4.5 mainline snapshot 20090910 and the compiler appeared to hang for over half an hour on an otherwise idle machine. Preprocessed C++ source attached. Flags -O2 -g -m64 required. -- Summary: compiler hang for C++ code 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=41371
[Bug c++/41371] compiler hang for C++ code
--- Comment #1 from dcb314 at hotmail dot com 2009-09-16 09:19 --- Created an attachment (id=18594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18594action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug java/41372] New: Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch
When I compile jar into shared library all symbols become local when -findirect-dispatch is specified. Local symbols can't be found by dlsym. -findirect-dispatch options shouldn't change symbols from global to local since external callers may choose to import them regardless of this option. -- Summary: Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41372
[Bug rtl-optimization/41371] [4.5 Regression] compiler hang for C++ code
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 09:54 --- it's var-tracking again. Slowly eating memory and time. Working very hard here: Run till exit from #0 vt_find_locations () at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:5467 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c++ |rtl-optimization Ever Confirmed|0 |1 Keywords||compile-time-hog, memory-hog Last reconfirmed|-00-00 00:00:00 |2009-09-16 09:54:02 date|| Summary|compiler hang for C++ code |[4.5 Regression] compiler ||hang for C++ code Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug c++/41368] Erroneous aliasing rules violation messages are issued
--- Comment #4 from yuri at rawbw dot com 2009-09-16 09:55 ---
Subject: Re: Erroneous aliasing rules violation messages are
issued
rguenth at gcc dot gnu dot org wrote:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-16 08:02
---
The compiler warns for the store in
D.1845_1 = (struct F *) eee.[0];
D.1854_8 ={v} 0B-D.1740.[0];
D.1845_1-ppp1 = D.1854_8;
because that stores to eee. (type char) via a pointer to type F which
is invalid.
If this is the case, I agree with the warning, but why is it placed in
function 'bbb', and not in 'ggg'? 'ggg' is the one that converts from
unsigned char to F.
I believe this is a bug that message is misplaced. This makes message
misleading and confusing.
Message line should be fixed, and also it should be one message, not two.
This case should be reopened.
Thank you,
Yuri
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug debug/41357] libgomp build fail
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-16 10:19 --- Created an attachment (id=18595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18595action=view) simplified fix After discussion on the -patches list, it seemed sensible to try preserving the precise value of the tls model that gets selected by the emulation, even if it is a bit surprising, so this reworked patch simply removes the targetm.have_tls test altogether. Now running bootstrap-and-test cycle. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18588|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug fortran/41369] Empty derived-type wrongly rejected as function return type
--- Comment #2 from burnus at gcc dot gnu dot org 2009-09-16 10:33 --- (In reply to comment #1) The test is also rejected by g95 and ifort, the latter gives: error #7128: A derived-type-def must have at least one component-def-stmt. I did not claim that I have a valid Fortran 95 program - in Fortran 2003 it is allowed. And ifort 11.1 compiles it (well, at least without the empty structure constructor which gives a not yet implemented error.). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41369
[Bug debug/41357] libgomp build fail
--- Comment #24 from jakub at gcc dot gnu dot org 2009-09-16 10:37 --- As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even their SYMBOL_REFs start using that TLS model. But, unlike the user vars, these occur normally in the instruction stream, so I wonder if this patch won't break things. Perhaps we shouldn't set SYMBOL_REF_TLS_MODEL if DECL_TLS_MODEL is TLS_MODEL_EMULATED, otherwise it risks that e.g. backends reject it as invalid constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #25 from davek at gcc dot gnu dot org 2009-09-16 10:51 --- (In reply to comment #24) As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even their SYMBOL_REFs start using that TLS model. But, unlike the user vars, these occur normally in the instruction stream, so I wonder if this patch won't break things. Perhaps we shouldn't set SYMBOL_REF_TLS_MODEL if DECL_TLS_MODEL is TLS_MODEL_EMULATED, otherwise it risks that e.g. backends reject it as invalid constant. Yes, I see what you mean. There are a lot of references to every other kind of TLS_MODEL_xxx value in the backend files, but no mentions of TLS_MODEL_EMULATED. And just to pick one example: xtensa_legitimize_tls_address() will gcc_unreachable() if it sees that value. So I'll give it one more try, adding a check that the decl's model isn't _EMULATED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #26 from davek at gcc dot gnu dot org 2009-09-16 10:54 --- Created an attachment (id=18596) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18596action=view) YA respin don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18595|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug c++/41373] New: attribute error and warning dont show the instantiation stack
Using functions with attribute error/warning from templates doesn't
output the instantiation stack. With attribute deprecated this works.
Consider this program:
/
void func() __attribute__ ((error(error)));
//void func() __attribute__ ((warning(warning)));
//void func() __attribute__ ((deprecated));
void func()
{}
templateclass T
void bar()
{
func();
}
int main( int, char** )
{
barint();
}
/
With attribute error:
t.cc: In function 'void bar() [with T = int]':
t.cc:11: error: call to 'func' declared with attribute error: error
With attribute deprecated:
t.cc: In function 'void bar() [with T = int]':
t.cc:16: instantiated from here
t.cc:11: warning: 'void func()' is deprecated (declared at t.cc:5)
--
Summary: attribute error and warning dont show the instantiation
stack
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41373
[Bug c/41374] New: C99 basic character set
I noticed the C99 standard (ISO/IEC 9899:1999) doesn't include the dollar sign ($), the at sign (@) and the grave accent (`) in the basic character set (see section 5.2.1). gcc, anyway, doesn't complain if I have something such as: char c = '$'; instead of char c = '\u0024'; I looked at the gcc man page, but I couldn't find an option to show a warning when something like this appears in a C99 source file. What do you think? -- Summary: C99 basic character set Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pi00100100 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41374
[Bug debug/41353] VTA missed-debug issues
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-16 11:48 ---
Looking at the
int
foo (int i)
{
asm volatile ( : +r (i));
int i1 = 2 * i;
int i2 = 2 * i;
int i3 = 2 * i;
return i;
}
testcase now, here the problem is that cse1 pass sees:
(insn 7 6 8 2 d6.c:4 (set (reg/v:SI 59 [ i ])
(reg:SI 60)) 47 {*movsi_1} (nil))
(pseudo 60 is the dest of the asm, pseudo 59 is the real variable) and replaces
all occurrences of pseudo 59 with pseudo 60 in the following insns, including
DEBUG_INSNs. But, pseudo 60 doesn't have REG_EXPR set obviously.
In *.compgotos we have:
(debug_insn 8 6 9 2 d6.c:4 (var_location:SI i (reg:SI 0 ax [60])) -1 (nil))
(debug_insn 9 8 10 2 d6.c:5 (var_location:SI i1 (mult:SI (reg:SI 0 ax [60])
(const_int 2 [0x2]))) -1 (nil))
(debug_insn 10 9 11 2 d6.c:6 (var_location:SI i2 (mult:SI (reg:SI 0 ax [60])
(const_int 2 [0x2]))) -1 (nil))
(debug_insn 11 10 19 2 d6.c:7 (var_location:SI i3 (mult:SI (reg:SI 0 ax [60])
(const_int 2 [0x2]))) -1 (nil))
(insn 19 11 24 2 d6.c:9 (use (reg/i:SI 0 ax)) -1 (nil))
So, we first have a MO_USE_NO_VAR, then MO_VAL_LOC saying i lives in %eax, then
MO_USE_NO_VAR for the occurrence of %eax in debug_insn 9, then MO_VAL_LOC
saying it lives in %eax * 2, etc. But, each such MO_USE_NO_VAR will clobber
anything that lives in that register or depends on it.
I wonder if we shouldn't special case regs without REG_EXPR referenced from
DEBUG_INSN expressions. Perhaps they could be ignored altogether or something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug debug/41353] VTA missed-debug issues
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-16 11:53 ---
With:
--- var-tracking.c.xx 2009-09-16 09:17:52.0 +0200
+++ var-tracking.c 2009-09-16 13:48:08.0 +0200
@@ -4416,14 +4416,14 @@ use_type (rtx *loc, struct count_use_inf
expr = REG_EXPR (*loc);
if (!expr)
-return MO_USE_NO_VAR;
+return cui DEBUG_INSN_P (cui-insn) ? MO_CLOBBER : MO_USE_NO_VAR;
else if (target_for_debug_bind (var_debug_decl (expr)))
return MO_CLOBBER;
else if (track_loc_p (*loc, expr, REG_OFFSET (*loc),
false, modep, NULL))
return MO_USE;
else
-return MO_USE_NO_VAR;
+return cui DEBUG_INSN_P (cui-insn) ? MO_CLOBBER : MO_USE_NO_VAR;
}
else if (MEM_P (*loc))
{
hack the vars var-tracking doesn't cancel everything immediately, but only
after the
(insn 19 32 36 2 d6.c:9 (use (reg/i:SI 0 ax)) -1 (nil))
insn - which isn't a debug insn and therefore it is still treated as
MO_USE_NO_VAR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug tree-optimization/41101] [4.4 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-09-16 11:56 --- Subject: Bug 41101 Author: rguenth Date: Wed Sep 16 11:56:31 2009 New Revision: 151744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151744 Log: 2009-09-16 Richard Guenther rguent...@suse.de Backport from mainline 2009-09-09 Richard Guenther rguent...@suse.de PR tree-optimization/41101 * tree-ssa-pre.c (maximal_set): Remove. (compute_antic_aux): Treat the maximal set as implicitly all ones. Defer all blocks we didn't visit at least one successor. (add_to_exp_gen): Do not add to the maximal set. (make_values_for_phi): Likewise. (compute_avail): Likewise. (init_pre): Do not allocate the maximal set. (execute_pre): Do not dump it. * gcc.c-torture/compile/pr41101.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr41101.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug tree-optimization/41101] [4.4 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-09-16 11:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.4.1 4.5.0 |4.4.1 4.4.2 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41101
[Bug c/41374] C99 basic character set
--- Comment #1 from joseph at codesourcery dot com 2009-09-16 12:00 --- Subject: Re: New: C99 basic character set String and character literals may contain characters from the source character set that are not members of the basic source character set. See the syntax for c-char and s-char. (C++98/C++03 may be more restrictive, but that's a separate issue.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41374
[Bug java/41375] New: Compiling native executable without -findirect-dispatch causes random SEGVs
I have a simple Java class that doesn't directly depend on anything except for java.lang.String, java.lang.reflect.Class and java.lang.reflect.Method. It loads other classes (from jars in my case) by name and invoked them through Class.forName()/Method.invoke() mechanism. But it only works when -findirect-dispatch is specified. Without -findirect-dispatch it crashes shortly into the run with the stack below. -findirect-dispatch should only impact the way how currently compiled unit links to other units. In case of the programs like mine (not dependent on anything else directly) -findirect-dispatch should have no impact at all. It should resolve classes and run them the same way, since in this scenario it's clear what should be done to load other classes. --- stack (debug info is not everywhere) --- 0x35ec31a7 in __error () from /lib/libthr.so.3 #1 0x35ec2d88 in __error () from /lib/libthr.so.3 #2 0x36005860 in ?? () #3 0x0008 in ?? () #4 0x0001 in ?? () #5 0x36005840 in ?? () #6 0x in ?? () #7 0x0001 in ?? () #8 0x33c718d4 in ?? () from /libexec/ld-elf.so.1 #9 0x35ec16df in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x35ec0f7d in pthread_cond_signal () from /lib/libthr.so.3 #11 0x347e57e8 in _Jv_CondWait (cv=0x35e5b78c, mu=0x35e5b780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #12 0x8c347cb0 in ?? () #13 0x35e5b78c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x35e5b780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x0001 in ?? () #19 0x33c4e998 in dladdr () from /libexec/ld-elf.so.1 -- Summary: Compiling native executable without -findirect-dispatch causes random SEGVs Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #1 from yuri at tsoft dot com 2009-09-16 12:12 --- I should also add that one of the classes has native methods, and crash occurs shortly after the first such method is invoked. This may or may not be a factor in the issue. Testcase is quite large and I can't submit it here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug c/41374] C99 basic character set
--- Comment #2 from pi00100100 at gmail dot com 2009-09-16 12:27 --- The fact is that the characters belonging to the source character set but not belonging the basic source character set are left to the implementation (as far as I understood). So it would be better (for portability purpouses) to have an option to avoid all of them and to use only the basic ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41374
[Bug middle-end/41347] [4.5 Regression] ICE with -O3 or '-O2 -finline-functions'
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-16 12:55 --- it's the inliner that exposes this. I didn't yet investigate further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41347
[Bug lto/41376] New: collect2 (and maybe lto1) do not handle static libraries
collect2 does not handle static libraries to maybe_run_lto_and_relink so it doesn't get a chance to optimize using its content. This for example means that when bootstrapping with BOOT_CFLAGS=-flto libbackend.a does not benefit from lto. -- Summary: collect2 (and maybe lto1) do not handle static libraries Product: gcc Version: lto Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376
[Bug lto/40754] lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:17 --- It looks like this: /* Read in lto_in_decl_state objects. */ data_ptr = (const uint32_t *) ((const char*) data + decl_offset); data_end = (const uint32_t *) ((const char*) data_ptr + header-decl_state_size); num_decl_states = *data_ptr++; may be the reason. I don't know what's easier - trying to properly align things or properly accessing things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40754
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20 --- Does replacing the #include with #ifdef HAVE_STDINT_H #include stdint.h #endif #ifdef HAVE_INTTYPES_H #include inttypes.h #endif work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug lto/40681] [ICE] expand_expr_real_1, at expr.c:7382
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-16 13:27 --- Works for me with the current branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40681
[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-16 13:29 --- Object files are not useful anymore. Please provide sources. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-16 13:32 --- The patch is not yet in but I think it's the wrong approach. Instead uncompression should deal with tail padding. Maybe the issue is no longer present though - can you possibly re-check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug lto/40410] [LTO] ICE verify_stmts failed
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-16 13:28 --- Object files are not useful as a testcase as the object format is not transferable between versions. Please provide sources. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40410
[Bug lto/39276] [lto] - Testsuite gcc.log shows many getconf: Invalid argument (_NPROCESSORS_ONLN)
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-16 13:38 --- For the ease of debugging lto_execute_ltrans should get a mode that just serially executes things without a script. I'm trying to get that running. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39276
[Bug lto/40410] [LTO] ICE verify_stmts failed
--- Comment #5 from rmansfield at qnx dot com 2009-09-16 13:55 --- I will have to reduce the source testcase before I can provide it. I tried to reproduce this PR with gcc version 4.5.0 20090910 (experimental) [lto revision 151644] (lto merged with rev 150842) and I now hit the ICE reported in PR41173. lto1: fatal error: internal error: builtin function to __builtin_bswap16 already processed. compilation terminated. Also, I had recently seen a couple of verify_stmts ICES on SH4 (using same rev as the ppc toolchain) Example #1. In function 'inflateCopy': lto1: error: non-trivial conversion at assignment struct internal_state * struct inflate_state * # .MEM_82 = VDEF .MEM_81 dest_3(D)-state = copy_16; lto1: internal compiler error: verify_stmts failed Example #2. lto1: error: type mismatch in indirect reference const struct PtTerminalWidget_t const struct PtTerminalWidget_t # VUSE .MEM_7(D) D.140180_2 = term_1(D)-cm.size; Example #3: lto1: error: non-trivial conversion at assignment struct xmlDict * struct _xmlDict * # VUSE .MEM_16(D) dict_6 = D.24482_5-dict; Is one testcase for the sh ICEs enough or one for each ICE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40410
[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263
--- Comment #6 from rmansfield at qnx dot com 2009-09-16 13:59 --- I now hit PR41173 when I try to reproduce this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263
--- Comment #7 from rmansfield at qnx dot com 2009-09-16 14:02 --- I can reproduce the x86 ICE with gcc version 4.5.0 20090902 (experimental) [lto revision 151401] (lto merged with rev 150842). I will try again with the latest and reduce a source testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
[Bug middle-end/41360] [4.5 regression] Revision 151696 breaks gcc.c-torture/compile/builtin_unreachable-1.c
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-16 14:37:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41360
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-09-16 14:37 --- Subject: Re: plugin-api.h unconditionally includes stdint.h --- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 13:20 --- Does replacing the #include with #ifdef HAVE_STDINT_H #include stdint.h #endif #ifdef HAVE_INTTYPES_H #include inttypes.h #endif work for you? The first part won't help on IRIX 6.5, which has stdint.h, but it's unusable in non-C99 mode. This is fixed (via fixincludes) in recent versions of gcc, though, which one could require to bootstrap. But again, if one bootstraps e.g with MIPSpro cc, it would fail again. The second part should help for e.g. Tru64 UNIX V5.1B, which has inttypes.h, but not on V4.0F, which lacks it. What needs to happen, I think, is a check if some header provides the necessary types and provide them otherwise. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug tree-optimization/41377] New: [4.5 Regression] ICE in unsplit_eh
The following testcase triggers an ICE on the trunk when compiled with -O3:
===
struct A
{
bool foo(int*) const;
} a;
struct B {};
struct B1 : B
{
bool (A::*pmf)(int*) const;
const A* pa;
B1() : pmf(A::foo), pa(a) {}
bool operator()() const { return (pa-*pmf)(new int); }
};
struct B2 : B
{
B1 b1;
B2(const B1 _b1) : b1(_b1) {}
bool operator()() const { return b1(); }
};
templateint struct C
{
void bar(B2 b2) { while (b2()) ; }
C() { bar(B2(B1())); }
};
void baz(int i)
{
switch(i)
{
case 0: new C0;
case 1: new C1;
case 2: new C2;
}
}
===
bug.cc: In function 'baz(int)':
bug.cc:31:6: internal compiler error: in unsplit_eh, at tree-eh.c:3359
Please submit a full bug report, [etc.]
--
Summary: [4.5 Regression] ICE in unsplit_eh
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
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=41377
[Bug tree-optimization/41377] [4.5 Regression] ICE in unsplit_eh
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41377
[Bug middle-end/41360] [4.5 regression] Revision 151696 breaks gcc.c-torture/compile/builtin_unreachable-1.c
--- Comment #4 from rth at gcc dot gnu dot org 2009-09-16 15:04 --- Subject: Bug 41360 Author: rth Date: Wed Sep 16 15:04:06 2009 New Revision: 151759 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151759 Log: PR middle-end/41360 * cfgbuild.c (find_bb_boundaries): Re-instate 2009-09-02 barrier fix. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgbuild.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41360
[Bug middle-end/41360] [4.5 regression] Revision 151696 breaks gcc.c-torture/compile/builtin_unreachable-1.c
--- Comment #5 from rth at gcc dot gnu dot org 2009-09-16 15:05 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41360
[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #5 from rmansfield at qnx dot com 2009-09-16 15:27 --- Problem still happens with gcc version 4.5.0 20090914 (experimental) [lto revision 151753] (lto merged with rev 150842) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug middle-end/41378] -fipa-pta -O3 leads to ICE : in insert_vi_for_tree, at tree-ssa-structalias.c:2601
--- Comment #1 from linuxl4 at sohu dot com 2009-09-16 15:28 --- Created an attachment (id=18597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18597action=view) the source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41378
[Bug lto/41379] WPA leaves asm temporary file behind
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-16 15:53 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-16 15:53:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41379
[Bug lto/41380] New: lto.exp leaves temporary files behind
After running make check-gcc RUNTESTFLAGS=lto.exp we have ls testsuite/gcc/ ccnMRJwL-c_lto_20090116_0.o.lto.o gcc-dg-lto-20090206-1-01 c_lto_20090116_0.s gcc-dg-lto-20090206-2-01 gcc-dg-lto-20081120-1-01 gcc-dg-lto-20090219-01 gcc-dg-lto-20081120-2-01 gcc-dg-lto-20090312-01 gcc-dg-lto-20081126-01 gcc-dg-lto-20090312-11 gcc-dg-lto-20081204-1-01 gcc-dg-lto-20090312-21 gcc-dg-lto-20081204-2-01 gcc-dg-lto-20090312-31 gcc-dg-lto-20081212-1-01 gcc-dg-lto-20090914-1-01 gcc-dg-lto-20081224-01 gcc.log gcc-dg-lto-20090126-1-01 gcc.sum gcc-dg-lto-20090126-2-01 site.exp (after fixing PR41379) -- Summary: lto.exp leaves temporary files behind Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41380
[Bug target/35294] iwmmxt intrinsics, internal compiler error
--- Comment #5 from ixt at nm dot ru 2009-09-16 15:58 --- Denis, nobody wants to open this thread. First, we must do it. PS You say in Russian? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
[Bug middle-end/41378] -fipa-pta -O3 leads to ICE : in insert_vi_for_tree, at tree-ssa-structalias.c:2601
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 16:02 --- FYI, -fipa-pta does nothing (and is known to be broken). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41378
[Bug fortran/41212] [4.5 Regression] miscompilation at -O2
--- Comment #18 from matz at gcc dot gnu dot org 2009-09-16 16:12 --- Subject: Bug 41212 Author: matz Date: Wed Sep 16 16:12:18 2009 New Revision: 151761 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151761 Log: PR fortran/41212 * tree.h (struct tree_decl_common): Add decl_restricted_flag, shorten decl_common_unused. (DECL_RESTRICTED_P): New accessor. * tree-ssa-alias.c (ptr_deref_may_alias_decl_p): Use it to disambiguate marked decls and restrict pointers. fortran/ * trans.h (struct lang_type): Remove nontarget_type member. * trans.c (gfc_add_modify): Don't access it. * trans-decl.c (gfc_finish_var_decl): Don't allocate and set it, instead set DECL_RESTRICTED_P on affected decls. testsuite/ * gfortran.dg/pr41212.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr41212.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug fortran/41212] [4.5 Regression] miscompilation at -O2
--- Comment #19 from matz at gcc dot gnu dot org 2009-09-16 16:13 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41212
[Bug target/41246] should sorry when regparm=3 and nested functions are encountered
--- Comment #18 from rth at gcc dot gnu dot org 2009-09-16 16:27 --- Subject: Bug 41246 Author: rth Date: Wed Sep 16 16:26:55 2009 New Revision: 151762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151762 Log: PR target/41246 * tree-cfg.c (verify_gimple_call): Validate that * gimple_call_chain is set only if DECL_NO_STATIC_CHAIN is unset. * tree-nested.c (iter_nestinfo_start, iter_nestinfo_next): New. (FOR_EACH_NEST_INFO): New. (walk_all_functions): Use it. (finalize_nesting_tree): Likewise. (unnest_nesting_tree): Likewise. (free_nesting_tree): Use iter_nestinfo_start, iter_nestinfo_next. (get_chain_decl, get_chain_field): Reset DECL_NO_STATIC_CHAIN. (convert_gimple_call): Early out if gimple_call_chain already set. (convert_all_function_calls): Iterate until no new functions require a static chain. (finalize_nesting_tree_1): Assert DECL_NO_STATIC_CHAIN is unset when building a trampoline. Use dump_function_to_file instead of dump_function. (lower_nested_functions): Open dump_file. Validate that decls that have DECL_NO_STATIC_CHAIN from the front end don't have that bit reset by this pass. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-nested.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
[Bug debug/41353] VTA missed-debug issues
--- Comment #7 from jakub at gcc dot gnu dot org 2009-09-16 16:42 --- Created an attachment (id=18598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18598action=view) expand-asm-stmt.patch Alternatively to cure this expand_asm_operands could ensure the temporaries have correct REG_ATTRS. This cures the testcase as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug debug/41353] VTA missed-debug issues
--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-16 16:43 --- The http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353#c4 patch has been obsoleted by http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01017.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug middle-end/41347] [4.5 Regression] ICE with -O3 or '-O2 -finline-functions'
--- Comment #6 from matz at gcc dot gnu dot org 2009-09-16 17:03 --- Mine. The inliner remaps types (when they are variably modified) without caring for qualifiers or attributes, resulting in these mismatches. I have a patch. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-16 17:03:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41347
[Bug debug/41353] VTA missed-debug issues
--- Comment #9 from jakub at gcc dot gnu dot org 2009-09-16 17:17 ---
Another interesting testcase:
int
foo (int i)
{
asm volatile ( : +r (i));
int i1 = 2 * i;
int i2 = 2 * i;
int i3 = 3 * i;
asm volatile ( : +r (i) : : memory);
return i;
}
Here things go wrong during regmove I'd say. Before regmove, the first asm
sets (reg:SI 60 [i]), which is also used in several DEBUG_INSNS (for i, i1, i2,
i3) in between the 2 asms, then the second asm uses pseudo 60 and sets 61.
regmove changes it to use pseudo 61 in all places (starting even before the
first asm), but none of the debug_insn arguments are changed, so they all refer
to a dead pseudo 60 and during RA they become clobber 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug debug/41353] VTA missed-debug issues
--- Comment #10 from jakub at gcc dot gnu dot org 2009-09-16 17:19 ---
And yet another testcase:
int
foo (int i, int j)
{
j += i;
int i1 = 2 * i;
int i2 = 3 * i;
asm volatile ( : +r (j) : : memory);
return j;
}
Here the debug_insn arguments are lost during cprop1 pass, no idea why yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
[Bug target/35294] iwmmxt intrinsics, internal compiler error
--- Comment #6 from den at openvz dot org 2009-09-16 17:22 --- for russian - yes. Should we open new issue? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
[Bug bootstrap/35619] [4.3/4.4/4.5 Regression] fixed includes not being found if building in src dir
-- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-05-28 01:15:42 |2009-09-16 17:46:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug c++/41381] New: Default copy constructor and assignment operator ignored
g++4.3.0 is wrongly eliding the copy constructor and the assignment of a
struct. Look at the following code:
#include iostream
#include complex
struct Complex {
std::complexdouble value;
};
const Complex one = { 1 };
int main() {
Complex z = one, w;
w = one;
std::cout one = one.value std::endl;
std::cout z = z.value std::endl;
std::cout w = w.value std::endl;
}
It prints:
one = (1,0)
z = (0,0)
w = (0,0)
When the value is of type double instead of complexdouble the problem doesn't
occur. Also, this doesn't happen using the compiler switch
-fno-elide-constructors .
--
Summary: Default copy constructor and assignment operator ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mjdcc at cftp dot ist dot utl dot pt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41381
[Bug c++/41381] Default copy constructor and assignment operator ignored
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-16 18:20 --- Works for me with current compilers built out any active release branch. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.4 4.4.1 4.5.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41381
[Bug target/35294] iwmmxt intrinsics, internal compiler error
--- Comment #7 from ixt at nm dot ru 2009-09-16 18:26 --- ß êîãäà-òî ïî ïîâîäó ýòîé îøèáêè îáèëüíî ãóãëèë è íàõîäèë íåñêîëüêî òðåäîâ â ýòîé áàãçèëëå. Èõ çàêðûâàëè ïîä ïðåäëîãîì duplicate. ß äóìàþ, åñëè òû çàõî÷åøü, òû èõ òîæå íàéä¸øü. Òàê ÷òî - ýòî ãëàâíûé òðåä. À òàê íàâåðíîå íàäî îòêðûâàòü íîâûé áàã è ñêîïèïàñòèòü òóäà ÷òî åñòü. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #9 from rth at gcc dot gnu dot org 2009-09-16 18:55 --- Fixed here: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01069.html -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #2 from yuri at tsoft dot com 2009-09-16 20:01 --- Created an attachment (id=18599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18599action=view) Java proxy example that crashes without -findirect-dispatch Try making an executable with -findirect-dispatch and run some large application through it's 'main' method. I get SEGV from inside this application. FreeBSD-72-STABLE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug middle-end/41360] [4.5 regression] Revision 151696 breaks gcc.c-torture/compile/builtin_unreachable-1.c
--- Comment #6 from rth at gcc dot gnu dot org 2009-09-16 20:12 --- Subject: Bug 41360 Author: rth Date: Wed Sep 16 20:12:35 2009 New Revision: 151771 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151771 Log: PR middle-end/41360 * cfgbuild.c (find_bb_boundaries): Really re-instate 2009-09-02 barrier fix. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgbuild.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41360
[Bug c/41382] New: Memory corruption observed in executable generated from struct array with compiler option -O
My source file contains some manipulation on struct arrays. After the
initialization of some local data, there is a call to a dummy function which
has its actual argument being the value of a field of one element of such an
array.
In running the executable compiled with -O, memory corruption can be observed.
Note that if the call to the dummy function is removed, the generated code runs
correctly.
Here is the example:
% cat tst.c
#include stdio.h
typedef struct {
int re, im;
} cint32_T;
static void m_foo(int i)
{}
int main()
{
static cint32_T sdata[3] = { { 504094, -1909779 }, { 658988, -552759 }, {
-15591, -896799 } };
cint32_T ldata[3];
cint32_T odata[3];
int i;
for(i = 0; i 3; i++) {// assign ldata from sdata
ldata[i] = sdata[i];
}
for(i = 0; i 3; i++) {// assign odata from ldata
odata[i] = ldata[i];
}
m_foo(ldata[2].re);// make a dummy call
// Now data stored in odata[0] is corrupted.
printf(%d, %d\n, odata[0].re, odata[0].im);
return 0;
}
% gcc -Wall tst.c -o correct
% correct
504094, -1909779
% gcc -Wall tst.c -O -o wrong
% wrong
0, 0
%
--
Summary: Memory corruption observed in executable generated from
struct array with compiler option -O
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: xqi at mathworks dot com
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=41382
[Bug middle-end/41357] libgomp build fail
--- Comment #27 from davek at gcc dot gnu dot org 2009-09-16 21:10 --- This is not really specific to debug info after all, and since tls doesn't have its own category, I think middle-end is the best description of this bug. Just about to post test results from final respin, only check-target-libffi left to go. -- davek at gcc dot gnu dot org changed: What|Removed |Added Component|debug |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug ada/41383] New: Timing_Events: Event time not cleared after Cancel_Handler
ARM D.15 about Ada.Real_Time.Timing_Events states: 9/2 An object of type Timing_Event is said to be set if it is associated with a non-null value of type Timing_Event_Handler and cleared otherwise. All Timing_Event objects are initially cleared. 17/2 The procedure Cancel_Handler clears the event if it is set. Cancelled is assigned True if the event was set prior to it being cleared; otherwise it is assigned False. 18/2 The function Time_Of_Event returns the time of the event if the event is set; otherwise it returns Real_Time.Time_First. There's a bug in the Cancel_Handler() procedure, because the event time remains set and is not reset to Ada.Real_Time.Time_First (as required by 18/2). Here is a small reproducer: -- with Ada.Real_Time.Timing_Events; package Timers is use Ada.Real_Time.Timing_Events; protected type Timer_Type is procedure Setup (At_Time : Ada.Real_Time.Time); function Get_Time return Ada.Real_Time.Time; procedure Stop (Status : out Boolean); private procedure Handle (Event : in out Timing_Event); Event : Timing_Event; end Timer_Type; end Timers; -- package body Timers is protected body Timer_Type is function Get_Time return Ada.Real_Time.Time is begin return Event.Time_Of_Event; end Get_Time; procedure Handle (Event : in out Timing_Event) is begin null; end Handle; procedure Setup (At_Time : Ada.Real_Time.Time) is begin Event.Set_Handler (At_Time = At_Time, Handler = Handle'Access); end Setup; procedure Stop (Status : out Boolean) is begin Event.Cancel_Handler (Cancelled = Status); end Stop; end Timer_Type; end Timers; -- with Ada.Text_IO; with Ada.Real_Time; with Timers; procedure Cancel_Handler is use Ada.Real_Time; Handler : Timers.Timer_Type; Timer : constant Time := Clock + Minutes (60); begin if Handler.Get_Time = Time_First then Ada.Text_IO.Put_Line (Time is Time_First ...); end if; Handler.Setup (At_Time = Timer); if Handler.Get_Time = Timer then Ada.Text_IO.Put_Line (Handler set ...); end if; declare Stopped : Boolean := False; begin Handler.Stop (Status = Stopped); if Stopped then Ada.Text_IO.Put_Line (Timer cancelled ...); if Handler.Get_Time = Timer then Ada.Text_IO.Put_Line (Why is the time still set then?); end if; end if; end; end Cancel_Handler; -- Summary: Timing_Events: Event time not cleared after Cancel_Handler Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reet at codelabs dot ch GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41383
[Bug c/41382] Memory corruption observed in executable generated from struct array with compiler option -O
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-16 21:19 --- Works on all active release branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.3 4.4.1 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41382
[Bug c/41382] Memory corruption observed in executable generated from struct array with compiler option -O
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-16 21:20 --- Confirmed with 4.2.4 btw. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41382
[Bug middle-end/41357] libgomp build fail
--- Comment #28 from davek at gcc dot gnu dot org 2009-09-16 21:29 --- Subject: Bug 41357 Author: davek Date: Wed Sep 16 21:29:17 2009 New Revision: 151773 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151773 Log: PR middle-end/41357 * varasm.c (default_encode_section_info): Copy TLS model into sym_ref flags regardless of backend support for TLS, for all model types except TLS_MODEL_EMULATED. Modified: branches/cygwin-improvements/gcc/ChangeLog.cygwin-improvements branches/cygwin-improvements/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263
--- Comment #8 from rmansfield at qnx dot com 2009-09-17 02:01 ---
I hit the PR41173 using an updated powerpc-unknown-linux-gnu configuration.
The x86 ICE is still reproducible using a reduced testcase and a mismatch of
optimizations levels.
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c++ --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090914 (experimental) [lto revision 151753] (lto merged
with rev 150842)
$ cat ice.i
typedef long double _Complex _Lcomplex;
_Lcomplex (casinhl)(_Lcomplex x) {
long double re = creall(x);
long double im = cimagl(x);
const short errx = _LDtest(re);
const short erry = _LDtest(im);
long double u, v;
if (errx == 2) if (erry == 2 || erry == 0){
const _Lcomplex w = csqrtl(_LCbuild(1.0L - im, re));
const _Lcomplex z = csqrtl(_LCbuild(1.0L + im, -re));
v = atan2l(im, creall(((w) * (z;
}
}
$ ./xgcc -B. -O -flto -lto-test ice.i -c
ice.i: In function âcasinhlâ:
ice.i:3:20: warning: incompatible implicit declaration of built-in function
âcreallâ
ice.i:4:20: warning: incompatible implicit declaration of built-in function
âcimaglâ
ice.i:9:25: warning: incompatible implicit declaration of built-in function
âcsqrtlâ
ice.i:11:9: warning: incompatible implicit declaration of built-in function
âatan2lâ
$ ./xgcc -B. -shared -flto ice.o -flto
In file included from ice.i:69:0,
from :5:
ice.i: In function âcasinhlâ:
ice.i:11:32: internal compiler error: in expand_mult, at expmed.c:3253
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
Also, has -lto-test (mentioned in the LTO_Driver wiki page) been removed or was
it ever added?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40409
[Bug c++/41384] New: initialization failure of global const variable of template class which has a constructor initializing its member which is a pointer to member data when compiled with -O2
I wrote the following code.
-- begin file haha.cc ---
struct C {
int i;
};
template typename T
struct A {
A() : p(C::i) {}
int C::*p;
};
const Aint r;
int main()
{
return 0;
}
end file haha.cc -
And I compiled it with -O2 switch. The exact compilation command given was:
$ g++ -O2 -Wall haha.cc
The compiler didn't produce any errors nor warnings. But when I ran the
generated binary, 'Segmentation fault' came up.
If you (1) make struct A a non-template class or (2) define r as non-const or
(3) declare A::p as a normal pointer or (4) don't give -O2 switch, it compiles
and runs well.
The following is the output from 'gcc -v' command:
$ gcc -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)
--
Summary: initialization failure of global const variable of
template class which has a constructor initializing its
member which is a pointer to member data when compiled
with -O2
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kyusic at gmail dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41384
[Bug middle-end/41385] New: [4.5 regression] Many regressions on trunk
On Linux/ia32, revision 151771 gave FAIL: gcc.dg/tls/alias-1.c (test for excess errors) FAIL: gcc.dg/tls/diag-1.c (test for excess errors) FAIL: gcc.dg/tls/diag-2.c (test for excess errors) FAIL: gcc.dg/tls/diag-3.c (test for excess errors) FAIL: gcc.dg/tls/diag-4.c (test for excess errors) FAIL: gcc.dg/tls/diag-5.c (test for excess errors) FAIL: gcc.dg/tls/diag-6.c (test for excess errors) FAIL: gcc.dg/tls/init-1.c (test for excess errors) FAIL: gcc.dg/tls/opt-11.c (test for excess errors) FAIL: gcc.dg/tls/section-1.c (test for excess errors) FAIL: gcc.dg/tls/trivial.c (test for excess errors) FAIL: gcc.dg/tree-ssa/20030920-1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/alias-16.c (test for excess errors) FAIL: gcc.dg/tree-ssa/ifc-3.c (test for excess errors) FAIL: gcc.dg/tree-ssa/ivopts-1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/pr15791-1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/pr20739.c (test for excess errors) FAIL: gcc.dg/weak/weak-6.c pointer conversion (test for errors, line 5) FAIL: gcc.dg/weak/weak-6.c (test for excess errors) FAIL: gcc.dg/weak/weak-7.c pointer conversion (test for errors, line 5) FAIL: gcc.dg/weak/weak-7.c (test for excess errors) FAIL: gcc.dg/weak/weak-8.c (test for excess errors) Revision 151754 is OK. -- Summary: [4.5 regression] Many regressions on trunk 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=41385
[Bug middle-end/41385] [4.5 regression] Many regressions on trunk
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-17 03:31 --- On Linux/x86-64, revision 151771 gave FAIL: gcc.dg/2111-1.c (test for excess errors) FAIL: gcc.dg/2906-1.c (test for excess errors) FAIL: gcc.dg/20010405-1.c (test for excess errors) FAIL: gcc.dg/20011214-1.c (test for excess errors) FAIL: gcc.dg/20020115-1.c (test for excess errors) FAIL: gcc.dg/20020122-1.c (test for excess errors) FAIL: gcc.dg/20020425-1.c (test for excess errors) FAIL: gcc.dg/20020607-1.c (test for excess errors) FAIL: gcc.dg/20021006-1.c (test for excess errors) FAIL: gcc.dg/20030323-1.c (test for excess errors) FAIL: gcc.dg/2003-1.c (test for excess errors) FAIL: gcc.dg/20040223-1.c (test for excess errors) FAIL: gcc.dg/20040305-2.c (test for excess errors) FAIL: gcc.dg/20040309-1.c (test for excess errors) FAIL: gcc.dg/20040322-1.c (test for excess errors) FAIL: gcc.dg/20040409-1.c (test for excess errors) FAIL: gcc.dg/20040622-2.c (test for excess errors) FAIL: gcc.dg/20040910-1.c (test for excess errors) FAIL: gcc.dg/20040920-1.c (test for excess errors) FAIL: gcc.dg/20041219-1.c (test for excess errors) FAIL: gcc.dg/20050121-1.c (test for excess errors) FAIL: gcc.dg/20050307-1.c (test for excess errors) FAIL: gcc.dg/20051207-1.c (test for excess errors) FAIL: gcc.dg/20051207-2.c (test for excess errors) FAIL: gcc.dg/20060419-1.c (test for excess errors) FAIL: gcc.dg/20061124-1.c (test for excess errors) FAIL: gcc.dg/20090902-1.c (test for excess errors) FAIL: gcc.dg/940409-1.c (test for excess errors) FAIL: gcc.dg/980816-1.c (test for excess errors) FAIL: gcc.dg/990506-0.c (test for excess errors) FAIL: gcc.dg/array-1.c (test for excess errors) FAIL: gcc.dg/array-9.c (test for excess errors) FAIL: gcc.dg/array-quals-1.c (test for excess errors) FAIL: gcc.dg/asm-1.c (test for excess errors) FAIL: gcc.dg/asm-6.c (test for excess errors) FAIL: gcc.dg/asm-7.c (test for excess errors) FAIL: gcc.dg/asm-pr24146.c (test for excess errors) FAIL: gcc.dg/attr-alias-1.c (test for excess errors) FAIL: gcc.dg/attr-alloc_size-2.c (test for excess errors) FAIL: gcc.dg/attr-error-1.c (test for excess errors) FAIL: gcc.dg/attr-nest.c (test for excess errors) FAIL: gcc.dg/attr-weak-1.c (test for excess errors) FAIL: gcc.dg/attr-weakref-1a.c (test for excess errors) FAIL: gcc.dg/attr-weakref-1b.c (test for excess errors) FAIL: gcc.dg/attr-weakref-2.c (test for excess errors) FAIL: gcc.dg/bconstp-1.c (test for excess errors) FAIL: gcc.dg/bconstp-2.c (test for excess errors) FAIL: gcc.dg/bconstp-3.c (test for excess errors) FAIL: gcc.dg/bconstp-4.c (test for errors, line 10) FAIL: gcc.dg/bconstp-4.c (test for excess errors) FAIL: gcc.dg/bitfld-2.c (test for excess errors) FAIL: gcc.dg/bitfld-2.c (test for warnings, line 15) FAIL: gcc.dg/bitfld-2.c (test for warnings, line 21) FAIL: gcc.dg/builtin-apply1.c (test for excess errors) FAIL: gcc.dg/builtin-apply2.c (test for excess errors) FAIL: gcc.dg/builtin-apply3.c (test for excess errors) FAIL: gcc.dg/builtin-constant_p-1.c (test for excess errors) FAIL: gcc.dg/builtin-inf-1.c (test for excess errors) FAIL: gcc.dg/builtin-prefetch-1.c (test for excess errors) FAIL: gcc.dg/builtin-return-1.c (test for excess errors) FAIL: gcc.dg/builtins-64.c (test for excess errors) FAIL: gcc.dg/builtins-66.c (test for excess errors) FAIL: gcc.dg/builtins-error.c (test for excess errors) FAIL: gcc.dg/builtin-strstr.c (test for excess errors) FAIL: gcc.dg/c90-array-quals-2.c (test for excess errors) FAIL: gcc.dg/c90-array-quals.c (test for excess errors) FAIL: gcc.dg/complete-port.c (test for excess errors) FAIL: gcc.dg/comp-return-1.c f1 (test for errors, line 27) FAIL: gcc.dg/comp-return-1.c f2 (test for errors, line 28) FAIL: gcc.dg/comp-return-1.c f3 (test for errors, line 29) FAIL: gcc.dg/comp-return-1.c f4 (test for errors, line 30) FAIL: gcc.dg/comp-return-1.c (test for excess errors) FAIL: gcc.dg/concat.c (test for excess errors) FAIL: gcc.dg/conv-1.c (test for excess errors) FAIL: gcc.dg/convert-vec-1.c (test for excess errors) FAIL: gcc.dg/cpp/19921210-1.c (test for excess errors) FAIL: gcc.dg/cpp/19930510-1.c (test for excess errors) FAIL: gcc.dg/cpp/19951025-1.c newline (test for errors, line 4) FAIL: gcc.dg/cpp/19951025-1.c (test for excess errors) FAIL: gcc.dg/cpp/19951227-1.c (test for excess errors) FAIL: gcc.dg/cpp/19960224-1.c (test for excess errors) FAIL: gcc.dg/cpp/19990119-1.c (test for excess errors) FAIL: gcc.dg/cpp/19990228-1.c (test for excess errors) FAIL: gcc.dg/cpp/19990407-1.c (test for excess errors) FAIL: gcc.dg/cpp/19990409-1.c (test for excess errors) FAIL: gcc.dg/cpp/19990413-1.c (test for excess errors) FAIL: gcc.dg/cpp/2127-1.c (test for excess errors) FAIL: gcc.dg/cpp/2207-1.c (test for excess errors) FAIL: gcc.dg/cpp/2207-2.c (test for excess errors) FAIL: gcc.dg/cpp/2209-1.c (test for excess errors) FAIL: gcc.dg/cpp/2301-1.c (test for excess errors) FAIL: gcc.dg/cpp/2419-1.c (test for excess errors) FAIL:
