[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #6 from Joost VandeVondele 2012-12-14 07:59:30 UTC --- I was just about to file a bugreport that STOP 1 should yield a backtrace if compiled with -fbacktrace that would really be useful to debug code that just calls 'STOP 1' on some error condition (of course happening only with 1 MPI tasks, so no gdb as far as I can manage). I would be happy to have -fbacktrace=STOP as a way to specify more explicitly when an error should happen (generalizable to -fbacktrace=STOP,ALLOCATE,... ?)
[Bug libstdc++/55682] New: erf, erfc not in cmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55682 Bug #: 55682 Summary: erf, erfc not in cmath Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: nico.schloe...@gmail.com The functions erf, erfc are part of the C++11 standard. They are already implemented in and available in the global namespace after #including it. However, they are missing from .
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-14 Ever Confirmed|0 |1 --- Comment #11 from Dominique d'Humieres 2012-12-14 07:21:35 UTC --- Confirmed.
[Bug c/55681] New: Qualifiers on asm statements are order-dependent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55681
Bug #: 55681
Summary: Qualifiers on asm statements are order-dependent
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: josh.m.con...@gmail.com
The syntax that is accepted for asm statement qualifiers is:
asm {volatile | const | restrict} {goto}
(this can easily be seen by looking at the code in c_parser_asm_statement).
This means, for example, that gcc isn't particularly orthogonal in what it
chooses to accept and reject:
asm volatile ("nop"); // accepted
asm const ("nop"); // accepted with warning
asm __restrict ("nop");// accepted with warning
asm const volatile ("nop");// parse error
asm const __restrict ("nop"); // parse error
asm volatile goto ("nop" : : : : label); // accepted
asm goto volatile ("nop" : : : : label); // parse error
This is probably rarely a problem, since most of the statements that would
result in an error are not likely to be seen (I came across this when adding a
new qualifier for our local port, which exacerbated the problem), but I thought
I would mention it anyway -- the fix is relatively straightforward since the
qualifiers are independent.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #10 from Jack Howarth 2012-12-14 01:23:42 UTC --- Patch posted to skip the invalid g++.dg/asan/interception-test-1.C and c-c++-common/asan/swapcontext-test-1.c on darwin... http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00952.html
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679
--- Comment #9 from Jack Howarth 2012-12-14
00:45:26 UTC ---
The c-c++-common/asan/swapcontext-test-1.c test case should have...
// { dg-skip-if "" { *-*-darwin* } { "*" } { "" } }
since ucontext support was depreciated in Mac OS X 10.6 and removed entirely in
Mac OS X 10.7.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679
--- Comment #8 from Jack Howarth 2012-12-14
00:36:10 UTC ---
The g++.dg/asan/interception-test-1.C test should have...
// { dg-skip-if "" { { *-*-darwin* } { "*" } { "" } }
since darwin uses mac function interposition rather than interception.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #7 from Jack Howarth 2012-12-14 00:22:31 UTC --- The g++.dg/asan/interception-test-1.C test for excess errors failures are all of the form... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/g++.dg/asan/interception-test-1.C -fsanitize=address -g -fno-diagnostics-show-caret -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/libstdc++-v3/testsuite/util -fmessage-length=0 -O0 -fno-builtin-malloc -fno-builtin-free -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libstdc++-v3/src/.libs -multiply_defined suppress -lm -m32 -o ./interception-test-1.exe(timeout = 300) Undefined symbols for architecture i386:^M "___interceptor_strtol", referenced from:^M _strtol in ccYdXB2Q.o^M ld: symbol(s) not found for architecture i386^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 output is: Undefined symbols for architecture i386:^M "___interceptor_strtol", referenced from:^M _strtol in ccYdXB2Q.o^M ld: symbol(s) not found for architecture i386^M collect2: error: ld returned 1 exit status^M FAIL: g++.dg/asan/interception-test-1.C -O0 (test for excess errors)
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #6 from Jack Howarth 2012-12-14 00:19:58 UTC --- The c-c++-common/asan/swapcontext-test-1.c test for excess errors failures are all of the form... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ swapcontext_available47450.c -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fno-builtin -lm -m32 -o swapcontext_available47450.exe(timeout = 300) Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -O0-lm -m32 -o ./swapcontext-test-1.exe(timeout = 300) In file included from /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:6:0:^M /usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:9:1: error: unknown type name 'ucontext_t'^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:10:1: error: unknown type name 'ucontext_t'^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c: In function 'Run':^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:33:16: error: request for member 'uc_stack' in something not a structure or union^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:34:16: error: request for member 'uc_stack' in something not a structure or union^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:36:18: error: request for member 'uc_link' in something not a structure or union^M compiler exited with status 1 output is: In file included from /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:6:0:^M /usr/include/ucontext.h:42:2: error: #error ucontext routines are deprecated, and require _XOPEN_SOURCE to be defined^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:9:1: error: unknown type name 'ucontext_t'^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:10:1: error: unknown type name 'ucontext_t'^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c: In function 'Run':^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:33:16: error: request for member 'uc_stack' in something not a structure or union^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:34:16: error: request for member 'uc_stack' in something not a structure or union^M /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/swapcontext-test-1.c:36:18: error: request for member 'uc_link' in something not a structure or union^M FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 (test for excess errors)
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #5 from Jack Howarth 2012-12-14 00:17:22 UTC --- Created attachment 28948 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28948 assembly file for c-c++-common/asan/stack-overflow-1.c -O1 execution test on x86_64-apple-darwin10 Generated with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/stack-overflow-1.c -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -O1 -fno-builtin-memset -lm -m32 -o ./stack-overflow-1.exe --save-temps for failing c-c++-common/asan/stack-overflow-1.c -O1 execution test x86_64-apple-darwin10. The resulting executable runs without crashing or triggering in libasan... # ./stack-overflow-1.exe #
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #4 from Jack Howarth 2012-12-14 00:11:30 UTC --- Created attachment 28947 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28947 assembly file for c-c++-common/asan/rlimit-mmap-test-1.c -O0 execution test on x86_64-apple-darwin10 Generated with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/rlimit-mmap-test-1.c -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -O0 -lm -m32 -o ./rlimit-mmap-test-1.exe --save-temps for failing c-c++-common/asan/rlimit-mmap-test-1.c -O0 execution test on x86_64-apple-darwin10. The resulting executable runs without crashing or triggering in libasan... # ./rlimit-mmap-test-1.exe #
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #3 from Jack Howarth 2012-12-14 00:05:51 UTC --- Created attachment 28946 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28946 assembly file for c-c++-common/asan/global-overflow-1.c -O1 execution test on x86_64-apple-darwin10 Generated with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/global-overflow-1.c -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -O1 -fno-builtin-memset -lm -m32 -o ./global-overflow-1.exe --save-temps for failing c-c++-common/asan/global-overflow-1.c -O1 execution test on x86_64-apple-darwin10. The resulting executable runs without crashing or triggering in libasan... # ./global-overflow-1.exe #
[Bug target/55673] Reversed before/after handling in sparc_emit_membar_for_model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55673 --- Comment #5 from Eric Botcazou 2012-12-13 23:42:07 UTC --- There is also a pasto in sync.md which disables the atomic_store pattern.
[Bug libgcc/55589] Failure compiling "generic-morestack-thread.c", without threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55589 --- Comment #4 from michael at talamasca dot ocis.net 2012-12-13 23:36:53 UTC --- The patch doesn't compile. At __wrap_pthread_create, it starts erroring because the pthread_t and pthread_attr_t types do not exist. It appears that since the module specifically depends on hooking user applications' attempts to use the pthread API, it's unavoidably specific to that API.
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #10 from Paolo Carlini 2012-12-13 23:29:42 UTC --- Guess we can close this.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #4 from janus at gcc dot gnu.org 2012-12-13 23:04:15 UTC --- (In reply to comment #2) > It seems I found yet another reincarnation of this bug (spotted in the wild, > unfortunately): Note: The patch in comment #1 does not seem to fix the behavior in comment #2. So, either the patch is not complete, or comment #2 is a distinct problem after all. (I would say that it's at least loosely related, even though I do not completely understand the problem yet.)
[Bug c++/55680] New: [C++11] Member specialization with lambda is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55680
Bug #: 55680
Summary: [C++11] Member specialization with lambda is rejected
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: qufa...@gmail.com
CONTENTS OF speclambda.cpp
template struct X {
static void (* code ) ();
};
template <> void (* X::code ) () = [](){};
int main () { return 0; }
OUTPUT OF g++-4.7 -std=c++11
speclambda.cpp:4:42: error: explicit specialization of non-template ‘’
==
It succeeds if I specialize the whole struct instead of just the one member.
The same error occurs if the type of 'code' is std::function.
The same error occurs during any kind of static member specialization whose
initializer contains a lambda (such as an initializer that calls a constructor
with a lambda as an argument).
I'm not 100% certain this is valid code, but even if it is invalid, the error
message is quite misleading.
OUTPUT OF g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-11precise2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-11precise2)
==
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #12 from Markus Trippelsdorf 2012-12-13 22:35:33 UTC --- (In reply to comment #11) > Do you happen to know what it was with lto/pgo before the change? Should be > roughly equivalent to hot-bb-count-ws-permille=970 from what I saw in your > profiles Yes, it was ~34MB before the change. > What size increase is acceptable? It's hard to say in case of Firefox, because the only thing that one can reliably measure is the JavaScript performance. And this varies only very slightly with different compiler options. So you have no way to measure up to which point more inlining is still beneficial.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #162 from Markus Trippelsdorf 2012-12-13 22:25:27 UTC --- The libxul binary size issue is solved now. During testing I came across another issue that looks similar to the one Comment 146: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /tmp/ccwu5G98.ltrans4.ltrans.o: requires dynamic R_X86_64_PC32 reloc against '_ZN13nsXUL Document14MaybeBroadcastEv.429466' which may overflow at runtime; recompile with -fPIC /tmp/ccwu5G98.ltrans4.ltrans.o:ccwu5G98.ltrans4.o:function nsRunnableMethodTraits::base_type* NS_NewRunnableMethod(nsXULDocument*, void (nsXULDocument::*)()) [clone .local.39398] [clone .constprop.84952]: error: undefined reference to 'nsXULDocument::MaybeBroadcast() [clone .429466]' /tmp/ccwu5G98.ltrans4.ltrans.o:ccwu5G98.ltrans4.o:function nsRunnableMethodTraits::base_type* NS_NewRunnableMethod(nsXULDocument*, void (nsXULDocument::*)()) [clone .local.39398] [clone .constprop.84952]: error: undefined reference to 'nsXULDocument::MaybeBroadcast() [clone .429466]' collect2: error: ld returned 1 exit status After I deleted both nsXULDocument.o and nsXULDocument.gcda and rebuild with: make -f client.mk realbuild MOZ_PROFILE_USE=1 the problem did go away.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #2 from Jack Howarth 2012-12-13 22:20:55 UTC --- Ignore Comment 1. The actual failures produce no particular error messages and can't be reproduced by hand for the c-c++-common/asan/global-overflow-1.c -O1 execution test Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/global-overflow-1.c -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -O1 -fno-builtin-memset -lm -m32 -o ./global-overflow-1.exe(timeout = 300) PASS: c-c++-common/asan/global-overflow-1.c -O1 (test for excess errors) Setting LD_LIBRARY_PATH to :/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc:/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs::/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc:/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/i386/libsanitizer/asan/.libs:/usr/local/NMRPipe/nmrbin.mac/lib FAIL: c-c++-common/asan/global-overflow-1.c -O1 execution test
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #3 from Dominique d'Humieres 2012-12-13 22:20:25 UTC --- Revision 156618 (2010-02-09) is OK. Revision 157955 (2010-03-30) miscompiles the tests.
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #1 from Jack Howarth 2012-12-13 22:16:22 UTC --- = ==47584== ERROR: AddressSanitizer: global-buffer-overflow on address 0x214a at pc 0x1ba6 bp 0xbfffc9c8 sp 0xbfffc9bc READ of size 1 at 0x214a thread T0 #0 0x1ba5 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/gcc/./global-overflow-1.exe+0x1ba5) #1 0x19c4 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/gcc/./global-overflow-1.exe+0x19c4) #2 0x0 (/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/gcc/./global-overflow-1.exe+0x0) 0x214a is located 0 bytes to the right of global variable 'YYY (/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/global-overflow-1.c)' (0x2140) of size 10 'YYY (/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121213/gcc/testsuite/c-c++-common/asan/global-overflow-1.c)' is ascii string '' Shadow byte and word: 0x2429: 2 0x2428: 00 02 f9 f9 More shadow bytes: 0x2418: 00 00 00 00 0x241c: 00 00 00 00 0x2420: 00 02 f9 f9 0x2424: f9 f9 f9 f9 =>0x2428: 00 02 f9 f9 0x242c: f9 f9 f9 f9 0x2430: 00 02 f9 f9 0x2434: f9 f9 f9 f9 0x2438: 00 00 00 00 Stats: 0M malloced (0M for red zones) by 0 calls Stats: 0M realloced by 0 calls Stats: 0M freed by 0 calls Stats: 0M really freed by 0 calls Stats: 0M (0 full pages) mmaped in 0 calls mmaps by size class: mallocs by size class: frees by size class: rfrees by size class: Stats: malloc large: 0 small slow: 0 ==47584== ABORTING Executing on host: addr2line -f -e /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/gcc/./global-overflow-1.exe 0x1ba5 0x19c4 0x0 (timeout = 300) PASS: c-c++-common/asan/global-overflow-1.c -O0 execution test PASS: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, READ of size 1 at 0x[0-9a-f]+ thread T0.*( |^M |^M)#0 0x[0-9a-f]+ (in _*main ([^ ^M]*global-overflow-1.c:15|[^ ^M]*:0)|[(])[^ ^M]*( |^M |^M).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^ ^M]* of size 10[^ ^M]*( |^M |^M)
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #11 from Teresa Johnson 2012-12-13 22:16:19 UTC --- Do you happen to know what it was with lto/pgo before the change? Should be roughly equivalent to hot-bb-count-ws-permille=970 from what I saw in your profiles. What size increase is acceptable? Thanks, Teresa On Thu, Dec 13, 2012 at 2:14 PM, markus at trippelsdorf dot de < gcc-bugzi...@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #10 from Markus Trippelsdorf > 2012-12-13 22:14:01 UTC --- > (In reply to comment #8) > > Please let me know how this affects the mozilla size. > > Looks much better now: > 39748288 hot-bb-count-ws-permille=999 (default) > 34573408 hot-bb-count-ws-permille=890 > 34072808 without lto/pgo > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug sanitizer/55679] New: new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 Bug #: 55679 Summary: new asan tests from r194458 fail on x86_64-apple-darwin10 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org Some of the new tests added in r194458 fail on x86_64-apple-darwin. These failures include... FAIL: c-c++-common/asan/global-overflow-1.c -O1 execution test FAIL: c-c++-common/asan/global-overflow-1.c -O2 execution test FAIL: c-c++-common/asan/global-overflow-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/global-overflow-1.c -O3 -g execution test FAIL: c-c++-common/asan/global-overflow-1.c -Os execution test FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto execution test FAIL: c-c++-common/asan/rlimit-mmap-test-1.c -O0 execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O1 execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O2 execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O3 -g execution test FAIL: c-c++-common/asan/stack-overflow-1.c -Os execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O2 -flto execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -g (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -Os (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto (test for excess errors) FAIL: c-c++-common/asan/rlimit-mmap-test-1.c -O0 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -g (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -Os (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O0 (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O1 (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O2 (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O3 -g (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -Os (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O2 -flto -flto-partition=none (test for excess errors) FAIL: g++.dg/asan/interception-test-1.C -O2 -flto (test for excess errors) at both -m32 and -m64.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #10 from Markus Trippelsdorf 2012-12-13 22:14:01 UTC --- (In reply to comment #8) > Please let me know how this affects the mozilla size. Looks much better now: 39748288 hot-bb-count-ws-permille=999 (default) 34573408 hot-bb-count-ws-permille=890 34072808 without lto/pgo
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-13 Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-12-13 21:39:29 UTC --- It seems I found yet another reincarnation of this bug (spotted in the wild, unfortunately): program GiBUU_neutrino_bug Type particle integer :: ID End Type type(particle), dimension(1:2,1:2) :: OutPart OutPart(1,:)%ID = 1 OutPart(2,:)%ID = 2 call s1(OutPart(1,:)) contains subroutine s1(j) type(particle) :: j(:) print *,j(:)%ID call s2(j) end subroutine subroutine s2(k) type(particle) :: k(1:2) print *,k(:)%ID end subroutine end It is expected to print 1 1 1 1 which it does with 4.3 and 4.4. As the test case in comment 0, it fails with everything from 4.5 up to trunk, printing: 1 1 1 2 A workaround is to declare both 'i' and 'j' in the same way, as either (:) or (1:2).
[Bug middle-end/55492] __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492 Richard Henderson changed: What|Removed |Added Keywords||wrong-code Status|ASSIGNED|RESOLVED Component|target |middle-end Resolution||FIXED --- Comment #7 from Richard Henderson 2012-12-13 21:19:38 UTC --- Fixed.
[Bug target/55492] __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492 --- Comment #6 from Richard Henderson 2012-12-13 21:17:55 UTC --- Author: rth Date: Thu Dec 13 21:17:52 2012 New Revision: 194491 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194491 Log: PR middle-end/55492 * optabs.c (expand_atomic_load): Emit acquire barrier after the load. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/optabs.c
[Bug target/55492] __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492 --- Comment #5 from Richard Henderson 2012-12-13 21:16:50 UTC --- Author: rth Date: Thu Dec 13 21:16:45 2012 New Revision: 194490 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194490 Log: PR middle-end/55492 * optabs.c (expand_atomic_load): Emit acquire barrier after the load. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c
[Bug c/55678] _Static_assert escapes tick marks just to make me mad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55678 --- Comment #1 from Daniel Santos 2012-12-13 21:12:24 UTC --- This appears to happen in the function c_parser_static_assert_declaration_no_semi (gcc/c/c-parser.c) when it calls "c_parser_peek_token (parser)->value", but I don't know gcc's internals very well and would rather not lie to you.
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 --- Comment #6 from Harald Anlauf 2012-12-13 21:11:20 UTC --- Adding some prints, I found that the crash is probably due to the actual order of invocation of some functions: gfc_post_options, which calls gfc_cpp_post_options; then gfc_cpp_register_include_paths, leading to the crash. At this time, gfc_init was not yet called. With -Wno-missing-include-dirs, the execution proceeds thru gfc_init and then gfc_cpp_init_0, where the callbacks finally are initialized.
[Bug c/55678] New: _Static_assert escapes tick marks just to make me mad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55678
Bug #: 55678
Summary: _Static_assert escapes tick marks just to make me mad
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.san...@pobox.com
#define BUILD_BUG_ON(cond) _Static_assert(!(cond), #cond)
void f() {
const int a='4';
BUILD_BUG_ON(a == '4');
_Static_assert(0, "don't call static assert with zero, silly!");
}
test.c: In function ‘f’:
test.c:4:2: error: static assertion failed: "a == \'4\'"
test.c:5:2: error: static assertion failed: "don\'t call static assert with
zero, silly!"
I found nothing in the standard that says to do escape any character, only
§6.7.10 (of C11) that says you can choose to not print a character that's not
in the basic source character set, but the single-quote/tick-mark is.
[Bug target/55492] __atomic_load doesn't match ACQUIRE memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-13 CC||rth at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 --- Comment #4 from Richard Henderson 2012-12-13 21:01:32 UTC --- Confirmed. While the code for the above patch is good, I'm going to update some comments at the same time.
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476
--- Comment #10 from Jan Hubicka 2012-12-13 20:56:13
UTC ---
> (gdb) call debug_tree (node->symbol.decl)
> type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x767f75e8 precision
> 32 min max 0x767fa080
> 2147483647>
> pointer_to_this >
> addressable used static external weak SI file t.c line 1 col 12 size
> unit size
> align 32 context attributes
>
> (mem:SI (symbol_ref/i:DI ("Wv10a") ) [0
> Wv10a+0 S4 A32]) chain >
>
> it has DECL_EXTERNAL set (but it also is TREE_STATIC and has RTL!).
> On the 4.7 branch we simply checked whether the DECL had RTL but didn't bother
> to check whether it does not have DECL_EXTERNAL set.
>
> I'd say either revert to 4.7 behavior here or do
>
> Index: varpool.c
> ===
> --- varpool.c (revision 194472)
> +++ varpool.c (working copy)
> @@ -358,7 +358,8 @@ varpool_remove_unreferenced_decls (void)
> && (!varpool_can_remove_if_no_refs (node)
> /* We just expanded all function bodies. See if any of
> them needed the variable. */
> - || (!DECL_EXTERNAL (node->symbol.decl)
> + || (!(DECL_EXTERNAL (node->symbol.decl)
> + && !TREE_STATIC (node->symbol.decl))
Oops, thanks! I had similar hunk sitting in my tree for a while, but forgot to
commit it.
The point of nor marking extenral as used at this point was to release memory
used by identifiers because at this stage they do not matter, but since we gave
up on that, I guess this is fine.
For 4.9 I think I should look into reorganizing weakrefs to have different
tree representation. This abuse of external flag is really anoying.
Honza
[Bug c++/55677] Virtual inheritance, 'this' pointer used as constructor parameter, parameter specialized in derived method, generated binary dumps core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55677 --- Comment #1 from x3n0m0rph59 at googlemail dot com 2012-12-13 20:33:46 UTC --- Created attachment 28945 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28945 C++11 Program Source with cmake project file
[Bug c++/55677] New: Virtual inheritance, 'this' pointer used as constructor parameter, parameter specialized in derived method, generated binary dumps core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55677
Bug #: 55677
Summary: Virtual inheritance, 'this' pointer used as
constructor parameter, parameter specialized in
derived method, generated binary dumps core
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: x3n0m0rp...@googlemail.com
If I compile the attached c++11 source with g++ and execute it, it dumps core
on my system. If I compile it with clang++ or msvc11 it works.
I don't know if the attached program source is legal C++ or not!? There is no
warning generated on any of the compilers I've tried, including g++.
The interesting part is in file 'class2.hpp'. If you replace the type 'class
middle' with 'class class1' the g++ binary doesn't dump core anymore
Does NOT work:
class2(middle *var) :
class1(var)
{
}
Does work:
class2(class1 *var) :
class1(var)
{
}
System:
lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 12.10
Release:12.10
Codename:quantal
g++ --version
g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
[Bug lto/55669] [4.8 Regression] ICE : in cgraph_mark_address_taken_node, at cgraph.c:1409
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55669 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Markus Trippelsdorf 2012-12-13 19:10:40 UTC --- Dup. Fixed by the patch in PR55674. *** This bug has been marked as a duplicate of bug 55674 ***
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #9 from Markus Trippelsdorf 2012-12-13 19:10:40 UTC --- *** Bug 55669 has been marked as a duplicate of this bug. ***
[Bug regression/55676] New: ICE in int_mode_for_mode, at stor-layout.c:423
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55676 Bug #: 55676 Summary: ICE in int_mode_for_mode, at stor-layout.c:423 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: gre...@gcc.gnu.org Target: arm-none-eabi FAIL: gcc.dg/sms-11.c (internal compiler error) /work/dec-builds/base/install/bin/arm-none-eabi-gcc -S -O2 -fmodulo-sched /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/sms-11.c /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/sms-11.c: In function 'invert': /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/sms-11.c:28:1: internal compiler error: in int_mode_for_mode, at stor-layout.c:423 } ^ 0x8ca223 int_mode_for_mode(machine_mode) /work/local-checkouts/gcc-fsf/gcc/stor-layout.c:423 0x6a0cf1 emit_move_via_integer /work/local-checkouts/gcc-fsf/gcc/expr.c:3069 0x6ac7f9 emit_move_ccmode /work/local-checkouts/gcc-fsf/gcc/expr.c:3285 0x6ac7f9 emit_move_insn_1(rtx_def*, rtx_def*) /work/local-checkouts/gcc-fsf/gcc/expr.c:3436 0x81d9b3 gen_move_insn(rtx_def*, rtx_def*) /work/local-checkouts/gcc-fsf/gcc/optabs.c:4794 0xd051f8 schedule_reg_moves /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:769 0xd0854d sms_schedule /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:1691 0xd0854d rest_of_handle_sms /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:3347 Please submit a full bug report, with preprocessed source if appropriate. The problem is that emit_move_via_integer called with CCFPmode. Known to fail with gcc trunk r194473, has been failing for at least a month with the same error message. Configured with: /work/local-checkouts/gcc-fsf/configure --target=arm-none-eabi --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --disable-nls --disable-threads --disable-lto --disable-tls --enable-checking=yes --disable-libssp --disable-libgomp --disable-libmudflap --with-cpu=cortex-a15 --with-fpu=neon-vfpv4 --with-float=softfp When the test is compiled -mcpu=cortex-a9, there is no ICE but execution fails with segmentation fault (tested on qemu) because generated code is incorrect. In the first inner loop, the register r4 that holds the value of j keeps increasing until tmp array is accessed out of bounds. $ /work/dec-builds/base/install/bin/arm-none-eabi-gcc /work/local-checkouts/gcc-fsf/gcc/testsuite/gcc.dg/sms-11.c -fno-diagnostics-show-caret -O2 -lm -o ./sms-11.exe -mfloat-abi=softfp -mcpu=cortex-a9 -fmodulo-sched $ qemu-arm sms-11.exe qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault
[Bug rtl-optimization/55161] internal compiler error: in schedule_reg_moves, at modulo-sched.c:731
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55161 gretay at gcc dot gnu.org changed: What|Removed |Added CC||gretay at gcc dot gnu.org --- Comment #1 from gretay at gcc dot gnu.org 2012-12-13 18:32:46 UTC --- This testcase still has ICE with gcc trunk r194473. ICE with both arm and thumb mode, using -O1 and -O2. No ICE when using -O3. ICE with -march=armv7-a. ICE with -mcpu=cortex-a8 but no ICE for any other cortex-a* cpu. /work/dec-builds/base/install/bin/arm-none-eabi-gcc -S test.c --std=c99 -fmodulo-sched -O1 -march=armv7-a -mthumb test.c: In function 'test_04': test.c:7:1: internal compiler error: in schedule_reg_moves, at modulo-sched.c:725 } ^ 0xd2db44 schedule_reg_moves /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:725 0xd3066f sms_schedule /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:1684 0xd31a4f rest_of_handle_sms /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:3340 /work/dec-builds/base/install/bin/arm-none-eabi-gcc -S test.c --std=c99 -fmodulo-sched -O1 -mcpu=cortex-a8 test.c: In function 'test_04': test.c:7:1: internal compiler error: in schedule_reg_moves, at modulo-sched.c:725 } ^ 0xd2db44 schedule_reg_moves /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:725 0xd3066f sms_schedule /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:1684 0xd31a4f rest_of_handle_sms /work/local-checkouts/gcc-fsf/gcc/modulo-sched.c:3340 Configured with: --target=arm-none-eabi --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --disable-nls --disable-threads --disable-lto --disable-tls --enable-checking=yes --disable-libssp --disable-libgomp --disable-libmudflap --with-cpu=cortex-a15 --with-fpu=neon-vfpv4 --with-float=softfp Unfortunately, because of the various failures related to modulo-sched on arm, I haven't been able to track down the exact revision responsible for this ICE. Regression test failure reported in PR55486 has the error message. FAIL: gcc.dg/sms-7.c (internal compiler error)
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #8 from Teresa Johnson 2012-12-13 18:23:08 UTC --- Dumb mistake in my previous fix to the lto support. Here is the patch that fixes it, I will submit for review after regression testing completes: Index: lto-cgraph.c === --- lto-cgraph.c (revision 194404) +++ lto-cgraph.c (working copy) @@ -1368,7 +1368,9 @@ so we need to account for a non-zero histogram entry at new_ix. */ unsigned new_ix = gcov_histo_index (scaled_min); lto_gcov_summary.histogram[new_ix].min_value - = MIN (lto_gcov_summary.histogram[new_ix].min_value, scaled_min); + = (lto_gcov_summary.histogram[new_ix].num_counters + ? MIN (lto_gcov_summary.histogram[new_ix].min_value, scaled_min) + : scaled_min); /* Some of the scaled counter values would ostensibly need to be placed into different (larger) histogram buckets, but we keep things simple here and place the scaled cumulative counter value in the bucket Please let me know how this affects the mozilla size. Thanks, Teresa On Thu, Dec 13, 2012 at 7:49 AM, Teresa Johnson wrote: > Reproduced. Looks like somehow my fix to stream this through LTO is > not working properly. I see that the min count is valid when > generating the .o file, but goes to zero when we do the link(lto) > phase. Hopefully this means that the heuristic itself is not broken. > =) I'll see if I can root cause this and have a fix today. > > Teresa > > On Thu, Dec 13, 2012 at 7:06 AM, markus at trippelsdorf dot de > wrote: >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 >> >> --- Comment #6 from Markus Trippelsdorf >> 2012-12-13 15:06:12 UTC --- >> (In reply to comment #5) >>> Ok, I will download tramp3d-v4 right now and see what is going on. Can >>> you send me the full set of options you are using to compile it? >>> >> >> g++ -w -O3 -fprofile-generate -march=native tramp3d-v4.cpp >> ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 >> g++ -w -O3 -fprofile-use -flto=4 -march=native tramp3d-v4.cpp >> >> -- >> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email >> --- You are receiving this mail because: --- >> You are on the CC list for the bug. > > > > -- > Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug target/55673] Reversed before/after handling in sparc_emit_membar_for_model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55673 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou 2012-12-13 18:12:58 UTC --- Taking care of it.
[Bug target/55673] Reversed before/after handling in sparc_emit_membar_for_model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55673 --- Comment #3 from Andrew Macleod 2012-12-13 18:07:19 UTC --- Yeah, there is already a PR for that which I have a patch to apply... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55492
[Bug c++/55576] Fails to compile a call to template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576 --- Comment #11 from Tudor Bosman 2012-12-13 18:03:35 UTC --- As I indicated in PR 55668, this has been broken since at least 4.1.2.
[Bug c++/55576] Fails to compile a call to template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576 Tudor Bosman changed: What|Removed |Added CC||tudorb at fb dot com --- Comment #10 from Tudor Bosman 2012-12-13 18:01:42 UTC --- *** Bug 55668 has been marked as a duplicate of this bug. ***
[Bug c++/55668] Incorrect lookup for template member of dependent template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55668 Tudor Bosman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Tudor Bosman 2012-12-13 18:01:42 UTC --- Jonathan: thanks, yes, that looks like a dup. Closing this one. *** This bug has been marked as a duplicate of bug 55576 ***
[Bug c++/55668] Incorrect lookup for template member of dependent template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55668 --- Comment #4 from Tudor Bosman 2012-12-13 18:01:04 UTC --- Jonathan: thanks, yes, that looks like a dup. Closing this one.
[Bug target/55673] Reversed before/after handling in sparc_emit_membar_for_model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55673 Richard Henderson changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Richard Henderson 2012-12-13 17:31:23 UTC --- The patch looks correct to me. And indeed while investigating this I notice that we have a similar problem with the fully generic code in optabs.c. Andrew, have a look at expand_atomic_load placing the barrier before the load. There's also a bit of incorrect commentary cut and paste between there and expand_atomic_store. It appears as if the only platform for which we get all this correct is powerpc, and there because it implements its own atomic_load and atomic_store patterns.
[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672
Uros Bizjak changed:
What|Removed |Added
Keywords||ra
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Uros Bizjak 2012-12-13 16:49:45
UTC ---
LRA doesn't substitute frame reg with bp. In _.209r.reload, we still have:
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0 x+0 S4 A32])
(const_int 4 [0x4]))) pr55672.c:4 7 {*cmpsi_1}
(nil))
Adding CC.
[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-12-13
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak 2012-12-13 16:43:23
UTC ---
Confirmed, we tried to print "frame" reg from:
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0 x+0 S4 A32])
(const_int 4 [0x4]))) pr55672.c:4 7 {*cmpsi_1}
(nil))
[Bug debug/55665] [4.8 Regression] Missing DW_TAG_lexical_block PC range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55665 --- Comment #6 from Jan Kratochvil 2012-12-13 16:02:48 UTC --- Confirming the GDB regression is fixed in the today's results, thanks!
[Bug c++/55652] [4.8 Regression] ICE (segfault) with templates and structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2012-12-13 15:52:33 UTC --- Fixed.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #7 from Teresa Johnson 2012-12-13 15:50:05 UTC --- Reproduced. Looks like somehow my fix to stream this through LTO is not working properly. I see that the min count is valid when generating the .o file, but goes to zero when we do the link(lto) phase. Hopefully this means that the heuristic itself is not broken. =) I'll see if I can root cause this and have a fix today. Teresa On Thu, Dec 13, 2012 at 7:06 AM, markus at trippelsdorf dot de wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #6 from Markus Trippelsdorf > 2012-12-13 15:06:12 UTC --- > (In reply to comment #5) >> Ok, I will download tramp3d-v4 right now and see what is going on. Can >> you send me the full set of options you are using to compile it? >> > > g++ -w -O3 -fprofile-generate -march=native tramp3d-v4.cpp > ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 > g++ -w -O3 -fprofile-use -flto=4 -march=native tramp3d-v4.cpp > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug sanitizer/55508] many test cases fail using -fsanitize=address with internal compiler error: in expand_call_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55508 Jack Howarth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Jack Howarth 2012-12-13 15:46:22 UTC --- Confirmed fixed at r194459 on x86_64-apple-darwin12.
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55675 --- Comment #2 from Jonathan Wakely 2012-12-13 15:33:55 UTC --- Thanks, Paolo. I couldn't find the relevant PR so suggested Sebastian should file one to ensure it's not forgotten.
[Bug libstdc++/54577] deque::erase() still takes iterator instead of const_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 Paolo Carlini changed: What|Removed |Added CC||sbock at hsr dot ch --- Comment #3 from Paolo Carlini 2012-12-13 15:31:06 UTC --- *** Bug 55675 has been marked as a duplicate of this bug. ***
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55675 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Component|c++ |libstdc++ Resolution||DUPLICATE --- Comment #1 from Paolo Carlini 2012-12-13 15:31:06 UTC --- Yes, this is well known. *** This bug has been marked as a duplicate of bug 54577 ***
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Richard Biener 2012-12-13 15:21:39 UTC --- Fixed.
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476 --- Comment #8 from Richard Biener 2012-12-13 15:21:05 UTC --- Author: rguenth Date: Thu Dec 13 15:20:57 2012 New Revision: 194481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194481 Log: 2012-12-13 Richard Biener PR middle-end/53476 * varpool.c (varpool_remove_unreferenced_decls): Revert to 4.7 behavior. Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55675 Bug #: 55675 Summary: const iterator overload for vector modifiers missing for C++11, e.g., iterator insert(const_iterator pos, T const &t) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sb...@hsr.ch is not yet implemented in 4.7.0/4.8.0 there's still only iterator insert(iterator pos, T const &t)
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #90 from Joost VandeVondele 2012-12-13 15:13:26 UTC --- (In reply to comment #89) > Just to repeat, the ICEs are with checking enabled only (but possibly cover up > for wong-code). I'm indeed worried that the release branches will as a result silently miscompile Fortran code in LTO mode, but I appreciate that the problem is hard to fix correctly. I wonder if an intermediate solution would be dropping the 'restrict qualifier' (in default of a better term) from allocatable components of derived types. This is a very small set of variables (as this was not allowed in Fortran90, IIRC) and should have small impact on the performance of typical programs. In exchange one would be able to use LTO without the risk of miscompilation, and presumably with significant benefit.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #6 from Markus Trippelsdorf 2012-12-13 15:06:12 UTC --- (In reply to comment #5) > Ok, I will download tramp3d-v4 right now and see what is going on. Can > you send me the full set of options you are using to compile it? > g++ -w -O3 -fprofile-generate -march=native tramp3d-v4.cpp ./a.out --cartvis 1.0 0.0 --rhomin 1e-8 -n 20 g++ -w -O3 -fprofile-use -flto=4 -march=native tramp3d-v4.cpp
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #5 from Teresa Johnson 2012-12-13 15:02:55 UTC --- Ok, I will download tramp3d-v4 right now and see what is going on. Can you send me the full set of options you are using to compile it? Teresa On Thu, Dec 13, 2012 at 6:52 AM, markus at trippelsdorf dot de wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #4 from Markus Trippelsdorf > 2012-12-13 14:52:37 UTC --- > (In reply to comment #3) >> Hi Markus, >> >> Are you sure you have my subsequent fixes patched in, to make sure the >> histogram is getting streamed through the LTO files? This was the >> behavior I saw when I was debugging the original issue that I fixed >> with those patches. Basically, the hotness checks before we went into >> LTO were good, and after LTO the min count was 0. >> > Hi Teresa, > > yes my gcc is up-to-date (from todays git). > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #4 from Markus Trippelsdorf 2012-12-13 14:52:37 UTC --- (In reply to comment #3) > Hi Markus, > > Are you sure you have my subsequent fixes patched in, to make sure the > histogram is getting streamed through the LTO files? This was the > behavior I saw when I was debugging the original issue that I fixed > with those patches. Basically, the hotness checks before we went into > LTO were good, and after LTO the min count was 0. > Hi Teresa, yes my gcc is up-to-date (from todays git).
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #3 from Teresa Johnson 2012-12-13 14:49:19 UTC --- Hi Markus, Are you sure you have my subsequent fixes patched in, to make sure the histogram is getting streamed through the LTO files? This was the behavior I saw when I was debugging the original issue that I fixed with those patches. Basically, the hotness checks before we went into LTO were good, and after LTO the min count was 0. Teresa On Thu, Dec 13, 2012 at 6:46 AM, markus at trippelsdorf dot de wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 > > --- Comment #2 from Markus Trippelsdorf > 2012-12-13 14:46:31 UTC --- > In the tramp3d-v4 case, when I run with this simple debug patch: > > diff --git a/gcc/predict.c b/gcc/predict.c > index 5d3de29..bf3a259 100644 > --- a/gcc/predict.c > +++ b/gcc/predict.c > @@ -147,6 +147,7 @@ maybe_hot_count_p (struct function *fun, gcov_type count) >gcc_assert (ws); >min_count = ws->min_counter; > } > + fprintf (stderr, "count=%i min_count=%i profile_info->sum_max=%i\n", count, > min_count, profile_info->sum_max); >return (count >= min_count); > } > > it shows that in the middle of the output, min_count changes from > 8585 to 0: > > ... ~60 similar lines with min_count=8585 > count=3 min_count=8585 profile_info->sum_max=257406300 > count=3 min_count=8585 profile_info->sum_max=257406300 > count=3 min_count=8585 profile_info->sum_max=257406300 > count=3 min_count=8585 profile_info->sum_max=257406300 > count=40 min_count=0 profile_info->sum_max=257406300 > count=61 min_count=0 profile_info->sum_max=257406300 > count=40 min_count=0 profile_info->sum_max=257406300 > count=40 min_count=0 profile_info->sum_max=257406300 > ... ~60 similar lines with min_count=0 > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #2 from Markus Trippelsdorf 2012-12-13 14:46:31 UTC --- In the tramp3d-v4 case, when I run with this simple debug patch: diff --git a/gcc/predict.c b/gcc/predict.c index 5d3de29..bf3a259 100644 --- a/gcc/predict.c +++ b/gcc/predict.c @@ -147,6 +147,7 @@ maybe_hot_count_p (struct function *fun, gcov_type count) gcc_assert (ws); min_count = ws->min_counter; } + fprintf (stderr, "count=%i min_count=%i profile_info->sum_max=%i\n", count, min_count, profile_info->sum_max); return (count >= min_count); } it shows that in the middle of the output, min_count changes from 8585 to 0: ... ~60 similar lines with min_count=8585 count=3 min_count=8585 profile_info->sum_max=257406300 count=3 min_count=8585 profile_info->sum_max=257406300 count=3 min_count=8585 profile_info->sum_max=257406300 count=3 min_count=8585 profile_info->sum_max=257406300 count=40 min_count=0 profile_info->sum_max=257406300 count=61 min_count=0 profile_info->sum_max=257406300 count=40 min_count=0 profile_info->sum_max=257406300 count=40 min_count=0 profile_info->sum_max=257406300 ... ~60 similar lines with min_count=0
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 --- Comment #1 from Teresa Johnson 2012-12-13 14:45:01 UTC --- I'm really surprised that using --param hot-bb-count-ws-permille=950 didn't help, since even fewer things should look hot enough to inline than before the revision. Would you send me the new -fdump-ipa-inline output? Thanks, Teresa
[Bug c++/55652] [4.8 Regression] ICE (segfault) with templates and structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55652 --- Comment #3 from Jakub Jelinek 2012-12-13 14:35:22 UTC --- Author: jakub Date: Thu Dec 13 14:35:12 2012 New Revision: 194479 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194479 Log: PR c++/55652 * typeck2.c (merge_exception_specifiers): Don't call operand_equal_p if noex is NULL. * g++.dg/cpp0x/noexcept19.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug target/55673] Reversed before/after handling in sparc_emit_membar_for_model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55673 Eric Botcazou changed: What|Removed |Added Target||sparc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-13 CC||ebotcazou at gcc dot ||gnu.org, rth at gcc dot ||gnu.org Target Milestone|--- |4.7.3 Summary|[SPARC] Transposed |Reversed before/after |before-after in |handling in |sparc_emit_membar_for_model |sparc_emit_membar_for_model |() | Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-12-13 14:34:35 UTC --- The 4.7.x series is (potentially) affected as well. Yes, that seems right to me, but I'll let Richard look into it.
[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476
--- Comment #7 from Richard Biener 2012-12-13
13:49:47 UTC ---
Reduced testcase:
static int Wv10a __attribute__((weakref ("Wv10b")));
static int Wv10b __attribute__((weakref ("wv10")));
extern int wv10;
extern void abort (void);
int main ()
{
if (!!&Wv10a)
abort ();
return 0;
}
fails to link at -O1 works with -O0.
>From .000i.cgraph:
Reclaiming functions:
Reclaiming variables:
Clearing address taken flags:
Trivially needed variables:
Removing variables: Wv10a
Final Symbol table:
...
Breakpoint 5, varpool_remove_unreferenced_decls ()
at /space/rguenther/src/svn/trunk/gcc/varpool.c:405
405 varpool_remove_node (node);
(gdb) call debug_symtab_node((symtab_node)node)
Wv10a/0 (Wv10a) @0x768fa068
Type: variable
Visibility: external weak
References: Wv10b/1 (alias)
Referring: main/2 (addr)
Availability: available
Varpool flags: analyzed finalized
so it's still refered to.
if (cgraph_dump_file)
fprintf (cgraph_dump_file, "Trivially needed variables:");
FOR_EACH_DEFINED_VARIABLE (node)
{
if (node->analyzed
&& (!varpool_can_remove_if_no_refs (node)
/* We just expanded all function bodies. See if any of
them needed the variable. */
|| (!DECL_EXTERNAL (node->symbol.decl)
&& DECL_RTL_SET_P (node->symbol.decl
doesn't catch it because
(gdb) call debug_tree (node->symbol.decl)
unit size
align 32 symtab 0 alias set -1 canonical type 0x767f75e8 precision
32 min max
pointer_to_this >
addressable used static external weak SI file t.c line 1 col 12 size
unit size
align 32 context attributes
(mem:SI (symbol_ref/i:DI ("Wv10a") ) [0
Wv10a+0 S4 A32]) chain >
it has DECL_EXTERNAL set (but it also is TREE_STATIC and has RTL!).
On the 4.7 branch we simply checked whether the DECL had RTL but didn't bother
to check whether it does not have DECL_EXTERNAL set.
I'd say either revert to 4.7 behavior here or do
Index: varpool.c
===
--- varpool.c (revision 194472)
+++ varpool.c (working copy)
@@ -358,7 +358,8 @@ varpool_remove_unreferenced_decls (void)
&& (!varpool_can_remove_if_no_refs (node)
/* We just expanded all function bodies. See if any of
them needed the variable. */
- || (!DECL_EXTERNAL (node->symbol.decl)
+ || (!(DECL_EXTERNAL (node->symbol.decl)
+ && !TREE_STATIC (node->symbol.decl))
&& DECL_RTL_SET_P (node->symbol.decl
{
enqueue_node (node, &first);
testing reversal to 4.7 behavior.
[Bug gcov-profile/55674] [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||tejohnson at google dot com Target Milestone|--- |4.8.0
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #9 from Manuel López-Ibáñez 2012-12-13 13:24:51 UTC --- Wsign-conversion was disabled for g++ by explicit request. I don't remember the details and Google seems unable to find the relevant discussion in gcc-patches.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-13 13:12:00 UTC --- > --- Comment #22 from Jakub Jelinek 2012-12-12 > 22:21:57 UTC --- > Created attachment 28942 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28942 > --param max-vartrack-reverse-op-size patch > > Another patch, to avoid adding reverse ops to VALUEs that already have lots of > locs, assuming for such locs it is unlikely going to be useful. > With the default of 50 (+ the previous sparc hack) in x86_64 -> sparc-solaris > cross the go1 testcase compiled in about 1.5 minutes, with 10 instead in 50 > seconds or so, with 100 in 3 minutes, etc. I've now retested the full sparcv9 reflect libgo test with this patch and the sparc hack: real 24:03.27 user 24:02.70 sys0.49 This is still way beyond the 5 min timeout (which isn't enforced for libgo compilations), but way better than 11 hours. With -fno-var-tracking-assignments, I get: real3:43.45 user3:43.00 sys0.33 Thanks. Rainer
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #161 from Markus Trippelsdorf 2012-12-13 12:59:59 UTC --- I've opened a new bug for the binary size increase issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
[Bug tree-optimization/53852] [4.8 Regression] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 --- Comment #6 from Richard Biener 2012-12-13 12:59:45 UTC --- Sven suggests sth like: Index: gcc/graphite-dependences.c === --- gcc/graphite-dependences.c (revision 194472) +++ gcc/graphite-dependences.c (working copy) @@ -461,13 +461,16 @@ compute_deps (scop_p scop, vec
[Bug gcov-profile/55674] New: [4.8 Regression] >20% size increase of lto/pgo binaries since r193747
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674 Bug #: 55674 Summary: [4.8 Regression] >20% size increase of lto/pgo binaries since r193747 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375#c144 onwards. Binaries build with "-flto -fprofile-use" increased more than 20% in size since revision 193747 went in. libxul's size increased ~20%: 34MB before, 42MB now. This also happens for simpler testcases, e.g tramp3d-v4.cpp (30% increase): 0.9MB before, 1.3M now. Setting "--param hot-bb-count-ws-permille" to lower values doesn't help.
[Bug target/55673] New: [SPARC] Transposed before-after in sparc_emit_membar_for_model()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55673
Bug #: 55673
Summary: [SPARC] Transposed before-after in
sparc_emit_membar_for_model()
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tomash.brec...@gmail.com
As for other architectures (compare with need_atomic_barrier_p() for instance),
in gcc/config/sparc/sparc.c:sparc_emit_membar_for_model() memory barrier for
ACQUIRE should be emitted _after_ the operation and memory barrier for RELEASE
should be emitted _before_ the operation, i.e.:
diff --git i/gcc/config/sparc/sparc.c w/gcc/config/sparc/sparc.c
index 4e9de98..fdc6374 100644
--- i/gcc/config/sparc/sparc.c
+++ w/gcc/config/sparc/sparc.c
@@ -11188,7 +11188,7 @@ sparc_emit_membar_for_model (enum memmodel model,
gcc_unreachable ();
}
- if (before_after & 1)
+ if (before_after & 2)
{
if (model == MEMMODEL_ACQUIRE
|| model == MEMMODEL_ACQ_REL
@@ -11200,7 +11200,7 @@ sparc_emit_membar_for_model (enum memmodel model,
mm |= StoreLoad | StoreStore;
}
}
- if (before_after & 2)
+ if (before_after & 1)
{
if (model == MEMMODEL_RELEASE
|| model == MEMMODEL_ACQ_REL
[Bug libstdc++/51823] [DR 198] [DR 2204] reverse iterator returns uninitialized values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51823 Jonathan Wakely changed: What|Removed |Added Status|NEW |SUSPENDED Summary|[DR 198] reverse iterator |[DR 198] [DR 2204] reverse |returns uninitialized |iterator returns |values |uninitialized values --- Comment #15 from Jonathan Wakely 2012-12-13 12:23:46 UTC --- Suspending pending resolution of Dave's issue: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3473.html#2204
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #89 from Richard Biener 2012-12-13 12:06:57 UTC --- Just to repeat, the ICEs are with checking enabled only (but possibly cover up for wong-code). I believe the correct solution will involve implementing the proposal for introducing explicit restrict tags and using that in the fortran frontend (removing the restrict qualification work). See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01011.html.
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #8 from loose at astron dot nl 2012-12-13 12:03:02 UTC --- OK, fine with me. It's only that I was caught by surprise that g++ did no longer warn about sign conversion. I can definitely live with an explicit -Wsign-conversion, though.
[Bug middle-end/55498] [devirt] trunk fails inline-devirt test #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-13 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-12-13 11:41:28 UTC --- Confirmed. It needs -O3 (or -fipa-cp-clone) to actually get to the point to devirtualize all indirect calls (thus inline print and one/twoStrategy). Jump functions: Jump functions of caller printf: Jump functions of caller main: callsite main/8 -> print/7 : param 0: CONST: twoStrategy callsite main/8 -> print/7 : param 0: CONST: oneStrategy good! Propagating constants: Not considering main for cloning; no hot calls. Not considering twoStrategy for cloning; no hot calls. Not considering two for cloning; no hot calls. Not considering oneStrategy for cloning; no hot calls. Not considering one for cloning; no hot calls. so it cloned print(), good! print.constprop.1/11 (print.constprop.1) @0x7f2c26dfa940 Type: function Visibility: References: twoStrategy/6 (addr) Referring: Clone of print/7 Availability: local Function flags: analyzed local finalized Called by: main/8 (3.00 per call) Calls: twoStrategy/6 (1.00 per call) twoStrategy/6 (1.00 per call) printf/9 (1.00 per call) printf/9 (1.00 per call) Has 2 outgoing edges for indirect calls. But the issue is that there are no return functions and thus we cannot discover the direct call for fn = indirect (); fn (); at IPA time even when indirect () returns just a constant. We need iteration for this at the moment. Or better, IPA-CP needs return functions implemented.
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #7 from Paolo Carlini 2012-12-13 11:29:24 UTC --- This is definitely by design, as the snippet I posted also clearly shows. The documentation could be maybe improved I agree, but it's a very general issue that it often gives more space to C than C++ because the latter is more recent in the development history of GCC. Maybe in this case we could repeat the example at the end and emphasize that we do *not* warn in C++ because it's indeed a common idiom in C++. Hey, C and C++ are two different languages, remember, and many details in the Standards are different also in basic (eg, no classes, no templates) areas.
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #6 from Jonathan Wakely 2012-12-13 11:25:37 UTC --- It gives it as an example then says "Warnings about conversions between signed and unsigned integers are disabled by default in C++ unless -Wsign-conversion is explicitly enabled." You only have to read the next paragraph.
[Bug target/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug target/55672] New: [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672
Bug #: 55672
Summary: [4.8 Regression] -fstack-check=generic ICEs in
print_reg, at config/i386/i386.c:13868
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: i?86-*-*
int main ()
{
int x[8];
if (x[0] != 4)
__builtin_abort ();
return 0;
}
./cc1 -quiet run-id-pr47653.i -O -fstack-check=generic -m32
run-id-pr47653.i: In function 'main':
run-id-pr47653.i:7:1: internal compiler error: in print_reg, at
config/i386/i386.c:13868
This is the
FAIL: gcc.dg/graphite/run-id-pr47653.c (internal compiler error)
FAIL: gcc.dg/graphite/run-id-pr47653.c (test for excess errors)
WARNING: gcc.dg/graphite/run-id-pr47653.c compilation failed to produce
executable
FAIL on x86_64 32-bit testing.
[Bug lto/55660] [4.7 Regression] ICE instead of some warning during lto build with supplied different options (-funsigned-char vs none)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55660 Richard Biener changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] ICE|[4.7 Regression] ICE |instead of some warning |instead of some warning |during lto build with |during lto build with |supplied different options |supplied different options |(-funsigned-char vs none) |(-funsigned-char vs none) Known to fail|4.8.0 | --- Comment #4 from Richard Biener 2012-12-13 11:13:53 UTC --- Fixed on trunk sofar.
[Bug lto/55660] [4.7/4.8 Regression] ICE instead of some warning during lto build with supplied different options (-funsigned-char vs none)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55660 --- Comment #3 from Richard Biener 2012-12-13 11:13:19 UTC --- Author: rguenth Date: Thu Dec 13 11:13:13 2012 New Revision: 194473 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194473 Log: 2012-12-13 Richard Biener PR lto/55660 * tree-streamer.c (record_common_node): Check that we are not recursively pre-loading nodes we want to skip. Handle char_type_node appearing as part of va_list_type_node. * gcc.dg/lto/pr55660_0.c: New testcase. * gcc.dg/lto/pr55660_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr55660_0.c trunk/gcc/testsuite/gcc.dg/lto/pr55660_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer.c
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #5 from loose at astron dot nl 2012-12-13 11:09:43 UTC --- If this is by design, then the documentation is buggy. Here's a literal quote form the man page of g++ -Wconversion Warn for implicit conversions that may alter a value. This includes conversions between real and integer, like "abs (x)" when "x" is "double"; conversions between signed and unsigned, like "unsigned ui = -1"; and conversions to smaller types, like "sqrtf (M_PI)". Do not warn for explicit casts like "abs ((int) x)" and "ui = (unsigned) -1", or if the value is not changed by the conversion like in "abs (2.0)". Warnings about conversions between signed and unsigned integers can be disabled by using -Wno-sign-conversion. For C++, also warn for confusing overload resolution for user- defined conversions; and conversions that will never use a type conversion operator: conversions to "void", the same type, a base class or a reference to them. Warnings about conversions between signed and unsigned integers are disabled by default in C++ unless -Wsign-conversion is explicitly enabled. It explicitly gives the example "unsigned ui = -1" as an example. Furthermore, older g++ compilers used to give this warning. I tried it with g++ 4.1.2 and it properly gives a warning. I also find it a bit counter-intuitive that gcc *does* warn about it, whereas g++ does *not*.
[Bug rtl-optimization/55141] [4.8 Regression] wrong code with -fno-split-wide-types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55141 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-12-13 11:01:24 UTC --- Fixed.
[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478 --- Comment #8 from Richard Biener 2012-12-13 10:46:00 UTC --- (In reply to comment #5) > As for the PRE issue - we indeed seem to not release SSA temporaries > created by PRE. I'll look into that. Fixed with 2012-12-13 Richard Biener * tree-ssa-pre.c (get_representative_for): Adjust dumping. Mark created SSA names for release. (eliminate_bb): Insert only when expr is not NULL.
[Bug tree-optimization/54570] [4.8/4.9 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54570 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #24 from Steven Bosscher 2012-12-13 10:44:22 UTC --- .
[Bug bootstrap/54718] [4.8 regression] ICE in remap_gimple_stmt, at tree-inline.c:1468
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54718 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #12 from Richard Biener 2012-12-13 10:43:54 UTC --- I believe the ICE has been fixed.
[Bug rtl-optimization/55667] [4.7 regression] -O1 enables frame pointer push to move around on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55667 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #3 from Richard Biener 2012-12-13 10:42:56 UTC --- It's a feature. Unwind information is now correctly produced for the prologue which means we can (finally) schedule it freely. You can try -fno-schedule-insns2.
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #4 from Paolo Carlini 2012-12-13 10:41:49 UTC --- I agree, I suspected it was by the design. Since Manuel worked on this, let's wait a bit before closing the Bug.
[Bug lto/55669] [4.8 Regression] ICE : in cgraph_mark_address_taken_node, at cgraph.c:1409
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55669 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/55668] Incorrect lookup for template member of dependent template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55668 --- Comment #3 from Jonathan Wakely 2012-12-13 10:40:23 UTC --- Very similar to PR 55576, the name foo<0> should be looked up in the scope of A
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #3 from Jonathan Wakely 2012-12-13 10:37:34 UTC --- This is a common idiom in C++ and shouldn't warn e.g. static const size_type npos = -1;
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 --- Comment #2 from Jonathan Wakely 2012-12-13 10:35:58 UTC --- Surely this is by design, as documented: Warnings about conversions between signed and unsigned integers are disabled by default in C++ unless -Wsign-conversion is explicitly enabled.
[Bug c++/55671] -Wconversion fails to warn for sign-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55671 Paolo Carlini changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-12-13 10:33:48 UTC --- Looks like, if we want this is trivial to change: Wsign-conversion C ObjC C++ ObjC++ Var(warn_sign_conversion) LangEnabledBy(C ObjC,Wconversion) Warn for implicit type conversions between signed and unsigned integers Manuel, can you look into this?
