[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54731
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||ramana at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18
08:37:02 UTC ---
Can you still reproduce this?
Perhaps related to PR54499 which has been fixed, though arm backend doesn't
call final_start_function and final_end_function in its arm_output_mi_thunk, so
it won't have any debug info for the thunk unlike targets that do call that
(e.g. config/{i386,rs6000,s390,aarch64} etc.). If you don't want to emit insns
in the thunk by creating RTL for them and call final on it, just take a look
what s390 does.
[Bug libstdc++/55727] New: better support for dynamic allocation of over-aligned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727
Bug #: 55727
Summary: better support for dynamic allocation of over-aligned
types
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org
Created attachment 28991
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28991
simple testcase for new
Hello,
I just tested the alignas support in GCC 4.8 and wondered how far the C++11
spec defines behavior of dynamic allocation of over-aligned types. Because,
with GCC 4.8, dynamic allocation via new or std::allocator (e.g. in
std::vector) results in unaligned placement. I quote the relevant parts of the
spec below, because I believe GCC could be much more helpful to developers.
I believe a must-have is that if dynamic allocation of an over-aligned type
would result in misalignment, the allocatio fails (3.11.9, 17.6.3.5.6). Perfect
would be a compile-time failure, which is theoretically possible. Runtime
errors resulting from misaligned allocation are often hard to debug, therefore
it would be *very* helpful to get an early warning about misalignment.
As I understand it, the C++ spec allows for GCC to also just do the right thing
automatically, which would be my preferred solution. So when I'd do:
struct alignas(128) Foo { int x; };
Foo *f = new Foo;
I'd (per default) get a pointer f that is aligned as requested (without having
to overload new/delete). The same would be very important for std::vectorFoo.
Right now it does not even suffice to reimplement new/delete inside Foo to make
std::vectorFoo work.
C++11 spec quotes:
3.9.2.3 Pointers to over-aligned types (3.11) have no special representation,
but their range of valid values is restricted by the extended alignment
requirement. This International Standard specifies only two ways of obtaining
such a pointer: taking the address of a valid object with an over-aligned type,
and using one of the runtime pointer alignment functions. An implementation may
provide other means of obtaining a valid pointer value for an over-aligned
type.
3.11.9 a request for runtime allocation of dynamic storage for which the
requested alignment cannot be honored shall be treated as an allocation
failure
5.3.4.1 It is implementation-defined whether over-aligned types are supported
(3.11).
5.3.4.14 The block of storage is assumed to be appropriately aligned and of
the requested size.
17.6.3.5.6 If the alignment associated with a specific over-aligned type is
not supported by an allocator, instantiation of the allocator for that type may
fail. The allocator also may silently ignore the requested alignment. [ Note:
Additionally, the member function allocate for that type may fail by throwing
an object of type std::bad_alloc. — end note
20.6.9.1.5 Returns: A pointer to the initial element of an array of storage of
size n * sizeof(T), aligned appropriately for objects of type T. It is
implementation-defined whether over-aligned types are supported (3.11).
[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727 --- Comment #1 from Matthias Kretz kretz at kde dot org 2012-12-18 08:53:24 UTC --- Created attachment 28992 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28992 simple testcase for std::vector
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Conrad conradsand.arma at gmail dot com changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #4 from Conrad conradsand.arma at gmail dot com 2012-12-18 08:55:23 UTC --- Compiling the invalid test.cpp (original attachment) under 4.8.0 20121209 (x86_64) also works, when it shouldn't. The code presented in Comment #3 by Jonathan Wakely also results in a linked error when using 4.8.0 20121209. Should this bug be upgraded to P2, given its wide ranging effects ?
[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727
--- Comment #2 from Matthias Kretz kretz at kde dot org 2012-12-18 09:11:41
UTC ---
(In reply to comment #0)
Right now it does not even suffice to reimplement new/delete inside Foo to
make
std::vectorFoo work.
Sorry, this statement seems to be wrong. The issue that I actually have is of
the form:
from my library:
struct alignas(32) A { ... }; //overloads new/delete for correct alignment
different library:
templatetypename T struct B { T x; };
application code:
std::vectorBA
The members of the vector are now misaligned because obviously the new/delete
overloads in A are not used. But the alignment information from A is passed on
to B so it could be used in the allocator of std::vector.
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #44 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 09:14:13 UTC --- Can't reproduce on x86_64-linux with current trunk at -O3 -g -ffast-math, both with LRA and when LRA is disabled. From what I understood, this bug used to be present on darwin, but went away two years ago, then it got reopened for x86_64-linux in July and apparently doesn't reproduce anymore either. So, is this broken anywhere now?
[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 ubizjak at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-12-18 09:54:17 UTC --- CC author of stack realignment functionality.
[Bug libgcj/55716] [4.8 Regression] gjavah throws an exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55716 --- Comment #5 from Andrew Haley aph at gcc dot gnu.org 2012-12-18 10:00:29 UTC --- Author: aph Date: Tue Dec 18 10:00:18 2012 New Revision: 194574 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194574 Log: PR gcc/55716 [4.8 Regression] gjavah throws an exception Modified: trunk/libjava/classpath/ChangeLog
[Bug libgcj/55716] [4.8 Regression] gjavah throws an exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55716 Andrew Haley aph at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Andrew Haley aph at gcc dot gnu.org 2012-12-18 10:01:39 UTC --- A comment must go here, apparently.
[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716 --- Comment #45 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 10:23:59 UTC --- I've bisected this and the bug went away (or has gone latent) with http://gcc.gnu.org/viewcvs?root=gccview=revrev=189915 There is a huge number of changes in *.optimized dumps, mainly D.N DECL_UID numbers but also SSA_NAME versions, if I abstract from those, the only real change is in a comparison: - x_15 = MIN_EXPR x_572, x_317; + x_382 = MIN_EXPR x_572, x_317; ... - x_89 = MIN_EXPR x_17, x_552; + x_95 = MIN_EXPR x_17, x_372; x_320 = aaa11.v0011; - x_384 = MAX_EXPR x_89, x_320; - aaa13.dt = x_384; - if (prephitmp.1593_1033 2) + x_15 = MAX_EXPR x_95, x_320; + aaa13.dt = x_15; + if (prephitmp.1593_1034 2) ... bb 100: - if (x_342 x_384) + if (x_15 x_342) (x_342 is the same thing in both cases, the vs. is probably the result of canonicalizing the comparison based on SSA_NAME versions). Anyway, is it really worth it to have this open as P1 on questionable testcase (well, questionable is mainly whether the testcase doesn't assume IEEE 754 semantics to make -ffast-math invalid for it) where the problem is just latent (and unclear whether it is a compiler issue at all)?
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 10:30:12 UTC --- So not a bug then?
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-18 10:46:57 UTC --- (In reply to comment #4) Should this bug be upgraded to P2, given its wide ranging effects ? If it was a serious problem it would have been reported before by more people.
[Bug rtl-optimization/55717] [4.8 Regression] ICE in form_sum, at reload.c:5400
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55717 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 10:50:51 UTC --- Author: jakub Date: Tue Dec 18 10:50:47 2012 New Revision: 194575 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194575 Log: PR debug/55717 * rtlhooks-def.h (RTL_HOOKS_GEN_LOWPART_NO_EMIT): Define to gen_lowpart_if_possible. (gen_lowpart_no_emit_general): Remove prototype. * rtlhooks.c (gen_lowpart_no_emit_general): Removed. * simplify-rtx.c (simplify_unary_operation_1, simplify_binary_operation_1): Continue simplifying if rtl_hooks.gen_lowpart_no_emit returns NULL_RTX. * dwarf2out.c (mem_loc_descriptor) case TRUNCATE: Handle truncation like lowpart SUBREG. * testsuite/g++.dg/opt/pr55717.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr55717.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/rtlhooks-def.h trunk/gcc/rtlhooks.c trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54114] [4.8 Regression] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||WONTFIX --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 11:01:24 UTC --- variable tracking : 0.08 ( 1%) usr 0.01 ( 3%) sys 0.11 ( 1%) wall 3165 kB ( 3%) ggc var-tracking dataflow : 0.36 ( 4%) usr 0.00 ( 0%) sys 0.38 ( 4%) wall 226 kB ( 0%) ggc var-tracking emit : 0.31 ( 3%) usr 0.00 ( 0%) sys 0.36 ( 4%) wall 2186 kB ( 2%) ggc for me, I'd call this insignificant, given that it was really a debug info correctness fix. We have PR54402 which tracks cases where the slowdown is actually significant.
[Bug target/55718] [4.8 Regression] ICE in gen_reg_rtx, at emit-rtl.c:866
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55718 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-18 AssignedTo|unassigned at gcc dot |krebbel at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-12-18 11:30:06 UTC --- Created attachment 28993 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28993 Experimental fix Starting with http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00088.html UNSPEC GOTENTs are accepted as legitimate address what leads to this error. For the strlen implementation we subtract the result from the source pointer. In the testcase the subtraction is done in a mode smaller than pointer size (SImode). The source pointer is the address of a global symbol in the GOT. Resolving the subreg on the address reload generates: (const:DI (plus:DI (unspec:DI [ (symbol_ref:DI (temp) [flags 0x440] var_decl 0x200060095f0 temp) ] UNSPEC_GOTENT) (const_int 4 [0x4]))) Instead of just letting it pass legitmize_pic_address tries to generate code for the add what needs an additional register. The attached patch fixes this.
[Bug rtl-optimization/55717] [4.8 Regression] ICE in form_sum, at reload.c:5400
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55717 --- Comment #7 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-12-18 11:35:33 UTC --- (In reply to comment #5) Created attachment 28987 [details] gcc48-pr55717.patch Untested fix. Instead of returning very likely bogus value x this patch returns NULL and let the callers deal with that as error (so they don't try that simplification, instead try some other or just punt at simplifying). Thanks. I've tested your patch on s390 and s390x. No regressions.
[Bug c++/55726] assignment of a scalar to a vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55726 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-18 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 11:35:43 UTC --- Confirmed. Does it work with C?
[Bug rtl-optimization/55717] [4.8 Regression] ICE in form_sum, at reload.c:5400
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55717 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 11:37:48 UTC --- Fixed.
[Bug c++/55726] assignment of a scalar to a vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55726 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-12-18 11:39:22 UTC --- no gcc -Ofast -march=corei7 assign.c -std=c99 assign.c: In function ‘main’: assign.c:9:21: error: incompatible types when initializing type ‘float32x4_t’ using type ‘float’ float32x4_t va = a;
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-18 12:06:21 UTC --- --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 10:30:12 UTC --- So not a bug then? I don't think so: even on x86_64-unknown-linux-gnu, when building an i686-unknown-linux-gnu compiler with an unbundled gcc 4.4 (which does support -static-libstdc++) where the 32-bit libstdc++.so.6 doesn't live in /usr/lib, but only in /vol/gcc-4.4/lib, the build tools are the only ones that don't run. If it were host and build tools alike, I'd agree, but the host tools are fine, as they were before the cxx-conversion. Rainer
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 12:09:52 UTC --- If you don't add that /vol/gcc-4.4/lib/ to ld.so.conf (or ld.so.conf.d), it is your responsibility to build with LD_LIBRARY_PATH, otherwise you are bootstrapping with a non-working C++ compiler.
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-12-18 12:12:32 UTC --- --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 12:09:52 UTC --- If you don't add that /vol/gcc-4.4/lib/ to ld.so.conf (or ld.so.conf.d), it is your responsibility to build with LD_LIBRARY_PATH, otherwise you are bootstrapping with a non-working C++ compiler. Not if you build with -static-libstdc++, which does work for e.g. go1 before the cxx-conversion and cc1* afterwards, just not for the build tools. That's what this is all about. Rainer
[Bug c++/55728] New: std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728
Bug #: 55728
Summary: std::bad_function_call has misleading what() result
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
cat t.cc EOF
#include functional
#include iostream
int main()
{
try
{
std::functionvoid()()();
}
catch( std::exception const e )
{
std::cout e.what() std::endl;
}
}
EOF
g++ -std=c++11 -o t t.cc
t
# gives me std::exception
Not wrong, but std::bad_function_call would have saved me some debug time.
[Bug fortran/55729] New: Problem with sum intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55729 Bug #: 55729 Summary: Problem with sum intrinsic Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pmarguin...@hotmail.com Created attachment 28994 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28994 source code $ /opt/softs/gnu/4.7.0/bin/gfortran -c init_isba_sbl.F90 init_isba_sbl.F90: In function ‘MAIN__’: init_isba_sbl.F90:1:0: error: mismatching comparison operand types real(kind=4) integer(kind=8) if (D.1941 0) goto D.1942; else goto D.1943; init_isba_sbl.F90:1: confused by earlier errors, bailing out
[Bug c/55695] Miscompilation of pow() sqrt() using musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55695 ojab ojab at ojab dot ru changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from ojab ojab at ojab dot ru 2012-12-18 12:45:57 UTC --- Closing per http://www.openwall.com/lists/musl/2012/12/18/6
[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 12:46:52 UTC --- Bumping the limit to assert on to off-by-two doesn't fix all cases (I can hand you a testcase if you like...)
[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (number_of_iterations)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 13:12:39 UTC --- Author: rguenth Date: Tue Dec 18 13:12:34 2012 New Revision: 194578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194578 Log: 2012-12-18 Richard Biener rguent...@suse.de PR tree-optimization/5 * tree-ssa-loop-niter.c (idx_infer_loop_bounds): Properly analyze evolution of the index for the loop it is used in. * tree-scalar-evolution.c (instantiate_scev_name): Take inner loop we will be creating a chrec for. Generalize fix for PR40281 and prune invalid SCEVs. (instantiate_scev_poly): Likewise - pass down inner loop we will be creating a chrec for. (instantiate_scev_binary): Take and pass through inner loop. (instantiate_array_ref): Likewise. (instantiate_scev_convert): Likewise. (instantiate_scev_not): Likewise. (instantiate_scev_3): Likewise. (instantiate_scev_2): Likewise. (instantiate_scev_1): Likewise. (instantiate_scev_r): Likewise. (resolve_mixers): Adjust. (instantiate_scev): Likewise. * gcc.dg/torture/pr5.c: New testcase. * gcc.dg/vect/vect-iv-11.c: Adjust. Added: trunk/gcc/testsuite/gcc.dg/torture/pr5.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-iv-11.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-niter.c
[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727 --- Comment #3 from Matthias Kretz kretz at kde dot org 2012-12-18 13:26:21 UTC --- (In reply to comment #2) (In reply to comment #0) Right now it does not even suffice to reimplement new/delete inside Foo to make std::vectorFoo work. Sorry, this statement seems to be wrong. After more investigation I see that my original statement was right. The default allocator uses ::operator new(size_t) instead of T::operator new - and obviously it has to use the global one because allocation and construction are split into two functions. I just created an allocator class that uses posix_memalign and __alignof to implement an allocator as I'd like to have for a proof of concept. If you are interested, I can patch the new_allocator class to support over-alignment (while still using operator new). Would you be interested?
[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (number_of_iterations)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 13:29:52 UTC --- Fixed.
[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz 2012-12-18 13:39:45 UTC --- Bumping the limit to assert on to off-by-two doesn't fix all cases (I can hand you a testcase if you like...) Yep, i guess it just depends on how many calls we diverge. I will take a look today after meeting. Honza
[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 13:41:07 UTC --- Created attachment 28995 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28995 gcc48-pr55562.patch Broken by the http://gcc.gnu.org/viewcvs?root=gccview=revrev=192969 sbitmap changes. modulo-sched.c seemed to be using sbitmap_a_and_b_cg in 4 places, that change replaced that by bitmap_and, but apparently the new function only returns non-zero (something changed) if destination sbitmap has popcount. sbitmap_a_and_b_cg on the other side asserted it doesn't have popcount.
[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 13:47:34 UTC --- Can somebody please test this on ppc? I'll bootstrap/regtest it on x86_64-linux and i686-linux momentarily.
[Bug rtl-optimization/55730] New: [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55730 Bug #: 55730 Summary: [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: powerpc64-linux Created attachment 28996 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28996 preprocessed source /usr/lib64/gcc/powerpc64-suse-linux/4.8/cc1 -fpreprocessed format_pack.i -msecure-plt -quiet -dumpbase format_pack.c -mcpu=power4 -auxbase-strip .libs/format_pack.o -g -O2 -Wall -Werror=implicit-function-declaration -Werror=missing-prototypes -std=c99 -version -fvisibility=hidden -fmessage-length=0 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fno-strict-aliasing -fno-builtin-memcmp -fPIC -o format_pack.s GNU C (SUSE Linux) version 4.8.0 20121217 [trunk revision 194556] (powerpc64-suse-linux) compiled by GNU C version 4.8.0 20121217 [trunk revision 194556], GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (SUSE Linux) version 4.8.0 20121217 [trunk revision 194556] (powerpc64-suse-linux) compiled by GNU C version 4.8.0 20121217 [trunk revision 194556], GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 95572fc9d0aa2e1ae6283f447379255d (clobber:QI (const_int 0 [0]))../../src/mesa/main/format_pack.c: In function 'pack_float_RGB565': ../../src/mesa/main/format_pack.c:467:1: internal compiler error: in mem_loc_descriptor, at dwarf2out.c:12725 } ^ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions.
[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55730 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|debug Target Milestone|--- |4.8.0
[Bug tree-optimization/55731] New: Issue with complete innermost loop unrolling (cunrolli)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55731 Bug #: 55731 Summary: Issue with complete innermost loop unrolling (cunrolli) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ysrum...@gmail.com CC: hubi...@ucw.cz, izamya...@gmail.com I attached 2 test-cases extracted from important benchmark at which clang and icc outperform gcc for x86 target (atom). For 1st test-case (t.c) cunrolli phase does not perform complete loop unrolling with the following message (test was compiled with -O3 -funroll-loops options): Loop size: 23 Estimated size after unrolling: 33 Not unrolling loop 1: size would grow. but it is unrolled by cunroll phase: Loop size: 24 Estimated size after unrolling: 32 Unrolled loop 1 completely (duplicated 2 times). I wonder why this loop was not unrolled by cunrolli? We lost a lot of optimizations for unrolled loop such as Constant (address) Propagation, Dead code elimination etc. and got non-optimal binaries. For comparsion I added another test (t2.c) with successfull complete unrolling by cunrolli, at which we can see that all assignments to local array 'b' were properly propagated and deleted but we don't have such transformations for 1st test-case.
[Bug tree-optimization/55731] Issue with complete innermost loop unrolling (cunrolli)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55731 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com 2012-12-18 14:23:30 UTC --- Created attachment 28997 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28997 testcase1
[Bug tree-optimization/55731] Issue with complete innermost loop unrolling (cunrolli)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55731 --- Comment #2 from Yuri Rumyantsev ysrumyan at gmail dot com 2012-12-18 14:24:05 UTC --- Created attachment 28998 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28998 testcase2
[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55201 --- Comment #2 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2012-12-18 14:28:31 UTC --- Author: ian Date: Tue Dec 18 14:28:24 2012 New Revision: 194581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194581 Log: libgo: Link against libatomic. ./: PR go/55201 * Makefile.def (all-target-libgo): Depend on all-target-libatomic. * Makefile.in: Regenerate. gcc/go: PR go/55201 * gospec.c (LIBATOMIC): Define. (LIBATOMIC_PROFILE): Define. (lang_specific_driver): Add LIBATOMIC[_PROFILE] option. gcc/testsuite: * lib/go.exp (go_link_flags): Add libatomic location to flags and ld_library_path. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/gcc/go/ChangeLog trunk/gcc/go/gospec.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/go.exp trunk/libgo/Makefile.am trunk/libgo/Makefile.in
[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55730 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 14:37:47 UTC --- Reducing.
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 14:39:55 UTC --- Author: rguenth Date: Tue Dec 18 14:39:49 2012 New Revision: 194582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194582 Log: 2012-12-18 Richard Biener rguent...@suse.de PR middle-end/54838 * cfgloopmanip.c (fix_loop_structure): Re-discover latch edges first and mark loops for removal if no latch edges remain. Properly re-create LOOPS_HAVE_FALLTHRU_PREHEADERS. * loop-init.c (loop_optimizer_finalize): Set LOOPS_MAY_HAVE_MULTIPLE_LATCHES. * g++.dg/torture/pr54838.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr54838.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/loop-init.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 14:40:28 UTC --- Fixed.
[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55201 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2012-12-18 14:45:00 UTC --- Fixed.
[Bug target/55642] [4.8 Regression] Invalid thumb code generated (thumb conditional instruction should be in IT block)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55642 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution||FIXED --- Comment #6 from ktkachov at gcc dot gnu.org 2012-12-18 14:45:31 UTC --- Fixed.
[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55730
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18
14:51:11 UTC ---
Reduced with a cross from x86_64 configured with --target=powerpc64-suse-linux
--with-cpu-64=power4 --enable-secureplt --with-long-double-128
--enable-languages=c,c++
typedef int GLint;
typedef unsigned char GLubyte;
typedef unsigned short GLushort;
typedef float GLfloat;
typedef union {
GLfloat f;
GLint i;
} fi_type;
void pack_float_GR88 (void *dst)
{
GLushort *d = ((GLushort *) dst);
GLubyte r, g;
fi_type __tmp;
if (__tmp.i 0)
g = (GLubyte) 0;
else
{
__tmp.f = __tmp.f * (255.0F/256.0F) + 32768.0F;
g = (GLubyte) __tmp.i;
}
*d = (((g) 8) | (r));
}
./cc1 -fpreprocessed format_pack.3.i -msecure-plt -quiet -mcpu=power4 -g -O2
(clobber:QI (const_int 0 [0]))format_pack.3.i: In function 'pack_float_GR88':
format_pack.3.i:22:1: internal compiler error: in mem_loc_descriptor, at
dwarf2out.c:12729
}
^
0x76b280 mem_loc_descriptor(rtx_def*, machine_mode, machine_mode,
var_init_status)
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:12729
0x76c090 loc_descriptor
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13068
0x76b85a loc_descriptor
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:12894
0x76c4c4 dw_loc_list_1
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13167
0x76cc5c dw_loc_list
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13423
0x76dab1 loc_list_from_tree
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:13808
0x771ea7 add_location_or_const_value_attribute
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:15302
0x77a85b gen_variable_die
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18415
0x77fbce gen_decl_die
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20051
0x77e3aa process_scope_var
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19595
0x77e416 decls_for_scope
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19617
0x779393 gen_subprogram_die
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:18004
0x77f84d gen_decl_die
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:19984
0x780836 dwarf2out_decl(tree_node*)
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20366
0x780870 dwarf2out_function_decl
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:20374
0x7e6ccc rest_of_handle_final
/space/rguenther/src/svn/trunk/gcc/final.c:4302
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/55565] [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565 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 2012-12-18 14:53:52 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=190339 which changed *.optimized dump tiny bit. I'd say the testcase is questionable, on such large routine assuming there can't be any floating point register moves is dubious.
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Conrad conradsand.arma at gmail dot com changed: What|Removed |Added Version|4.7.2 |4.8.0 --- Comment #6 from Conrad conradsand.arma at gmail dot com 2012-12-18 14:54:50 UTC --- If it was a serious problem it would have been reported before by more people. I'm not sure if the degree of popularity of a bug should diminish its seriousness. This is an accepts-invalid, rejects-valid, wrong-code bug, which is pretty nasty as far as bugs go. The use of C++ is expanding (including GCC's own code base), meaning this bug is going to bite more people as time goes on. However, I do understand that bugs which affect more people right now should get looked at first. Furthermore, given its wide ranging impact, perhaps fixing this bug in 4.7.x would not be doable (ie. too invasive). As such, I'll reassign this bug to 4.8.0.
[Bug c++/55724] [4.7/4.8 Regression] [C++11] Default type of a template value is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55724
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.7.3
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18
15:08:44 UTC ---
trunk now says:
t.C: In function 'int main()':
t.C:3:25: error: no matching function for call to 'f(S1)'
int main() { S1 s; f(s); }
^
t.C:3:25: note: candidate is:
t.C:2:38: note: templateclass T, T N void f(SN)
templatetypename T = int, T N void f(SN) {}
^
t.C:2:38: note: template argument deduction/substitution failed:
t.C:3:25: note: couldn't deduce template parameter 'N'
int main() { S1 s; f(s); }
^
[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
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-12-18 15:11:38
UTC ---
This is what we changed in reload for stack realignment:
diff --git a/gcc/reload1.c b/gcc/reload1.c
index f28b01c..9b81062 100644
--- a/gcc/reload1.c
+++ b/gcc/reload1.c
@@ -3663,8 +3663,11 @@ update_eliminables (HARD_REG_SET *pset)
frame_pointer_needed = 1;
for (ep = reg_eliminate; ep reg_eliminate[NUM_ELIMINABLE_REGS]; ep++)
{
- if (ep-can_eliminate ep-from == FRAME_POINTER_REGNUM
- ep-to != HARD_FRAME_POINTER_REGNUM)
+ if (ep-can_eliminate
+ ep-from == FRAME_POINTER_REGNUM
+ ep-to != HARD_FRAME_POINTER_REGNUM
+ (! SUPPORTS_STACK_ALIGNMENT
+ || ! crtl-stack_realign_needed))
frame_pointer_needed = 0;
if (! ep-can_eliminate ep-can_eliminate_previous)
@@ -3720,7 +3723,10 @@ init_elim_table (void)
ep-to = ep1-to;
ep-can_eliminate = ep-can_eliminate_previous
= (CAN_ELIMINATE (ep-from, ep-to)
- ! (ep-to == STACK_POINTER_REGNUM frame_pointer_needed));
+ ! (ep-to == STACK_POINTER_REGNUM
+ frame_pointer_needed
+ (! SUPPORTS_STACK_ALIGNMENT
+|| ! stack_realign_fp)));
}
#else
reg_eliminate[0].from = reg_eliminate_1[0].from;
LRA should have similar codes.
[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 #18 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-18 15:15:38 UTC --- (In reply to comment #16) I am puzzled as to why this issue with global-overflow-1.c and stack-overflow-1.c can't be triggered on x86_64 linux. The obvious change of -mtune=core2 seems to be insufficient to cause the failures.
[Bug tree-optimization/53198] [4.6/4.7 Regression] gcc wrongly emits array subscript is above array bounds for simple arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53198 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Known to fail|4.7.0, 4.8.0|4.7.2 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:16:16 UTC --- (In reply to comment #4) (In reply to comment #3) Created attachment 27801 [details] another testcase - from xorg mouse driver This warns with GCC 4.8 r192379: pr53198.c: In function ‘CheckProtocol’: pr53198.c:35:30: warning: array subscript is above array bounds [-Warray-bounds] for (i = 0; internalNames[i]; i++) ^ It doesn't warn with gcc 4.5.1 Doesn't warn any longer on trunk.
[Bug fortran/55732] New: -fno-automatic: Doesn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55732 Bug #: 55732 Summary: -fno-automatic: Doesn' Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org subroutine foo(i) integer :: i integer, allocatable :: j if (i == 1) j = 42 if (.not. allocated (j)) call abort () if (j /= 42) call abort () end call foo(1) call foo(2) end
[Bug debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54731 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org 2012-12-18 15:18:44 UTC --- I couldn't reproduce it on arm-eabi. Kyrill
[Bug tree-optimization/52588] false warning: array subscript is above array bounds: number of elements is 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52588 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:19:01 UTC --- Fixed for 4.8.0.
[Bug fortran/55733] New: -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 Bug #: 55733 Summary: -fno-automatic: Fails for scalar allocatables Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org -fno-automatic implies SAVE. However, it doesn't work for scalar allocatables: subroutine foo(i) integer :: i integer, allocatable :: j if (i == 1) j = 42 if (.not. allocated (j)) call abort () if (j /= 42) call abort () end call foo(1) call foo(2) end
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 --- Comment #9 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 15:19:55 UTC --- Author: aldyh Date: Tue Dec 18 15:19:43 2012 New Revision: 194583 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194583 Log: PR other/54324 * ansidecl.h (ATTRIBUTE_UNUSED): Do not set __attribute__ for GCC 3.4. Modified: trunk/include/ChangeLog trunk/include/ansidecl.h
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 15:20:40 UTC --- *** Bug 55732 has been marked as a duplicate of this bug. ***
[Bug fortran/55732] -fno-automatic: Doesn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55732 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 15:20:40 UTC --- Stupid bugzilla! *** This bug has been marked as a duplicate of bug 55733 ***
[Bug debug/55730] [4.8 Regression] ICE in mem_loc_descriptor, at dwarf2out.c:12725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55730
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-12-18
CC||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18
15:21:00 UTC ---
Even further reduced (-g -O2):
union U
{
float f;
int i;
};
void
foo (unsigned short *x, unsigned char y)
{
unsigned char g;
union U u;
if (u.i 0)
g = 0;
else
{
u.f = u.f * (255.0F / 256.0F) + 32768.0F;
g = (unsigned char) u.i;
}
*x = (g 8) | y;
}
[Bug middle-end/55045] ira.c:879:32: error: array subscript is above array bounds (for vax)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55045 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:23:35 UTC --- Doesn't reproduce for me anymore, thus fixed (likely either by my fixes or by Honzas unrollings).
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18
15:24:16 UTC ---
The following test case also fails; I think the problem is the string
components which isn't marked as TREE_STATIC:
! { dg-do run }
! { dg-options -fno-automatic }
!
subroutine foo()
logical, save :: first = .false.
character(len=:), allocatable :: str(:)
if (first) then
if (allocated (str)) call abort ()
str = [ABCDEF, ABCDEF ]
end if
if (.not. allocated (str)) call abort ()
if (len (str) /= 6) call abort ()
if (any (str(:)(1:6) /= ABCDEF)) call abort ()
end subroutine foo
call foo()
call foo()
end
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 --- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 15:26:50 UTC --- Author: aldyh Date: Tue Dec 18 15:26:27 2012 New Revision: 194584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194584 Log: PR other/54324 * tree-ssa-coalesce.c (struct ssa_name_var_hash): Remove union from template parameter. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-coalesce.c
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-18 15:29:59 UTC --- (In reply to comment #6) If it was a serious problem it would have been reported before by more people. I'm not sure if the degree of popularity of a bug should diminish its seriousness. If noone else has ever reported it in all the time it's been in GCC it's not causing a lot of problems, then it's not causing serious problems to most GCC users. It's not a regression and there's a workaround (qualify the names) so it's not P2. This is an accepts-invalid, rejects-valid, wrong-code bug, which is pretty nasty as far as bugs go. Almost any name lookup bug can be turned into all three categories, it doesn't alter its seriousness. The use of C++ is expanding (including GCC's own code base), meaning this bug is going to bite more people as time goes on. It will get fixed, it doesn't need to be P2 for that.
[Bug gcov-profile/55734] New: gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 Bug #: 55734 Summary: gcov-io.c uses builtins not available in non-GCC compilers Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: al...@gcc.gnu.org gcov-io.c uses the following builtins that are not available in non-GCC compilers or in older GCC's (pre 3.4): __builtin_popcountll __builtin_clzll
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-18 Component|c++ |libstdc++ Ever Confirmed|0 |1
[Bug tree-optimization/55731] Issue with complete innermost loop unrolling (cunrolli)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55731 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-18 Ever Confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:34:51 UTC --- The reason is that unrolling early can be harmful to for example vectorization and thus cunrolli restricts itself to obviously profitable cases. In this case the loop is not an inner loop - it doesn't have a containing loop and so growth is not allowed even with -O3 (we otherwise will fail to vectorize if the unrolled body ends up as part of other basic-blocks). It's a know issue that after cunroll there is no strong value-numbering pass that handles memory (there is DOM which only has weak memory handling). So, it's a trade-off we make, mostly for the sake of loop optimizations that do not handle unrolled loops well.
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Keywords||build Last reconfirmed||2012-12-18 Ever Confirmed|0 |1 Summary|gcov-io.c uses builtins not |[4.8 Regression] gcov-io.c |available in non-GCC|uses builtins not available |compilers |in non-GCC compilers Target Milestone|--- |4.8.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:37:47 UTC --- Confirmed.
[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 #15 from Jan Hubicka hubicka at ucw dot cz 2012-12-18 15:40:34 UTC --- 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. One way to get better differences is to disable the JIT :) Doesn't snappy allow us to measure things like startup time and other stuff where not much of JITed code is involved? So you have no way to measure up to which point more inlining is still beneficial. I will do some testing on SPEC on when the performance starts dropping. Setting limit to 890 seems bit dangerous. -Os can slow down the code considerably, so if 10% of time program will be running -Os code, we probably get measurable slowdowns overall. Thanks! Honza
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 15:45:17 UTC --- I have a proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00766.html ...which was deemed not sexy at all. So perhaps Richard or someone else can suggest another route?
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #3 from Teresa Johnson tejohnson at google dot com 2012-12-18 15:49:03 UTC --- In that thread, I had asked: --- If you prefer, I can simply inline the popcount/clz functionality into gcov-io.c directly (or at least when not using recent versions of GCC). But that in fact would be duplicating the code, when I thought Aldy's solution was trying to avoid that by providing the more general interfaces. Teresa --- but didn't get a response. Richard, is that your preferred route for fixing this issue? Thanks, Teresa On Tue, Dec 18, 2012 at 7:45 AM, aldyh at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 15:45:17 UTC --- I have a proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00766.html ...which was deemed not sexy at all. So perhaps Richard or someone else can suggest another route? -- 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/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:52:40 UTC --- (In reply to comment #3) In that thread, I had asked: --- If you prefer, I can simply inline the popcount/clz functionality into gcov-io.c directly (or at least when not using recent versions of GCC). But that in fact would be duplicating the code, when I thought Aldy's solution was trying to avoid that by providing the more general interfaces. Teresa --- but didn't get a response. Richard, is that your preferred route for fixing this issue? We already have popcount_hwi and clz_hwi available. Can't you piggy-back on that to provide (inline in gcov-io.c) popcountll and clzll? Why do you need the long long variants anyway?
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:53:42 UTC --- (In reply to comment #4) (In reply to comment #3) In that thread, I had asked: --- If you prefer, I can simply inline the popcount/clz functionality into gcov-io.c directly (or at least when not using recent versions of GCC). But that in fact would be duplicating the code, when I thought Aldy's solution was trying to avoid that by providing the more general interfaces. Teresa --- but didn't get a response. Richard, is that your preferred route for fixing this issue? We already have popcount_hwi and clz_hwi available. Can't you piggy-back on that to provide (inline in gcov-io.c) popcountll and clzll? Why do you need the long long variants anyway? You don't seem to: unsigned histo_bitvector[GCOV_HISTOGRAM_BITVECTOR_SIZE]; ... h_cnt += __builtin_popcountll (histo_bitvector[bv_ix]); so just use popcount_hwi.
[Bug fortran/55735] New: ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 Bug #: 55735 Summary: ICE with deferred-length strings in COMMON Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org I think the following test case it valid. In any case, an ICE is a bug. Vaguely related is PR 55733. block data character(len=:), pointer :: str(:) common /foo/ str end block data subroutine bar() character(len=:), pointer :: str common /foo/ str ! print *, len(str), ''//str//'' !ICE in gfc_conv_intrinsic_len print '(3a)', '',str(1:6),'' ! ICE in gfc_conv_variable end character(len=:), pointer :: str(:) common /foo/ str allocate (character(len=6) :: str(1)) str = ABCDEF call bar() end
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 15:59:28 UTC --- Maybe for BLOCK DATA something similar has to be done. Cf. PR 55735.
[Bug fortran/55735] ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 16:06:14 UTC --- Postscript: The example in comment 0 mixes a scalar and an array pointers. While the ICE occurs with either, the declaration should be consistent.
[Bug fortran/55729] Problem with sum intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55729 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 16:12:59 UTC --- Works for me with GCC 4.1 to 4.8: It compiles without any warning/error on x86-64-linux. What exactly is your GCC 4.7 version and which platform are you using? (gfortran -v shows this data. For instance, I used 4.7.2 20120920 [gcc-4_7-branch revision 191568] on x86_64-gnu-linux.) GCC 4.7.0 can is either the 4.7.0 version, released on 2012-03-22, or to any developer version between 2011-03-14 and that date. You could additionally re-check whether a newer GCC 4.7 or current GCC 4.8 fixes the issue.
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 16:19:33 UTC --- Created attachment 28999 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28999 proposed patch Oh, I didn't realize we always had the HWI variants available (inlined in hwint.h). Is something like this what you have in mind Richard?
[Bug other/54324] [4.8 Regression] GCC install document does not list minimum required g++ version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 --- Comment #11 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 16:22:11 UTC --- Author: aldyh Date: Tue Dec 18 16:21:57 2012 New Revision: 194586 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194586 Log: PR other/54324 * doc/install.texi (Tools/packages necessary for building GCC): Suggest --disable-stage1-checking for older GCC's. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #7 from Teresa Johnson tejohnson at google dot com 2012-12-18 16:24:13 UTC --- On Tue, Dec 18, 2012 at 7:53 AM, rguenth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18 15:53:42 UTC --- (In reply to comment #4) (In reply to comment #3) In that thread, I had asked: --- If you prefer, I can simply inline the popcount/clz functionality into gcov-io.c directly (or at least when not using recent versions of GCC). But that in fact would be duplicating the code, when I thought Aldy's solution was trying to avoid that by providing the more general interfaces. Teresa --- but didn't get a response. Richard, is that your preferred route for fixing this issue? We already have popcount_hwi and clz_hwi available. Can't you piggy-back on that to provide (inline in gcov-io.c) popcountll and clzll? Why do you need the long long variants anyway? You don't seem to: unsigned histo_bitvector[GCOV_HISTOGRAM_BITVECTOR_SIZE]; ... h_cnt += __builtin_popcountll (histo_bitvector[bv_ix]); so just use popcount_hwi. The complication seems to be that hwint is not currently available for libgcov.a (it is included by system.h which is not in libgcov.a). I thought this was why Aldy took the approach of splitting out the hwi routines into a separate helper file included by both hwint.c and gcov-io. I can see if there is a way to simplify this, but I'm not sure it is simple to include hwint into the gcov-io.c (and therefore libgcov.a). Teresa -- 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 fortran/55729] Problem with sum intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55729 --- Comment #2 from pmarguinaud at hotmail dot com 2012-12-18 16:25:01 UTC --- Hi Tobias, I use gfortran 4.7.0. It was build and installed by our admin, as you can see below : $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home_nfs/softs/gnu/4.7.0/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure CC=/usr/bin/gcc --prefix=/home_nfs/softs/gnu/4.7.0 Thread model: posix gcc version 4.7.0 (GCC) Our cluster is a SandyBridge with a RedHat 6.0; uname -a says : Linux login0 2.6.32-220.23.1.bl6.Bull.28.8.x86_64 #1 SMP Thu Jul 5 17:34:18 CEST 2012 x86_64 x86_64 x86_64 GNU/Linux I will try newer versions of gcc, as you suggest.
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Attachment #28999|0 |1 is obsolete|| --- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 16:25:49 UTC --- Created attachment 29000 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29000 proposed patch Duh, they're always available. Like this?
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #9 from Teresa Johnson tejohnson at google dot com 2012-12-18 16:31:08 UTC --- On Tue, Dec 18, 2012 at 8:25 AM, aldyh at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Attachment #28999|0 |1 is obsolete|| --- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-18 16:25:49 UTC --- Created attachment 29000 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29000 proposed patch Duh, they're always available. Like this? Things will build, but you will presumably get an undefined symbol in your libgcov.a, which would result in an undefined trying to build with -fprofile-generate. Can you verify that this works. I just checked with a similar change, which yields: $ nm gcc/libgcov.a | grep popc U popcount_hwi /home/tejohnson/extra/gcc_trunk_5_validate/bld-gcc/gcc/libgcov.a(_gcov.o): In function `__gcov_read_summary': libgcov.c:(.text+0x7f3): undefined reference to `popcount_hwi' collect2: error: ld returned 1 exit status Teresa -- 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 debug/54731] [4.8 regression] arm-elf/arm-eabisim crosses fails in make-check due to undefined LFE references: corrupt debug_line tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54731 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-18 16:37:21 UTC --- Fixed then.
[Bug fortran/55729] Problem with sum intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55729 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-18 16:39:51 UTC --- This appeared between revisions 180652, 2011-10-29 (OK), and 180989, 2011-11-04 (ICE), and has been fixed between revisions 188914, 2012-06-24 (still ICE), and 189336, 2012-07-06 (OK again). It looks like a duplicate of pr53732, fixed on trunk at revision 189292 and on 4.7 at revision 189341. *** This bug has been marked as a duplicate of bug 53732 ***
[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2012-12-18 16:39:47 UTC --- OK, we are inlining Inline summary for bool C::c1(float, float)/7 inlinable self time: 34 global time: 34 self size: 18 global size: 18 self stack: 0 global stack:0 estimated growth:-6 size:1.50, time:1.50, predicate:(true) size:3.50, time:2.50, predicate:(not inlined) size:0.50, time:0.50, predicate:(op0[ref offset: 64] changed) (not inlined) size:0.50, time:0.50, predicate:(op0[ref offset: 64] changed) size:2.00, time:2.00, predicate:(op0[ref offset: 64] changed || op1 changed) size:0.50, time:0.355000, predicate:(op0[ref offset: 96] changed) (not inlined) size:0.50, time:0.355000, predicate:(op0[ref offset: 96] changed) size:2.00, time:1.42, predicate:(op0[ref offset: 96] changed || op2 changed) calls: void B::b2()/12 function body not available loop depth: 0 freq: 723 size: 2 time: 11 callee size: 0 stack: 0 indirect call loop depth: 0 freq:1000 size: 5 time: 17 into Inline summary for void bar()/8 inlinable self time: 38 global time: 53 self size: 22 global size: 32 self stack: 0 global stack:0 size:14.50, time:8.849000, predicate:(true) size:3.00, time:2.00, predicate:(not inlined) calls: bool C::c1(float, float)/7 inlined loop depth: 0 freq:1000 size: 4 time: 13 callee size: 9 stack: 0 Stack frame offset 0, callee self size 0, callee size 0 void B::b2()/12 function body not available loop depth: 0 freq: 723 size: 2 time: 11 callee size: 0 stack: 0 indirect call loop depth: 0 freq:1000 size: 5 time: 17 double foo()/11 function body not available loop depth: 0 freq:1000 size: 2 time: 11 callee size: 0 stack: 0 void __cxa_guard_release(long long int*)/10 function body not available loop depth: 0 freq: 151 size: 2 time: 11 callee size: 0 stack: 0 op0 is compile time invariant int __cxa_guard_acquire(long long int*)/9 function body not available loop depth: 0 freq: 389 size: 3 time: 12 callee size: 0 stack: 0 op0 is compile time invariant ipa-inline-analysis figures out that we can devirtualize call to b3, but ipa-cp won't. So this seems another disagreement in between ipa-cp and ipa-prop... Honza
[Bug fortran/53732] [4.7/4.8 Regression] mismatching comparison operand types on compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53732 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||pmarguinaud at hotmail dot ||com --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-18 16:39:51 UTC --- *** Bug 55729 has been marked as a duplicate of this bug. ***
[Bug fortran/55735] ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2012-12-18 16:47:10 UTC --- (In reply to comment #1) Postscript: The example in comment 0 mixes a scalar and an array pointers. While the ICE occurs with either, the declaration should be consistent. I could be wrong, but I believe that the program in comment 0 is invalid. F2008: p. 116 A data pointer shall be storage associated only with data pointers of the same type and rank. Data pointers that are storage associated shall have deferred the same type parameters; corresponding nondeferred type parameters shall have the same value. I doubt that it is possible to catch the rank mismatch (except maybe under -fwhole-program with everything in one file).
[Bug gcov-profile/55734] [4.8 Regression] gcov-io.c uses builtins not available in non-GCC compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55734 --- Comment #10 from Aldy Hernandez aldyh at redhat dot com 2012-12-18 16:48:40 UTC --- Ah yes, now I remember. Yes, there is a problem with libgcov.a. I wasn't seeing it because I was only building cc1. You are correct Teresa, that is the reason for the gymnastics in my original patch. houston:/build/trunkboot/gcc$ nm libgcov.a |grep popc U popcount_hwi I will let you and Richard sort it out :).
[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 #16 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-18 17:03:52 UTC --- I did some measurements with tramp3d and in this case the default (999) gives the best performance: par. sizetime 999 955859 3.71752 990 933390 3.73969 980 904718 3.84547 ... 750 904718 3.84769 740 837654 7.67177 600 836024 8.80879
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #9 from Richard Henderson rth at gcc dot gnu.org 2012-12-18 17:14:37 UTC --- It doesn't look to me that the first two hunks of the patch are needed. The last hunk doesn't look like it should be considering either TYPE_PACKED of the parent structure, or TYPE_ALIGN of the field type, but rather using DECL_ALIGN of the field. Which ought already have been assigned by layout_decl via update_alignment_for_field. The biggest problem to me appears to be the entire ms_bitfield_layout_p block of code there, whose block comments talk about adjusting bitfields, and yet is firing for structures that contain no bitfields at all. That tells me that the logic higher in the block (or elsewere wrt bitfield_layout_p) is in error.
[Bug tree-optimization/55683] [4.8 Regression] ICE in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683
--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2012-12-18
17:15:51 UTC ---
Created attachment 29001
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29001
proposed patch
OK,
we know the argument is constant
addr_expr 0x77585700
type pointer_type 0x775741f8
type record_type 0x77560f18 C sizes-gimplified addressable
needs-constructing type_1 type_5 BLK
size integer_cst 0x773f7e40 constant 128
unit size integer_cst 0x773f7e60 constant 16
align 64 symtab 0 alias set 4 canonical type 0x77560f18 fields
field_decl 0x7755ca18 c2 context translation_unit_decl 0x77410170
D.1
full-name struct C
needs-constructor X() X(constX) this=(X) n_parents=0
use_template=0 interface-unknown
pointer_to_this pointer_type 0x775741f8 chain type_decl
0x7755aac8 C
public unsigned DI
size integer_cst 0x773f7dc0 constant 64
unit size integer_cst 0x773f7de0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x775741f8
constant
arg 0 var_decl 0x7755cda8 c type record_type 0x77560f18 C
addressable used static tree_1 tree_3 decl_5 decl_6 BLK file t.C line
25 col 12 size integer_cst 0x773f7e40 128 unit size integer_cst
0x773f7e60 16
align 128 context function_decl 0x77576900 bar
ipa_get_indirect_edge_target used when we estimate effect of inlining goes into
path looking up the binfo based on constant
if (TREE_CODE (t) != TREE_BINFO)
{
tree binfo;
binfo = gimple_extract_devirt_binfo_from_cst (t);
if (!binfo)
return NULL_TREE;
binfo = get_binfo_at_offset (binfo, anc_offset, otr_type);
if (!binfo)
return NULL_TREE;
return gimple_get_virt_method_for_binfo (token, binfo);
}
this code is missing in try_make_edge_direct_virtual_call that is actually
responsible for devirtualizing. I am testing the attached patch.
If I read this right, we should get the problem every time we devirtualize
based on static object. I am surprised this do not trigger in
testsuite/bootstrap.
Honza
[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 #17 from Jan Hubicka hubicka at ucw dot cz 2012-12-18 17:25:37 UTC --- I did some measurements with tramp3d and in this case the default (999) gives the best performance: par. sizetime 999 955859 3.71752 990 933390 3.73969 980 904718 3.84547 ... 750 904718 3.84769 740 837654 7.67177 600 836024 8.80879 Yep, tramp3d is unforutnately quite special case: we measure the number of instructions prior late optimization, while in tramp3d over 90% of code disappear as a result of inlining and further simplification, so we get GIGO problem... I am not sure how to handle these things in any resonable way I will test couple of values on spec2k this week and lets see how things scale elsewhere. Honza
[Bug bootstrap/50148] GCC fails to bootstrap with -O3 due to may be used uninitialized errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148 --- Comment #6 from Matt Hargett matt at use dot net 2012-12-18 17:26:54 UTC --- Applying the supplied patch reveals another issue underneath, which is a false positive: /work/mhargett/gcc-trunk-obj/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-obj/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange -floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o gengtype \ gengtype.o gengtype-lex.o gengtype-parse.o gengtype-state.o version.o errors.o libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a ../libbacktrace/.libs/libbacktrace.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a In file included from ../../gcc-trunk/libiberty/cp-demangle.c:876:0, from :51: ../../gcc-trunk/libbacktrace/elf.c: In function ‘elf_add’: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: ‘ehdr_view.len’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.len’ was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:876:0, from :51: ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: ‘ehdr_view.base’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.base’ was declared here struct backtrace_view ehdr_view; ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:516:10: error: ‘ehdr_view.data’ may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (ehdr, ehdr_view.data, sizeof ehdr); ^ In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0, from :51: ../../gcc-trunk/libbacktrace/elf.c:476:25: note: ‘ehdr_view.data’ was declared here struct backtrace_view ehdr_view; ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccQGEpYR.ltrans15.ltrans.o] Error 1 in libbacktrace/elf.c, elf_add() calls backtrace_get_view(..., ehdr_view). ehdr_view isn't initialized. backtrace_get_view() will return 1 and leave edhr_view uninitialized, but the potential uninitialized use of ehdr_view is guarded in get_elf() with a 'goto fail'. Therefore, the uninitialized ehdr_view would never get to backtrace_release_view(). Let me know if I should file a separate bug for this.
[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 --- Comment #5 from David Edelsohn dje at gcc dot gnu.org 2012-12-18 17:30:55 UTC --- I did a quick test on powerpc-ibm-aix and the patch seems to fix the problem. You should have access to a lot of PPC systems for testing.
[Bug c++/55724] [4.7/4.8 Regression] [C++11] Default type of a template value is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55724 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727 --- Comment #4 from Matthias Kretz kretz at kde dot org 2012-12-18 18:20:00 UTC --- Created attachment 29002 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29002 support for over-aligned types in new_allocator I finished my allocator to fix the issue and it was easy to port it over to new_allocator. So here's the patch. Questions: 1. I use sizeof(void*) for the natural alignment or alignof(std::max_align_t) for C++11. Is there a better way to do this? 2. I'm not sure you like the way I abuse enum for compile-time constants. May I use constexpr, or would that have to be ifdefed? 3. What's the proper integer type to use for pointer manipulation? I'd really like to write __p = ~__alignment_mask, but I don't see how to not breaking strict-aliasing with this. Note that new_allocator will compile to the same code as long as alignof(_Tp1) is = alignof(std::max_align_t). The extra code to handle alignment will only kick in for over-aligned types - and those want the extra complexity.
[Bug libstdc++/55727] better support for dynamic allocation of over-aligned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55727 Matthias Kretz kretz at kde dot org changed: What|Removed |Added Attachment #29002|0 |1 is obsolete|| --- Comment #5 from Matthias Kretz kretz at kde dot org 2012-12-18 18:30:43 UTC --- Created attachment 29003 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29003 updated the patch
[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 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-12-18 19:42:59 UTC --- LRA doesn't handle HARD_FRAME_POINTER_IS_FRAME_POINTER at all.
[Bug fortran/55735] ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 20:04:12 UTC --- (In reply to comment #2) (In reply to comment #1) Postscript: The example in comment 0 mixes a scalar and an array pointers. While the ICE occurs with either, the declaration should be consistent. I could be wrong, but I believe that the program in comment 0 is invalid. Mixing scalars and arrays is invalid. But as written, the same ICE occurs if one has only arrays or only scalars (which I intended but didn't post). And do I believe the program(s) is (are) valid in that case. I doubt that it is possible to catch the rank mismatch Well, the compiler does warn that the named common blocks have a different size.
[Bug rtl-optimization/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 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-12-18 20:35:17 UTC --- (In reply to comment #4) If stack_realign_p is true, frame_pointer_needed is also true. So we can use fp to eliminate frame but i386.c::x86_can_eliminate prohibits it. The code looks strange: if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == STACK_POINTER_REGNUM)); So we permit to change argument pointer but not frame pointer to FP which again is strange IMHO. Changing the code to if (stack_realign_fp) return ((from == ARG_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == STACK_POINTER_REGNUM) || (from == FRAME_POINTER_REGNUM to == HARD_FRAME_POINTER_REGNUM)); solves the problem. It fixes ICE, but generates questionable code: main: .LFB0: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$8236, %esp orl$0, (%esp) addl$8204, %esp cmpl$4, -40(%ebp) je.L2 callabort .L2: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret Without LRA, we got main: .LFB0: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$8236, %esp orl$0, (%esp) addl$8204, %esp cmpl$4, (%esp) je.L2 callabort .L2: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret The difference is --- x.s2012-12-18 12:24:17.072888139 -0800 +++ no-lra.s2012-12-18 12:30:11.419157548 -0800 @@ -14,7 +14,7 @@ main: subl$8236, %esp orl$0, (%esp) addl$8204, %esp -cmpl$4, -40(%ebp) +cmpl$4, (%esp) je.L2 callabort .L2: I think LRA generated code is wrong. The reason we don't allow converting software frame pointer to hardware frame pointer is when stack alignment is needed, hardware frame pointer is used to save stack pointer. We can no longer use it for software frame pointer.
[Bug c++/55726] assignment of a scalar to a vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55726 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC|marc.glisse at ens dot fr |glisse at gcc dot gnu.org --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2012-12-18 20:53:52 UTC --- If I have: void f(double); void f(float32x4_t); float a; what should f(a) do? Not sure that's the right question (I am sick this week, so I have an excuse for posting nonsense), but hopefully you see the point, adding implicit conversions has a lot of consequences, which might be good but need to be considered.
