[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #11 from pault at gcc dot gnu dot org 2009-11-20 07:57 --- Many thanks for the report. Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #10 from janus at gcc dot gnu dot org 2009-11-20 06:57 --- (In reply to comment #8) > I will take it that this is an OK from you. Sure thing. Thanks for committing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #9 from pault at gcc dot gnu dot org 2009-11-20 06:43 --- Subject: Bug 42104 Author: pault Date: Fri Nov 20 06:43:13 2009 New Revision: 154358 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154358 Log: 2009-11-20 Paul Thomas Janus Weil PR fortran/42104 * trans-expr.c (gfc_conv_procedure_call): If procedure pointer component call, use the component's 'always_explicit' attr for array arguments. 2009-11-20 Paul Thomas Janus Weil PR fortran/42104 * gfortran.dg/proc_ptr_comp_23.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug c++/9050] Can't explicitly specialize C++ constructor templates
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-02-11 23:43:25 |2009-11-20 05:17:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
[Bug c++/5023] Error declaring constructor of template class specialization as friend
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-20 05:15 --- friend S::S() is not valid; S::S names the constructor, which is not a template. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#147 -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5023
[Bug c++/561] std:unclear about Overloaded Function Pointer resolution
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-20 05:10 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=561
[Bug c++/42115] r154072 & r154073 break build of ppl, non-placement deallocation issue
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-20 05:06 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
[Bug c++/42115] r154072 & r154073 break build of ppl, non-placement deallocation issue
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-20 05:03 --- Subject: Bug 42115 Author: jason Date: Fri Nov 20 05:03:21 2009 New Revision: 154357 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154357 Log: PR c++/42115 * call.c (build_op_delete_call): Don't complain about using op delete (void *, size_t) for placement delete if there's an op delete (void *). Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/init/placement5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #8 from pault at gcc dot gnu dot org 2009-11-20 04:59 --- (In reply to comment #7) Janus, That version is a very good suggestion - thanks. I am set up to apply the patch, so, although component procedure pointers is one of your specialisations, I can efficiently get on and do it. I will take it that this is an OK from you. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-11-20 04:02 --- Subject: Bug 42090 Author: jvdelisle Date: Fri Nov 20 04:02:33 2009 New Revision: 154356 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154356 Log: 2009-11-19 Jerry DeLisle PR libgfortran/42090 * gfortran.dg/direct_io_11.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/direct_io_11.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-20 04:00 --- Subject: Bug 42090 Author: jvdelisle Date: Fri Nov 20 04:00:03 2009 New Revision: 154355 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154355 Log: 2009-11-19 Jerry DeLisle PR libgfortran/42090 Backport from trunk. * io/transfer.c (skip_record): Set bytes_left_subrecord to zero after skipping the remaining bytes in the record. (next_record_r): Call skip_record with the number of bytes_left to be skipped. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug target/42109] stack alignment happens _before_ mcount "push %ebp ..." depending on -mtune flags
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-20 04:00 --- (In reply to comment #6) > The good ones produce: > > 650: 55 push %ebp > 651: 89 e5 mov%esp,%ebp > 653: 83 e4 f0and$0xfff0,%esp > > The bad one: > > 05f0 : > 5f0: 57 push %edi > 5f1: 8d 7c 24 08 lea0x8(%esp),%edi > 5f5: 83 e4 f0and$0xfff0,%esp > 5f8: ff 77 fcpushl -0x4(%edi) > 5fb: 55 push %ebp > 5fc: 89 e5 mov%esp,%ebp > > It's worse code for no reason and breaks the kernel assumption of ebp + 4 > pointing to the real return address on the stack. I think the difference comes from DRAP: /* Nonzero if function being compiled needs dynamic realigned argument pointer (drap) if stack needs realigning. */ bool need_drap; It may be triggered by -mno-accumulate-outgoing-args, alloca, long jump, ... -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c++/42115] r154072 & r154073 break build of ppl, non-placement deallocation issue
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-20 03:10 --- That said, I can see a reading whereby since PPL also defines operator delete (void *), the operator delete (void *, size_t) isn't the usual deallocation function, so we shouldn't give an error. I'll implement that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
[Bug c++/42115] r154072 & r154073 break build of ppl, non-placement deallocation issue
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-20 03:05 ---
I just had another email exchange about this, but can't find it right now.
Anyway, 5.3.4 [expr.new]:
A declaration of a placement deallocation function matches the declaration of a
placement allocation function if it has the same number of parameters and,
after parameter transformations (8.3.5), all parameter types except the first
are identical. Any non-placement deallocation function matches a non-placement
allocation function. If the lookup finds a single matching deallocation
function, that function will be called; otherwise, no deallocation function
will be called. If the lookup finds the two-parameter form of a usual
deallocation function (3.7.4.2) and that function, considered as a placement
deallocation function, would have been selected as a match for the allocation
function, the program is ill-formed. [ Example:
struct S {
// Placement allocation function:
static void* operator new(std::size_t, std::size_t);
// Usual (non-placement) deallocation function:
static void operator delete(void*, std::size_t);
};
// ill-formed: non-placement deallocation function matches
// placement allocation function
S* p = new (0) S;
end example ]
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-20 03:06:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
[Bug c++/34158] Template delete doesn't call if exception thrown in constructor
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-20 02:37 --- . -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug c/42114] c99-stdint test fails for ptrdiff test
--- Comment #3 from joseph at codesourcery dot com 2009-11-20 02:36 --- Subject: Re: c99-stdint test fails for ptrdiff test On Fri, 20 Nov 2009, hutchinsonandy at gcc dot gnu dot org wrote: > So should I skip ptrdiff limit test based on pointers being <32 bits? Perhaps > ints < 32 bits Or do I use stdint definition of INTPTR_MAX <65535 ? I'd say skip it for the individual target for which you have decided a nonconforming choice of ptrdiff_t is more useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114
[Bug c++/34158] Template delete doesn't call if exception thrown in constructor
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-20 02:31 --- Fixed -- jason at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug c/42114] c99-stdint test fails for ptrdiff test
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-11-20 02:07 --- I found c99 limit now which explains it. I was tempted to make PTRDIFF_TYPE signed 32 bits to solve c99 compliance - however that completely useless as we cannot declare array exceeding > 32767 bytes anyway (http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00023.html), despite it being physically possible and with SIZE_TYPE unsigned 16 bits. Skipping the paricular test would seem appropriate - keeping the others which are useful. So should I skip ptrdiff limit test based on pointers being <32 bits? Perhaps ints < 32 bits Or do I use stdint definition of INTPTR_MAX <65535 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114
[Bug c/42107] Scanning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #7 from suren dot r at live dot in 2009-11-20 02:02 --- (In reply to comment #6) > (In reply to comment #5) > > Mr. Andrew, > > I dont understand the term 'undefined code'. Are you saying this is not a > > bug? > > This is not a bug in GCC but the code you wrote. scanf's %d takes a pointer > to > an int variable and not a pointer to a char variable. > This is a defacto standard in embedded industry to save memory. You can see the second value gets the number from the scanf correctly. why the first number can't? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug c++/42115] r154072 & r154073 break build of ppl, non-placement deallocation issue
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-11-20 01:47 --- Created an attachment (id=19063) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19063&action=view) preprocessed source, still quite large -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
[Bug c++/42115] New: r154072 & r154073 break build of ppl, non-placement deallocation issue
There is an issue with non-placement deallocation: In file included from ../../../../../../../src/ppl-0.10.2/src/Row.defs.hh:504:0, from ../../../../../../../src/ppl-0.10.2/src/Linear_Row.defs.hh:28, from ../../../../../../../src/ppl-0.10.2/src/Constraint.defs.hh:28, from ../../../../../../../src/ppl-0.10.2/src/Box.defs.hh:33, from ../../../../../../../src/ppl-0.10.2/src/Box.cc:24: ../../../../../../../src/ppl-0.10.2/src/Row.inlines.hh: In member function 'void Parma_Polyhedra_Library::Row::allocate(Parma_Polyhedra_Library::dimension_type, Parma_Polyhedra_Library::Row::Flags)': ../../../../../../../src/ppl-0.10.2/src/Row.inlines.hh:92:1: error: non-placement deallocation function 'static void Parma_Polyhedra_Library::Row_Impl_Handler::Impl::operator delete(void*, Parma_Polyhedra_Library::dimension_type)' ../../../../../../../src/ppl-0.10.2/src/Row.inlines.hh:224:31: error: selected for placement delete caused by: Author: jason Date: Tue Nov 10 18:18:51 2009 New Revision: 154072 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154072 Log: PR c++/34158 PR c++/36406 * call.c (non_placement_deallocation_fn_p): Split out... (build_op_delete_call): ...from here. Use instantiate_type for placement delete. Simplify logic. * pt.c (primary_template_instantiation_p): Non-static. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/init/placement4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog and Author: jason Date: Tue Nov 10 18:31:22 2009 New Revision: 154073 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154073 Log: * call.c (build_op_delete_call): Tweak error. Added: trunk/gcc/testsuite/g++.dg/init/placement5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- Summary: r154072 & r154073 break build of ppl, non-placement deallocation issue Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer at emrich-ebersheim dot de GCC build triplet: *-*-mingw32 GCC host triplet: *-*-mingw32 GCC target triplet: *-*-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
[Bug c/42114] c99-stdint test fails for ptrdiff test
--- Comment #1 from joseph at codesourcery dot com 2009-11-20 01:13 --- Subject: Re: New: c99-stdint test fails for ptrdiff test On Fri, 20 Nov 2009, hutchinsonandy at gcc dot gnu dot org wrote: > __PTRDIFF_MAX__ is set by gcc at 32767 and so stdint.h gives PTRDIFF_MAX 32767 > and PTRDIFF_MIN -32768 > > I am not sure why minimum range limits are applied in this test or if > test/gcc/target is wrong. C99 specifies these as the minimum range of ptrdiff_t, so this target is not conforming with C99 in this respect. I suppose you could disable the relevant tests for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114
[Bug c/42114] New: c99-stdint test fails for ptrdiff test
Test gcc.dg/c99-stdint-1.c checks for range of__PTRDIFF_TYPE__ and fails for
avr target.
test_misc_limits (void)
{
CHECK_SIGNED_LIMITS_2(__PTRDIFF_TYPE__, PTRDIFF_MIN, PTRDIFF_MAX, -65535L,
65535L);
On AVR pointers and integers are 16bit.
INTPTR_MIN =-32768
INTPTR_MAX = 32767
UINTPTR_MAX = 65535U
__PTRDIFF_MAX__ is set by gcc at 32767 and so stdint.h gives PTRDIFF_MAX 32767
and PTRDIFF_MIN -32768
I am not sure why minimum range limits are applied in this test or if
test/gcc/target is wrong.
--
Summary: c99-stdint test fails for ptrdiff test
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114
[Bug target/42109] stack alignment happens _before_ mcount "push %ebp ..." depending on -mtune flags
--- Comment #6 from tglx at linutronix dot de 2009-11-20 00:52 --- I changed the summary to match the real problem. Further info: While testing various kernel configs we found out that the problem comes and goes. Finally I started to compare the gcc command line options and after some fiddling it turned out that the following minimal deltas change the code generator behaviour: Bad: -march=pentium-mmx-Wa,-mtune=generic32 Good: -march=i686-mtune=generic -Wa,-mtune=generic32 Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32 The good ones produce: 650: 55 push %ebp 651: 89 e5 mov%esp,%ebp 653: 83 e4 f0and$0xfff0,%esp The bad one: 05f0 : 5f0: 57 push %edi 5f1: 8d 7c 24 08 lea0x8(%esp),%edi 5f5: 83 e4 f0and$0xfff0,%esp 5f8: ff 77 fcpushl -0x4(%edi) 5fb: 55 push %ebp 5fc: 89 e5 mov%esp,%ebp It's worse code for no reason and breaks the kernel assumption of ebp + 4 pointing to the real return address on the stack. -- tglx at linutronix dot de changed: What|Removed |Added Summary|16 byte stack alignment on |stack alignment happens |random Linux kernel |_before_ mcount "push %ebp |functions |..." depending on -mtune ||flags http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug regression/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #2 from mattst88 at gmail dot com 2009-11-20 00:45 --- Created an attachment (id=19062) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19062&action=view) Test Case 2 - flist.i - preprocessed flist.c from rsync -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug regression/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #1 from mattst88 at gmail dot com 2009-11-20 00:44 --- Created an attachment (id=19061) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19061&action=view) Test Case 1 - pp.i - preprocessed pp.c from libperl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug regression/42113] New: [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
Unfortunately, but 8603 seems to cause internal compiler errors on select files
when using -O3. -O{s,0,1,2} are unaffected.
I'm attaching pp.i (preprocessed pp.c from libperl), and flist.i (preprocessed
flist.c from rsync) as test cases.
gcc-4.3.4 does not exhibit this failure, but when patched from bug 8603, it
fails. gcc-4.4.1 does not exhibit this failure, but gcc-4.4.2, which includes
the patch from 8603, does fail.
--
Summary: [4.3/4.4/4.5 Regression] Internal Compiler error with -
O3, breaking commit known
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattst88 at gmail dot com
GCC build triplet: alpha-unknown-linux-gnu
GCC host triplet: alpha-unknown-linux-gnu
GCC target triplet: alpha-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug fortran/42112] overloaded function with allocatable result problem
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2009-11-20 00:20 ---
Subject: Re: overloaded function with allocatable result problem
If the code is compiled with -fdump-tree-original one
immediately see the cause of the runtime error. Eliminating
the common code in the dumps, I find this code
pure function f() result(i)
integer :: i
integer, allocatable :: loc_ar(:)
allocate(loc_ar(1))
loc_ar = gen_g() ! does not work
deallocate(loc_ar)
i = 1
end function f
generates
f ()
{
g (&loc_ar);
}
loc_ar has been allocated and the pointer to it is passed
to g() where is becomes associated with the result variable j.
You then try to allocate j, which is already allocated.
When you call g() directly in
pure function f() result(i)
integer :: i
integer, allocatable :: loc_ar(:)
allocate(loc_ar(1))
loc_ar = g() ! no problem here
deallocate(loc_ar)
i = 1
end function f
the dump shows
f ()
{
{
integer(kind=8) D.1398;
struct array1_integer(kind=4) atmp.1;
integer(kind=8) D.1393;
integer(kind=8) D.1392;
integer(kind=8) D.1391;
integer(kind=4)[0:] * restrict D.1390;
D.1390 = (integer(kind=4)[0:] * restrict) loc_ar.data;
D.1391 = loc_ar.offset;
D.1392 = loc_ar.dim[0].lbound;
D.1393 = loc_ar.dim[0].ubound;
atmp.1.dtype = 265;
atmp.1.data = 0B;
atmp.1.offset = 0;
g (&atmp.1);
g() is called with a unallocated temporary variable, so
your allocation in g() works. The next several lines
copy atmp into loc_ar.
D.1398 = NON_LVALUE_EXPR ;
{
integer(kind=8) S.2;
S.2 = 0;
while (1)
{
if (atmp.1.dim[0].ubound - atmp.1.dim[0].lbound < S.2) goto L.2;
(*D.1390)[(S.2 + D.1398) + D.1391]
= (*(integer(kind=4)[0:] * restrict) atmp.1.data)[S.2];
S.2 = S.2 + 1;
}
L.2:;
}
Here, the temporary variable is destroyed.
{
void * D.1397;
D.1397 = (void *) atmp.1.data;
if (D.1397 != 0B)
{
__builtin_free (D.1397);
}
}
}
}
I need to go read the Fortran standard to determine the
semantics of a function returning an allocatable entity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-11-20
00:13 ---
Why do we have
case dw_val_class_const_double:
switch (HOST_BITS_PER_WIDE_INT)
{
case 8:
return DW_FORM_data2;
case 16:
return DW_FORM_data4;
case 32:
return DW_FORM_data8;
case 64:
default:
return DW_FORM_block1;
}
in gcc/dwarf2out.c? Almost all of the other case statements in the subroutine
value_format() have
default:
gcc_unreachable ();
for the default case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug fortran/42112] overloaded function with allocatable result problem
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-19 23:55 --- If you remove allocate(loc_ar(1)) deallocate(loc_ar) in function f(), the code compiles and runs in either case. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112
[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-11-19 23:27 --- We have an update on radar 7397601 from Nick Kledzik... 7397601 is a bug in dsymutils. It was not handling the case when the dwarf debug info contained an AT_location with form DW_FORM_block1 with zero length. It may also be possible to have the compiler not emit that as a work around. Could we get a proposed patch to have the compiler not emit this offending code on darwin (at least so that we can verify that this is the only source of the dsymutils aborts after the VAR merge)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #7 from anlauf at gmx dot de 2009-11-19 22:33 --- I tried the code on a x86 Core2 system (32 bit mode). gfortran 4.3, 4.5: 22.74user 0.03system 0:22.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k Intels ifort 11.1 is only ~ 5% faster, but: SunStudio 12.1: (sunf95 -fast) 11.50user 0.00system 0:11.51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k Wow, that gives a 100% improvement potential! (I added a print *, foo3(n) after the call to eval to make sure that nothing gets optimized away.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug middle-end/40281] [4.4/4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #9 from spop at gcc dot gnu dot org 2009-11-19 22:33 --- Subject: Bug 40281 Author: spop Date: Thu Nov 19 22:32:50 2009 New Revision: 154348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154348 Log: Fix PR40281. 2009-11-18 Sebastian Pop PR middle-end/40281 * testsuite/gcc.dg/graphite/pr40281.c: New. * tree-scalar-evolution.c (instantiate_scev_poly): Base and stride evolutions should not variate in inner loops. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr40281.c Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug middle-end/42050] [4.5 Regression] ice in graphite-clast-to-gimple.c:165
--- Comment #3 from spop at gcc dot gnu dot org 2009-11-19 22:33 --- Subject: Bug 42050 Author: spop Date: Thu Nov 19 22:32:44 2009 New Revision: 154347 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154347 Log: Testcase for PR42050. 2009-11-18 Sebastian Pop PR middle-end/42050 * testsuite/gfortran.dg/graphite/pr42050.f90: New. Added: branches/graphite/gcc/testsuite/gfortran.dg/graphite/pr42050.f90 Modified: branches/graphite/gcc/ChangeLog.graphite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42050
[Bug fortran/42112] New: overloaded function with allocatable result problem
The attached code produces an error at runtime, however it seems fine to me. Notice that there is no error accessing the function with the specific name "g", while there is an error when using the generic name "gen_g". gfortran --version GNU Fortran (GCC) 4.5.0 20091105 (experimental) gfortran ./abc.f90 -o abc ./abc At line 23 of file ./abc.f90 Fortran runtime error: Attempting to allocate already allocated array 'j' module mod_m implicit none public :: f private interface gen_g module procedure g end interface contains pure function f() result(i) integer :: i integer, allocatable :: loc_ar(:) allocate(loc_ar(1)) loc_ar = gen_g() ! does not work !loc_ar = g() ! no problem here deallocate(loc_ar) end function f pure function g() result(j) integer, allocatable :: j(:) allocate( j(1) ) j = 2 end function g end module mod_m !-- program abc_main use mod_m, only: f implicit none integer :: p p = f() end program abc_main -- Summary: overloaded function with allocatable result problem Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrestelli at gmail dot com GCC host triplet: Linux 2.6.27-gentoo-r8 x86_64 AMD Turion(tm) GCC target triplet: GNU Fortran (GCC) 4.5.0 20091105 (experimental) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112
[Bug middle-end/40281] [4.4/4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #8 from spop at gcc dot gnu dot org 2009-11-19 22:14 ---
Subject: Re: [4.4/4.5 Regression] -fprefetch-loop-arrays:
ICE: in initialize_matrix_A, at tree-data-ref.c:1887
Hi,
Here is a fix for this one, on top of the graphite branch.
I will commit this fix to the graphite branch to run the automatic testers,
and then it will be included in the merge from graphite to trunk.
Sebastian
diff --git a/gcc/tree-scalar-evolution.c b/gcc/tree-scalar-evolution.c
index fcd3382..7321b6e 100644
--- a/gcc/tree-scalar-evolution.c
+++ b/gcc/tree-scalar-evolution.c
@@ -2215,9 +2215,21 @@ instantiate_scev_poly (basic_block instantiate_below,
if (CHREC_LEFT (chrec) != op0
|| CHREC_RIGHT (chrec) != op1)
{
+ unsigned var = CHREC_VARIABLE (chrec);
+
+ /* When the instantiated stride or base has an evolution in an
+innermost loop, return chrec_dont_know, as this is not a
+valid SCEV representation. In the reduced testcase for
+PR40281 we would have {0, +, {1, +, 1}_2}_1 that has no
+meaning. */
+ if ((tree_is_chrec (op0) && CHREC_VARIABLE (op0) > var)
+ || (tree_is_chrec (op1) && CHREC_VARIABLE (op1) > var))
+ return chrec_dont_know;
+
op1 = chrec_convert_rhs (chrec_type (op0), op1, NULL);
- chrec = build_polynomial_chrec (CHREC_VARIABLE (chrec), op0, op1);
+ chrec = build_polynomial_chrec (var, op0, op1);
}
+
return chrec;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-19 21:59 --- (In reply to comment #6) > Index: gcc/fortran/trans-expr.c > === > --- gcc/fortran/trans-expr.c(revision 154327) > +++ gcc/fortran/trans-expr.c(working copy) > @@ -2979,7 +2979,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * > f = (fsym != NULL) > && !(fsym->attr.pointer || fsym->attr.allocatable) > && fsym->as->type != AS_ASSUMED_SHAPE; > - f = f || !sym->attr.always_explicit; > + if (comp) > + f = f || !comp->attr.always_explicit; > + else > + f = f || !sym->attr.always_explicit; > > if (e->expr_type == EXPR_VARIABLE > && is_subref_array (e)) This patch makes the test case work and regtests without regressions. Paul, should I commit it or do you prefer your version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug middle-end/42111] New: Failure in gcc.dg/cleanup-13.c on older x86 boxes
I seeing failures in gcc.dg/cleanup-13.c on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu with gcc-4.4.3 svn. E.g.: FAIL: gcc.dg/cleanup-13.c (test for excess errors) http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01708.html gcc.dg/cleanup-13.c: Assembler messages: gcc.dg/cleanup-13.c:305: Error: CFI instruction used without previous .cfi_startproc compiler exited with status 1 The failure only occurs on certain systems. E.g. on CFARM gcc14 it does NOT occur. However I do see it on nearly every other CFARM i686 & x86_64 box (e.g. gcc03, gcc09, gcc11, gcc12, gcc13, gcc16, gcc17 all fail). It probably has to do with older software (gas?) I seem to recall this came up before and don't recall whether it was fixed somehow or not. But the error does not occur on mainline. The uname and as --version output on the box it passes is: Linux gcc14 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux GNU assembler (GNU Binutils for Debian) 2.18.0.20080103 And if it helps, the uname and as --version output on the failing systems is: Linux gcc03 2.6.12-10-686-smp #1 SMP Fri Nov 18 12:27:41 UTC 2005 i686 GNU/Linux GNU assembler 2.16.1 Debian GNU/Linux Linux gcc09 2.6.12-10-686-smp #1 SMP Sat Mar 11 16:41:12 UTC 2006 i686 GNU/Linux GNU assembler 2.16.1 Debian GNU/Linux Linux gcc11 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc12 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc13 2.6.18-6-vserver-amd64 #1 SMP Sun Feb 10 17:55:04 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc16 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc17 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux -- Summary: Failure in gcc.dg/cleanup-13.c on older x86 boxes Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42111
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #17 from andreast at gcc dot gnu dot org 2009-11-19 21:15 --- Unfortunately I'm now in the same boat with you: [deuterium:gcc/head/objdir-x86_64] andreast% ./gcc/xgcc -v Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: x86_64-apple-darwin9 Configured with: /Volumes/development/gcc/head/gcc/configure --prefix=/Volumes/development/gcc/head/testbin-x86_64 --build=x86_64-apple-darwin9 --target=x86_64-apple-darwin9 --with-gmp=/usr/local/x86_64 --with-mpfr=/usr/local/x86_64 --disable-static --enable-languages=c,c++,java --disable-multilib Thread model: posix gcc version 4.5.0 20091119 (experimental) [trunk revision 154326] (GCC) And now I always get the abort too: [deuterium:~] andreast% gcj -C hello.java gcj: Internal error: Abort trap (program ecj1) Please submit a full bug report. See <http://gcc.gnu.org/bugs.html> for instructions. CrashReporter: Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x, 0x Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x7fff80fc1f16 __kill + 10 1 libgcj.11.dylib 0x0001000136bb _Jv_Throw + 75 (exception.cc:128) 2 libgcj.11.dylib 0x000100052582 java::lang::Class* java::lang::Class::forName(java::lang::String*, bool, java::lang::ClassLoader*) + 226 (natClass.cc:108) 3 ??? 0x6176616a2e756e67 0 + 702290604742759 Big sigh! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug middle-end/42050] [4.5 Regression] ice in graphite-clast-to-gimple.c:165
--- Comment #2 from spop at gcc dot gnu dot org 2009-11-19 21:12 --- Fixed in the Graphite branch. The changes of the branch will be pushed into trunk soon. I will commit the reduced testcase to the Graphite testsuite. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42050
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-19 21:09 --- (In reply to comment #5) > The fix is to make use of the fact a proc_pointer component call is already > detected and can be used to suppress the internal_pack. Thusly: > > Index: gcc/fortran/trans-expr.c > === > --- gcc/fortran/trans-expr.c(revision 153651) > +++ gcc/fortran/trans-expr.c(working copy) > @@ -2918,7 +2918,7 @@ > f = (fsym != NULL) > && !(fsym->attr.pointer || fsym->attr.allocatable) > && fsym->as->type != AS_ASSUMED_SHAPE; > - f = f || !sym->attr.always_explicit; > + f = f || (!sym->attr.always_explicit && !comp); > > if (e->expr_type == EXPR_VARIABLE > && is_subref_array (e)) > > This fixes the PR but has not been regtested. I will do this tonight. If all > is well, I will commit as obvious, although your OK would be helpful, Janus! The question is if you want to do this for *all* PPCs. It seems the 'always_explicit' flag is correctly set for PPCs (by the same criteria as for normal procedures). Therefore I would propose the following: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 154327) +++ gcc/fortran/trans-expr.c(working copy) @@ -2979,7 +2979,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * f = (fsym != NULL) && !(fsym->attr.pointer || fsym->attr.allocatable) && fsym->as->type != AS_ASSUMED_SHAPE; - f = f || !sym->attr.always_explicit; + if (comp) + f = f || !comp->attr.always_explicit; + else + f = f || !sym->attr.always_explicit; if (e->expr_type == EXPR_VARIABLE && is_subref_array (e)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
-- 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=42110
[Bug middle-end/42110] New: [4.5 Regression] ICE with inlining
The following valid code snippet triggers an ICE on trunk
when compiled with "-O2":
===
bool foo();
struct A
{
A* fooA() { if (foo()) foo(); return this; }
virtual void barA(char);
};
template struct B
{
A *p, *q;
void fooB(char c) { p->fooA()->barA(c); }
};
template inline void bar(B b) { b.fooB(0); }
extern template void bar(B<0>);
void (*f)(B<0>) = bar;
void baz()
{
B<0>().fooB(0);
}
===
bug.cc:26:1: error: inlined_to pointer set for noninline callers
bug.cc:26:1: error: multiple inline callers
A::fooA()/7(-1) @0xb7cea820 (inline copy in baz()/1) availability:available 17
time, 12 benefit 6 size, 3 benefit reachable body finalized inlinable
called by: _ZN1BILi0EE4fooBEc.clone.0/5 (1.00 per call) (can throw external)
_ZN1BILi0EE4fooBEc.clone.0/6 (1.00 per call) (inlined) (can throw external)
calls: foo()/4 (1.00 per call) (can throw external) foo()/4 (0.39 per call)
(can throw external)
bug.cc:26:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report, [etc.]
The regression was introduced between 2009-11-13 and 2009-11-17.
--
Summary: [4.5 Regression] ICE with inlining
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
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=42110
[Bug target/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec
--- Comment #7 from brunorex at gmail dot com 2009-11-19 20:08 --- I don't get the error anymore with gcc 4.5.0 20091112. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #6 from toon at moene dot org 2009-11-19 19:53 --- Richard Guenther wrote: > Well, within eval there's nothing really obvious to me. The > innermost loop is exactly the same: But it is a very inefficient way of vectorizing, because the inner loop's body is either executed twice or three times per outer loop (depending on the value of i). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #5 from sfilippone at uniroma2 dot it 2009-11-19 19:42 --- (In reply to comment #4) > Subject: Re: [4.4/4.5 Regression] Vectorizer > cannot deal with PAREN_EXPR gracefully, 50% performance regression > > > Heh, with -fwhole-program GCC optimizes the test away and I get 0.0s > runtime. > Not too surprising, after all this was extracted to make the test case manageable, the original code is not pointless..:-) > Well, within eval there's nothing really obvious to me. The > innermost loop is exactly the same: > > .L39: > movsd (%r15), %xmm0 > addq%rsi, %r15 > subsd (%rdx), %xmm0 > addq%rsi, %rdx > subl$1, %eax > mulsd %xmm0, %xmm0 > addsd %xmm0, %xmm1 > jne .L39 > > the next outer loop has some less loads in 4.5 but also different > induction variables. So - nothing obvious to me. > Exactly, it's quite surprising to see a difference with such a simple loop. However the size of the generated assembler is different, so there must be something... > Richard. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug target/42109] 16 byte stack alignment on random Linux kernel functions
--- Comment #5 from tglx at linutronix dot de 2009-11-19 19:27 ---
(In reply to comment #4)
> Is this really a bug since you have:
> struct entry {
> ...
> } __attribute__((__aligned__((1 << (4);
>
> ...
>
> void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
> void *timerf, char *comm,
> unsigned int timer_flag)
> {
> spinlock_t *lock;
> struct entry *entry, input;
>
>
> Since input is required to be 16byte aligned by the __aligned__ attribute on
> the struct.
Yes, Andrew pointed that out in the LKML thread as well. This still does not
explain why the mcount magic
push %ebp
mov %esp, %ebp
happens _after_ the alignment and the stack layout assumption of mcount:
return address
saved ebp
is done via a copy of the return address instead of just keeping the
push %ebp
mov %esp, %ebp
sequence right at the beginning of the function.
GCC 4.4.x silently changed this and we now need to figure out how to _NOT_ trip
over that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c/42097] Reference operator (&) error from included file.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 19:12 --- >Take a look at "The C Programming Language" by Kernighan and Ritchie, chapter 5. But this is not a reference operator at this point. It is for a reference type. Reference types are different from the reference operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097
[Bug c/42097] Reference operator (&) error from included file.
--- Comment #2 from bradhomer at gbis dot com 2009-11-19 19:11 --- Subject: Re: Reference operator (&) error from included file. Take a look at "The C Programming Language" by Kernighan and Ritchie, chapter 5. On 18 Nov 2009 20:11:51 -, "pinskia at gcc dot gnu dot org" wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-18 20:11 > --- > C90/C99 does not have a reference type. > > extern void Prop (double &, double &, double &, double &, double &, double > &, > int) ; > > is C++ code, compile it with the C++ front-end. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #13 from aoliva at gcc dot gnu dot org 2009-11-19 18:54 --- > one could randomize the delta we add to next_decl_uid Yeah, that would be an interesting test. In fact, we had something along these lines before, when we used (randomized) pointers rather than uids, and we failed. I don't think anything was done to avoid this kind of failure, and randomizing decl uids could get even those that passed because of uid stability to fail compare-debug. I guess we'll only know for sure when someone undertakes it. Thanks for looking into the lto/compare-debug regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #7 from ludovic at ludovic-brenta dot org 2009-11-19 18:50 --- Created an attachment (id=19060) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19060&action=view) Disassembly of prj-part.adb, with sources (objdump -S) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug target/42109] 16 byte stack alignment on random Linux kernel functions
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-19 18:34 ---
Is this really a bug since you have:
struct entry {
...
} __attribute__((__aligned__((1 << (4);
...
void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
void *timerf, char *comm,
unsigned int timer_flag)
{
spinlock_t *lock;
struct entry *entry, input;
Since input is required to be 16byte aligned by the __aligned__ attribute on
the struct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c/42109] 16 byte stack alignment on random Linux kernel functions
--- Comment #3 from tglx at linutronix dot de 2009-11-19 18:30 --- Created an attachment (id=19059) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19059&action=view) compiler command line -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c/42109] 16 byte stack alignment on random Linux kernel functions
--- Comment #2 from tglx at linutronix dot de 2009-11-19 18:28 --- Created an attachment (id=19058) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19058&action=view) intermediate file timer_stats.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c/42109] 16 byte stack alignment on random Linux kernel functions
--- Comment #1 from tglx at linutronix dot de 2009-11-19 18:27 --- Created an attachment (id=19057) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19057&action=view) source code (kernel/time/timer_stat.c) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c/42109] New: 16 byte stack alignment on random Linux kernel functions
Random Linux Kernel functions have 16 byte stack alignment at the start of the function. This stack alignment happens before the push %ebp mov %esp, %ebp sequence and breaks the kernel function graph tracer which needs to manipulate the return address. When the alignment happens then still 4(%ebp) contains the return address, but this is only a copy of the real stack entry which is used by the ret instruction. So the tracer modifies the copy and not the real return address stack entry. There are two problems: 1) why is gcc doing 16 byte stack aligment at all 2) why is the stack alignment happening _before_ the "push %ebp, mov %esp %ebp" sequence. -- Summary: 16 byte stack alignment on random Linux kernel functions Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tglx at linutronix dot de GCC build triplet: i586-redhat-linux GCC host triplet: i586-redhat-linux GCC target triplet: i586-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
[Bug c/42107] Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-11-19 18:07 --- (In reply to comment #5) > Mr. Andrew, > I dont understand the term 'undefined code'. Are you saying this is not a bug? This is not a bug in GCC but the code you wrote. scanf's %d takes a pointer to an int variable and not a pointer to a char variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug c/42107] Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #5 from suren dot r at live dot in 2009-11-19 18:05 --- Mr. Andrew, I dont understand the term 'undefined code'. Are you saying this is not a bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #4 from rguenther at suse dot de 2009-11-19 17:30 --- Subject: Re: [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression On Thu, 19 Nov 2009, sfilippone at uniroma2 dot it wrote: > --- Comment #3 from sfilippone at uniroma2 dot it 2009-11-19 17:17 > --- > (In reply to comment #2) > > -ftree-vectorizer-verbose=2 tells you: > > > > eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 = > > ((D.1683_72)); > > > > eval.f90:32: note: not vectorized: relevant stmt not supported: D.1684_58 = > > ((D.1683_57)); > > > > PAREN_EXPRs are new in 4.4 and I believe they cannot be turned off > > right now. > > > > The loops are > > > > do i=1,nnd > > x(i) = 1.d0 + (1.d0*i)/nnd > > end do > > do i=1,n > > foo4(i) = 1.d0 + (1.d0*i)/n > > end do > > > > where the vectorizer doesn't know how to ensure evaluation order is > > preserved when trying to vectorize (1.d0*i)/n. Writing them as > > 1.d0*i/n vectorizes the function. > > > > Still the performance is lower by a factor of two compared to 4.3 > > (even with -ffast-math). > > > > Probably the bug should be split. > > > > Well, the performance drop I am looking at is in the subroutine. The > initialization loops are (to me) irrelevant, I had posted a previous version > to the mailing list where the initialization was done with random_number and > the situation was the same. > A run with profiling shows that more than 99% of the time is spent in eval_ Heh, with -fwhole-program GCC optimizes the test away and I get 0.0s runtime. Well, within eval there's nothing really obvious to me. The innermost loop is exactly the same: .L39: movsd (%r15), %xmm0 addq%rsi, %r15 subsd (%rdx), %xmm0 addq%rsi, %rdx subl$1, %eax mulsd %xmm0, %xmm0 addsd %xmm0, %xmm1 jne .L39 the next outer loop has some less loads in 4.5 but also different induction variables. So - nothing obvious to me. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #3 from sfilippone at uniroma2 dot it 2009-11-19 17:17 --- (In reply to comment #2) > -ftree-vectorizer-verbose=2 tells you: > > eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 = > ((D.1683_72)); > > eval.f90:32: note: not vectorized: relevant stmt not supported: D.1684_58 = > ((D.1683_57)); > > PAREN_EXPRs are new in 4.4 and I believe they cannot be turned off > right now. > > The loops are > > do i=1,nnd > x(i) = 1.d0 + (1.d0*i)/nnd > end do > do i=1,n > foo4(i) = 1.d0 + (1.d0*i)/n > end do > > where the vectorizer doesn't know how to ensure evaluation order is > preserved when trying to vectorize (1.d0*i)/n. Writing them as > 1.d0*i/n vectorizes the function. > > Still the performance is lower by a factor of two compared to 4.3 > (even with -ffast-math). > > Probably the bug should be split. > Well, the performance drop I am looking at is in the subroutine. The initialization loops are (to me) irrelevant, I had posted a previous version to the mailing list where the initialization was done with random_number and the situation was the same. A run with profiling shows that more than 99% of the time is spent in eval_ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug libstdc++/41622] [DR 1245] [c++0x] std::hash::operator() copies its argument
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-19 17:03 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41622
[Bug c++/561] std:unclear about Overloaded Function Pointer resolution
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-19 16:59 --- Subject: Bug 561 Author: jason Date: Thu Nov 19 16:59:05 2009 New Revision: 154336 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154336 Log: PR c++/561 * decl.c (static_fn_type): Split out... (revert_static_member_fn): ...from here. * cp-tree.h: Declare it. * class.c (resolve_address_of_overloaded_function): Use it to compare pointers to member functions. * typeck.c (build_static_cast_1): Call instantiate_type. Added: trunk/gcc/testsuite/g++.dg/overload/pmf2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=561
[Bug libstdc++/41622] [DR 1245] [c++0x] std::hash::operator() copies its argument
--- Comment #8 from paolo at gcc dot gnu dot org 2009-11-19 16:55 --- Subject: Bug 41622 Author: paolo Date: Thu Nov 19 16:55:25 2009 New Revision: 154335 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154335 Log: 2009-11-19 Paolo Carlini PR libstdc++/41622 * include/bits/functional_hash.h: Implement inline the various std::hash specializations, using, when appropriate, pass by const ref too, per DR 1245. * include/tr1_impl/functional_hash.h: Remove, move its contents... * include/tr1/functional_hash.h: ... here. * include/std/functional: Tweak includes. * src/hash_c++0x: Rename to... * src/compatibility-c++0x.cc: ... this, implementing compatibility std::hash<>::operator() specializations. * src/hash.cc: Do not mark specializations as throw(). * src/Makefile.am: Adjust. * include/Makefile.am: Likewise. * src/Makefile.in: Regenerate. * include/Makefile.in: Likewise. * testsuite/util/testsuite_api.h: Define a dummy hash for NonDefaultConstructible. * testsuite/23_containers/unordered_map/requirements/ explicit_instantiation/2.cc: Use it. * testsuite/23_containers/unordered_multimap/requirements/ explicit_instantiation/2.cc: Likewise. * testsuite/23_containers/unordered_set/requirements/ explicit_instantiation/2.cc: Likewise. * testsuite/23_containers/unordered_multiset/requirements/ explicit_instantiation/2.cc: Likewise. Added: trunk/libstdc++-v3/src/compatibility-c++0x.cc - copied, changed from r154326, trunk/libstdc++-v3/src/hash_c++0x.cc Removed: trunk/libstdc++-v3/include/tr1_impl/functional_hash.h trunk/libstdc++-v3/src/hash_c++0x.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/functional_hash.h trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/include/tr1/functional_hash.h trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/hash.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/explicit_instantiation/2.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/requirements/explicit_instantiation/2.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/requirements/explicit_instantiation/2.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/explicit_instantiation/2.cc trunk/libstdc++-v3/testsuite/util/testsuite_api.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41622
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-19 16:49 --- -ftree-vectorizer-verbose=2 tells you: eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 = ((D.1683_72)); eval.f90:32: note: not vectorized: relevant stmt not supported: D.1684_58 = ((D.1683_57)); PAREN_EXPRs are new in 4.4 and I believe they cannot be turned off right now. The loops are do i=1,nnd x(i) = 1.d0 + (1.d0*i)/nnd end do do i=1,n foo4(i) = 1.d0 + (1.d0*i)/n end do where the vectorizer doesn't know how to ensure evaluation order is preserved when trying to vectorize (1.d0*i)/n. Writing them as 1.d0*i/n vectorizes the function. Still the performance is lower by a factor of two compared to 4.3 (even with -ffast-math). Probably the bug should be split. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at il dot ibm dot com, ||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|fortran |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2009-11-19 16:49:51 date|| Summary|Performance drop from 4.3 to|[4.4/4.5 Regression] |4.4/4.5 |Vectorizer cannot deal with ||PAREN_EXPR gracefully, 50% ||performance regression Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #22 from yipiha2008 at gmail dot com 2009-11-19 16:47 --- I tried applying this patch: (define_insn "*iwmmxt_movsi_insn" - [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z,r,?z,Uy,z") + [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z,rk,?z,Uy,z") (match_operand:SI 1 "general_operand" "rk, I,K,mi,rk,r,z,Uy,z, z"))] "TARGET_REALLY_IWMMXT && ( register_operand (operands[0], SImode) I really have no clue as to whether it is correct or not. I rely on the assembler to crash with an error in the event this generates an invalid instruction. So far I compiled a lot of stuff with this patch applied, and I got no ICE. However it's likely that the generated code is incorrect somehow and my code will crash (SIGILL?) when executed. I will test this in a few hours. Any other idea? Maybe we could contact the people who originally wrote the iwmmxt.md file, they might be able to help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #8 from tromey at gcc dot gnu dot org 2009-11-19 16:45 --- Created an attachment (id=19056) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19056&action=view) patch for readelf This patch modifies the binutils readelf utility to dump the new section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #7 from tromey at gcc dot gnu dot org 2009-11-19 16:30 --- Created an attachment (id=19055) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19055&action=view) modified patch I've slightly updated the patch to handle non-public entities as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug fortran/42108] Performance drop from 4.3 to 4.4/4.5
--- Comment #1 from sfilippone at uniroma2 dot it 2009-11-19 16:01 --- Created an attachment (id=19054) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19054&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/42108] New: Performance drop from 4.3 to 4.4/4.5
With the attached sample code I get a substantial performance drop from 4.3.1 to either 4.4.1 or 4.5.0, same compiler option, same machine. To reproduce, feed a size to the program (in the case below, 4) and time the executable. [sfili...@donald fgp_fmm_20091112]$ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/gcc43 --with-mpfr=/u sr/local/mpfr --with-gmp=/usr/local/gmp Thread model: posix gcc version 4.3.1 (GCC) [sfili...@donald fgp_fmm_20091112]$ gfortran -O3 -o try_eval eval.f90 [sfili...@donald fgp_fmm_20091112]$ time ./try_eval
[Bug bootstrap/42096] lto.c:289:7: error: implicit declaration of function 'strtoll'
--- Comment #4 from espindola at gcc dot gnu dot org 2009-11-19 15:57 --- Closing this bug as bootstrap should now work. The gold plugin still needs some portability improvements. -- espindola at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42096
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #13 from wuerzner at gmail dot com 2009-11-19 15:47 --- If you have no speedup, do you recognize any loss of speed due to the parallelization overhead (for small examples)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #12 from rguenther at suse dot de 2009-11-19 15:36 --- Subject: Re: flag_gtoggle in free_lang_data hides -fcompare-debug errors On Thu, 19 Nov 2009, ebotcazou at gcc dot gnu dot org wrote: > --- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-19 15:11 > --- > > For not doing the boolean_type_node fixing we'd need to not pre-load the > > streamer chache with (selected) builtin type nodes but instead stream them > > with every unit and function and pass them through the merging machinery. > > Basically make lto_get_common_nodes return an empty vector (that likely > > requires us to register and fixup all builtin types in lto1 before starting > > to stream in stuff - I likely have some patches doing this somewhere). > > Can't boolean_type_node (and sizetypes) be special-cased somehow, since it > seems that the other builtin types aren't problematic? The problem is that they are used in other builtin types (well, maybe not, but that's a big problem with various pointer types). I will look into getting the lto1 fixups into trunk (ISTR they fix some corner-cases anyway), it should then be easy to experiment with excluding single builtin types from the cache pre-loading. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #12 from singler at gcc dot gnu dot org 2009-11-19 15:35 --- Remove old email address. -- singler at gcc dot gnu dot org changed: What|Removed |Added CC|singler at ira dot uka dot | |de | Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #11 from singler at gcc dot gnu dot org 2009-11-19 15:33 --- Created an attachment (id=19053) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19053&action=view) Functional patch for parallel fill and fill_n. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #10 from singler at gcc dot gnu dot org 2009-11-19 15:32 --- The new patch is functional. However, for simple cases like setting integers, I have no speedup (yet). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug c/42107] Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #4 from suren dot r at live dot in 2009-11-19 15:31 --- Created an attachment (id=19052) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19052&action=view) .o file created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug c/42107] Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 15:31 --- Compiling with -W -Wall, we get the following warnings: t.c: In function âmainâ: t.c:9: warning: format â%dâ expects type âint *â, but argument 2 has type âunsigned char *â t.c:11: warning: format â%dâ expects type âint *â, but argument 2 has type âunsigned char *â Those warnings show that this code is undefined, -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug c/42107] Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #2 from suren dot r at live dot in 2009-11-19 15:30 --- Created an attachment (id=19051) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19051&action=view) .i file generated -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug bootstrap/42096] lto.c:289:7: error: implicit declaration of function 'strtoll'
--- Comment #3 from espindola at gcc dot gnu dot org 2009-11-19 15:30 --- Subject: Bug 42096 Author: espindola Date: Thu Nov 19 15:30:04 2009 New Revision: 154330 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154330 Log: 2009-11-19 Rafael Avila de Espindola PR bootstrap/42096 * lto-plugin.c (claim_file_handler): Print offsets in hex. 2009-11-19 Rafael Avila de Espindola PR bootstrap/42096 * lto-elf.c (lto_elf_file_open): Use lto_parse_hex. * lto.c (lto_parse_hex): New. (lto_resolution_read): Use lto_parse_hex. * lto.h (lto_parse_hex): New. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-elf.c trunk/gcc/lto/lto.c trunk/gcc/lto/lto.h trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42096
[Bug c/42107] Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
--- Comment #1 from suren dot r at live dot in 2009-11-19 15:29 --- Created an attachment (id=19050) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19050&action=view) Source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug c/42107] New: Scaning unsigned char variable as integer using scanf results in that variable initialised to 0
Declare two variables as unsigned char. use scanf with %d to read two values and store in the variables when executing, the first variable have 0 instead of scanned number; the second variable have the scanned number; -- Summary: Scaning unsigned char variable as integer using scanf results in that variable initialised to 0 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: suren dot r at live dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-19 15:11 --- > For not doing the boolean_type_node fixing we'd need to not pre-load the > streamer chache with (selected) builtin type nodes but instead stream them > with every unit and function and pass them through the merging machinery. > Basically make lto_get_common_nodes return an empty vector (that likely > requires us to register and fixup all builtin types in lto1 before starting > to stream in stuff - I likely have some patches doing this somewhere). Can't boolean_type_node (and sizetypes) be special-cased somehow, since it seems that the other builtin types aren't problematic? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug lto/42088] flag_gtoggle in free_lang_data hides -fcompare-debug errors
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-19 14:40 --- Btw I can reproduce the bootstrap comparison fail with Ada when removing the bogus flag_gtoggle check. Fixing the problem with canonicalize_cond_expr_cond isn't the whole story appearantly - fixing it doesn't fix the miscompare. Still fixing it makes sense anyway, so I'm currently testing a patch. For not doing the boolean_type_node fixing we'd need to not pre-load the streamer chache with (selected) builtin type nodes but instead stream them with every unit and function and pass them through the merging machinery. Basically make lto_get_common_nodes return an empty vector (that likely requires us to register and fixup all builtin types in lto1 before starting to stream in stuff - I likely have some patches doing this somewhere). I know it's all sort-of a mess right now ... (still tracking down the specific Ada problem is intersting). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42088
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #21 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-19 14:39 --- forget comment #20. WLDRW wcgr0, [fp, #-1324] would be an invalid instruction. Offset is 10 bit only so that the RTL is invalid for the iwmmxt processor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #20 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:09 ---
This patch creates now
---
(insn 460 148 153 20 ../sysdeps/unix/sysv/linux/libc_fatal.c:106 (set (reg:SI
43 wcgr0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -1324 [0xfad4])) [10 %sfp+-1292 S4
A32])) 441 {*iwmmxt_movsi_insn} (nil))
../sysdeps/unix/sysv/linux/libc_fatal.c:172: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396
---
in glibc; which should emit the
WLDRW wcgr0, [fp, #-1324]
instruction (??). This instruction does not exist yet and I am not
sure about further annotations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #19 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-19 13:57 --- Created an attachment (id=19049) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19049&action=view) patch to fix reported ICE [not official, I really do not know whether this is the correct way] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug c++/42106] New: Simplistic build works, then fails to find cc1plus on its own
Simplistic build works, then fails to find cc1plus on its own when using g++ SunOS cairo 5.10 Generic_13-08 sun4u sparc SUNW,Sun-Fire-280R ~:cairo> ../gcc-4.3.4/configure --prefix=/cairo/tmp/jblaine \ --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld \ --disable-shared --without-gnu-ld --without-gnu-as ... ~:cairo> make bootstrap ... ~:cairo> make install ... ~:cairo> which g++ /cairo/tmp/jblaine/bin/g++ ~:cairo> ~:cairo> g++ --version g++ (GCC) 4.3.4 ... ~:cairo> g++ -shared foo.cpp gcc: error trying to exec 'cc1plus': execvp: No such file or directory ~:cairo> ~:cairo> find /cairo/tmp/jblaine -name cc1plus /cairo/tmp/jblaine/libexec/gcc/sparc-sun-solaris2.10/4.3.4/cc1plus ~:cairo> -- Summary: Simplistic build works, then fails to find cc1plus on its own Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jblaine at mitre dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42106
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #18 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-19 13:47 --- (define_insn "*iwmmxt_movsi_insn" - [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z,r,?z,Uy,z") + [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z ,rk,?z,Uy,z") -(match_operand:SI 1 "general_operand" "rk, I,K,mi,rk,r,z,Uy,z, +(match_operand:SI 1 "general_operand" "rk, I,K,mi,rk,rk,z ,Uy,z, will fix the reported ICE. But, a) you will get other ICEs which are more tricky to fix (other _insn need new alternatives with new assembly instructions) b) all the 'r' constraints in other _insn should be revised whether 'k' has to be added -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #5 from pault at gcc dot gnu dot org 2009-11-19 13:25 --- Martien, Thank you very much for this report. I have assigned it to myself and have a non-regtested fix: As remarked by Janus, the problem is with the array argument. The code produced for the proc_pointer call is parm.13.dtype = 281; parm.13.dim[0].lbound = 1; parm.13.dim[0].ubound = 2; parm.13.dim[0].stride = 1; parm.13.data = (void *) &A.12[0]; parm.13.offset = 0; D.1402 = _gfortran_internal_pack (&parm.13); D.1404 = funcp.p (&C.1396, D.1402); The internal_pack should not be there, since the assumed shape formal argument requires that a descriptor be passed. This, in its turn comes about because the symbol funcp is not marked as being always_explicit. (In fact, he and I had a mid-air collision on this!) The fix is to make use of the fact a proc_pointer component call is already detected and can be used to suppress the internal_pack. Thusly: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 153651) +++ gcc/fortran/trans-expr.c(working copy) @@ -2918,7 +2918,7 @@ f = (fsym != NULL) && !(fsym->attr.pointer || fsym->attr.allocatable) && fsym->as->type != AS_ASSUMED_SHAPE; - f = f || !sym->attr.always_explicit; + f = f || (!sym->attr.always_explicit && !comp); if (e->expr_type == EXPR_VARIABLE && is_subref_array (e)) This fixes the PR but has not been regtested. I will do this tonight. If all is well, I will commit as obvious, although your OK would be helpful, Janus! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Severity|major |normal Status|NEW |ASSIGNED Last reconfirmed|2009-11-19 10:45:21 |2009-11-19 13:25:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
--- Comment #17 from yipiha2008 at gmail dot com 2009-11-19 13:18 --- I tried removing the whole movsi section from the machine definition file (iwmmxt.md) but if I do that GCC refuses to compile. Reading the GCC internals documentation it appears that the movsi section is mandatory. Does anyone know which part of the movsi section of iwmmxt.md has a problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug bootstrap/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-19 12:31 --- > This is most likely due to one of Jan's recent commits. Right, r154121 changed gcc_assert ((!DECL_WEAK (vnode->decl) || DECL_COMMON (vnode->decl)) || TREE_PUBLIC (vnode->decl) || DECL_EXTERNAL (node->decl)); to gcc_assert ((!DECL_WEAK (vnode->decl) && !DECL_COMMON (vnode->decl) && !DECL_COMDAT (vnode->decl)) || TREE_PUBLIC (vnode->decl) || DECL_EXTERNAL (node->decl)); and r154128 didn't really fix the "accidental commit": gcc_assert ((!DECL_WEAK (vnode->decl) && !DECL_COMMON (vnode->decl)) || TREE_PUBLIC (vnode->decl) || DECL_EXTERNAL (vnode->decl)); Please, Jan, fix the breakage ASAP. -- ebotcazou 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-11-19 12:31:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42000] missing -Wuninitialized warning on a user-defined class ctor
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:28 --- I think this is a duplicate of either bug 2972 or bug 19808 or one of the SRA testcases. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org OtherBugsDependingO||24639 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42000
[Bug bootstrap/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Tru64 UNIX Ada bootstrap
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-11-19 12:26 --- Created an attachment (id=19048) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19048&action=view) Reduced testcase To be gnatchop-ed and cross-compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/39936] -Wuninitialized false positive with unhelpful diagnostic
--- Comment #3 from manu at gcc dot gnu dot org 2009-11-19 12:22 --- The best we can do is to add this testcase to GCC 4.5 and close this as FIXED in mainline. These kind of fixes are typically not easy to backport. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-19 12:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39936
[Bug middle-end/41817] bogus "may be uninitialized" (huge testcase, inlining?)
--- Comment #7 from manu at gcc dot gnu dot org 2009-11-19 12:19 --- This is still unconfirmed until someone looks at the dumps and check that the variables are indeed initialized in all paths that can be sensibly detected by GCC. BTW, when you release code, your compiler flags should not contain -Werror. If some package does, you should really report it upstream because taking into account all the amount of new warnings, and fixes to existing warnings that occur between consecutive GCC releases, that is madness for any user compiling your code. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org OtherBugsDependingO||24639 nThis|| Summary|elfutils fails with "may be |bogus "may be uninitialized" |uninitialized" with -O3 - |(huge testcase, inlining?) |mtune=k8| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41817
[Bug c/41441] failure to warn about uninitialized induction var
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:13 --- If the loop does nothing, the whole loop is removed before warning about anything. If you find a testcase where the loop does something useful, and there is still no warning, please open a new bug report. Thanks. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41441
[Bug middle-end/19430] V_MAY_DEF (taking address of var) causes missing uninitialized warning
--- Comment #17 from manu at gcc dot gnu dot org 2009-11-19 12:00 --- *** Bug 42079 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||m dot b dot lankhorst at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
[Bug c/42079] missing unitialized warning on simple testcase
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:00 --- Taking address of var causes missing may be uninitialized. *** This bug has been marked as a duplicate of 19430 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42079
[Bug fortran/42104] [F03] runtime segfault with procedure pointer component
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-19 11:57 ---
Let's have a look at the dump for the test case in comment #2.
The call to 'func' is translated to:
real(kind=4) D.1568;
struct array1_real(kind=4) parm.7;
static real(kind=4) A.6[2] = {1.0001490116119384765625e-1,
1.0001490116119384765625e-1};
static integer(kind=4) C.1562 = 3;
parm.7.dtype = 281;
parm.7.dim[0].lbound = 1;
parm.7.dim[0].ubound = 2;
parm.7.dim[0].stride = 1;
parm.7.data = (void *) &A.6[0];
parm.7.offset = 0;
D.1568 = func (&C.1562, &parm.7);
The PPC call to 'funcp%p' looks simlar, except for:
D.1576 = _gfortran_internal_pack (&parm.10);
D.1578 = funcp.p (&C.1570, D.1576);
(i.e. it has an additional _gfortran_internal_pack).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #9 from jakub at gcc dot gnu dot org 2009-11-19 11:54 --- The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED macro on __gthread_mutex_destroy argument. It is perfectly fine on __gthread_key_delete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
