[Bug translation/40872] String not extracted for translation
--- Comment #18 from pearly dot zhao at oracle dot com 2009-11-12 07:54
---
Run "make gcc.pot" in objdir/gcc/ can extract both branches of this conditional
expression. That is to say, the ("declared") line is also include at
objdir/gcc/gcc.pot.
Can this bug be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning
--- Comment #5 from irar at il dot ibm dot com 2009-11-12 07:51 --- (In reply to comment #4) > I didn't check yet. We'll work on a simple cost-model integration of > predcom. You mean, vectorizer cost model will take predcom into account? If the vectorization is not profitable (vs. scalar without predcom), it can be a matter of vectorizer cost model tuning (looks easier). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #10 from ubizjak at gmail dot com 2009-11-12 07:40 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||11/msg00562.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #9 from uros at gcc dot gnu dot org 2009-11-12 07:30 --- Subject: Bug 41930 Author: uros Date: Thu Nov 12 07:30:05 2009 New Revision: 154116 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154116 Log: PR middle-end/41930 * simplify-rtx.c (simplify_replace_fn_rtx) : Skip processing if XEXP (x, i) is NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug gcov-profile/42015] New: gcov reports incorrect branches executed
While trying to rerun the gcov example supplied in "man gcov" it was noticed
that the branch values reported are incorrect. The contents in tmp.c.gcov
appears to be correct.
gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
#include
int main (void)
{
int i, total;
total = 0;
for (i = 0; i < 10; i++)
total += i;
if (total != 45)
printf ("Failure\n");
else
printf ("Success\n");
return 0;
}
fro...@frodak-laptop:~/gcov$ gcov -b tmp.c
File 'tmp.c'
Lines executed:87.50% of 8
Branches executed:100.00% of 4
Taken at least once:75.00% of 4
Calls executed:50.00% of 2
tmp.c:creating 'tmp.c.gcov'
fro...@frodak-laptop:~/gcov$ cat tmp.c.gcov
-:0:Source:tmp.c
-:0:Graph:tmp.gcno
-:0:Data:tmp.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
function main called 1 returned 100% blocks executed 86%
1:3:int main (void)
-:4:{
-:5: int i, total;
-:6:
1:7: total = 0;
-:8:
11:9: for (i = 0; i < 10; i++)
branch 0 taken 91%
branch 1 taken 9% (fallthrough)
10: 10:total += i;
-: 11:
1: 12: if (total != 45)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
#: 13:printf ("Failure\n");
call0 never executed
-: 14: else
1: 15:printf ("Success\n");
call0 returned 100%
1: 16: return 0;
-: 17:}
-: 18:
--
Summary: gcov reports incorrect branches executed
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: frodak17 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42015
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-12 05:47 --- More hoops to jump through to prevent the magic decltype handling of calls exposed by constant folding... -- 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-12 05:47:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug other/42014] Inconsistant column number display for "In file incuded from"
--- Comment #2 from indy2718 at gmail dot com 2009-11-12 05:14 --- (In reply to comment #1) > >This affects any inflexible error parsing program. > > Considering flag_show_column controls the display of column info, it does not > say always display it, only when aviable. > Should be consistent though. Possibly remove the flag_show_column block or add another pp_verbatim LAST_SOURCE_COLUMN in the while loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014
[Bug c++/38712] can't mangle template-id g(t)
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-12 04:59 ---
This issue isn't limited to C++0x mode:
struct A
{
typedef int Type;
};
template
typename T::Type f ();
template
char (* g())[sizeof(f())];
int main()
{
g();
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[c++0x] can't mangle|can't mangle template-id
|template-id g(t) |g(t)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38712
[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-12 04:57 --- Actually, we have PR 38712 specifically about the template-id case, so let's go ahead and close this PR. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #19 from jason at gcc dot gnu dot org 2009-11-12 04:54 --- I was thinking that the ABI didn't distinguish between C and C++ function types, but I was wrong; it does specify a different mangling for extern "C" functions. The problem is that currently G++ only tracks language linkage for declarations, not types. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/3187] gcc lays down two copies of constructors
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug c++/39131] decimal float point: ICE on typeid( 0.dd )
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-12 04:49 --- The ICE was fixed a while back; the patch I just checked in makes uses of typeid(0.dd) link. -- 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=39131
[Bug other/42014] Inconsistant column number display for "In file incuded from"
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-12 04:47 --- >This affects any inflexible error parsing program. Considering flag_show_column controls the display of column info, it does not say always display it, only when aviable. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014
[Bug c++/39131] decimal float point: ICE on typeid( 0.dd )
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-12 04:44 --- Subject: Bug 39131 Author: jason Date: Thu Nov 12 04:44:24 2009 New Revision: 154113 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154113 Log: PR c++/39131 * rtti.c (emit_support_tinfos): Add DFP types. * config/abi/pre/gnu.ver: Add DFP types. * testsuite/util/testsuite_abi.cc (check_version): Add CXXABI_1.3.4. Added: trunk/gcc/testsuite/g++.dg/dfp/typeid1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/ChangeLog trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131
[Bug c++/42014] New: Inconsistant column number display for "In file incuded from"
In file included from a.h:3:0,
from c.cpp:2:
Notice there's a 0 on the first line, and no column number on the second line.
This affects any inflexible error parsing program.
In gcc/diagnostic.c line 245 there's a check for flag_show_column for the first
error line but no check for the rest.
{
map = INCLUDED_FROM (line_table, map);
if (flag_show_column)
pp_verbatim (context->printer,
"In file included from %s:%d:%d",
map->to_file,
LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
else
pp_verbatim (context->printer,
"In file included from %s:%d",
map->to_file, LAST_SOURCE_LINE (map));
while (! MAIN_FILE_P (map))
{
map = INCLUDED_FROM (line_table, map);
pp_verbatim (context->printer,
",\n from %s:%d",
map->to_file, LAST_SOURCE_LINE (map));
}
pp_verbatim (context->printer, ":");
pp_newline (context->printer);
}
--
Summary: Inconsistant column number display for "In file incuded
from"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: indy2718 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42014
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-12 04:16 --- Might be related to the old fixed bug 36628. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug c++/42013] cv-qualification of conditional expression type depending on the value of its first expression?!?
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-12 04:09
---
Actually, the observation about C++0x is largely incorrect, because the actual
specifications in DR 1255 are different, use std::add_rvalue_reference.
However, my main puzzlement stands.
Also, as regards the C++0x common_type (per DR 1255), I'm seeing the problem
with cv-qualified void, eg, replace in the snippet int -> void and const int ->
const void, because in that case std::add_rvalue_reference does nothing:
#include
template
struct __declval_protector
{
static typename std::add_rvalue_reference<_Tp>::type __delegate();
};
template
typename std::add_rvalue_reference<_Tp>::type
declval()
{
return __declval_protector<_Tp>::__delegate();
}
template
struct common_type
{
typedef __decltype(true ? declval<_Tp>() : declval<_Up>()) typet;
typedef __decltype(false ? declval<_Tp>() : declval<_Up>()) typef;
};
template struct is_same;
template struct is_same<_Tp, _Tp> { typedef _Tp type; };
void f()
{
typedef common_type::typet typet;
typedef common_type::typef typef;
typedef is_same::type type;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug c++/42013] New: cv-qualification of conditional expression type depending on the value of its first expression?!?
I'm seeing something strange while implementing C++0x declval. In a nutshell,
since I'm not reading anything in 5.16 (of C++03) saying that the type of a
conditional expression depends on the value of its first expression, I'm
surprised that this is the case with GCC, as far as cv-qualification is
concerned.
By the way, if actually this is conforming behavior, then the current C++0x
specifications for the two arguments common_type become really weird (see
20.6.7/3 in N2960): the cv-qualification of the common_type ends up depending
on the order of the types. Cannot be right, IMHO.
For example, the below doesn't compile:
template
struct __declval_protector
{
static _Tp __delegate();
};
template
_Tp
declval()
{
return __declval_protector<_Tp>::__delegate();
}
template
struct common_type
{
typedef __decltype(true ? declval<_Tp>() : declval<_Up>()) typet;
typedef __decltype(false ? declval<_Tp>() : declval<_Up>()) typef;
};
template struct is_same;
template struct is_same<_Tp, _Tp> { typedef _Tp type; };
void f()
{
typedef common_type::typet typet;
typedef common_type::typef typef;
typedef is_same::type type;
}
--
Summary: cv-qualification of conditional expression type
depending on the value of its first expression?!?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paolo dot carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42013
[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
--- Comment #3 from joseph at codesourcery dot com 2009-11-12 03:01 --- Subject: Re: Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target Note that there are more than just e500 processors with the SPE functionality; for example, at least some e200 processors also support SPE with single-precision floating point only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
--- Comment #2 from oakad at yahoo dot com 2009-11-12 02:51 --- I understand that changing a triplet behavior is not a good idea. However, it seems quite unfortunate, that important, performance affecting feature depends on obscure gcc configuration flag in situation where most existing and all future chips of this type provide the necessary functionality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-11-12 02:43 --- Unfortunately, the proposed patch doesn't solve the crashes in gcj on intel darwin. I would note that if I use javac to convert testme.java into testme.class that... gcj --main=testme -O testme.class compiles fine on x86_64-apple-darwin10. This is likely why the problem went unnoticed for so long as the libjava testsuite appears to test gcj via the class files in the associated jar files rather than with the java files themselves (if ejc1 is present). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug middle-end/41440] SEG FAULT in CSE.C caused by bad RTL expansion
--- Comment #10 from hutchinsonandy at gcc dot gnu dot org 2009-11-12 02:36 --- Subject: Bug 41440 Author: hutchinsonandy Date: Thu Nov 12 02:35:49 2009 New Revision: 154112 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154112 Log: PR middle-end/41440 * cfgexpand.c (expand_gimple_basic_block): Append NOP to a fallthru, single successor block, ending with jump created by RTL expander. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41440
[Bug middle-end/41729] Undefined reference with -fPIC -fwhole-program -flto
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-11-11 23:45 --- Subject: Bug 41729 Author: hubicka Date: Wed Nov 11 23:45:09 2009 New Revision: 154108 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154108 Log: PR middle-end/41729 * ipa.c (function_and_variable_visibility): Do not privatize COMDAT and WEAK variables at -fwhole-program. PR middle-end/41735 * ipa.c (whole_program_function_and_variable_visility): COMDAT functions/variables are not needed even if they are externally visible. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41729
[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-11 23:45 --- Subject: Bug 41735 Author: hubicka Date: Wed Nov 11 23:45:09 2009 New Revision: 154108 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154108 Log: PR middle-end/41729 * ipa.c (function_and_variable_visibility): Do not privatize COMDAT and WEAK variables at -fwhole-program. PR middle-end/41735 * ipa.c (whole_program_function_and_variable_visility): COMDAT functions/variables are not needed even if they are externally visible. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735
[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use
--- Comment #22 from paolo dot carlini at oracle dot com 2009-11-11 23:40 --- *** Bug 42012 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||aleppos at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343
[Bug c/42012] server not respond
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-11 23:40 --- Thanks Joseph. Thus, let's close this one as duplicate, please re-open if the problem can be reproduced also with current mainline. Thanks. *** This bug has been marked as a duplicate of 41343 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012
[Bug c/42012] server not respond
--- Comment #2 from joseph at codesourcery dot com 2009-11-11 23:35 --- Subject: Re: server not respond This is probably a duplicate of bug 41343 (it's reported against a trunk version more than a month old). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012
[Bug c/42012] server not respond
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-11 23:27 --- Indeed, please provide the error message, at least, plus all the required bug information per: http://gcc.gnu.org/bugs/ -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012
[Bug target/40983] The scheduler incorrectly swaps MMX and floating point instructions
--- Comment #6 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-11-11 23:06 --- I think you can commit it to gcc. I don't see a reason why it shouldn't be committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
[Bug java/41991] gcj segfaults on i686-apple-darwin* and x86_64-apple-darwin*
--- Comment #3 from andreast at gcc dot gnu dot org 2009-11-11 22:40 --- Does this help: [deuterium:head/gcc/libjava] andreast% svn diff Makefile.am Makefile.in Index: Makefile.am === --- Makefile.am (revision 154097) +++ Makefile.am (working copy) @@ -1085,7 +1085,7 @@ if NATIVE -ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) +ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) $(extra_gij_ldflags) if ENABLE_SHARED ## Use ecj.jar at runtime. Index: Makefile.in === --- Makefile.in (revision 154097) +++ Makefile.in (working copy) @@ -8511,7 +8511,7 @@ --main=org.eclipse.jdt.internal.compiler.batch.GCCMain @native_fa...@ecjx_link = $(GCJ_FOR_ECJX_LINK) $(ecjx_LDFLAGS) -...@native_true@ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) +...@native_true@ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS) $(extra_gij_ldflags) @ENABLE_SHARED_FALSE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH) @ENABLE_SHARED_TRUE@@native_t...@ecjx_ldflags = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR) @native_fa...@ecjx_ldflags = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-11 22:40:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-11 22:38 --- Fixed with r154107. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978
[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-11 22:37 --- Subject: Bug 41978 Author: janus Date: Wed Nov 11 22:37:31 2009 New Revision: 154107 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154107 Log: 2009-11-11 Janus Weil PR fortran/41978 * resolve.c (resolve_ref): Take care of procedure pointer component references. 2009-11-11 Janus Weil PR fortran/41978 * gfortran.dg/proc_ptr_comp_22.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_22.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978
[Bug tree-optimization/41735] [4.5 Regression] inlined comdat function sometimes is emitted
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-11-11 22:23 --- Testing patch. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-24 11:59:05 |2009-11-11 22:23:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41735
[Bug middle-end/41729] Undefined reference with -fPIC -fwhole-program -flto
--- Comment #1 from hubicka at gcc dot gnu dot org 2009-11-11 22:15 --- This seems to be some issue with EH producing type infos too early. LDFCM0 appears there is action record: .LLSDACSE1: .byte 0x1 # Action record table .byte 0x0 .align 4 .long .LDFCM0-. and later here: .type .LDFCM0.2083, @object .size .LDFCM0.2083, 8 .LDFCM0.2083: .quad _ZTIP10cException .hidden DW.ref.__gxx_personality_v0 .weak DW.ref.__gxx_personality_v0 .section .data.DW.ref.__gxx_personality_v0,"awG",@progbits,DW.ref.__gxx_personality_v0,comdat .align 8 .type DW.ref.__gxx_personality_v0, @object .size DW.ref.__gxx_personality_v0, 8 it is however gets this -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-11 22:15:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41729
[Bug c/42012] New: server not respond
i build glibc ../glibc/configure --prefix=/usr --enable-shared --disable-profile --enable- add-ons --with-tls --with-__thread --enable-kernel=2.6.18 -- libexecdir=/usr/lib/glibc --build=x86_64-redhat-linux make gcc (GCC) 4.5.0 20091003 (experimental) it's work but stop in this lines - gcc ../sysdeps/ieee754/dbl-64/dosincos.c -c -std=gnu99 -fgnu89-inline -O2 - Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-unwind-tables -g - Wstrict-prototypes -Wno-uninitialized -D__NO_MATH_INLINES - D__LIBC_INTERNAL_MATH_INLINES -I../include - I/root/aleppos/libraries/glibc_build/math - I/root/aleppos/libraries/glibc_build -I../sysdeps/x86_64/elf - I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 - I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux - I../nptl/sysdeps/pthread -I../sysdeps/pthread - I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux - I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman - I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv - I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 - I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix - I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../nptl/sysdeps/x86_64 - I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 - I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 - I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. - I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h - DNOT_IN_libc=1 -DIS_IN_libm=1- o /root/aleppos/libraries/glibc_build/math/dosincos.o -MD -MP - MF /root/aleppos/libraries/glibc_build/math/dosincos.o.dt - MT /root/aleppos/libraries/glibc_build/math/dosincos.o -- http://sourceware.org/bugzilla/show_bug.cgi?id=10941 -- If you are using experimental gcc, it can be gcc bug. But you didn't even report the actual error message... -- Summary: server not respond Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aleppos at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42012
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-11-11 21:59 ---
All 4.x sh compilers fail with similar way. Looks only when unoptimized.
Does the patch below work for you?
--- ORIG/trunk/gcc/mode-switching.c 2009-02-21 09:26:24.0 +0900
+++ trunk/gcc/mode-switching.c 2009-11-11 11:03:04.0 +0900
@@ -325,7 +325,14 @@ create_pre_exit (int n_entities, int *en
else
break;
if (copy_start >= FIRST_PSEUDO_REGISTER)
- break;
+ {
+ if (!optimize)
+ {
+ last_insn = return_copy;
+ continue;
+ }
+ break;
+ }
copy_num
= hard_regno_nregs[copy_start][GET_MODE (copy_reg)];
BTW, I guess that __builtin_apply/__builtin_return may be a bit obsolete.
If my memory is correct, there was an argument on the list for dropping
them from the compiler.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.0.4 4.1.3 4.2.4 4.3.4
||4.4.2 4.5.0
Known to work||3.4.6
Priority|P3 |P4
Last reconfirmed|-00-00 00:00:00 |2009-11-11 21:59:45
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment
--- Comment #3 from domob at gcc dot gnu dot org 2009-11-11 21:08 --- I've not checked the standard about this, but seems fine to me. I also give you an ok for that patch (maybe with a test-case) if you want to submit/commit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978
[Bug middle-end/41992] ICE on invalid dereferencing of void *
--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-11-11 21:06 ---
You can dereference void * in asm arguments --- i.e.
void *p; ... asm volatile ("prefetch %0"::"m"(*p));
gcc warns in this case about the dereference and maybe it shouldn't (but it's
trivial to supress the warning with a cast to char *).
If you change "m" constraint to "mr", you get an ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992
[Bug fortran/41978] [F03] ICE in gfc_conv_expr_descriptor for array PPC assignment
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-11 21:02 ---
(In reply to comment #1)
> I'm not 100% sure, but I think this also applies to PPCs.
If this is correct, then the fix for this PR is as simple as
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 153965)
+++ gcc/fortran/resolve.c (working copy)
@@ -4272,7 +4272,8 @@ resolve_ref (gfc_expr *expr)
case REF_COMPONENT:
if (current_part_dimension || seen_part_dimension)
{
- if (ref->u.c.component->attr.pointer)
+ if (ref->u.c.component->attr.pointer
+ || ref->u.c.component->attr.proc_pointer)
{
gfc_error ("Component to the right of a part reference "
"with nonzero rank must not have the POINTER "
Daniel, what do you think?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-11 21:02:50
date||
Summary|ICE in |[F03] ICE in
|gfc_conv_expr_descriptor for|gfc_conv_expr_descriptor for
|array PPC assignment|array PPC assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978
[Bug fortran/41978] ICE in gfc_conv_expr_descriptor for array PPC assignment
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-11 20:38 --- Replacing the PPC assignment by a plain pointer component assignment IMPLICIT NONE TYPE t integer, pointer :: p END TYPE t integer :: i TYPE(t) :: arr(2) arr%p => i END is being rejected with: arr%p => i 1 Error: Component to the right of a part reference with nonzero rank must not have the POINTER attribute at (1) This is C614 in the F03 standard: C614 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. I'm not 100% sure, but I think this also applies to PPCs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41978
[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-11 20:38 --- I didn't check yet. We'll work on a simple cost-model integration of predcom. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-11 20:37 --- Fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug c++/42011] New: linker error with typedef struct
Hello,
I'd like to point your attention to a weird linker error I see on my system
on gcc version 4.3.3, 4.4.1 and 4.4.2.
I could not find anything related to this in bugzilla using the keyword
typedef.
Here are three files I use to produce the error:
/*
* bug.cpp
*
* Created on: 07.11.2009
* Author: Wolf Lammen
*/
#include "A.h"
int main()
{
A::B().foo();
return 0;
}
===
/*
* A.h
*
* Created on: 07.11.2009
* Author: Wolf Lammen
*/
/*
* this compiles and links fine, if I
* a) inline foo i.e use "void foo(){}" and remove foo() from A.cpp
* b) avoid the keyword typedef and use "struct B { void foo(); };" instead
*/
struct A {
typedef struct {
void foo();
} B;
};
===
/*
* A.cpp
*
* Created on: 07.11.2009
* Author: Wolf Lammen
*/
#include "A.h"
void A::B::foo() {}
===
Here's the output I get with g++, latest version
(similar for 4.3.3 or 4.4.1)
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ --version
Copyright (C) 2009 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
w...@kubuntu-910:~/bug$ cat A.h
/*
* A.h
*
* Created on: 07.11.2009
* Author: Wolf Lammen
*/
/*
* this compiles fine, if I
* a) inline foo i.e use void foo(){} and remove foo() from A.cpp
* b) avoid the keyword typedef and use struct B { void foo(); }; instead
*/
struct A {
typedef struct {
void foo();
} B;
};
w...@kubuntu-910:~/bug$ ~/bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"A.d" -MT"A.d" -o"A.o" "A.cpp"
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"bug.d" -MT"bug.d" -o"bug.o" "bug.cpp"
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ -o"test" ./A.o ./bug.o
./bug.o: In function `main':
/home/wolf/bug/bug.cpp:12: undefined reference to `A::B::foo()'
collect2: ld gab 1 als Ende-Status zurück
There is a simple work-around:
use
struct B{
void foo();
};
instead of the typedef struct {...} in file A.h, and everything compiles
and links fine (see below):
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ --version
g++ (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
w...@kubuntu-910:~/bug$ ~/bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"A.d" -MT"A.d" -o"A.o" "A.cpp"
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ -O0 -g3 -Wall -c
-fmessage-length=0 -MMD -MP -MF"bug.d" -MT"bug.d" -o"bug.o" "bug.cpp"
w...@kubuntu-910:~/bug$ ../bin/gcc-4.4.2/bin/g++ -o"test" ./A.o ./bug.o
w...@kubuntu-910:~/bug$ cat A.h
/*
* A.h
*
* Created on: 07.11.2009
* Author: Wolf Lammen
*/
/*
* this compiles fine, if I
* a) inline foo i.e use void foo(){} and remove foo() from A.cpp
* b) avoid the keyword typedef and use struct B { void foo(); }; instead
*/
struct A {
struct B{
void foo();
};
};
Although there is a simple work-around (with slightly different semantics), the
example is AFAIK correct C++ code, that shouldn't rise any problems.
cheers
Wolf Lammen
--
Summary: linker error with typedef struct
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ookami1 at gmx dot de
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=42011
[Bug middle-end/42004] [4.5 regression] Revision 154079 failed g++.dg/torture/stackalign/unwind-2.C
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42004
[Bug c/42006] [4.5 Regression] Termination problem with -O2 and -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-11 20:35 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2009-11-11 20:35:30 date|| Summary|Termination problem with -O2|[4.5 Regression] Termination |and -O3 |problem with -O2 and -O3 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42006
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #9 from hjl at gcc dot gnu dot org 2009-11-11 20:34 --- Subject: Bug 42001 Author: hjl Date: Wed Nov 11 20:34:13 2009 New Revision: 154104 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154104 Log: 2009-11-11 H.J. Lu PR testsuite/42001 * gcc.dg/lto/lto.exp: Pass no-mathlib to lto_init. Call lto_finish at the end. * lib/lto.exp (lto_init): Set mathlib to " " for no-mathlib. (lto_finish): New. Restore mathlib. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/lto.exp trunk/gcc/testsuite/lib/lto.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug c++/37352] thunks for virtual function should work on lto
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-11 20:32 --- There's a simple workaround for most cases, condition asm-thunks on !flag_write_lto. We'll do this if a proper implementation doesn't come up for 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #8 from hjl dot tools at gmail dot com 2009-11-11 20:06 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00566.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||11/msg00566.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug c++/42010] New: ICE: lang_* check: failed in discriminator_for_local_entity, at cp/mangle.c:1581
Following code crashes in gcc trunk revisions r154095 and r154098. r153685
compiles fine.
Command line switches:
g++ -std=c++0x
or
g++ -std=gnu++0x
-- testcase.cpp --
struct A {
void f()
{
static struct {
} s;
}
};
--
$ /mnt/svn/gcc-trunk/binary-154095-lto/bin/g++ -v -std=gnu++0x -c -o tmp.o
testcase.cpp
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-154095-lto/bin/g++
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-154095-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=lto,c,c++
--prefix=/mnt/svn/gcc-trunk/binary-154095-lto/
Thread model: posix
gcc version 4.5.0 2009 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=gnu++0x' '-c' '-o' 'tmp.o' '-shared-libgcc'
'-mtune=generic'
/mnt/svn/gcc-trunk/binary-154095-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-fpreprocessed testcase-x.i -quiet -dumpbase testcase-x.i -mtune=generic
-auxbase-strip tmp.o -std=gnu++0x -version -o /tmp/ccQx8uCh.s
GNU C++ (GCC) version 4.5.0 2009 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 2009 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.5.0 2009 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 2009 (experimental), GMP version
4.3.1, MPFR version 2.4.1-p5, MPC version 0.7
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ea1de8eb0212138b74b7539fd1683110
testcase-x.i: In member function ‘void A::f()’:
testcase-x.i:5:7: internal compiler error: lang_* check: failed in
discriminator_for_local_entity, at cp/mangle.c:1581
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE: lang_* check: failed in
discriminator_for_local_entity, at cp/mangle.c:1581
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42010
[Bug lto/42009] LTO unable to link in presence of multiple inheritance
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-11 18:28 --- This is a dup of bug 37352 which is about thunks not working. *** This bug has been marked as a duplicate of 37352 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009
[Bug c++/37352] thunks for virtual function should work on lto
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-11-11 18:28 --- *** Bug 42009 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352
[Bug lto/42009] LTO unable to link in presence of multiple inheritance
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-11 18:27 --- Yes this is a known issue, thunks are not implemented. I thought there was a bug about this already too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009
[Bug lto/42009] LTO unable to link in presence of multiple inheritance
--- Comment #2 from wouter dot vermaelen at scarlet dot be 2009-11-11
18:26 ---
I (independently) found the same issue today.
I managed to reduce it to the following testcase:
> cat foo.cc
struct Base1 { virtual ~Base1(); };
struct Base2 { virtual ~Base2(); };
struct Foo : Base1, Base2 { virtual ~Foo(); };
Base1::~Base1() {}
Base2::~Base2() {}
Foo::~Foo() {}
int main() { return 0; }
> g++ foo.cc
[works fine]
> g++ -flto foo.cc
/usr/bin/ld: /tmp/ccNr43fh.lto.o: in function
_ZTV3Foo:ccuOnB3i.o(.gnu.linkonce.r._ZTV3Foo+0x30): error: undefined reference
to '_ZThn8_N3FooD1Ev'
/usr/bin/ld: /tmp/ccNr43fh.lto.o: in function
_ZTV3Foo:ccuOnB3i.o(.gnu.linkonce.r._ZTV3Foo+0x38): error: undefined reference
to '_ZThn8_N3FooD0Ev'
collect2: ld returned 1 exit status
--
wouter dot vermaelen at scarlet dot be changed:
What|Removed |Added
CC||wouter dot vermaelen at
||scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009
[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-11-11 15:36 --- Changing the meaning of an existing target triplet is a bad idea. Use --enable-e500-double when configuring GCC if you want -mfloat-gprs=double by default. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
[Bug testsuite/41913] ERROR: tcl error sourcing gcc.dg/lto/lto.exp
--- Comment #5 from hjl dot tools at gmail dot com 2009-11-11 15:33 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00541.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||11/msg00541.html Summary|ERROR: tcl error sourcing |ERROR: tcl error sourcing |/home/dave/gnu/gcc- |gcc.dg/lto/lto.exp |4.5/gcc/gcc/testsuite/gcc.dg| |/lto/lt | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41913
[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)
--- Comment #11 from jamborm at gcc dot gnu dot org 2009-11-11 15:10 --- Basile, can you please confirm that this is now fixed? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932
[Bug testsuite/42001] LTO tests fail with non multilib targets (but still not --disable-multilib )
--- Comment #7 from hjl dot tools at gmail dot com 2009-11-11 15:08 --- (In reply to comment #5) > well most targets are multilibbed now so I never saw it. I think you should > just remove -lm then . > -lm is added to most, if not, tests. How do you remove it? Shouldn't we have both -r and -shared options? We use -r for those targets which don't support shared libraries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42001
[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)
--- Comment #10 from jamborm at gcc dot gnu dot org 2009-11-11 15:07 --- Subject: Bug 41932 Author: jamborm Date: Wed Nov 11 15:07:18 2009 New Revision: 154095 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154095 Log: 2009-11-11 Martin Jambor PR lto/41932 * ipa-prop.c (ipa_update_after_lto_read): Call ipa_check_create_node_params and ipa_check_create_edge_args. Also call ipa_initialize_node_params instead of ipa_populate_param_decls. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932
[Bug lto/42009] LTO unable to link in presence of multiple inheritance
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-11 14:40 --- Created an attachment (id=19004) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19004&action=view) Testcase This is the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009
[Bug lto/42009] New: LTO unable to link in presence of multiple inheritance
The C++ testcase that I am about to attach compiles and links well without LTO at all optimizations levels. Unfortunately, whenever I try to compile it with LTO (at any optimization level including zero), I get the following link error: mjam...@host:~/gcc/fail$ ~/gcc/inst/trunk/bin/g++ -flto testcase.cpp /tmp/ccxMi1Vq.lto.o:(.rodata._ZTV1B[_ZTV1B]+0x18): undefined reference to `_ZThn16_N1B3fooEi' collect2: ld returned 1 exit status When I remove the first ancestor of class B from the list of ancestors, the testcase links and works fine. I get a very similar error on x86_64 too. On both machines the used compiler is pristine trunk revision 154038. -- Summary: LTO unable to link in presence of multiple inheritance Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jamborm at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42009
[Bug bootstrap/42002] Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-11 14:20 --- Not sure where you searched, http://download.fedora.redhat.com/pub/fedora/linux/updates/11/ppc/ certainly contains both elfutils-libelf-devel-0.142-1.fc11.ppc.rpm elfutils-libelf-devel-0.142-1.fc11.ppc64.rpm and similarly Everything tree. And F12 also supports ppc64. This is all distro specific and doesn't belong here though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42002
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #10 from redi at gcc dot gnu dot org 2009-11-11 14:05 --- Sorry for the lack of progress, I'll take another crack at it this week and report back on what I've got and what doesn't work. If I can't finish it I'll say so and unassign myself from this PR -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug bootstrap/42002] Bootstrap failure: ld doesn't find 64-bit libelf on Fedora 11
--- Comment #2 from lucier at math dot purdue dot edu 2009-11-11 13:52 --- Thanks a lot for the explanation! I'm looking through the list of packages on Fedora with elfutils in the title; there is no elfutils-libelf-devel.ppc64, but the only ppc64 packages I can find are elfutils-devel-0.142-1.fc11 (ppc64) with file list /usr/include/dwarf.h /usr/include/elfutils /usr/include/elfutils/elf-knowledge.h /usr/include/elfutils/libasm.h /usr/include/elfutils/libdw.h /usr/include/elfutils/libdwfl.h /usr/include/elfutils/libebl.h /usr/include/elfutils/version.h /usr/lib64/libasm.so /usr/lib64/libdw.so /usr/lib64/libebl.a and elfutils-libelf-0.142-1.fc11 (ppc64) with file list /usr/lib64/libelf-0.142.so /usr/lib64/libelf.so.1 So I put in the link from libelf.so to libelf.so.1 by hand and the bootstrap is proceeding. Should I file a bug report with Fedora? I was told Fedora 12 won't support ppc64, so maybe there's no point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42002
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-11 13:19 --- Jon, do you have any updated plans about this and related issues? I think it would be nice if we could make progress on the C++0x for 4.5.0... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #1 from burnus at gcc dot gnu dot org 2009-11-11 12:54 --- Misread the program one. I think it is also valid. The constraint which is wrongly applied is: "C1268 A local variable declared in the specification-part or internal-subprogram-part of a pure subprogram shall not have the SAVE attribute." I could not find any (other) relevant constraint in "12.6 Pure procedures". -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug c++/42000] missing -Wuninitialized warning on a user-defined class ctor
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-11 11:50 --- It would certainly be nice to get warnings about members that are not initialized in the constructor, I don't think GCC currently does that anywhere. If you add -O then you will get a warning for the use of the member. It's unfortunate that this warning is missed without optimisation, but -Wuninitialized no longer warns if you use it without -O -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42000
[Bug fortran/42008] New: Wrongly rejected derived types with default initializers in PURE procedures
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/141265154c2fcc71 Reinhold Bader thinks that at least the second program, using default initializers, is valid. Oddly, the program works with the TYPE is not defined locally but use-associated. The first program of M. Restelli is presumably wrong as it uses variables which are implicitly declared as SAVE. - But one should re-check. ifort v11.1, NAG f95 v5.1, pathscale 3.3b all accept all programs, g95 and gfortran reject "one" and "two (B)". !-- Program one -- module mod_xyz implicit none contains pure subroutine psub() type ilist type(ilist), pointer :: next => null() integer :: i end type ilist end subroutine psub end module mod_xyz !-- !-- Program two (A) -- module mod_xyz implicit none type ilist type(ilist), pointer :: next => null() integer :: i end type ilist contains pure subroutine psub() type(ilist) :: var ! ACCEPTED end subroutine psub end module mod_xyz !-- Program two (B) -- module mod_xyz2 implicit none contains pure subroutine psub() type ilist type(ilist), pointer :: next => null() integer :: i end type ilist type(ilist) :: var ! REJECTED end subroutine psub end module mod_xyz2 !- -- Summary: Wrongly rejected derived types with default initializers in PURE procedures 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=42008
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #8 from ubizjak at gmail dot com 2009-11-11 11:10 --- Testing patch (it bootstraps OK on alpha-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #7 from ubizjak at gmail dot com 2009-11-11 10:37 ---
We recurse with:
simplify_replace_fn_rtx called, x =
(expr_list:REG_DEP_TRUE (symbol_ref:DI ("_OtsGeqX") [flags 0x41])
(expr_list:REG_DEP_TRUE (mem:TF (reg/f:DI 75 [ array_3(D)->data ]) [3 S16
A128])
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil
simplify_replace_fn_rtx called, x =
(symbol_ref:DI ("_OtsGeqX") [flags 0x41])
simplify_replace_fn_rtx called, x =
(expr_list:REG_DEP_TRUE (mem:TF (reg/f:DI 75 [ array_3(D)->data ]) [3 S16
A128])
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil)))
simplify_replace_fn_rtx called, x =
(mem:TF (reg/f:DI 75 [ array_3(D)->data ]) [3 S16 A128])
simplify_replace_fn_rtx called, x =
(reg/f:DI 75 [ array_3(D)->data ])
simplify_replace_fn_rtx called, x =
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil))
simplify_replace_fn_rtx called, x =
(reg:TF 76)
gcc dies in "case 'e':", recursing with (nil) from:
(expr_list:REG_DEP_TRUE (reg:TF 76)
(nil))
The fix is then trivial, like [no whitespace diff]:
--cut here--
Index: simplify-rtx.c
===
--- simplify-rtx.c (revision 154088)
+++ simplify-rtx.c (working copy)
@@ -489,6 +489,8 @@ simplify_replace_fn_rtx (rtx x, const_rt
break;
case 'e':
+ if (XEXP (x, i))
+ {
op = simplify_replace_fn_rtx (XEXP (x, i), old_rtx, fn, data);
if (op != XEXP (x, i))
{
@@ -496,6 +498,7 @@ simplify_replace_fn_rtx (rtx x, const_rt
newx = shallow_copy_rtx (x);
XEXP (newx, i) = op;
}
+ }
break;
}
return newx;
--cut here--
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2009-11-11 10:01:06 |2009-11-11 10:37:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
--- Comment #6 from ubizjak at gmail dot com 2009-11-11 10:01 --- (In reply to comment #3) > Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c > > > I'll build a cross compiler from i386-pc-solaris2.10 and see if I can > > reproduce the problem there. > > Unfortunately, the problem does not reproduce in such a cross compiler, > so I'll have to either start a native reghunt or find a way to debug the > native compiler (maybe compiling with -g without -O2 or try the stage1 > compiler if it is also affected). Add --with-long-double-128 to your configure flags and it will also trigger with a cross compiler. Confirmed with a cross from x86_64-pc-linux-gnu. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-11 10:01:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug fortran/41631] [OOP] Support CLASS IS () in SELECT TYPE
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-11 09:41 --- Fixed on the fortran-dev branch as of r154089. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-11 09:41:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41631
[Bug middle-end/42004] [4.5 regression] Revision 154079 failed g++.dg/torture/stackalign/unwind-2.C
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-11-11 08:25 --- > On Linux/ia32, revision 154079: > > http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00300.html > > caused: > > FAIL: g++.dg/torture/stackalign/unwind-2.C -O1 execution test > FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 execution test > FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -flto execution test > FAIL: g++.dg/torture/stackalign/unwind-2.C -O2 -fwhopr execution test On i686 only, i[345]86 are OK. Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-11 08:25:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42004
