[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-12 09:01:36 UTC --- Copy quote from bug 468742 comment 12: The solution is the same as for gfc_trans_arrayfunc_assign, where the same issue can occur. Cf. PR 44582.
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
--- Comment #3 from Eskil Steenberg eskil at obsession dot se 2010-12-12
09:09:54 UTC ---
Hi
(In reply to comment #1)
There is no integer overflow in the code provided at all.
Sorry it underflows. How about this:
void my_func(unsigned short a, unsigned short c)
{
unsigned int b;
b = a * c;
Even if there was, the standard says the behavior is undefined which means
anything can happen.
Yes, but the doesn't the C spec define the overflow as undefined, rather
then the entire program? The behavior is defined, just not by the C spec,
its defined by the hardware implementation. The compile time assumption
that nothing will ever overflow seams dangerous.
My problem is not that C has undefined behavior, but rather that gcc makes
assumptions about this behavior that _can_ turn out to be not true.
Cheers
E
[Bug testsuite/46895] FAIL: gcc.target/i386/max-stack-align.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|middle-end |testsuite --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-12-12 09:20:43 UTC --- This is 64bit specific test. See %rbp clobber. Also, 8 input regs is a bit too much for 32bit targets.
[Bug testsuite/46895] FAIL: gcc.target/i386/max-stack-align.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895
--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2010-12-12 09:30:35
UTC ---
/* { dg-do compile } */
/* { dg-options -fomit-frame-pointer } */
#ifdef __x86_64__
# define BP_REG %rbp
#else
# define BP_REG %ebp
#endif
void foo (void)
{
__asm__ volatile ( ::: BP_REG );
}
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-12
10:20:03 UTC ---
Sorry it underflows.
No, conversion does not have any overflow/underflow in it.
void my_func(unsigned short a, unsigned short c)
{
unsigned int b;
b = a * c;
There is no overflow here since this unsigned integers wrap and don't overflow.
Yes, but the doesn't the C spec define the overflow as undefined, rather
then the entire program?
No it is a runtime undefined behavior rather than the result being undefined.
rather that gcc makes assumptions about this behavior that _can_ turn out to
be not true.
But assumptions? Since it is undefined behavior, it does not matter because
GCC can make different assumptions in when it feels like.
Unless you can give a testcase that does not depend on undefined behavior, it
is hard to prove GCC is doing something wrong. -fwrapv can be used to define
signed integer overflow as wrapping.
See http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Integers-implementation.html
for how the conversion is implementation defined behavior:
# The result of, or the signal raised by, converting an integer to a signed
integer type when the value cannot be represented in an object of that type
(C90 6.2.1.2, C99 6.3.1.3).
For conversion to a type of width N, the value is reduced modulo 2^N to be
within range of the type; no signal is raised.
Conversions are never causes an overflow rather it causes an implementation
defined behavior in some cases.
[Bug fortran/46900] New: 50% slowdown when linking with LTO in a single step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46900 Summary: 50% slowdown when linking with LTO in a single step Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Cf. PR 44334 for another LTO slowdown. Cf. http://gcc.gnu.org/ml/fortran/2010-12/msg00067.html I had expected that doing the LTO linkage in one or in two steps is identical, but seemingly it is not: $ gfortran -fexternal-blas -flto -Ofast -march=native \ test.f90 dgemm.f lsame.f xerbla.f $ ./a.out Time, MATMUL:1.4680910 53.480084765505403 dgemm:1.4720919 56.452265589399069 But if one first compiles and then links (w/ or w/o LTO), the programm is 47% faster: $ gfortran -fexternal-blas -Ofast -march=native \ test.f90 dgemm.f lsame.f xerbla.f Time, MATMUL:1.0080630 53.480084765505403 dgemm:1.0200630 56.452265589399069 $ gfortran -c -fexternal-blas -flto -Ofast -march=native \ test.f90 dgemm.f lsame.f xerbla.f $ gfortran -flto -Ofast -march=native test.o dgemm.o lsame.o xerbla.o $ ./a.out Time, MATMUL:1.0080630 53.480084765505403 dgemm:1.0080630 56.452265589399069 (If one
[Bug middle-end/46900] 50% slowdown when linking with LTO in a single step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46900 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Component|fortran |middle-end --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-12 10:33:09 UTC --- (If one uses the libgfortran MATMUL (i.e. without -fexternal-matmul), the call takes 1.7001060s)
[Bug middle-end/46900] 50% slowdown when linking with LTO in a single step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46900 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-12 10:34:48 UTC --- Created attachment 22722 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22722 Test case (tar.bz2). The .f files are from BLAS (taken from LAPACK 3.3)
[Bug middle-end/46900] [4.6 Regression] 50% slowdown when linking with LTO in a single step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46900 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 Summary|50% slowdown when linking |[4.6 Regression] 50% |with LTO in a single step |slowdown when linking with ||LTO in a single step --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-12 10:39:17 UTC --- The linkage seems to be a regression. If I compile with GCC 4.5, I get for the direct dgemm call the same performance if I link in a single step: $ gfortran-4.5 -fexternal-blas -flto -O3 -ffast-math -march=native \ test.f90 dgemm.f lsame.f xerbla.f $ ./a.out Time, MATMUL:1.4160880 53.480084765505403 dgemm:1.0840679 56.452265589399069 (I don't understand why the MATMUL part differs that much - it should call the same BLAS function [via the same GCC 4.6 libgfortran.so wrapper] and LTO should not affect it.)
[Bug c++/46901] New: Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 Summary: Error message repeats itself Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: goe...@uddeborg.se In convert_for_assignment in gcc/cp/typcheck.c there is a message target of conversion might be might be a candidate for a format attribute There is one might be too many in there.
[Bug middle-end/46900] [4.6 Regression] 50% slowdown when linking with LTO in a single step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46900 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-12 10:50:09 UTC --- (In reply to comment #3) (I don't understand why the MATMUL part differs that much - it should call the same BLAS function [via the same GCC 4.6 libgfortran.so wrapper] and LTO should not affect it.) Seemingly, LTO is crucial for 4.5 - without LTO dgemm gets slower but the libgfortran version gets faster: $ gfortran-4.5 -fexternal-blas -O3 -ffast-math -march=native test.f90 dgemm.f lsame.f xerbla.f ./a.out Time, MATMUL:1.3200819 53.480084765505403 dgemm:1.3120821 56.452265589399069 $ gfortran-4.5 -c -flto -fexternal-blas -O3 -ffast-math -march=native test.f90 dgemm.f lsame.f xerbla.f $ gfortran-4.5 -flto -O3 -ffast-math -march=native test.o dgemm.o lsame.o xerbla.o $ ./a.out Time, MATMUL:1.3080810 53.480084765505403 dgemm:1.0800680 56.452265589399069 Here, for GCC 4.5, one sees that for the direct call of dgemm, LTO improves the performance - and doing a single step compilation+linkage or in two steps does not matter. However, also for GCC 4.5 the single-step pessimizes the performance of the libgfortran MATMUL (which is a wrapper for dgemm).
[Bug c++/46901] Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.12 11:00:48 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 11:00:48 UTC --- Right, I'll fix it momentarily.
[Bug c++/46901] Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2010-12-12 11:21:22 UTC --- Author: paolo Date: Sun Dec 12 11:21:19 2010 New Revision: 167723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167723 Log: 2010-12-12 Paolo Carlini paolo.carl...@oracle.com PR c++/46901 * typeck.c (convert_for_assignment): Fix typo in warning message. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug c++/46901] Error message repeats itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46901 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 11:22:57 UTC --- Done.
[Bug libstdc++/46869] FAIL: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler-not _ZNSt23enable_shared_from_thisIiEC2Ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46869 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.12 11:38:37 CC||bkoz at redhat dot com Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 11:38:37 UTC --- s390 shows similar problems: http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01002.html Benjamin, could you please double check whether something should be tweaked in the dg-finals? Thanks.
[Bug c/46902] New: [4.6 Regression] gcc.dg/plugin/plugindir*.c gives ICEs on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902 Summary: [4.6 Regression] gcc.dg/plugin/plugindir*.c gives ICEs on powerpc-apple-darwin9 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: d...@redhat.com, i...@airs.com, jos...@codesourcery.com, ia...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Between revisions 166379 and 166752 on my logs the following failures in the test suite appeared on powerpc-apple-darwin9 with both -m32 and -m64: FAIL: gcc.dg/plugin/plugindir1.c (internal compiler error) FAIL: gcc.dg/plugin/plugindir1.c (test for excess errors) FAIL: gcc.dg/plugin/plugindir2.c (internal compiler error) FAIL: gcc.dg/plugin/plugindir2.c (test for excess errors) FAIL: gcc.dg/plugin/plugindir3.c (internal compiler error) FAIL: gcc.dg/plugin/plugindir3.c (test for excess errors) FAIL: gcc.dg/plugin/plugindir4.c (internal compiler error) FAIL: gcc.dg/plugin/plugindir4.c (test for excess errors) Reduced range from regress: revision 166543 works, revision 166589 fails, see: http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00831.html http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00875.html Without better knowledge, revisions 166544, 166552, 16653, 166555, 166565, and 166570 could be candidates (no guarantee about an exhaustive list!-). These failures are due to ICEs during the compilation [karma] f90/bug% /opt/gcc/gcc4.6w/bin/gcc -c -fplugin=foo /opt/gcc/gcc-4.6-work/gcc/testsuite/gcc.dg/plugin/plugindir1.c [address=fffc pc=94afe928] cc1: internal compiler error: Segmentation Fault The backtrace is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xfffc 0x94afe928 in strlen () (gdb) bt #0 0x94afe928 in strlen () #1 0x008b6414 in concat (first=0x Address 0x out of bounds) at ../../gcc-4.6-work/libiberty/concat.c:76 #2 0x0051e660 in add_new_plugin (plugin_name=0xbfffdac2 foo) at ../../gcc-4.6-work/gcc/plugin.c:157 #3 0x00515888 in handle_common_deferred_options () at ../../gcc-4.6-work/gcc/opts-global.c:385 #4 0x005e3844 in toplev_main (argc=3, argv=0x) at ../../gcc-4.6-work/gcc/toplev.c:1923 #5 0x2560 in start () This PR seems different from pr43759.
[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-12 11:53:15 UTC --- See also pr46902 for other failures of gcc.dg/plugindir*.c.
[Bug libffi/42378] cls_*double_va.c failures on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42378 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-12 11:55:48 UTC --- Among other benefits, this PR is fixed by the patch in http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00804.html . Thanks!-)
[Bug libffi/29152] 64-bit darwin ppc port needed for libffi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-12 11:58:49 UTC --- Fixed by the patch in http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00804.html.
[Bug c++/46903] New: [C++0x] ICE unexpected expression of kind template_id_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46903 Summary: [C++0x] ICE unexpected expression of kind template_id_expr Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rubid...@openttd.org Created attachment 22723 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22723 Test case, compile with C++0x. The attached test case fails with an ICE: test.ii:6:18: internal compiler error: unexpected expression ‘CreateAA’ of kind template_id_expr Using: g++-trunk -std=gnu++0x test.ii With g++-trunk (GCC) 4.6.0 20101211 (experimental) (revision 167723) It compiles fine with gcc 4.5.1, 4.4.5 and 4.3.5.
[Bug c/46902] [4.6 Regression] gcc.dg/plugin/plugindir*.c gives ICEs on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902 --- Comment #1 from Iain Sandoe iains at gcc dot gnu.org 2010-12-12 12:26:44 UTC --- this commit triggers the bug.. http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00454.html
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
--- Comment #5 from Eskil Steenberg eskil at obsession dot se 2010-12-12
12:30:15 UTC ---
Hi
void my_func(unsigned short a, unsigned short c)
{
unsigned int b;
b = a * c;
There is no overflow here since this unsigned integers wrap and don't
overflow.
Yes there is since a and c are promoted to signed ints and thats where the
multiplication takes place, before they are converted to an unsigned int.
A max unsigned short times a max unsigned short will overflow a signed
int. (given a 32 bit system at least)
Yes, but the doesn't the C spec define the overflow as undefined, rather
then the entire program?
No it is a runtime undefined behavior rather than the result being
undefined.
So how can the compiler make a compile time assumption about the outcome
of the behavior since it is undefined at compile time?
rather that gcc makes assumptions about this behavior that _can_ turn
out to
be not true.
But assumptions? Since it is undefined behavior, it does not matter
because GCC can make different assumptions in when it feels like.
Could you clarify this statement?
Unless you can give a testcase that does not depend on undefined behavior,
it is hard to prove GCC is doing something wrong.
The very problem I'm addressing is how gcc deals with this, at compile
time, undefined behavior.
Cheers
E
[Bug c++/46903] [4.6 Regression][C++0x] ICE unexpected expression of kind template_id_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46903 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.12 12:33:44 CC||jason at gcc dot gnu.org Target Milestone|--- |4.6.0 Summary|[C++0x] ICE unexpected |[4.6 Regression][C++0x] ICE |expression of kind |unexpected expression of |template_id_expr|kind template_id_expr Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 12:33:44 UTC --- Looks like a regression.
[Bug c++/46904] New: [4.6 Regression] g++.dg/tree-prof/(indir-call-prof.C|inline_mismatch_args.C) fail on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46904 Summary: [4.6 Regression] g++.dg/tree-prof/(indir-call-prof.C|inline_mismatch_ar gs.C) fail on powerpc-apple-darwin9 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 On powerpc-apple-darwin9 with both -m32/64, between revisions 167074 and 167096 the following failures appeared (see http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01969.html http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg02001.html ): FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -g -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-g -fprofile-use FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -O0 -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-O0 -fprofile-use FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -O1 -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-O1 -fprofile-use FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -O2 -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-O2 -fprofile-use FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -O3 -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-O3 -fprofile-use FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -O3 -g -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-O3 -g -fprofile-use FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -Os -fprofile-use UNRESOLVED: g++.dg/tree-prof/indir-call-prof.C execution,-Os -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -g -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-g -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -O0 -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-O0 -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -O1 -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-O1 -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -O2 -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-O2 -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -O3 -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-O3 -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -O3 -g -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-O3 -g -fprofile-use FAIL: g++.dg/tree-prof/inline_mismatch_args.C compilation, -Os -fprofile-use UNRESOLVED: g++.dg/tree-prof/inline_mismatch_args.C execution,-Os -fprofile-use The failures are Executing on host: /opt/gcc/darwin_buildw/gcc/testsuite/g++/../../g++ -B/opt/gcc/darwin_buildw/gcc/testsuite/g++/../../ /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C -nostdinc++ -I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/include/powerpc-apple-darwin9 -I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/include -I/opt/gcc/gcc-4.6-work/libstdc++-v3/libsupc++ -I/opt/gcc/gcc-4.6-work/libstdc++-v3/include/backward -I/opt/gcc/gcc-4.6-work/libstdc++-v3/testsuite/util -fmessage-length=0 -O0 -O2 -fdump-tree-optimized -fdump-ipa-tree_profile_ipa -fprofile-use -L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src/.libs -B/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src/.libs -L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src/.libs -L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libiberty -multiply_defined suppress -lm -m64 -o /opt/gcc/darwin_buildw/gcc/testsuite/g++/indir-call-prof.x12(timeout = 300) /var/tmp//ccMopaCO.s:6:FATAL:symbol: __ZN1A2AAEv can't be a weak_definition (currently only supported in section of type coalesced) compiler exited with status 1 Executing on host: /opt/gcc/darwin_buildw/gcc/testsuite/g++/../../g++ -B/opt/gcc/darwin_buildw/gcc/testsuite/g++/../../ /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/tree-prof/inline_mismatch_args.C -nostdinc++ -I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/include/powerpc-apple-darwin9 -I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/include -I/opt/gcc/gcc-4.6-work/libstdc++-v3/libsupc++ -I/opt/gcc/gcc-4.6-work/libstdc++-v3/include/backward -I/opt/gcc/gcc-4.6-work/libstdc++-v3/testsuite/util -fmessage-length=0 -g -O2 -fdump-tree-einline -fprofile-use -L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src/.libs
[Bug lto/46905] New: -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 Summary: -flto -fno-lto does not disable lto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org gcc -flto -fno-lto hello.c generates LTO objects. It should not. In large makefiles it's often convenient to use -fno... to disable something for only specific files.
[Bug fortran/31821] character pointer = target(range) should detect if lengths don't match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-12 13:58:15 UTC --- Created attachment 22724 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22724 patch which causes regressions
[Bug target/46179] Codegen/TLS: invalid assembler syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46179 --- Comment #11 from Andreas Schwab schwab at gcc dot gnu.org 2010-12-12 14:03:59 UTC --- Author: schwab Date: Sun Dec 12 14:03:55 2010 New Revision: 167724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167724 Log: Author: Finn Thain fth...@telegraphics.com.au PR target/46179 * gcc/config/m68k/m68k.c (handle_move_double): Insert calls to m68k_final_prescan_insn to clean up @TLS operand syntax. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c
[Bug target/46179] Codegen/TLS: invalid assembler syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46179 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #12 from Andreas Schwab sch...@linux-m68k.org 2010-12-12 14:08:48 UTC --- Fixed.
[Bug fortran/31821] character pointer = target(range) should detect if lengths don't match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-12 14:09:12 UTC --- The patch in comment#7 causes a regression in program gfcbug33 character(12) :: a(2) a(1) = abcdefghijkl a(2) = mnopqrstuvwx call foo ((a(2:1:-1)(6:))) contains subroutine foo (chr) character(7) :: chr(:) print *,'X',chr(1),'Y' print *,'A',chr(2),'B' if (chr(1)//chr(2) .ne. rstuvwxfghijkl) call abort () end subroutine foo end program gfcbug33 i...@linux-fd1f:~/Krempel/Char gfortran short_1.f90 i...@linux-fd1f:~/Krempel/Char ./a.out XrstuvwxY A%�2�fgB Abgebrochen which is a shortened version of actual_array_substr_1.f90. The part of the patch - if (substring) - primary-ts.u.cl = NULL; - opens a can of worms of wrong-code and rejects-valid bugs...
[Bug lto/46905] -flto -fno-lto does not disable lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905 --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2010-12-12 14:19:00 UTC --- Same bug seems to be in the code generating phase gcc -O2 -flto -fno-lto object.o does code generation even if object.o has fallback code
[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org 2010-12-12 14:58:18 UTC --- Created attachment 22725 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22725 Starting point patch This passes gfortran.dg/*transpose*
[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org 2010-12-12 15:04:03 UTC --- For the cases to be discarded from optimization, the patch above reuses pr44582's code blindly, hoping it's correct.
[Bug libstdc++/46906] New: istreambuf_iterator is late?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
Summary: istreambuf_iterator is late?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
The following program prints:
11
12
32
With some other libraries I get 11 22 33 (but libstdc++ is not the only one
that outputs 11 12 32).
As far as I understand the standard, operator++ and operator* should just call
sbumpc and sgetc on the underlying streambuf, which happens to be the same for
the two iterators. It looks like the iterator caches the result somehow. Am I
missing some provision for this in the standard?
#include ios
#include istream
#include sstream
#include iostream
using namespace std;
int main(){
istringstream s(1234);
istreambuf_iteratorchar i1(s);
istreambuf_iteratorchar i2(i1);
std::cerr *i1 *i2 '\n';
++i2;
std::cerr *i1 *i2 '\n';
++i1;
std::cerr *i1 *i2 '\n';
}
[Bug c/46907] New: printf width not properly working for negative numbers which are variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46907
Summary: printf width not properly working for negative numbers
which are variables
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adrian.hawry...@gmail.com
Host: Windows XP SP2
Target: mingw32
Build: 4.5.0
#include stdio.h
#include math.h
int main()
{
char a = 0x7f;
printf(%02x , 0x80);
printf(%02x , (char)0x80);
printf(%02x , a + 1);
printf(%02x , ++a);
printf(%02x , a);
return 0;
}
Result:
80 ff80 80 ff80 ff80
Given this test, it looks like it might have to do with promotion to an int (or
is it long?), which is fine, except that I used the width to stop this problem
from happening. Looks sketchy.
C:\gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)
--
A
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #45 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 15:54:16 UTC --- Since init_priority is global, I will work on binutils to allow mixing .ctors and .init_array.
[Bug c/46908] New: printf not handling printing of double correctly in certain cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908
Summary: printf not handling printing of double correctly in
certain cases
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adrian.hawry...@gmail.com
Host: Windows XP SP2
Target: mingw32
Build: 4.5.0
This is a weird one. Under different compile options, it does it wrong in
different ways. :)
#include stdio.h
#include math.h
void printld(long double* pld)
{
int i;
printf(*%p = , pld);
for (i = 0; i sizeof(long double); ++i) {
printf(%02x , ((unsigned char*)pld)[i]);
}
printf(\n);
}
int main()
{
long double number1 = 1.0;
long double number2 = 1.0;
printf (%lf, %lf\n, number1, number2);
printf (Enter number1: );
scanf (%lf, number1);
printf (Enter number2: );
scanf (%lf, number2);
printf (%lf, %lf\n, number1, number2);
printf (%lf, %lf\n, number1, number1);
printld(number1);
printld(number2);
return 0;
}
C:\tmpgcc -o tmp.exe file.c
C:\tmptmp
0.00, 0.00
Enter number1: 3
Enter number2: 4
3.00, 0.00
3.00, 0.00
*0022FF30 = 00 00 00 00 00 00 08 40 ff 3f 00 00
*0022FF20 = 00 00 00 00 00 00 10 40 ff 3f 00 00
C:\tmpgcc -std=c99 -o tmp.exe file.c
C:\tmptmp
1.00, 1.00
Enter number1: 3
Enter number2: 4
0.00, 0.00
0.00, 0.00
*0022ff30 = 00 00 00 00 00 00 08 40 ff 3f 00 00
*0022ff20 = 00 00 00 00 00 00 10 40 ff 3f 00 00
There was even a way of printing the same variable (number1) twice on a line
and it would output it twice. That is why I had put in:
printf (%lf, %lf\n, number1, number1);
as a test, but it didn't show up in this test code.
C:\tmpgcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)
--
A
[Bug middle-end/46909] New: [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909 Summary: [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com GCC 4.6 revision 167711 miscompiles elf32-i386.c and elf64-x86-64.c in binutils. I got FAIL: TLS descriptor -fpic -shared transitions FAIL: TLS with global dynamic and descriptors for both i386 and x86-64 TLS tests with error like: /export/build/gnu/binutils/build-x86_64-linux/ld/../binutils/objdump -drj.text tmpdir/libtlsdesc.so regexp_diff match failure regexp ^ [0-9a-f]+:81 c3 9a 13 00 00[ ]+add\$0x[0-9a-f]+,%ebx$ line2df:81 c3 ae 13 00 00add$0x13ae,%ebx regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 f8 ff ff ff[ ]+mov-0x8\(%ebx\),%eax$ line2f5:8b 83 f4 ff ff ffmov-0xc(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 c4 ff ff ff[ ]+mov-0x3c\(%ebx\),%eax$ line301:8b 83 bc ff ff ffmov-0x44(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 d4 ff ff ff[ ]+mov-0x2c\(%ebx\),%eax$ line30d:8b 83 cc ff ff ffmov-0x34(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 b0 ff ff ff[ ]+mov-0x50\(%ebx\),%eax$ line325:8b 83 a0 ff ff ffmov-0x60(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 b4 ff ff ff[ ]+mov-0x4c\(%ebx\),%eax$ line331:8b 83 a4 ff ff ffmov-0x5c(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 bc ff ff ff[ ]+mov-0x44\(%ebx\),%eax$ line33d:8b 83 ac ff ff ffmov-0x54(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 c8 ff ff ff[ ]+mov-0x38\(%ebx\),%eax$ line361:8b 83 c0 ff ff ffmov-0x40(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 e8 ff ff ff[ ]+mov-0x18\(%ebx\),%eax$ line36d:8b 83 e4 ff ff ffmov-0x1c(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 cc ff ff ff[ ]+mov-0x34\(%ebx\),%eax$ line385:8b 83 c4 ff ff ffmov-0x3c(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 ec ff ff ff[ ]+mov-0x14\(%ebx\),%eax$ line391:8b 83 e8 ff ff ffmov-0x18(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:8b 83 e0 ff ff ff[ ]+mov-0x20\(%ebx\),%eax$ line39d:8b 83 d8 ff ff ffmov-0x28(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:2b 8b f8 ff ff ff[ ]+sub-0x8\(%ebx\),%ecx$ line3f0:2b 8b f4 ff ff ffsub-0xc(%ebx),%ecx regexp_diff match failure regexp ^ [0-9a-f]+:2b 83 d0 ff ff ff[ ]+sub-0x30\(%ebx\),%eax$ line402:2b 83 c8 ff ff ffsub-0x38(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:03 8b c4 ff ff ff[ ]+add-0x3c\(%ebx\),%ecx$ line415:03 8b bc ff ff ffadd-0x44(%ebx),%ecx regexp_diff match failure regexp ^ [0-9a-f]+:03 83 d4 ff ff ff[ ]+add-0x2c\(%ebx\),%eax$ line427:03 83 cc ff ff ffadd-0x34(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:2b 8b b0 ff ff ff[ ]+sub-0x50\(%ebx\),%ecx$ line43a:2b 8b a0 ff ff ffsub-0x60(%ebx),%ecx regexp_diff match failure regexp ^ [0-9a-f]+:2b 83 b8 ff ff ff[ ]+sub-0x48\(%ebx\),%eax$ line44c:2b 83 a8 ff ff ffsub-0x58(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:03 8b b4 ff ff ff[ ]+add-0x4c\(%ebx\),%ecx$ line45f:03 8b a4 ff ff ffadd-0x5c(%ebx),%ecx regexp_diff match failure regexp ^ [0-9a-f]+:03 83 bc ff ff ff[ ]+add-0x44\(%ebx\),%eax$ line471:03 83 ac ff ff ffadd-0x54(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:2b 83 e4 ff ff ff[ ]+sub-0x1c\(%ebx\),%eax$ line496:2b 83 e0 ff ff ffsub-0x20(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:03 8b c8 ff ff ff[ ]+add-0x38\(%ebx\),%ecx$ line4a9:03 8b c0 ff ff ffadd-0x40(%ebx),%ecx regexp_diff match failure regexp ^ [0-9a-f]+:03 83 e8 ff ff ff[ ]+add-0x18\(%ebx\),%eax$ line4bb:03 83 e4 ff ff ffadd-0x1c(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:2b 8b cc ff ff ff[ ]+sub-0x34\(%ebx\),%ecx$ line4ce:2b 8b c4 ff ff ffsub-0x3c(%ebx),%ecx regexp_diff match failure regexp ^ [0-9a-f]+:2b 83 dc ff ff ff[ ]+sub-0x24\(%ebx\),%eax$ line4e0:2b 83 d4 ff ff ffsub-0x2c(%ebx),%eax regexp_diff match failure regexp ^ [0-9a-f]+:03 8b ec ff ff ff[ ]+add-0x14\(%ebx\),%ecx$
[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-12
16:37:48 UTC ---
The patch in comment #5 fixes this PR, but the tests in pr41278, pr44912, and
the variant below of pr40646 yields ICEs:
in proc_call_can_redefine_sym, at fortran/trans-expr.c:5411 for (variant of
pr40646 and pr44912)
or pr41278.f90:10:0: internal compiler error: Segmentation fault.
! { dg-do run }
!
! PR 40646
!
! array-valued PPCs
!
! Original test case by Charlie Sharpsteen ch...@sharpsteen.net
! Modified by Janus Weil ja...@gcc.gnu.org
module bugTestMod
implicit none
type:: boundTest
procedure(returnMat), pointer, nopass:: test
end type boundTest
contains
function returnMat( a, b ) result( mat )
integer:: a, b
double precision, dimension(a,b):: mat
mat = 1d0
end function returnMat
end module bugTestMod
program bugTest
use bugTestMod
implicit none
type( boundTest ):: testObj
double precision, dimension(2,2):: testCatch
testObj%test = returnMat
testCatch = testObj%test(2,2)
print *,testCatch
if (sum(testCatch)/=4) call abort()
end program bugTest
! { dg-final { cleanup-modules bugTestMod } }
[Bug c/46907] printf width not properly working for negative numbers which are variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46907 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-12-12 16:48:42 UTC --- The width in the format string is a minimum width.
[Bug libstdc++/46910] New: std::shared_ptr requires public destructor for a class with friend deleter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46910
Summary: std::shared_ptr requires public destructor for a class
with friend deleter
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gccbugzi...@virginmedia.com
Created attachment 22726
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22726
Code example and compiler output
class TestA
{
public:
static std::shared_ptrTestA CreateTestA();
private:
TestA();
~TestA();
private:
class Deleter;
friend class Deleter;
};
class TestA::Deleter
{
public:
void operator()( TestA * p)
{
std::cout Deleting TestA\n;
delete p;
}
};
std::shared_ptrTestA TestA::CreateTestA()
{
return std::shared_ptrTestA(
new TestA(),
TestA::Deleter()
);
}
will not compile:
error: ‘TestA::~TestA()’ is private
The boost shared_ptr works OK.
[Bug c/46908] printf not handling printing of double correctly in certain cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-12-12 16:51:28 UTC --- l has no effect on %f.
[Bug libstdc++/46910] std::shared_ptr requires public destructor for a class with friend deleter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46910 --- Comment #1 from Sam gccbugzilla at virginmedia dot com 2010-12-12 16:54:01 UTC --- gcc 4.5.1 and test code built on Linux 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux
[Bug lto/46911] New: [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46911 Summary: [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu - testcase.f - common/main1/ eps(2) call dalie6s(iqmod6,1,wx,cor6d) end -- reduced from gfortran.dg/lto/20091015-1_2.f Compiler output: $ gfortran -O -finline-small-functions -flto -g testcase.f -r -nostdlib ==5279== Invalid read of size 2 ==5279==at 0x5C75BC: add_name_and_src_coords_attributes (dwarf2out.c:17792) ==5279==by 0x5D8104: gen_variable_die (dwarf2out.c:19400) ==5279==by 0x5DCF14: gen_decl_die (dwarf2out.c:20981) ==5279==by 0x5DA34A: decls_for_scope (dwarf2out.c:20555) ==5279==by 0x5DF38B: gen_block_die (dwarf2out.c:19669) ==5279==by 0x5DA37D: decls_for_scope (dwarf2out.c:20567) ==5279==by 0x5DF582: gen_block_die (dwarf2out.c:19701) ==5279==by 0x5DA37D: decls_for_scope (dwarf2out.c:20567) ==5279==by 0x5DA8FF: gen_subprogram_die (dwarf2out.c:19277) ==5279==by 0x5DCDA2: gen_decl_die (dwarf2out.c:20914) ==5279==by 0x5E00E8: dwarf2out_function_decl (dwarf2out.c:21296) ==5279==by 0x638FCC: rest_of_handle_final (final.c:4286) ==5279==by 0x771ADE: execute_one_pass (passes.c:1553) ==5279==by 0x771DA4: execute_pass_list (passes.c:1608) ==5279==by 0x771DB6: execute_pass_list (passes.c:1609) ==5279==by 0x771DB6: execute_pass_list (passes.c:1609) ==5279==by 0x8B2605: tree_rest_of_compilation (tree-optimize.c:422) ==5279==by 0xA77EB1: cgraph_expand_function (cgraphunit.c:1508) ==5279==by 0xA7A489: cgraph_optimize (cgraphunit.c:1567) ==5279==by 0x4FF78E: lto_main (lto.c:2453) ==5279==by 0x85BDE7: toplev_main (toplev.c:579) ==5279==by 0x6369BBC: (below main) (in /lib64/libc-2.11.2.so) ==5279== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==5279== In file included from :0:0: testcase.f: In function 'main': testcase.f:3:0: 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. lto-wrapper: /mnt/svn/gcc-trunk/binary-167643-lto-fortran-checking-yes-rtl-df/bin/gfortran returned 1 exit status collect2: lto-wrapper returned 1 exit status Tested revisions: r167643 - crash r165699 - crash r161659 - OK 4.5 r166509 - OK
[Bug c/46908] printf not handling printing of double correctly in certain cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2010-12-12 17:32:26 UTC --- Use -Wall: test.c:18: warning: format ‘%f’ expects type ‘double’, but argument 2 has type ‘long double’ which means that %f is not for long double, you should use %Lf and it will work.
[Bug libstdc++/46910] std::shared_ptr requires public destructor for a class with friend deleter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46910 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 17:35:21 UTC --- Jon, can you have a look?
[Bug libstdc++/46906] istreambuf_iterator is late?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 17:38:10 UTC --- Yes, this is an old issue, as you noticed already other implementations also decided that performance issue may take precedence here. After so many years with this scheme, I honestly don't think we want to change this before breaking the ABI.
[Bug middle-end/46909] [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||sandra at codesourcery dot ||com Target Milestone|--- |4.6.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 17:44:39 UTC --- It is caused by revision 160445: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00359.html
[Bug testsuite/46912] New: [4.6 Regression] Test failures for g++.dg/plugin/*plugin*.C on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46912 Summary: [4.6 Regression] Test failures for g++.dg/plugin/*plugin*.C on powerpc-apple-darwin9 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org On powerpc-apple-darwin9 , between revisions 166301 and 166355 (see http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00318.html http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00432.html ) the following failures appeared: FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line ) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 7) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 7) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 16) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for excess errors) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line ) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 5) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 9) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 14) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 10) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 14) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 18) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 19) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 24) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 50) FAIL: g++.dg/plugin/dumb-plugin-test-1.C -fplugin=./dumb_plugin.so (test for warnings, line 50) FAIL: g++.dg/tree-prof/indir-call-prof.C compilation, -g -fprofile-use From the log file, the errors are output is: /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/attribute_plugin-test-1.C:4:55: warning: 'user' attribute directive ignored [-Wattributes] /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/attribute_plugin-test-1.C:5:63: warning: 'user' attribute directive ignored [-Wattributes] /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/attribute_plugin-test-1.C:11:52: warning: 'user' attribute directive ignored [-Wattributes] FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line ) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 7) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 7) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for warnings, line 16) FAIL: g++.dg/plugin/attribute_plugin-test-1.C -fplugin=./attribute_plugin.so (test for excess errors) Excess errors: /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/attribute_plugin-test-1.C:4:55: warning: 'user' attribute directive ignored [-Wattributes] /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/attribute_plugin-test-1.C:5:63: warning: 'user' attribute directive ignored [-Wattributes] /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/attribute_plugin-test-1.C:11:52: warning: 'user' attribute directive ignored [-Wattributes] no output FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line ) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 5) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 9) FAIL: g++.dg/plugin/pragma_plugin-test-1.C -fplugin=./pragma_plugin.so (test for warnings, line 14) output is: /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/dumb-plugin-test-1.C: In function 'void __static_initialization_and_destruction_0(int, int)': /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/dumb-plugin-test-1.C:50:1: warning: Analyze function __static_initialization_and_destruction_0 [enabled by default] /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/dumb-plugin-test-1.C: In constructor 'Foo::Foo()': /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/dumb-plugin-test-1.C:50:1: warning: Analyze function __comp_ctor [enabled by default] /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/dumb-plugin-test-1.C: In member function 'void Foo::setA(int)': /opt/gcc/gcc-4.6-work/gcc/testsuite/g++.dg/plugin/dumb-plugin-test-1.C:50:1: warning: Analyze function
[Bug libstdc++/46906] istreambuf_iterator is late?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906 --- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2010-12-12 18:01:41 UTC --- (In reply to comment #1) Yes, this is an old issue, Oups, sorry, I am not very good at finding old issues in bugzilla... as you noticed already other implementations also decided that performance issue may take precedence here. After so many years with this scheme, I honestly don't think we want to change this before breaking the ABI. Ok, part of my bugreport was to get confirmation that it was indeed a bug (streams can be confusing at times). I understand from your comment that you intend to fix it when the ABI is broken for C++0x, which is good enough for me. Thanks.
[Bug libstdc++/46910] std::shared_ptr requires public destructor for a class with friend deleter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46910 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.12 18:09:59 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-12 18:09:59 UTC --- Created attachment 22727 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22727 do not derive Sp_counted_deleter from Sp_counted_ptr The problem is that the Sp_counted_deleter class inherits from Sp_counted_ptr so even though Sp_counter_ptr::_M_dispose is never called, it does get instantiated. I'm testing this patch
[Bug middle-end/46909] [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 18:12:47 UTC --- elf64_x86_64_allocate_dynrelocs and elf64_x86_64_size_dynamic_sections are miscompiled.
[Bug libstdc++/46906] istreambuf_iterator is late?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 18:28:02 UTC --- To be clear: I remember discussing this issue with Nathan many years ago, when we noticed that variance among implementations, and that we considered more strictly conforming not buffering anything (but also much worse perfoming in many normal circumstances). But now I don't have a final word on that, should at least collect my old notes. As I mentioned already, anyway, even if we wanted to do the change now, it would risk breaking compatibility or leaving the _M_c member unused or other ugly options. Definitely something to be re-evaluated when the ABI is broken.
[Bug testsuite/46913] New: send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913
Summary: send_log $first != $second\n in gdb-test fails when
$first starts with '-'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
Executing on host: /home/dave/gnu/gcc-4.6/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.6/objdir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/nrv-1.c
-O2
-flto -flto-partition=none -g -fno-tree-sra -lm -o ./nrv-1.exe(timeout
= 300)spawn /home/dave/gnu/gcc-4.6/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4.6/objdir/gcc
/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/nrv-1.c -O2 -flto
-flto-pa
rtition=none -g -fno-tree-sra -lm -o ./nrv-1.exe
PASS: gcc.dg/guality/nrv-1.c -O2 -flto -flto-partition=none (test for excess
e
rrors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc::/home/dave/gnu/gcc/ob
jdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src/.libs:/home/dave/
gnu/gcc/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/
libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/g
cc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
spawn [open ...]
PASS: gcc.dg/guality/nrv-1.c -O2 -flto -flto-partition=none execution test
Spawning: gdb -nx -nw -quiet -x nrv-1.gdb ./nrv-1.exe
spawn gdb -nx -nw -quiet -x nrv-1.gdb ./nrv-1.exe
Reading symbols from
/home/dave/gnu/gcc-4.6/objdir/gcc/testsuite/gcc/nrv-1.exe..
.done.
Breakpoint 1 at 0x10558: file
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/gualit
y/nrv-1.c, line 20.
Breakpoint 1, f ()
at /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/guality/nrv-1.c:20
20a2.i[4] = 7; /* { dg-final { gdb-test 20 a2.i\[0\] 42 } } */
$1 = -1093315243
$2 = 42
A debugging session is active.
Inferior 1 [process 8290] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
ERROR OCCURED: usage: send [args] string
while executing
send_log $first != $second\n
invoked from within
expect {
-i exp7 -timeout 300
-re {[\n\r]\$1 = ([^\n\r]*)[\n\r]+\$2 = ([^\n\r]*)[\n\r]} {
set first $expect_out(1,string)
set second $expe...
(uplevel body line 1)
invoked from withinuplevel $body TCL LOOKUP INDEX flag {-1093315243 != 42
} usage: send [args] stringUNSUPPORTED: gcc.dg/guality/nrv-1.c -O2 -flto
-flto-partition=none line 20 a2.i[0] == 42
Note that this appears to also cause a test timeout (UNSUPPORTD output).
I think we need to use send_log -- $first != $second\n in the script.
See http://sourceware.org/bugzilla/show_bug.cgi?id=9737.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #46 from Mark Mitchell mark at codesourcery dot com 2010-12-12 18:40:35 UTC --- On 12/11/2010 4:32 PM, hjl.tools at gmail dot com wrote: Mark, I may have misunderstood you. Correct me if I am wrong. Currently, it may be possible to interleave constructors between different object files by examing .ctors section names and passing object files in specific order to linker. It is possible. The linker sorts the section names, so a higher priority constructor always runs before a lower priority constructor, independent of object file order. You may also be able to play games with object file order to control the order of constructors with the same priority, but we don't document that anywhere, as far as I know. But we can't do it between .init_array and .crors sections. Correct, we do not at present do that. That's the problem I'm raising with switching to .init_array. If you do that, and someone links in old object code using .ctors, we may run a low-priority .ctors constructor after a high-priority .init_array constructor, or we may run a low-priority .init_array constructor after a low-priority .ctors constructor. Either outcome would be a bug; we would break semantics. My opinion is that we can't switch to .init_array unless we either (a) make the linker detect the problem and fix it, or (b) at least make the linker detect the problem and issue an *error*. I do not think a warning is sufficient.
[Bug libstdc++/46910] std::shared_ptr requires public destructor for a class with friend deleter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46910 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|jwakely.gcc at gmail dot| |com | --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 19:19:02 UTC --- Many thanks!
[Bug middle-end/46909] [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2010.12.12 19:22:15
Ever Confirmed|0 |1
Severity|normal |blocker
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 19:22:15
UTC ---
[...@gnu-6 tmp]$ cat y.c
extern void abort ();
struct entry
{
unsigned char tls_type;
} h;
int
__attribute__ ((__noinline__))
foo (struct entry *h)
{
int tls_type = h-tls_type;
if (! ((tls_type) == 4 || ((tls_type) == (2 | 4)))
|| ((tls_type) == 2 || ((tls_type) == (2 | 4
return 1;
return -1;
}
int
main ()
{
struct entry h;
h.tls_type = 6;
if (foo (h) != 1)
abort ();
return 0;
}
[...@gnu-6 tmp]$ /usr/gcc-4.6/bin/gcc -O2 y.c
[...@gnu-6 tmp]$ ./a.out
Aborted
[...@gnu-6 tmp]$ gcc -O2 y.c
[...@gnu-6 tmp]$ ./a.out
[...@gnu-6 tmp]$
[Bug middle-end/46909] [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 19:27:08
UTC ---
Smaller one:
[...@gnu-6 tmp]$ cat y.c
extern void abort ();
int
__attribute__ ((__noinline__))
foo (unsigned int tls_type)
{
if (! (tls_type == 4 || (tls_type == 6))
|| (tls_type == 2 || (tls_type == 6)))
return 1;
return -1;
}
int
main ()
{
if (foo (6) != 1)
abort ();
return 0;
}
[...@gnu-6 tmp]$ /usr/gcc-4.6/bin/gcc -O2 y.c
[...@gnu-6 tmp]$ ./a.out
Aborted
[...@gnu-6 tmp]$
[Bug middle-end/46909] [4.6 Regression] elf32-i386.c and elf64-x86-64.c in binutils are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-12 19:30:36 UTC --- I'll look at it tomorrow.
[Bug middle-end/45388] [4.6 Regression] Global constructor not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12 19:54:28 UTC --- Mine, patch sent http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00961.html Sorry about the delay. The problem is not that I would not want constructors to be global. The problem was that since the original constructor merging was introduced (in 2004), C++ FE produced collect2 recognizable names for no reason. This problem was masked by fact that the code set always inline flag on all functions. This is wrong, since not all functions are inlinable so it can lead to ICE when non-inlinable static constructor is introduced. The patch should avoid those recognizable names until final merging pass and thus avoid the problem. Honza
[Bug libstdc++/46914] New: std::atomicint*::exchange(...) doesn't store correct value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46914
Summary: std::atomicint*::exchange(...) doesn't store correct
value.
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frts...@hotmail.com
Run the following to compile the program below.
$ g++ -std=c++0x ./test.cpp -o test.tsk
//test.cpp
#include iostream
#include stdatomic.h
int main(int argc, char **argv)
{
int *a = new int(10);
std::cout a = a *a = *a std::endl;
std::atomicint* x(a);
int *ptr = x;
std::cout ptr = ptr *ptr *ptr std::endl;
int *b = new int(11);
std::cout b = b *b = *b std::endl;
std::cout x.exchange(b) = x.exchange(b) std::endl;
ptr = x;
std::cout ptr = ptr *ptr *ptr std::endl;
int *c = new int(12);
std::cout c = c *c = *c std::endl;
std::cout x.exchange(c) = x.exchange(c) std::endl;
ptr = x;
std::cout ptr = ptr *ptr *ptr std::endl;
return 0;
}
$ g++ --version
g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It runs and gives the following result.
./test.tsk
a = 0x9b9c008 *a = 10
ptr = 0x9b9c008 *ptr 10
b = 0x9b9c018 *b = 11
x.exchange(b) = 0x9b9c008
ptr = 0x1ec71b *ptr -388381823
c = 0x9b9c028 *c = 12
x.exchange(c) = 0x1ec71b
ptr = 0x1ec71b *ptr -388381823
After x is initialized with a, it doesn't store the new value correctly in
its exchange member function.
[Bug testsuite/46913] send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-12 20:03:31 UTC --- So post a patch to gcc-patches?
[Bug testsuite/46913] send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2010-12-12 20:10:51 UTC --- So post a patch to gcc-patches? Will do when I complete testing on the system where I see the problem. It currently doing a full check that I don't want to mess up. There is some expect/tcl version dependency. Dave
[Bug libstdc++/46914] std::atomicint*::exchange(...) doesn't store correct value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46914 --- Comment #1 from Francis frtsang at hotmail dot com 2010-12-12 20:15:04 UTC --- Forget to mention my system type $ uname -a Linux my_mach_name 2.6.32-26-generic #48-Ubuntu SMP Wed Nov 24 09:00:03 UTC 2010 i686 GNU/Linux
[Bug testsuite/46913] send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-12 20:18:59 UTC --- If it doesn't work on some expect or tcl or dejagnu versions, the alternative would be send_log actual $first != expected $second\n
[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12 20:38:21 UTC --- I commited the fix, could you confirm if the bug is gone now?
[Bug fortran/46896] [4.2/4.3/4.4/4.5/4.6 Regression] Wrong code with transpose(a) passed to subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-12-12 20:47:48 UTC --- Not surprisingly with the patch in comment #5 I get the following regressions: FAIL: gfortran.dg/array_function_5.f90 * (internal compiler error) FAIL: gfortran.dg/proc_ptr_comp_9.f90 * (internal compiler error) FAIL: gfortran.dg/proc_ptr_comp_12.f90 * (internal compiler error) The backtrace for gfortran.dg/array_function_5.f90 is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0028 proc_call_can_redefine_sym (proc=0x14191f000) at ../../work/gcc/fortran/trans-expr.c:5409 5409 gfc_symbol *sym = expr-symtree-n.sym; (gdb) bt #0 proc_call_can_redefine_sym (proc=0x14191f000) at ../../work/gcc/fortran/trans-expr.c:5409 #1 0x0001000da15e in gfc_conv_procedure_call (se=0x7fff5fbfd500, sym=0x14191f000, args=0x1419182b0, expr=0x1419181f0, append_args=0x141f1f380) at ../../work/gcc/fortran/trans-expr.c:3114 Previous frame inner to this frame (gdb could not unwind past this frame)
[Bug c++/42033] libstdc++ seems to miss std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_stringchar*(char*, char*, std::allocatorchar const)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42033 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12 20:47:42 UTC --- It no longer reproduce to me. Hope the problem didn't just get latent again, but I guess it was fixed as part of numberous fixes to handling COMDATs and LTO/whole-program privatizing in last few months. Honza
[Bug libstdc++/46914] std::atomicint*::exchange(...) doesn't store correct value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46914 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-12 20:51:40 UTC --- I cannot reproduce this on anything from current 4.4 branch to mainline (with atomic). I get: a = 0x603010 *a = 10 ptr = 0x603010 *ptr 10 b = 0x603030 *b = 11 x.exchange(b) = 0x603010 ptr = 0x603030 *ptr 11 c = 0x603050 *c = 12 x.exchange(c) = 0x603030 ptr = 0x603050 *ptr 12
[Bug target/46276] cppbuiltin.c:154:7: error: 'or' of unmatched not-equal tests is always 1 [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46276 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2010-12-12 20:59:43 UTC --- Fixed when the dupe PR46456 was fixed.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.12 20:59:48 CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12 20:59:48 UTC --- I reproduce same issue on gcc14, too. This seems like previously semi-latent problem. One can definitly declare main into text.startup by hand. H.J., do you have any idea how to fix/work around this? Steve: HPUX is not using function sections, so it is probably unrelated issue. Honza
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-12 21:02:55 UTC --- it is undefined at compile time? No, it is undefined at runtime. This again is not an undefined behavior at compile time but rather at runtime. What that means is the behavior cannot be diagnosed (at least by the C standard definitions) at compile time and has to compile. There is no undefined at compile time behavior here, only at runtime.
[Bug fortran/46809] [OOP] ICE with -fcheck=pointer for CLASS IS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809 --- Comment #6 from janus at gcc dot gnu.org 2010-12-12 21:14:16 UTC --- Author: janus Date: Sun Dec 12 21:14:13 2010 New Revision: 167731 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167731 Log: 2010-12-12 Janus Weil ja...@gcc.gnu.org PR fortran/46809 * resolve.c (resolve_select_type): Set the location of the first argument when generating the EXTENDS_TYPE_OF call. 2010-12-12 Janus Weil ja...@gcc.gnu.org PR fortran/46809 * gfortran.dg/pointer_check_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_check_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/46913] send_log $first != $second\n in gdb-test fails when $first starts with '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2010-12-12 21:14:37 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46913 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-12-12 20:18:59 UTC --- If it doesn't work on some expect or tcl or dejagnu versions, the alternative would be send_log actual $first != expected $second\n Which do you prefer? It's not easy to test multiple versions. What I know is the error only occurs with certain versions. Dave
[Bug middle-end/46909] [4.6 Regression] Logical OR expressions are miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46909 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 21:29:08 UTC --- Bad patch was posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg1.html
[Bug fortran/46809] [OOP] ICE with -fcheck=pointer for CLASS IS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46809 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from janus at gcc dot gnu.org 2010-12-12 21:30:34 UTC --- Fixed with r167731. Closing.
[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46790 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-12-12 21:31:57 UTC --- There are some gc-sections bug fixes since binutils 2.18: Fix --gc-sections to detect unresolved symbol in DSO. PR 11218. Fix linker --gc-sections with undefined __start_XXX/__stop_XXX symbols. PR 11133. Fix linker --gc-sections with SHT_NOTE section. PR 11143. Fix ld -r --gc-sections --entry crash with COMDAT group. PR 9727. You can try the Linux binutils from http://www.kernel.org/pub/linux/devel/binutils/ to narrow down which binutils fixes it.
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
--- Comment #7 from Eskil Steenberg eskil at obsession dot se 2010-12-12
21:46:18 UTC ---
Hi
No, it is undefined at runtime. This again is not an undefined behavior
at
compile time but rather at runtime. What that means is the behavior
cannot be
diagnosed (at least by the C standard definitions) at compile time and has
to
compile. There is no undefined at compile time behavior here, only at
runtime.
Well the compiler does make assumptions about what the runtime will do.
Have a look at this function:
void my_func(unsigned short a, unsigned short b)
{
unsigned int c;
c = a * b;
printf(c = %u\n, c);
if(f 30) /* 3 billion */
printf(foo bar\n);
}
using gcc you can get the output (with the input , and ):
c = 4294836225
foo bar
This output should not be possible and will be very confusing to the user
(it was to me). My (limited) reading of the C spec should not support this
even though i understand why it happens.
At compile time the compiler decides that c can never be larger then max
singned int, and therefor it thinks that it can optimize away the if
statement.
Cheers
E
PS sorry I dont have a compiler on this machine so excuse any typos.
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-12 21:52:40 UTC --- This output should not be possible No, it is possible because the value is undefined so both the if being false and the printout happening can happen.
[Bug fortran/46897] [OOP] Polymorphic type - defined ASSIGNMENT(=) not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897 --- Comment #1 from janus at gcc dot gnu.org 2010-12-12 22:15:30 UTC --- Here is a slightly reduced test case: module m implicit none type component contains procedure :: assign generic :: assignment(=)=assign end type type t type(component) :: foo end type contains subroutine assign(lhs,rhs) class(component), intent(out) :: lhs class(component), intent(in) :: rhs print *,'defined assignment called' end subroutine end module program main use m implicit none type(t) :: infant, newchild infant = newchild end
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #9 from Eskil Steenberg eskil at obsession dot se 2010-12-12 22:23:36 UTC --- Hi No, it is possible because the value is undefined so both the if being false and the printout happening can happen. But undefined still means that the variable c has a value, just not something that cant be determined at compile time. The value c is not undefined, just the operation that produces the value stored in c. Therefor anything the variable c touches shouldn't become undefined too. If i give someone the number 9 and tell them to do a square root of it, they should produce a 3 even if I dont define where I got the number 9. if they go ahead and produce the value 4, I'm going to say that they are wrong, and not buy the argument Since you dont define where you got the number, I'm going to assume you really meent 16 and not 9. I really dislike the idea that something can be undefined, and at the same time the compiler can make assumptions about what it can be. pick one. Cheers E
[Bug fortran/46897] defined ASSIGNMENT(=) not used for derived type component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] Polymorphic type -|defined ASSIGNMENT(=) not |defined ASSIGNMENT(=) not |used for derived type |used|component --- Comment #2 from janus at gcc dot gnu.org 2010-12-12 22:25:52 UTC --- I think one can run into the same problem already without polymorphism: module m implicit none type component end type interface assignment(=) module procedure assign end interface type t type(component) :: foo end type contains subroutine assign(lhs,rhs) type(component), intent(out) :: lhs type(component), intent(in) :: rhs print *,'defined assignment called' end subroutine end module program main use m implicit none type(t) :: infant, newchild infant = newchild end
[Bug target/46915] New: Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915
Summary: Wrong code is generated for conditional branch
followed by zero length asm
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa*-*-*
Target: hppa*-*-*
Build: hppa*-*-*
Created attachment 22728
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22728
Preprocessed source
With gcc 4.4 and current head, we generate incorrect code for the function
add_to_swap at -O2:
int add_to_swap(struct page *page)
{
swp_entry_t entry;
int err;
do { (void)(!PageLocked(page)); } while (0);
do { (void)(!PageUptodate(page)); } while (0);
entry = get_swap_page();
...
PageUptodate is:
static inline __attribute__((always_inline)) int PageUptodate(struct page
*page)
{
int ret = test_bit(PG_uptodate, (page)-flags);
# 297 include/linux/page-flags.h
if (ret)
__asm__ __volatile__(:::memory);
return ret;
}
The generated RTL is:
(jump_insn 13 10 14 (set (pc)
(if_then_else (eq (zero_extract:SI (reg:SI 28 %r28 [orig:100 D.22506 ]
[
100])
(const_int 1 [0x1])
(const_int 28 [0x1c]))
(const_int 0 [0]))
(label_ref 16)
(pc))) include/linux/page-flags.h:297 29 {*pa.md:1610}
(expr_list:REG_BR_PRED (const_int 5 [0x5])
(expr_list:REG_DEAD (reg:SI 28 %r28 [orig:100 D.22506 ] [100])
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil
- 16)
(note 14 13 15 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn:TI 15 14 16 (parallel [
(asm_operands/v () () 0 []
[]
[] mm/swap_state.c:185)
(clobber (mem:BLK (scratch) [0 A8]))
]) include/linux/page-flags.h:298 -1
(nil))
(code_label 16 15 17 15 [1 uses])
(note 17 16 19 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 19 17 107 NOTE_INSN_DELETED)
(insn 107 19 122 (sequence [
(call_insn:TI 18 19 4 (parallel [
(set (reg:SI 28 %r28)
(call (mem:SI (symbol_ref/v:SI (@get_swap_page)
[f
lags 0x41] function_decl 0x40ae6280 get_swap_page) [0 S4 A32])
...
This results in the following assembler:
globl add_to_swap
.type add_to_swap, @function
add_to_swap:
.PROC
.CALLINFO FRAME=64,CALLS,SAVE_RP,ENTRY_GR=5
.ENTRY
stw %r2,-20(%r30)
stwm %r5,64(%r30)
stw %r3,-56(%r30)
copy %r26,%r3
stw %r4,-60(%r30)
ldw 0(%r26),%r28
ldw 0(%r26),%r28
bb,=,n %r28,28,.L15
.L15:
bl get_swap_page,%r2
ldi 0,%r4
As can be seen, the bb instruction branches to its delay slot. This
is not handled by the hardware.
The asm confuses the branch code generation.
[Bug c/46908] printf not handling printing of double correctly in certain cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908
Adrian Hawryluk adrian.hawryluk at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #3 from Adrian Hawryluk adrian.hawryluk at gmail dot com
2010-12-12 22:53:43 UTC ---
Sorry, changed to %Lf with same results.
#include stdio.h
#include math.h
void printld(long double* pld)
{
int i;
printf(*%p = , pld);
for (i = 0; i sizeof(long double); ++i) {
printf(%02x , ((unsigned char*)pld)[i]);
}
printf(\n);
}
int main()
{
long double number1 = 1.0;
long double number2 = 1.0;
printf (%Lf, %Lf\n, number1, number2);
printf (Enter number1: );
scanf ( %Lf, number1);
printf (Enter number2: );
scanf ( %Lf, number2);
printf (%Lf, %Lf\n, number1, number2);
printf (%Lf, %Lf\n, number1, number1);
printld(number1);
printld(number2);
return 0;
}
[Bug c/46908] printf not handling printing of double correctly in certain cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908 --- Comment #4 from Adrian Hawryluk adrian.hawryluk at gmail dot com 2010-12-12 22:55:47 UTC --- But found that L is not a known conversion type character. When is L supposed to be implemented? C:\tmpgcc -Wall -o tmp.exe file.c file.c: In function 'main': file.c:18:5: warning: unknown conversion type character 'L' in format file.c:18:5: warning: unknown conversion type character 'L' in format file.c:18:5: warning: too many arguments for format file.c:21:5: warning: unknown conversion type character 'L' in format file.c:21:5: warning: too many arguments for format file.c:23:5: warning: unknown conversion type character 'L' in format file.c:23:5: warning: too many arguments for format file.c:25:5: warning: unknown conversion type character 'L' in format file.c:25:5: warning: unknown conversion type character 'L' in format file.c:25:5: warning: too many arguments for format file.c:26:5: warning: unknown conversion type character 'L' in format file.c:26:5: warning: unknown conversion type character 'L' in format file.c:26:5: warning: too many arguments for format
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455 --- Comment #19 from Vincent Lefèvre vincent at vinc17 dot org 2010-12-12 23:02:58 UTC --- FYI, the problem has been handled in the MPFR trunk r7291 for MPFR 3.1.0. MPFR's configure script now retrieves the location of the GMP source from GMP's Makefile and adds the necessary -I... flags to CPPFLAGS. Note also that the behavior will be different from the one with MPFR 2.x. A side effect is that library versioning is not supported in this case (by that, I mean that a GMP upgrade without recompiling MPFR against the new GMP version may break things) because providing --with-gmp-build makes the MPFR build use GMP's internals, which may change without notice.
[Bug c/46908] printf not handling printing of double correctly in certain cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908 --- Comment #5 from Adrian Hawryluk adrian.hawryluk at gmail dot com 2010-12-12 23:08:58 UTC --- Used flag -std=c99 and this reduced the number of warnings. They were limited to the scanf format string. C:\tmpgcc -Wall -std=c99 -o tmp.exe file.c file.c: In function 'main': file.c:21:5: warning: unknown conversion type character 'L' in format file.c:21:5: warning: too many arguments for format file.c:23:5: warning: unknown conversion type character 'L' in format file.c:23:5: warning: too many arguments for format
[Bug middle-end/46916] New: gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler from profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916 Summary: gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler from profiledbootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu When gcc trunk is built with profiledbootstrap, the resulting compiler exhibits ICEs in... FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-1.c -O1 compilation failed to produce executable FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 (test for excess errors) WARNING: gcc.dg/torture/stackalign/non-local-goto-2.c -O1 compilation failed to produce executable These are of the form... /Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ /Users/howarth/gcc/gcc/testsuite/gcc.dg/torture/stackalign/non-local-goto-1.c -O1 -mstackrealign -mpreferred-stack-boundary=5 -mno-mmx -lm -m32 -o ./non-local-goto-1.exe xgcc: internal compiler error: Segmentation fault (program cc1) and backtrace as... Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x7fff5bc00fe0 0x000100829fa8 in htab_find_slot_with_hash (htab=0x143200af0, element=value temporarily unavailable, due to optimizations, hash=value temporarily unavailable, due to optimizations, insert=INSERT) at ../../gcc/libiberty/hashtab.c:668 668 else if ((*htab-eq_f) (entry, element)) (gdb) bt #0 0x000100829fa8 in htab_find_slot_with_hash (htab=0x143200af0, element=value temporarily unavailable, due to optimizations, hash=value temporarily unavailable, due to optimizations, insert=INSERT) at ../../gcc/libiberty/hashtab.c:668 #1 0x0001007bc701 in cgraph_node (decl=0x143304e00) at ../../gcc/gcc/cgraph.c:502 (gdb)
[Bug middle-end/46916] gcc.dg/torture/stackalign/non-local-goto-[1,2].c ICEs compiler from profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Target||x86_64-apple-darwin10 Host||x86_64-apple-darwin10 Build||x86_64-apple-darwin10 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-12 23:13:28 UTC --- Using built-in specs. COLLECT_GCC=/Users/howarth/dist/bin/gcc COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper Target: x86_64-apple-darwin10.5.0 Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-languages=c Thread model: posix gcc version 4.6.0 20101212 (experimental) (GCC)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12 23:52:52 UTC --- Current mainline crashes: Program received signal SIGSEGV, Segmentation fault. lto_cgraph_replace_node (slot=value optimized out, data=value optimized out) at ../../gcc/lto-symtab.c:227 227 if (prevailing_node-same_body_alias) (gdb) bt #0 lto_cgraph_replace_node (slot=value optimized out, data=value optimized out) at ../../gcc/lto-symtab.c:227 #1 lto_symtab_merge_cgraph_nodes_1 (slot=value optimized out, data=value optimized out) at ../../gcc/lto-symtab.c:798 #2 0x00b0ae08 in htab_traverse_noresize (htab=value optimized out, callback=0x60eca0 lto_symtab_merge_cgraph_nodes_1, info=0x0) at ../../libiberty/hashtab.c:784 #3 0x004aabf9 in read_cgraph_and_symbols () at ../../gcc/lto/lto.c:2213 #4 lto_main () at ../../gcc/lto/lto.c:2438 #5 0x006cb658 in compile_file (argc=2627, argv=0x11a7460) at ../../gcc/toplev.c:579 #6 do_compile (argc=2627, argv=0x11a7460) at ../../gcc/toplev.c:1874 #7 toplev_main (argc=2627, argv=0x11a7460) at ../../gcc/toplev.c:1937 #8 0x76597bc6 in __libc_start_main () from /lib64/libc.so.6 #9 0x00493411 in _start () at ../sysdeps/x86_64/elf/start.S:113 I guess it is fallout of the merging patch. It is weird since previaling_node is NULL. _moz_cairo_surface_destroy/567259(-1) @0x7ffebef47c60 (asm: _moz_cairo_surface_destroy) visibilit: 2 binds_local called by: CreateSimilarSurface/567227 (0.21 per call) CreateSimilarSurface/567227 (0.14 per call) Init/567225 (0.39 per call) _ZN11gfxASurface7ReleaseEv.part.2/567209 (1.00 per call) calls: References: Refering this function: $5 = void I also generated profile. samples %image name app name symbol name 228038 25.3225 lto1 lto1 htab_find_slot_with_hash 82588 9.1710 lto1 lto1 iterative_hash_hashval_t 58000 6.4406 lto1 lto1 type_pair_eq 32557 3.6153 lto1 lto1 gimple_lookup_type_leader 31622 3.5115 lto1 lto1 gtc_visit 29149 3.2369 lto1 lto1 htab_expand 27463 3.0496 lto1 lto1 gimple_type_hash_1 24348 2.7037 lto1 lto1 gimple_types_compatible_p 24217 2.6892 lto1 lto1 inflate_fast 21984 2.4412 lto1 lto1 gimple_types_compatible_p_1 21796 2.4203 libc-2.11.1.so libc-2.11.1.so memset 21700 2.4097 libc-2.11.1.so libc-2.11.1.so _int_malloc 17894 1.9870 lto1 lto1 lookup_type_pair.isra.120.constprop.129 16087 1.7864 lto1 lto1 ggc_set_mark 15719 1.7455 lto1 lto1 gt_ggc_mx_lang_tree_node Our abuse of hashing is making us slow. It is not only type merging but all the hashing during streaming in.
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12 23:55:24 UTC --- With -O2 during early optimization we get to 68% in cgraph_check_inline_limits. This is weird since early inliner should not be terribly sensitive to this. I guess it is because we end up walking very long edge lists. I will check if I can do something here. Honza
[Bug c/46899] compiler optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org 2010-12-13 00:21:09 UTC --- The execution of an undefined operation produces an undefined value, and any further operation becomes undefined.
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||dnovillo at google dot com --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13 00:58:04 UTC --- letting compilation to run longer I get: 3068656 60.0462 cc1 cc1 gsi_for_stmt 1211665 23.7093 cc1 cc1 cgraph_check_inline_limits 3965947.7604 cc1 cc1 gimple_set_bb 29937 0.5858 libc-2.11.1.so libc-2.11.1.so _IO_vfscanf 23409 0.4581 libc-2.11.1.so libc-2.11.1.so _int_malloc 14539 0.2845 cc1 cc1 gimple_split_block 13307 0.2604 libc-2.11.1.so libc-2.11.1.so memset 9532 0.1865 cc1 cc1 htab_delete 8275 0.1619 cc1 cc1 bitmap_set_bit so gsi_for_stmt nonlinearity kicks in. I guess it is the inliner calling BB split and that calling gsi_for_stmt. We probably can have gsi_split_bb with gsi argument too. I always wondered why Diego did not embed gimple_seq_node_d into gimple statment (we don't have too many statements that would not be living in basic blocks so it would not be wasteful and it would result in better locality walking the lists). In that case gsi_for_stmt would become O(1). Honza
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13 00:59:53 UTC --- ... actually split_bb does not use gsi_for_stmt since it has to walk all the statements in the BB anyway. It seems that it is one of routines updating callers from cgraph edges.
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13 01:07:33 UTC --- My profile was at -O2. Concerning Jakub's callgrind, the -O0 compilation finishes in about 44s for me. Profile is: 4349 3.8607 libc-2.11.1.so libc-2.11.1.so _int_malloc 3150 2.7963 cc1 cc1 record_reg_classes.constprop.9 2881 2.5575 cc1 cc1 htab_find_slot_with_hash 2104 1.8678 cc1 cc1 ggc_set_mark 2039 1.8101 libc-2.11.1.so libc-2.11.1.so msort_with_tmp 2005 1.7799 cc1 cc1 bitmap_set_bit 1836 1.6299 cc1 cc1 df_ref_create_structure 1775 1.5757 cc1 cc1 find_reloads 1738 1.5429 cc1 cc1 ggc_internal_alloc_stat 1538 1.3653 libc-2.11.1.so libc-2.11.1.so memset 1430 1.2694 cc1 cc1 eq_node 1375 1.2206 cc1 cc1 preprocess_constraints 1317 1.1691 libc-2.11.1.so libc-2.11.1.so _int_free 1309 1.1620 cc1 cc1 df_insn_refs_collect 1289 1.1443 cc1 cc1 ix86_function_arg_regno_p 1277 1.1336 cc1 cc1 df_ref_record 1249 1.1088 cc1 cc1 ix86_save_reg 1215 1.0786 cc1 cc1 ix86_compute_frame_layout 1171 1.0395 libc-2.11.1.so libc-2.11.1.so malloc_consolidate 1134 1.0067 cc1 cc1 extract_insn So I don't get that much of RA by itself. Tracking that malloc ineffeciency might be low hanging fruit.
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13 01:17:19 UTC --- And since Richard did not include 4.6 in his -ftime-reports, here is -O0 garbage collection: 1.74 ( 4%) usr 0.00 ( 0%) sys 1.76 ( 3%) wall 0 kB ( 0%) ggc callgraph construction: 1.07 ( 2%) usr 0.26 ( 5%) sys 1.33 ( 3%) wall 41984 kB ( 3%) ggc callgraph optimization: 0.62 ( 1%) usr 0.24 ( 5%) sys 0.98 ( 2%) wall 91137 kB ( 6%) ggc df scan insns : 3.47 ( 8%) usr 0.32 ( 6%) sys 3.72 ( 7%) wall 7168 kB ( 0%) ggc parser: 1.37 ( 3%) usr 0.41 ( 8%) sys 1.59 ( 3%) wall 202094 kB (13%) ggc inline heuristics : 1.33 ( 3%) usr 0.01 ( 0%) sys 1.29 ( 3%) wall 0 kB ( 0%) ggc tree gimplify : 0.70 ( 2%) usr 0.06 ( 1%) sys 0.70 ( 1%) wall 73728 kB ( 5%) ggc tree CFG construction : 0.21 ( 0%) usr 0.09 ( 2%) sys 0.25 ( 0%) wall 82433 kB ( 5%) ggc tree operand scan : 0.10 ( 0%) usr 0.10 ( 2%) sys 0.15 ( 0%) wall 69141 kB ( 5%) ggc expand: 2.32 ( 5%) usr 0.24 ( 5%) sys 2.45 ( 5%) wall 242940 kB (16%) ggc post expand cleanups : 0.50 ( 1%) usr 0.02 ( 0%) sys 0.49 ( 1%) wall 76289 kB ( 5%) ggc integrated RA : 10.03 (22%) usr 0.15 ( 3%) sys 10.44 (20%) wall 135680 kB ( 9%) ggc reload: 4.42 (10%) usr 0.07 ( 1%) sys 4.60 ( 9%) wall 55295 kB ( 4%) ggc rest of compilation : 3.03 ( 7%) usr 0.82 (16%) sys 3.65 ( 7%) wall 170498 kB (11%) ggc final : 3.67 ( 8%) usr 0.09 ( 2%) sys 3.65 ( 7%) wall 30144 kB ( 2%) ggc unaccounted todo : 1.63 ( 4%) usr 0.91 (18%) sys 2.58 ( 5%) wall 0 kB ( 0%) ggc Wonder what is accounted into rest of compilation. Otherwise RA remains the compile time bottleneck. Will do memory stats later. Adding Vladimir to CC for RA.
[Bug fortran/46917] New: ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46917 Summary: ICE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: vivekr...@yahoo.com For the code module random_integer_mod implicit none contains function vec_block(ivec,block_size) result(jvec) integer, intent(in) :: ivec(:) integer, intent(in) :: block_size integer :: jvec(size(ivec)*block_size) jvec = 1 end function vec_block ! function permute_blocks(nitems,block_size) result(ivec) integer, intent(in) :: block_size,nitems integer :: ivec(nitems) integer :: nblocks integer, allocatable :: jvec(:) nblocks = 1 allocate (jvec(nblocks*block_size)) jvec = vec_block(permutation(nblocks),block_size) ivec = 1 end function permute_blocks ! function permutation(n) result(ivec) integer, intent(in) :: n integer :: ivec(n) ivec = 1 end function permutation end module random_integer_mod Compiling gives gfortran -c -v random_integer_gf_ice.f90 Built by Equation Solution http://www.Equation.com. Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/fsf/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe Target: i686-pc-mingw32 Thread model: win32 gcc version 4.6.0 20101211 (experimental) (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=pentiumpro' c:/fsf/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/f951.exe random_integer_gf_ice.f90 -quiet -dumpbase random_integer_gf_ice.f90 -mtune=generic -march=pentiumpro -auxbase random_integer_gf_ice -version -fintrinsic-modules-path c:/fsf/bin/../lib/gcc/i686-pc-mingw32/4.6.0/finclude -o C:\DOCUME~1\Vivek\LOCALS~1\Temp\ccZNOJh6.s GNU Fortran (GCC) version 4.6.0 20101211 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.6.0 20101211 (experimental), GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101211 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.6.0 20101211 (experimental), GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 random_integer_gf_ice.f90: In function 'permute_blocks': random_integer_gf_ice.f90:18:0: 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.
[Bug debug/46101] [4.6 Regression] ICE: in build_abbrev_table, at dwarf2out.c:10333 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46101 --- Comment #5 from Zdenek Sojka zsojka at seznam dot cz 2010-12-13 01:29:11 UTC --- Created attachment 22729 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22729 another testcase Running testsuite with -g -feliminate-dwarf2-dups still gives similiar (or the same?) ICE. It seems those failures happen only in C++0x mode. Attached is one such reduced testcase. Should I open new PR for that? $ gcc -std=c++0x -g -feliminate-dwarf2-dups pr46101-2.C pr46101-2.C:8:4: internal compiler error: in build_abbrev_table, at dwarf2out.c:10476 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tha failing assert is: gcc_assert (dwarf_version = 4 || AT_ref (a)-die_id.die_symbol); (indeed it passes with -gdwarf-4)
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13 01:46:39 UTC --- Created attachment 22730 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22730 Fix for inline cost problem The attached patch fixes the inliner cost problem so we converge at -O1. It is bit brute force, but I guess it should work well in practice. With the fix -O1 converges in 90 secons. Profile is similar to one at -O0 14898 6.7090 libc-2.11.1.so libc-2.11.1.so _int_malloc 7981 3.5941 cc1 cc1 bitmap_set_bit 5993 2.6988 libc-2.11.1.so libc-2.11.1.so memset 5063 2.2800 cc1 cc1 htab_delete 4091 1.8423 libc-2.11.1.so libc-2.11.1.so _IO_vfscanf 3849 1.7333 no-vmlinux no-vmlinux /no-vmlinux 3807 1.7144 libc-2.11.1.so libc-2.11.1.so _int_free 3632 1.6356 cc1 cc1 df_note_compute 3469 1.5622 libc-2.11.1.so libc-2.11.1.so malloc_consolidate 3352 1.5095 libc-2.11.1.so libc-2.11.1.so msort_with_tmp 2978 1.3411 cc1 cc1 htab_traverse_noresize 2941 1.3244 libc-2.11.1.so libc-2.11.1.so free 2824 1.2717 cc1 cc1 bitmap_clear_bit 2653 1.1947 cc1 cc1 df_ref_create_structure 2429 1.0938 libc-2.11.1.so libc-2.11.1.so malloc 2239 1.0083 cc1 cc1 df_insn_refs_collect
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #47 from Ian Lance Taylor ian at airs dot com 2010-12-13 02:29:46 UTC --- Jan Hubicka hubi...@ucw.cz writes: 1) is there any kind of any documented requirement on initialization of static libraries? (i.e. is EABI fully standard conforming?) Not in C++. 2) I believe that the backwarding order of .ctor section was concious QOI issue. Yes. Some programs may implicitly rely on the fact that global constructors in archives linked later are run before constructors in the object linked against those archives. That is, given g++ foo.o -lbar where bar is a static archive, not a shared library, then currently the global constructors in objects pulled in from libbar.c will be executed before the global constructors in foo.o. That was an intentional choice because it is more likely to be correct than the reverse. However, the C++ standard does not guarantee it, so any programs which relies on this ordering is technically invalid. But of course it does not follow that we should break such programs for no reason. I wonder how much legacy code this might break when static libraries start initializing after main modules. i686-linux execute a lot more code than EABI. I don't know. Comment #1 refers to relative relocations. I'm sure which relocations this means. In a linked binary I would not expect to see any relocations in the .ctors section. As far as backward disk seeks, I assume this refers to the constructors that the program calls, not the .ctors section itself. The program will walk through the .ctors section forward to find then end and then backward to invoke the constructors, so no backward seek should be introduced there. So I assume the backward seek refers to the tendency of the constructors called earlier to be located later in the binary. I think the appropriate fix for this is better code positioning in the linker, which is completely in control. I'm not at all opposed to using .init_array, but changing the linker would be a better way to address this particular issue, as it would encourage such things as putting all the global constructors together rather than scattered across the program. As Mark says, obviously we can not switch to .init_array for code using constructor priorities unless we modify the linker. But I don't think that is a particularly big deal; we can continue to use .ctors for constructors with priorities and use .init_array for normal constructors, the latter case being vastly more common. Ian
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2010-12-13 02:45:37 UTC --- Reduced testcase attached.
