[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #3 from gcc at coreland dot ath dot cx 2009-11-23 08:15 --- Using built-in specs. Target: x86_64-portbld-freebsd7.2 Configured with: ./..//gcc-4.4.0/configure --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=44 --bindir=/usr/local/bin/gcc44 --libdir=/usr/local/lib/gcc-4.4.0 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc44 --build=x86_64-portbld-freebsd7.2 Thread model: posix gcc version 4.4.0 (GCC) FreeBSD viper.internal.network 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 2 08:22:32 UTC 2009 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #4 from gcc at coreland dot ath dot cx 2009-11-23 08:16 --- Using built-in specs. COLLECT_GCC=/gnat/svn/builds/r154285/bin/gcc-r154285 COLLECT_LTO_WRAPPER=/gnat/svn/builds/r154285/libexec/gcc/x86_64-unknown-freebsd7.2/4.5.0/lto-wrapper Target: x86_64-unknown-freebsd7.2 Configured with: /gnat/svn/src/configure --enable-languages=c,c++,ada,fortran --prefix=/gnat/svn/builds/r154285 --with-system-zlib --disable-nls --program-suffix=-r154285 --enable-libstdcxx-debug Thread model: posix gcc version 4.5.0 20091118 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #5 from charlet at gcc dot gnu dot org 2009-11-23 08:21 --- Sorry, but we still need a self contained set of sources attached in bugzilla (with only the needed sources to reproduce the bug), and a single, stand alone gcc command line with no extra shell scripts. See http://gcc.gnu.org/bugs/ for more details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug fortran/42053] [OOP] SELECT TYPE: reject duplicate CLASS IS blocks
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-23 08:47 --- Subject: Bug 42053 Author: janus Date: Mon Nov 23 08:47:14 2009 New Revision: 154432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154432 Log: 2009-11-23 Janus Weil ja...@gcc.gnu.org PR fortran/42053 * resolve.c (resolve_select_type): Check for duplicate CLASS IS blocks. 2009-11-23 Janus Weil ja...@gcc.gnu.org PR fortran/42053 * gfortran.dg/select_type_9.f03: New. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/select_type_9.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev branches/fortran-dev/gcc/fortran/resolve.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42053
[Bug fortran/42053] [OOP] SELECT TYPE: reject duplicate CLASS IS blocks
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-23 08:49 --- Fixed with r154432. 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=42053
[Bug target/40835] redundant comparison instruction
--- Comment #9 from carrot at google dot com 2009-11-23 08:51 --- Fixed by Richard. Close it. -- carrot at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #18 from irar at il dot ibm dot com 2009-11-23 09:02 --- I tried to vectorize eval.f90 with 4.3 and mainline on x86_64-suse-linux. In both cases no loop gets vectorized in subroutine eval. The k loop is not vectorizable because the step of x is unknown (function argument), and scalar evolution analysis fails to analyze it. The j loop is not vectorized first of all because of the k loop unknown loop bound (this is on our todo list). Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #2 from laurent at guerby dot net 2009-11-23 09:06 --- hpux11 mixes its own s-osinte spec with the posix body hence the issue: ifeq ($(strip $(filter-out hppa% hp hpux11%,$(targ))),) s-osinte.adbs-osinte-posix.adb \ s-osinte.adss-osinte-hpux.ads \ I missed this one sorry about that, patch coming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #3 from laurent at guerby dot net 2009-11-23 09:06 --- Created an attachment (id=19089) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19089action=view) Patch for hpux11 Dave, could try this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #6 from gcc at coreland dot ath dot cx 2009-11-23 10:16 --- Created an attachment (id=19090) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19090action=view) source file that generates the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #7 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19091) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19091action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #8 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19092) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19092action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #9 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19093) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19093action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #10 from gcc at coreland dot ath dot cx 2009-11-23 10:17 --- Created an attachment (id=19094) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19094action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #11 from gcc at coreland dot ath dot cx 2009-11-23 10:18 --- Created an attachment (id=19095) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19095action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #12 from gcc at coreland dot ath dot cx 2009-11-23 10:18 --- Created an attachment (id=19096) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19096action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #13 from gcc at coreland dot ath dot cx 2009-11-23 10:18 --- Created an attachment (id=19097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19097action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #14 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19098) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19098action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #15 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19099) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19099action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #16 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19100action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #17 from gcc at coreland dot ath dot cx 2009-11-23 10:19 --- Created an attachment (id=19101) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19101action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #18 from gcc at coreland dot ath dot cx 2009-11-23 10:20 --- Created an attachment (id=19102) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19102action=view) dependency for arc_dir_003.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #19 from gcc at coreland dot ath dot cx 2009-11-23 10:22 --- Really fail to see how this is more convenient or useful for anyone involved but oh well, what do I know? gcc-4.4.0: gcc -c pfseudo.ads pfseudo-path.adb pfseudo-archiver.ads pfseudo-archiver-directory.adb test.adb arc_dir_003.adb pfseudo-archiver-directory.adb:24:41: wrong type for return_subtype_indication pfseudo-archiver-directory.adb:46:35: wrong type for return_subtype_indication arc_dir_003.adb:25:32: _master conflicts with declaration at line 21 gcc-r154285: gcc-r154285 -c pfseudo.ads pfseudo-path.adb pfseudo-archiver.ads pfseudo-archiver-directory.adb test.adb arc_dir_003.adb arc_dir_003.adb:25:32: _master conflicts with declaration at line 21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug tree-optimization/42154] New: [4.5 Regression] Wrong code from (early) SRA
struct A { char x[1]; };
extern void abort (void);
void __attribute__((noinline,noclone))
foo (struct A a)
{
if (a.x[0] != 'a')
abort ();
}
int main ()
{
struct A a;
int i;
for (i = 0; i 1; ++i)
a.x[i] = 'a';
foo (a);
return 0;
}
fails at -O1 because (early) SRA converts
bb 2:
i_2 = 0;
goto bb 4;
bb 3:
a.x[i_1] = 97;
i_3 = i_1 + 1;
bb 4:
# i_1 = PHI 0(2), i_3(3)
if (i_1 = 0)
goto bb 3;
else
goto bb 5;
bb 5:
foo (a);
to
bb 2:
i_2 = 0;
goto bb 4;
bb 3:
a$x$_9 = 97;
i_3 = i_1 + 1;
bb 4:
# i_1 = PHI 0(2), i_3(3)
# a$x$_7 = PHI a$x$_4(D)(2), a$x$_9(3)
if (i_1 = 0)
goto bb 3;
else
goto bb 5;
bb 5:
a.x[i_1] = a$x$_7;
foo (a);
see how the store to a.x[i_1] is wrong as i_1 does no longer have the same
value as before (SRA invalidly moved it out of the loop). SRA should have
replaced i_1 with zero as it reasoned there is only one element and only
because of that it SRAd this.
--
Summary: [4.5 Regression] Wrong code from (early) SRA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154
[Bug tree-optimization/42154] [4.5 Regression] Wrong code from (early) SRA
-- 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=42154
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2009-11-23 11:02 --- Really fail to see how this is more convenient or useful for anyone involved but oh well, what do I know? Attaching a lot of files is indeed inconvenient, that's why http://gcc.gnu.org/bugs section Detailed bug reporting instructions for GNAT instructs you to submit a single file for gnatchop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #21 from gcc at coreland dot ath dot cx 2009-11-23 11:12 --- Created an attachment (id=19103) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19103action=view) version suitable for gnatchop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #22 from gcc at coreland dot ath dot cx 2009-11-23 11:13 --- Any way I can remove the above attachments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug fortran/42144] [OOP] deferred TBPs do not work
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-23 11:41 --- Another example (with generics): module foo_module implicit none private public :: foo,rescale type ,abstract :: foo contains procedure(times_interface) ,deferred :: times procedure(assign_interface) ,deferred :: assign generic :: operator(*) = times generic :: assignment(=) = assign end type abstract interface function times_interface(this,factor) result(product) import :: foo class(foo) ,intent(in) :: this class(foo) ,allocatable :: product real, intent(in) :: factor end function subroutine assign_interface(lhs,rhs) import :: foo class(foo) ,intent(inout) :: lhs class(foo) ,intent(in) :: rhs end subroutine end interface contains subroutine rescale(this,scale) class(foo) ,intent(inout) :: this real, intent(in) :: scale this = this*scale end subroutine end module module bar_module use foo_module ,only : foo implicit none private public :: bar type ,extends(foo) :: bar private real :: x=1. contains procedure :: times = times_bar procedure :: assign = assign_bar end type contains subroutine assign_bar(lhs,rhs) class(bar) ,intent(inout) :: lhs class(foo) ,intent(in) :: rhs select type(rhs) type is (bar) lhs%x = rhs%x end select end subroutine function times_bar(this,factor) result(product) class(bar) ,intent(in) :: this real, intent(in) :: factor class(foo), allocatable :: product select type(this) type is (bar) allocate(product,source=this) select type(product) type is(bar) product%x = this%x*factor end select end select end function end module program main use foo_module ,only : foo,rescale use bar_module ,only : bar implicit none type(bar) :: unit call rescale(unit,3.141592654) end program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42144
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #4 from burnus at gcc dot gnu dot org 2009-11-23 12:38 --- Does your patch still reject pure function test() integer, pointer :: p = null() ! INVALID per C1272 integer :: test test = p end function test That is currently rejected as Error: Initialization of pointer at (1) is not allowed in a PURE procedure. NAG f95 rejects it with: ERROR: Local variable P of PURE procedure TEST has the SAVE attribute as p gets implicitly declared as SAVE. There might well be a check for it in gfortran already, but seemingly no test case. If there is no such test case, could you also add it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug tree-optimization/42142] GCC 4.5 doesn't compile a certain quicksort implementation correctly when optimizing with -O1 or higher
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-23 12:40 --- Richard, can you have a look to this one? First blush, I don't see anything wrong with the code... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug middle-end/42130] [graphite-branch] dealII fails
--- Comment #3 from grosser at gcc dot gnu dot org 2009-11-23 13:02 --- Subject: Bug 42130 Author: grosser Date: Mon Nov 23 13:02:08 2009 New Revision: 154440 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154440 Log: Protect loops that might be executed zero times. 2009-11-23 Tobias Grosser gros...@fim.uni-passau.de PR middle-end/42130 * graphite-clast-to-gimple.c (graphite_create_new_loop_guard, translate_clast_for_loop): New. (translate_clast_for): Add a condition around the loop, to do not execute loops with zero iterations. * testsuite/g++.dg/graphite/pr42130.C: New. * testsuite/gcc.dg/graphite/pr35356-2.c: Adapt. Added: branches/graphite/gcc/testsuite/g++.dg/graphite/pr42130.C Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite-clast-to-gimple.c branches/graphite/gcc/testsuite/gcc.dg/graphite/pr35356-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
[Bug tree-optimization/42142] GCC 4.5 doesn't compile a certain quicksort implementation correctly when optimizing with -O1 or higher
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-23 13:10 ---
==29953== Conditional jump or move depends on uninitialised value(s)
==29953==at 0x400671: sort (qsort.c:16)
==29953==by 0x40079F: main (qsort.c:45)
qsort.c.034t.cddce1 deletes the store to end[i+1].
I will investigate further. Partially reduced testcase:
extern void abort (void);
void __attribute__((noinline,noclone))
sort(int *arr, int elements)
{
int piv, beg[10] = {}, end[10] = {}, i=0, L, R ;
beg[0]=0; end[0]=elements;
while (i=0)
{
L=beg[i]; R=end[i]-1;
if (LR)
{
piv=arr[L];
if (i==9)
abort ();
while (LR)
{
while (arr[R]=piv LR) R--; if (LR) arr[L++]=arr[R];
while (arr[L]=piv LR) L++; if (LR) arr[R--]=arr[L];
}
arr[L]=piv; beg[i+1]=L+1; end[i+1]=end[i]; end[i++]=L;
}
{
i--;
}
}
}
int main(int argc, char *argv[])
{
int table[10];
int count;
for (count = 0; count 10; count++)
table[count] = 10 - count;
sort(table, 10);
for ( count = 0; count 9; count++ )
if ( table[count] table[count+1] )
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-23 13:10:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug tree-optimization/42142] [4.5 Regression] DCE miscompiles a certain quicksort implementation correctly when optimizing with -O1 or higher
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|GCC 4.5 doesn't compile a |[4.5 Regression] DCE |certain quicksort |miscompiles a certain |implementation correctly|quicksort implementation |when optimizing with -O1 or |correctly when optimizing |higher |with -O1 or higher Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug tree-optimization/42142] [4.5 Regression] DCE miscompiles a certain quicksort implementation when optimizing with -O1 or higher
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-23 13:29 ---
int __attribute__((noinline,noclone))
sort(int L)
{
int end[2] = { 10, 10, }, i=0, R;
while (i2)
{
R = end[i];
if (LR)
{
end[i+1] = 1;
end[i] = 10;
++i;
}
else
break;
}
return i;
}
extern void abort (void);
int main()
{
if (sort (5) != 1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42142
[Bug c++/14777] [4.3/4.4/4.5 Regression] typedef doesn't fully expose base class type
--- Comment #18 from dodji at gcc dot gnu dot org 2009-11-23 13:30 --- Subject: Bug 14777 Author: dodji Date: Mon Nov 23 13:29:50 2009 New Revision: 154443 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154443 Log: Fix PR c++/14777 gcc/cp/ChangeLog: PR c++/14777 * cp-tree.def TEMPLATE_INFO: Declare new kind of tree node. * cp-tree.h (struct tree_template_info, struct qualified_typedef_usage_s): New. (cp_tree_node_structure_enum): add TS_CP_TEMPLATE_INFO. (union lang_tree_node): Add template_info. (TI_TEMPLATE, TI_ARGS, TI_TYPEDEFS_NEEDING_ACCESS_CHECKING): Adjust. (build_template_info): Declare. (get_types_needing_access_check): Adjust return type. (add_typedef_to_current_template_for_access_check): Declare. * cp-objcp-common.c (cp_tree_size): Handle TEMPLATE_INFO. * semantics.c (add_typedef_to_current_template_for_access_check): Split from ... (check_accessibility_of_qualified_id): ... here. * decl.c (make_typename_type): Use it. * pt.c (build_template_info): Define. (check_explicit_specialization, find_parameter_packs_r, push_template_decl_real, lookup_template_class, for_each_template_parm_r, tsubst_decl, tsubst): Use build_template_info. (get_types_needing_access_check): Adjust return type. (append_type_to_template_for_access_check_1): Record the location of the usage point of the typedef. Adjust to TEMPLATE_INFO. (append_type_to_template_for_access_check): Add new location parameter. Pass it to append_type_to_template_for_access_check_1. Adjust to TEMPLATE_INFO. (perform_typedefs_access_check): Temporarily set input_location to the usage point of the typedef we are checking access for. Adjust to new TEMPLATE_INFO tree node. * tree.c (bind_template_template_parm): Use build_template_info. * call.c (add_template_candidate_real): Likewise. * decl.c (grokfndecl): Likewise. (cp_tree_node_structure): Handle TEMPLATE_INFO. gcc/testsuite/ChangeLog: PR c++/14777 * g++.dg/template/typedef13.C: Adjust. * g++.dg/template/typedef19.C: Adjust. * g++.dg/template/typedef20.C: Adjust. * g++.dg/template/typedef22.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/typedef22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-tree.def trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/typedef13.C trunk/gcc/testsuite/g++.dg/template/typedef19.C trunk/gcc/testsuite/g++.dg/template/typedef20.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-11-23 13:44 --- Without the patch it is rejected, with the patch it is not. I will look into this further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug c++/14777] [4.3/4.4/ Regression] typedef doesn't fully expose base class type
--- Comment #19 from dodji at gcc dot gnu dot org 2009-11-23 13:44 --- This should be fixed in 4.5. Adjusting the Regression tag. Not planning to fix in 4.3/44. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4/ Regression] |typedef doesn't fully expose|typedef doesn't fully expose |base class type |base class type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug c++/14777] [4.3/4.4/ Regression] typedef doesn't fully expose base class type
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dodji 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=14777
[Bug tree-optimization/42154] [4.5 Regression] Wrong code from (early) SRA
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-11-23 14:01 --- I'm looking into this. This example shows why using access-expr to create new expressions is a dangerous thing to do, at least in some contexts (which I did not really realize until now). I'd better look at them all. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-23 14:01:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #6 from david dot resnick at comverse dot com 2009-11-23 14:15 --- (In reply to comment #5) Subject: Re: g++ should warn or error on internal 0 size array in struct On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote: (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. Several cases of C99 flexible array members that C99 does not permit are only diagnosed as pedwarns-if-pedantic for C because of glibc using them. (I gave an example in http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html.) I haven't looked into why it does this. (In reply to comment #5) Subject: Re: g++ should warn or error on internal 0 size array in struct On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote: (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. Several cases of C99 flexible array members that C99 does not permit are only diagnosed as pedwarns-if-pedantic for C because of glibc using them. (I gave an example in http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html.) I haven't looked into why it does this. OK, can't argue with not breaking existing headers I suppose. But this is to me clearly a bogus usage. What are the semantics of using internal zero sized arrays in a struct? They have the same offset as the following field and impose alignment restrictions on it. Do they have the same nominal requirements as unions for usage (can't write one, read the other?)? Or is the idea that if they are 0 sized and internal they are not to be used for any purpose whatsoever, and they are only not warnable because of existing usage in glibc headers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #30 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:22 --- Perhaps something like... Index: dwarf2out.c === --- dwarf2out.c (revision 154443) +++ dwarf2out.c (working copy) @@ -10447,8 +10447,11 @@ /* Output the block length for this list of location operations. */ dw2_asm_output_data (constant_size (size), size, %s, name); - - output_loc_sequence (AT_loc (a)); + + if (dwarf_strict (size == 0)) +break; + else + output_loc_sequence (AT_loc (a)); break; case dw_val_class_const: could fix this on darwin (untested) since we are the only target defaulting to dwarf_strict. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #31 from rguenther at suse dot de 2009-11-23 14:26 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #30 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:22 --- Perhaps something like... Index: dwarf2out.c === --- dwarf2out.c (revision 154443) +++ dwarf2out.c (working copy) @@ -10447,8 +10447,11 @@ /* Output the block length for this list of location operations. */ dw2_asm_output_data (constant_size (size), size, %s, name); - - output_loc_sequence (AT_loc (a)); + + if (dwarf_strict (size == 0)) +break; + else + output_loc_sequence (AT_loc (a)); break; case dw_val_class_const: could fix this on darwin (untested) since we are the only target defaulting to dwarf_strict. Well, I don't think outputting zero-length location sequences makes sense at all. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41151] Gas fails to consume the assembly Error: offset too big
--- Comment #4 from thiago at kde dot org 2009-11-23 14:32 --- My experience: gcc 4.4 + binutils 2.18.50.20070820 + no -march: ok gcc 4.4 + binutils 2.18.50.20070820 + -march=armv7-a: error gcc 4.4 + binutils 2.19.51.0.2.20090204: ok in both cases The instruction I had problems with was: movwr1, #:lower16:_ZL18qt_resource_struct My guess is that gcc started generating these instructions for newer ARM models, but binutils 2.18 couldn't consume them properly. But since it works with a newer binutils, my guess is that the problem is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41151
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:38 --- I got this response over on the gdb mailing list regarding the validity of emitting dwarf debug info containing an AT_location with any block form having a zero length... http://sourceware.org/ml/gdb/2009-11/msg00168.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2009-11-23 14:41 --- I should reiterate the dsymutil's maintainers comments on this issue... The variable should be checked to make sure it really doesn't have a location, and if it doesn't just don't emit the DW_AT_location attribute. If it does have a valid location, then a lenght of zero is probably a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #7 from redi at gcc dot gnu dot org 2009-11-23 14:53 --- (In reply to comment #6) OK, can't argue with not breaking existing headers I suppose. But this is to me clearly a bogus usage. What are the semantics of using internal zero sized arrays in a struct? They have the same offset as the following field and impose alignment restrictions on it. Do they have the same nominal requirements as unions for usage (can't write one, read the other?)? Or is the idea that if they are 0 sized and internal they are not to be used for any purpose whatsoever, and they are only not warnable because of existing usage in glibc headers? All good questions! It should be possible to make the C++ front end stricter about these so that outside of system headers they are an error, downgradeable to a warning with -fpermissive. I might try that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-11-23 14:53 --- I suppose empty DW_AT_location lists may now denote places where the value dies and is no longer available. We now properly track this with VTA. Alex? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #4 from guerby at gcc dot gnu dot org 2009-11-23 14:57 --- Subject: Bug 42153 Author: guerby Date: Mon Nov 23 14:56:58 2009 New Revision: 154446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154446 Log: 2009-11-23 Eric Botcazou ebotca...@adacore.com Laurent GUERBY laur...@guerby.net PR ada/42153 * s-osinte-linux.ads (struct_timeval): Delete. * s-osinte-hpux.ads (struct_timeval, To_Duration, To_Timeval): Delete. * s-osinte-kfreebsd-gnu.ads: Likewise. * s-osinte-rtems.ads: Likewise. * s-osinte-aix.ads: Likewise. * s-osinte-hpux-dce.ads: Likewise. * s-osinte-darwin.ads: Likewise. * s-osinte-solaris-posix.ads: Likewise. * s-osinte-irix.ads: Likewise. * s-osinte-solaris.ads: Likewise. * s-osinte-hpux-dce.adb (To_Duration, To_Timeval): Delete. * s-osinte-irix.adb: Likewise. * s-osinte-solaris.adb: Likewise. * s-osinte-rtems.adb: Likewise. Minor reformatting. * s-osinte-aix.adb (To_Duration, To_Timeval): Delete. (clock_gettime): Use cal.c timeval_to_duration. * s-osinte-darwin.adb: Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-aix.adb trunk/gcc/ada/s-osinte-aix.ads trunk/gcc/ada/s-osinte-darwin.adb trunk/gcc/ada/s-osinte-darwin.ads trunk/gcc/ada/s-osinte-hpux-dce.adb trunk/gcc/ada/s-osinte-hpux-dce.ads trunk/gcc/ada/s-osinte-hpux.ads trunk/gcc/ada/s-osinte-irix.adb trunk/gcc/ada/s-osinte-irix.ads trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-linux.ads trunk/gcc/ada/s-osinte-rtems.adb trunk/gcc/ada/s-osinte-rtems.ads trunk/gcc/ada/s-osinte-solaris-posix.ads trunk/gcc/ada/s-osinte-solaris.adb trunk/gcc/ada/s-osinte-solaris.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:03 --- If it is in fact valid dwarf, the question remains of what to do about the breakage that this causes with dsymutil on darwin. Inhibiting the emission of this in dwarf-strict might be a reasonable compromise since only darwin is defaulting that on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #36 from rguenther at suse dot de 2009-11-23 15:07 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #35 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:03 --- If it is in fact valid dwarf, the question remains of what to do about the breakage that this causes with dsymutil on darwin. Inhibiting the emission of this in dwarf-strict might be a reasonable compromise since only darwin is defaulting that on. If it's valid dwarf then it is also dwarf-strict. Please get apple fix its tools and issue a maintainance update. (I'm inclined to close this bug as invalid) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug rtl-optimization/42155] New: Optimizer generates bad code for ARM7 THUMB mode (local variable lost)
Hello.
I've found bug in GCC 4.4.1 for ARM7TDMI in THUMB mode.
Test code:
void foo(char *bar);
char test()
{
char tmp;
foo(tmp);
return tmp;
}
Compiled with: arm-elf-gcc -S -mcpu=arm7tdmi -O2 -mthumb test.c
Then using -O2 or -O3 optimization, assembler code looks like:
1:test:
2:push{r4, lr}
3:sub sp, sp, #4
4:mov r4, sp
5:add r4, r4, #3
6:mov r0, r4
7:bl foo
8:add sp, sp, #4
9:ldrbr0, [r4]
10: @ sp needed for prologue
11: pop {r4, pc}
So, if interrupt or task switching occurs between line 8 and line 9,
local variable in stack (referenced by r4) will be garbaged by service routine,
because stack rewinds before usage of local variable.
This code works fine with -O1:
1:test:
2:push{r4, lr}
3:sub sp, sp, #4
4:mov r4, sp
5:add r4, r4, #3
6:mov r0, r4
7:bl foo
8:ldrbr0, [r4]
9:add sp, sp, #4
10: @ sp needed for prologue
11: pop {r4, pc}
--
Summary: Optimizer generates bad code for ARM7 THUMB mode (local
variable lost)
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heavy at smtp dot ru
GCC build triplet: arm-elf
GCC host triplet: i486-linux-gnu
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42155
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:26 --- (In reply to comment #36) If it's valid dwarf then it is also dwarf-strict. Please get apple fix its tools and issue a maintainance update. (I'm inclined to close this bug as invalid) Richard. Apple will be fixing this for Xcode 3.2.x, but realistically it extremely unlikely that the fix will be backported to Xcode 3.1.x or early so you are basically cutting off all releases earlier than Snow Leopard from generating complete debug code in gcc trunk. Currently we can't generate dSYM's for... libgcj.dylib libgcjgc.1.dylib libgfortran.3.dylib libgomp.1.dylib libobjc-gnu.2.dylib libssp.0.dylib libstdc++.6.dylib because of this issue. Our only other choice left will be to carry around non-standard patches to avoid this problem in distributed FSF gcc binaries for darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #38 from rguenther at suse dot de 2009-11-23 15:28 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:26 --- (In reply to comment #36) If it's valid dwarf then it is also dwarf-strict. Please get apple fix its tools and issue a maintainance update. (I'm inclined to close this bug as invalid) Richard. Apple will be fixing this for Xcode 3.2.x, but realistically it extremely unlikely that the fix will be backported to Xcode 3.1.x or early so you are basically cutting off all releases earlier than Snow Leopard from generating complete debug code in gcc trunk. Currently we can't generate dSYM's for... libgcj.dylib libgcjgc.1.dylib libgfortran.3.dylib libgomp.1.dylib libobjc-gnu.2.dylib libssp.0.dylib libstdc++.6.dylib because of this issue. Our only other choice left will be to carry around non-standard patches to avoid this problem in distributed FSF gcc binaries for darwin. As this only affects GCC 4.5 it is not unreasonable to require an up-to-date Xcode. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/14777] [4.3/4.4/ Regression] typedef doesn't fully expose base class type
--- Comment #20 from jason at gcc dot gnu dot org 2009-11-23 15:40 --- If you don't think it's worth fixing on the older branches, the right thing to do is set the Target Milestone to the release where it will be fixed, and then close the bug as fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:43 --- Normally this wouldn't be a big deal, but powerpc support stops at Leopard so we are effectively cutting off powerpc-apple-darwin* from every properly generating dSYMs in gcc 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #13 from sje at cup dot hp dot com 2009-11-23 15:43 --- I think you will need to create a fde-freebsd.c file in gcc/config/ia64 to define Unwind_FindTableEntry. See fde-glibc.c and fde-vms.c for examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #40 from jakub at gcc dot gnu dot org 2009-11-23 15:49 --- Given: 2.6.1.1.4 Empty Location Descriptions An empty location description consists of a DWARF expression containing no operations. It represents a piece or all of an object that is present in the source but not in the object code (perhaps due to optimization). I believe this is valid DWARF, and IMNSHO it is Apple's responsibility to issue a bug fix update, GCC shouldn't be working around Apple's bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug middle-end/42095] [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-23 16:10 --- Subject: Bug 42095 Author: jakub Date: Mon Nov 23 16:10:19 2009 New Revision: 154449 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154449 Log: PR middle-end/42095 * tree.c: Include cgraph.h. (cp_fix_function_decl_p): Don't return true for same_body aliases. * Make-lang.in (cp/tree.o): Depend on $(CGRAPH_H). Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/cp/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #14 from mexas at bristol dot ac dot uk 2009-11-23 16:12 --- can I add a FBSD ia64 developer email to the CC list (xcl...@mac.com)? I tried to do this before, but was refused. I'm just reporting the bug. I've neigher skill not time to deal with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #41 from rguenther at suse dot de 2009-11-23 16:29 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote: --- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-11-23 15:43 --- Normally this wouldn't be a big deal, but powerpc support stops at Leopard so we are effectively cutting off powerpc-apple-darwin* from every properly generating dSYMs in gcc 4.5. So it's the responsibility of the darwin community to come up with either a fixed dsymutil or a proper re-implementation of it. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #42 from howarth at nitro dot med dot uc dot edu 2009-11-23 16:35 --- (In reply to comment #41) So it's the responsibility of the darwin community to come up with either a fixed dsymutil or a proper re-implementation of it. Richard. Unfortunately, dsymutil isn't part of Apple's open source releases so realistically we will just have to add a hack like comment 30 for distributed binary builds of FSF gcc in MacPorts and fink (if we want to be able to be able to debug code that triggers this issue on darwin9 and earlier). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-23 16:42 --- *** Bug 42155 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||heavy at smtp dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/42155] Optimizer generates bad code for ARM7 THUMB mode (local variable lost)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-23 16:42 --- *** This bug has been marked as a duplicate of 38644 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42155
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-23 17:09 --- Presumably, thanks Laurent. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug objc++/42156] New: Hundreds of objc++ testsuite regressions
Sometime between mainline revision 154353: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01929.html and 154391: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01929.html I'm getting massive numbers of objc++ testsuite regressions. -- Summary: Hundreds of objc++ testsuite regressions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] Hundreds of objc++ testsuite regressions
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-11-23 18:15 --- Sorry the second results for 154391 link is: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug fortran/42008] Wrongly rejected derived types with default initializers in PURE procedures
--- Comment #6 from burnus at gcc dot gnu dot org 2009-11-23 19:35 ---
(In reply to comment #5)
Without the patch it is rejected, with the patch it is not. I will look into
this further.
Would something like if (...-attr.saved) { gfc_error } work, combined with
the patch from comment 3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42008
[Bug middle-end/42095] [4.5 Regression] g++.dg/lto/20081118-1 cp_lto_20081118-1_0.o-cp_lto_20081118-1_1.o link
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-23 20:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42095
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #43 from andreast at gcc dot gnu dot org 2009-11-23 20:55 --- I understood Jack this way that he asked/is looking for a temporary solution to prove that this is the only issue we face with dsymutil. It is not the idea, from my understanding, that we, gcc, 'fix'/tweak gcc to workaround OS issues. Right now, my expectation is this, Apple has to fix this issue on both, Xcode-3.1x (Leopard) and Xcode-3.2x(Snow Leopard). There are a lot of users which are still on Xcode-3.1x, and a few will stay on this release since they can not upgrade due to the fact that Snow Leopard does not run on ppc machines. From the technical POV we should try to help isolating the issue. My 2 cents. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #10 from ltuikov at yahoo dot com 2009-11-23 20:56 --- Can anyone comment on this? I'd really like to use gcc 4.4.2 to cross compile ARC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #11 from uros at gcc dot gnu dot org 2009-11-23 21:14 --- Subject: Bug 42113 Author: uros Date: Mon Nov 23 21:14:32 2009 New Revision: 154464 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154464 Log: PR target/42113 * config/alpha/alpha.md (*cmp_sadd_si): Change mode of scratch register to SImode. (*cmp_sadd_sidi): Ditto. (*cmp_ssub_si): Ditto. (*cmp_ssub_sidi): Ditto. testsuite/ChangeLog: PR target/42113 * gcc.target/alpha/pr42113.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr42113.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/alpha.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #12 from uros at gcc dot gnu dot org 2009-11-23 21:27 --- Subject: Bug 42113 Author: uros Date: Mon Nov 23 21:27:30 2009 New Revision: 154465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154465 Log: PR target/42113 * config/alpha/alpha.md (*cmp_sadd_si): Change mode of scratch register to SImode. (*cmp_sadd_sidi): Ditto. (*cmp_ssub_si): Ditto. (*cmp_ssub_sidi): Ditto. testsuite/ChangeLog: PR target/42113 * gcc.target/alpha/pr42113.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr42113.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/alpha/alpha.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #13 from ubizjak at gmail dot com 2009-11-23 21:30 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2009-11-23 21:41 --- (In reply to comment #43) From the technical POV we should try to help isolating the issue. My 2 cents. Actually, if the Alexandre's patch... http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01292.html is approved, the issue will disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #15 from mexas at bristol dot ac dot uk 2009-11-23 21:47 --- Hi Marcel, sorry to bother you with this again. Are you happy to be on my Cc list for this bug? Sure. sje@ doesn't quite know what he's talking about because he doesn't know FreeBSD. See also below. --- Comment #13 from sje at cup dot hp dot com 2009-11-23 15:43 --- I think you will need to create a fde-freebsd.c file in gcc/config/ia64 to define Unwind_FindTableEntry. See fde-glibc.c and fde-vms.c for examples. _Unwind_FindTableEntry is defined in libc. FYI, -- Marcel Moolenaar xcl...@mac.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug fortran/42131] Weird translation of DO loops
--- Comment #11 from tkoenig at gcc dot gnu dot org 2009-11-23 21:48 --- Created an attachment (id=19104) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19104action=view) another proposed patch Here's another proposed patch, but there is a problem with it. If we calculate (m2 - m1 + m3)/m3 with signed types, then this will overflow, for example, for do i=-huge(i),huge(i),2 The current implementation gets around that by doing the addition and division unsigned, then dividing unsigned as well. For this, there have to be two cases, one for m30 and one for m30, which is what we generate at the moment. Possible solutions: - get rid of the loop counter altogether - perform the intermediate calculation with increased precision, if available - Multiply everything by the sign of m3 before doing the unsigned math (which is what we do now, except that we hide this behind an if) - Trust two's complement arithmetic and hope that overflows don't trap (not, in general, a good idea) Any tricks I have missed? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #19076|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug target/29720] Latest CVS: undefined reference to __tls_get_addr
--- Comment #3 from ubizjak at gmail dot com 2009-11-23 21:58 --- (In reply to comment #2) OK, that fixed the problem. But shouldn't configuration have caught it? So, fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29720
[Bug fortran/41860] -finit-local-XXX clobbers -fno-automatic
--- Comment #2 from jb at gcc dot gnu dot org 2009-11-23 22:01 --- Closing as fixed, as no complaints about the committed patch have surfaced. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860
[Bug middle-end/42127] Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-11-23 22:04 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42127
[Bug bootstrap/42157] New: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions
While building current mainline (rev 154216) again after half a year, the bootstrap aborted while building the stage 1 libgcc: /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__muldi3': /vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:562:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_muldi3.o] Error 1 Running cc1 under gdb reveals (gdb) run -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-synci -auxbase-strip _muldi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o libgcc2.s Starting program: /tmp_mnt/vol/gcc/obj/gcc-4.5.0-20091116/5.3-gcc/mips-sgi-irix5.3/libgcc/cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-synci -auxbase-strip _muldi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o libgcc2.s GNU C (GCC) version 4.5.0 20091116 (experimental) [trunk revision 154216] (mips-sgi-irix5.3) compiled by GNU C version 4.1.1, GMP version 4.2.1, MPFR version 2.3.2, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.5.0 20091116 (experimental) [trunk revision 154216] (mips-sgi-irix5.3) compiled by GNU C version 4.1.1, GMP version 4.2.1, MPFR version 2.3.2, MPC version 0.8 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 23aff50e67c559603acf00c443e2c073 Program received signal SIGSEGV, Segmentation fault. 0x014a2e48 in compare_access_positions (a=0x10292084, b=0x1029208c) at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1106 (gdb) p f1 $1 = (const access_p) 0x20 (gdb) p f2 $2 = (const access_p) 0x10291d80 (gdb) where #0 0x014a2e48 in compare_access_positions (a=0x10292084, b=0x1029208c) at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1106 #1 0x0fac4254 in qsort () at qsort.c:94 #2 0x014a610c in sort_and_splice_var_accesses (var=0x1a98b40) at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1407 #3 0x014a9050 in analyze_all_variable_accesses () at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1875 #4 0x014ad7dc in perform_intra_sra () at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:2568 #5 0x014ada50 in early_intra_sra () at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:2597 #6 0x00d17cec in execute_one_pass (pass=0x10180324) at /vol/gcc/src/gcc-dist/gcc/passes.c:1522 #7 0x00d1853c in execute_pass_list (pass=0x10180324) at /vol/gcc/src/gcc-dist/gcc/passes.c:1577 #8 0x00d18584 in execute_pass_list (pass=0x1017fe38) at /vol/gcc/src/gcc-dist/gcc/passes.c:1578 #9 0x00d16064 in do_per_function_toporder ( callback=0xd184a4 execute_pass_list, data=0x1018cb48) at /vol/gcc/src/gcc-dist/gcc/passes.c:1120 #10 0x00d19254 in execute_ipa_pass_list (pass=0x1017fe04) at /vol/gcc/src/gcc-dist/gcc/passes.c:1743 #11 0x011d6504 in ipa_passes () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1363 #12 0x011d6884 in cgraph_optimize () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1422 #13 0x011d5330 in cgraph_finalize_compilation_unit () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1090 #14 0x004c60a4 in c_write_global_declarations () at /vol/gcc/src/gcc-dist/gcc/c-decl.c:9489 #15 0x00626034 in compile_file () at /vol/gcc/src/gcc-dist/gcc/toplev.c:1061 #16 0x0062ac60 in do_compile () at /vol/gcc/src/gcc-dist/gcc/toplev.c:2408 #17 0x0062ae8c in toplev_main (argc=25, argv=0x7ffbfeb4) at /vol/gcc/src/gcc-dist/gcc/toplev.c:2450 #18 0x00601160 in main (argc=25, argv=0x7ffbfeb4) at /vol/gcc/src/gcc-dist/gcc/main.c:35 So far, I couldn't reproduce this in an i386-pc-solaris2.10 - mips-sgi-irix5.3 cross compiler. -- Summary: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: mips-sgi-irix5.3 GCC host triplet: mips-sgi-irix5.3 GCC target triplet: mips-sgi-irix5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42157
[Bug c/36470] sizeof UTF-32 is 2 on AVR
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2009-11-23 22:10 --- Subject: Bug 36470 Author: hutchinsonandy Date: Mon Nov 23 22:10:18 2009 New Revision: 154471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154471 Log: PR testsuite/36470 * gcc.dg/utf-cvt.c: Skip int test for 16bit int targets. Enable short test for avr target. * gcc.dg/utf32-1.c: Enable test for avr and m32 targets. * gcc.dg/utf32-2.c: Ditto. * gcc.dg/utf32-3.c: Ditto. * gcc.dg/utf32-4.c: Enable test for non-32bit targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/utf-cvt.c trunk/gcc/testsuite/gcc.dg/utf32-1.c trunk/gcc/testsuite/gcc.dg/utf32-2.c trunk/gcc/testsuite/gcc.dg/utf32-3.c trunk/gcc/testsuite/gcc.dg/utf32-4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36470
[Bug tree-optimization/42154] [4.5 Regression] Wrong code from (early) SRA
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-11-23 22:19 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01311.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42154
[Bug middle-end/42151] verify_cgraph_node failed with -O3 -Winline
--- Comment #2 from hubicka at gcc dot gnu dot org 2009-11-23 22:27 --- Subject: Bug 42151 Author: hubicka Date: Mon Nov 23 22:27:15 2009 New Revision: 154475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154475 Log: PR middle-end/42151 * ipa-inline.c (inline_transform): Avoid ICE when transform is called twice. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42151
[Bug middle-end/42151] verify_cgraph_node failed with -O3 -Winline
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-11-23 22:30 --- Fixed. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42151
[Bug regression/40329] gcc-4.5 build fails on alpha
--- Comment #1 from ubizjak at gmail dot com 2009-11-23 22:31 --- Can you check if latest SVN still fails? If the build still fails, please attach preprocessed source to the report (see http://gcc.gnu.org/bugs/ for instructions). -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40329
[Bug regression/40329] gcc-4.5 build fails on alpha
--- Comment #2 from mexas at bristol dot ac dot uk 2009-11-23 22:35 --- sorry, I no longer have alpha, I moved to ia64 FreeBSD. many thanks for your efforts anyway! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40329
[Bug libgcj/40345] All libjava executions tests time out on Tru64 UNIX V4.0F
--- Comment #1 from ubizjak at gmail dot com 2009-11-23 22:36 --- Apparently fixed: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00799.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40345
[Bug regression/40329] gcc-4.5 build fails on alpha
--- Comment #3 from ubizjak at gmail dot com 2009-11-23 22:55 --- Works for me on linux. -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40329
[Bug testsuite/42086] FAIL: gcc.target/ia64/fptr-1.c execution test
--- Comment #2 from hjl at gcc dot gnu dot org 2009-11-23 22:56 --- Subject: Bug 42086 Author: hjl Date: Mon Nov 23 22:55:54 2009 New Revision: 154478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154478 Log: 2009-11-23 H.J. Lu hongjiu...@intel.com PR testsuite/42086 * gcc.target/ia64/fptr-1.c: Make it a compile test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/ia64/fptr-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42086
[Bug c++/11764] [DR147] g++ does not treat injected class name correctly.
--- Comment #18 from jason at gcc dot gnu dot org 2009-11-23 22:57 --- Mine now. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|gdr at gcc dot gnu dot org |jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11764
[Bug c++/42038] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42038
[Bug c++/42038] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #4 from paolo dot carlini at oracle dot com 2009-11-23 23:18 --- Jason, as far as I know, we never compiled this, the ICE is new. If we only want to avoid the ICE, I'm attaching a patchlet to except.c which works fine, otherwise, please let me know... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42038
[Bug c++/42038] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-23 23:19 --- Created an attachment (id=19105) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19105action=view) Draft patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42038
[Bug c++/42158] New: structure alignment for derived class is wrong in some cases
if the base class and the derived class have different alignments, g++
sometimes uses the alignment of the base class for the derived class.
it happens if the source code has definition of a base class instance before
the declaration of the derived class, then the base alignment is used, which is
wrong.
3 files to reproduce the bug:
== gcc_align_bug.h
#pragma pack(push, 1)
struct myset_t : public std::setint
{
void myadd(int x);
};
#pragma pack(pop)
== gcc_align_bug.cpp ==
#include set
#include stdio.h
// comment this line to fix the bug. apparently is causes generation of
// wrong code for myset_t:
std::setint my_intset;
#include gcc_align_bug.h
int main()
{
printf(alignment bug demo\n);
myset_t s;
s.myadd(0); // crash
// NOTREACHED
printf(all ok\n);
return 0;
}
== myadd.cpp ==
#include set
#include gcc_align_bug.h
//-
void myset_t::myadd(int x)
{
// will crash here:
insert(x);
}
Compile without any options and run:
g++ gcc_align_bug.cpp myadd.cpp
./a.out
alignment bug demo
Segmentation fault
--
Summary: structure alignment for derived class is wrong in some
cases
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at hex-rays dot com
GCC build triplet: 4.4.1 - 4.1.3 and probably other builds
GCC host triplet: x86-linux-elf
GCC target triplet: x86-linux-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42158
[Bug c++/42158] structure alignment for derived class is wrong in some cases
--- Comment #1 from info at hex-rays dot com 2009-11-24 00:11 --- Created an attachment (id=19106) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19106action=view) sample files to reproduce the bug compile it with g++ gcc_align_bug.cpp myadd.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42158
[Bug c++/42158] structure alignment for derived class is wrong in some cases
--- Comment #2 from info at hex-rays dot com 2009-11-24 00:12 --- Created an attachment (id=19107) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19107action=view) sample files to reproduce the bug -- sorry for the previous attachment compile with g++ gcc_align_bug.cpp myadd.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42158
[Bug c++/42159] New: app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding
A 64 bit build of gcc 4.4.2 installed via darwinports on a Mac Pro server
running Snow Leopard 10.6.2 causes a crash in the following program:
cat src/test.cpp
#include iostream
struct X
{
~X () // crash disappears if there is no destructor
{
}
};
void
dummy ()
{
X x;
throw 0;
}
int main()
{
try
{
dummy ();
}
catch (...)
{
std::cout CAUGHT std::endl;
}
return 0;
}
Instead of the expected CAUGHT the system pops up with:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
abort() called
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x7fff801a3fe6 __kill + 10
1 libSystem.B.dylib 0x7fff80244e32 abort + 83
2 libgcc_s.1.dylib0x0001001a2aa2 uw_init_context_1 +
146
3 libgcc_s.1.dylib0x0001001a2ef8 _Unwind_Resume + 72
4 crash 0x00010cfe main + 0
5 crash 0x00010d0a main + 12
6 crash 0x00010c88 start + 52
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x rbx: 0x7fff5fbff560 rcx: 0x7fff5fbff288
rdx: 0x
rdi: 0x00014c96 rsi: 0x0006 rbp: 0x7fff5fbff2a0
rsp: 0x7fff5fbff288
r8: 0x0001002fc0a0 r9: 0x0001002fc0a4 r10: 0x7fff801a0026
r11: 0x0206
r12: 0x7fff5fbff6a0 r13: 0x00010cfe r14: 0x7fff5fbff2b0
r15: 0x
rip: 0x7fff801a3fe6 rfl: 0x0206 cr2: 0x0001001a5924
Binary Images:
0x1 -0x10ff7 +crash ??? (???)
1795FC81-D57C-8C65-42CB-984BCE974933 /Users/vlad/PRJ/test/crash
0x13000 -0x1000a9fe7 +libstdc++.6.dylib ??? (???)
7ED4A235-4CEF-A737-9698-18B1301A9979 /sw/lib/gcc4.4/lib/libstdc++.6.dylib
0x100195000 -0x1001a8ff7 +libgcc_s.1.dylib ??? (???)
A31CA578-6BE8-891F-8F79-680CAAA8DE22 /sw/lib/gcc4.4/lib/libgcc_s.1.dylib
0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???)
B633F790-4DDB-53CD-7ACF-2A3682BCEA9F /usr/lib/dyld
0x7fff80155000 - 0x7fff80313ff7 libSystem.B.dylib ??? (???)
526DD3E5-2A8B-4512-ED97-01B832369959 /usr/lib/libSystem.B.dylib
0x7fff8373b000 - 0x7fff8373fff7 libmathCommon.A.dylib ??? (???)
95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib
0x7fe0 - 0x7fe01fff libSystem.B.dylib ??? (???)
526DD3E5-2A8B-4512-ED97-01B832369959 /usr/lib/libSystem.B.dylib
Model: MacPro4,1, BootROM MP41.0081.B04, 8 processors, Quad-Core Intel Xeon,
2.66 GHz, 16 GB, SMC 1.39f5
As long as a local object 'x' with a destructor is created prior to the 'throw'
inside dummy(), the problem occurs.
[18:53:02] testg++-4 -v -save-temps src/test.cpp -o crash
Using built-in specs.
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.4.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/share/info
--enable-languages=c,c++,fortran,objc,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--disable-libjava-multilib --build=x86_64-apple-darwin10
--host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
Thread model: posix
gcc version 4.4.2 (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o'
'crash' '-shared-libgcc' '-mtune=generic'
/sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/cc1plus -E -quiet -v
-D__DYNAMIC__ src/test.cpp -fPIC -mmacosx-version-min=10.6.2 -mtune=generic
-fpch-preprocess -o test.ii
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../x86_64-apple-darwin10/include
#include ... search starts here:
#include ... search starts here:
/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../include/c++/4.4.2
/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../include/c++/4.4.2/x86_64-apple-darwin10
/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/../../../../include/c++/4.4.2/backward
/sw/lib/gcc4.4/include
/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/include
/sw/lib/gcc4.4/lib/gcc/x86_64-apple-darwin10/4.4.2/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.2' '-v' '-save-temps' '-o'
'crash' '-shared-libgcc' '-mtune=generic'
/sw/lib/gcc4.4/libexec/gcc/x86_64-apple-darwin10/4.4.2/cc1plus -fpreprocessed
test.ii -fPIC -quiet -dumpbase test.cpp -mmacosx-version-min=10.6.2
-mtune=generic -auxbase test -version -o test.s
GNU C++ (GCC) version 4.4.2
[Bug rtl-optimization/42116] ICE cross-compiling libgcc2.c, host: x86_64, target: arc-elf32 (unrecognizable insn)
--- Comment #11 from ltuikov at yahoo dot com 2009-11-24 01:05 --- Update Summary to give visibility in searches. -- ltuikov at yahoo dot com changed: What|Removed |Added Summary|ice on valid code |ICE cross-compiling |(unrecognizable insn) |libgcc2.c, host: x86_64, ||target: arc-elf32 ||(unrecognizable insn) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug c++/42159] app compiled with 4.4.2 SIGABRTs after a trivial nested throw/stack unwinding
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2009-11-24 01:25 --- This bug doesn't appear to be present in current gcc trunk on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
