[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 #6 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-08 09:12:01 UTC --- And I'd say that something in bypass_block from cprop.c is the culprit. Not calling bypass_block - no ICE, and compilation proceeds fine. Working on a patch.
[Bug fortran/43207] [OOP] invalid pointer assignment = type%parent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43207
--- Comment #11 from janus at gcc dot gnu.org 2012-11-08 09:25:39 UTC ---
(In reply to comment #10)
Here is a draft patch which rejects comment #1:
This shows one testsuite failure:
FAIL: gfortran.dg/abstract_type_3.f03 -O (test for errors, line 44)
FAIL: gfortran.dg/abstract_type_3.f03 -O (test for excess errors)
where it correctly triggers on this line:
arg = again_abst_t () ! { dg-error Can't construct ABSTRACT type 'again_ab
1
Error: Nonpolymorphic reference to abstract type at (1)
[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 --- Comment #1 from Anton Shterenlikht mexas at bristol dot ac.uk 2012-11-08 09:49:08 UTC --- On the same system gcc47 updated fine to gcc-4.7.3.20121103
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #9 from Sebastian Huber sebastian.hu...@embedded-brains.de 2012-11-08 10:19:33 UTC --- (In reply to comment #8) Created attachment 28624 [details] gcc48-pr55137.patch Untested patch. I tried this patch and GCC Git version 5838c24a86ac8a8afe77285f224a3ce50596954e and I get this: internal compiler error: in compute_antic, at tree-ssa-pre.c:2511 With an earlier snapshot 4.8-20120923 your patch solves my problem.
[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48385 Martin Decky martin at decky dot cz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Known to fail|4.7.2, 4.8.0| --- Comment #9 from Martin Decky martin at decky dot cz 2012-11-08 10:24:06 UTC --- I can confirm that the bug is no longer present in 4.7.2, as noted in comment #8. Therefore I am closing this bug as resolved/fixed. I am not marking it as duplicate of 49866 since this bug was reported earlier and to a different version (but feel free to change this). Thanks for fixing this!
[Bug tree-optimization/55216] [4.8 Regression] Infinite loop generated on non-infinite code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-08 10:42:25 UTC --- Oh and this was a dup of bug 53073 which has the fix for the source. Note someone if not already should report this to SPEC. *** This bug has been marked as a duplicate of bug 53073 ***
[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||josh.m.conner at gmail dot ||com --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-08 10:42:25 UTC --- *** Bug 55216 has been marked as a duplicate of this bug. ***
[Bug web/55237] New: Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237 Bug #: 55237 Summary: Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: ubiz...@gmail.com I would like to propose a scheme of short URLs for fast SVN revision access, similar to the short URLs for fast PR access: gcc.gnu.org/PR12345 (existing, very useful to reference/link to the particular PR) Proposed: gcc.gnu.org/r123456 in effect a short ULR for http://gcc.gnu.org/viewcvs?view=revisionrevision=123456 This shortcuts could be a nice way to add references to a correspondence on the mainling lists, and can eventuall be used to insert automatic links to a particular revision from bugzilla (again, similar to existing PR12345 processing).
[Bug tree-optimization/54153] [4.8 Regression] Bytemark IDEA 6% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54153 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-11-08 11:22:02 UTC --- Can't reproduce. I get (4.7.2 vs. current trunk gcc on i7-2600 CPU: -NUMERIC SORT: 1990.3 : 51.04 : 16.76 -STRING SORT : 1182.7 : 528.47 : 81.80 -BITFIELD: 6.1099e+08 : 104.81 : 21.89 -FP EMULATION: 652.32 : 313.01 : 72.23 -FOURIER : 51655 : 58.75 : 33.00 -ASSIGNMENT : 66.054 : 251.35 : 65.19 -IDEA: 12560 : 192.10 : 57.04 -HUFFMAN : 5505.8 : 152.68 : 48.75 -NEURAL NET : 112.24 : 180.31 : 75.84 -LU DECOMPOSITION: 3004.5 : 155.65 : 112.39 +NUMERIC SORT: 2130.2 : 54.63 : 17.94 +STRING SORT : 1218.6 : 544.49 : 84.28 +BITFIELD: 6.137e+08 : 105.27 : 21.99 +FP EMULATION: 679.16 : 325.89 : 75.20 +FOURIER : 51200 : 58.23 : 32.71 +ASSIGNMENT : 63.724 : 242.48 : 62.89 +IDEA: 12488 : 191.00 : 56.71 +HUFFMAN : 5553.3 : 153.99 : 49.18 +NEURAL NET : 114.36 : 183.71 : 77.28 +LU DECOMPOSITION: 2996.3 : 155.22 : 112.09 ==ORIGINAL BYTEMARK RESULTS== -INTEGER INDEX : 181.639 -FLOATING-POINT INDEX: 118.130 +INTEGER INDEX : 184.502 +FLOATING-POINT INDEX: 118.410
[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-08 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 11:50:36 UTC --- Broken by http://gcc.gnu.org/viewcvs?root=gccview=revrev=190190
[Bug tree-optimization/55238] New: ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238 Bug #: 55238 Summary: ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com CC: jamb...@gcc.gnu.org Created attachment 28634 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28634 preprocessed src $ ./xgcc -B. -O3 ~/ice.i /home/ryan/ice.i:15:11: error: unknown type name ‘gz_statep’ gz_reset (gz_statep state) ^ ryan@zoidberg:~/gnu/gcc/trunk/tmp/gcc$ ./xgcc -B. -O3 ~/ice.i /home/ryan/ice.i:42:1: internal compiler error: in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 } ^ 0xd01072 find_aggregate_values_for_callers_subset ../../gcc/ipa-cp.c:2908 0xd01072 decide_about_value ../../gcc/ipa-cp.c:3255 0xd01072 decide_about_value ../../gcc/ipa-cp.c:3195 0xd02acb decide_whether_version_node ../../gcc/ipa-cp.c:3301 0xd02acb ipcp_decision_stage ../../gcc/ipa-cp.c:3441 0xd02acb ipcp_driver ../../gcc/ipa-cp.c:3483 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 tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin10 |x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-08 Host|x86_64-apple-darwin10 | Ever Confirmed|0 |1 Build|x86_64-apple-darwin10 | --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-08 12:06:43 UTC --- It's also can be seen for x86_64-unknown-linux-gnu. In particular, 447.dealII fails with -O3 and -funroll-loops So changing target to x86_64-*-* and status to new. Note that this PR blocks the testing of the polyhedron suite with -funroll-loops.
[Bug debug/54519] [4.6/4.7 Regression] Debug info quality regression due to (pointless) partial inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54519 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Debug |Debug info quality |info quality regression due |regression due to |to (pointless) partial |(pointless) partial |inlining |inlining| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 12:25:52 UTC --- Fixed for trunk, not planning a backport.
[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53518 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-11-08 12:27:20 UTC --- --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-07 18:20:16 UTC --- (In reply to comment #7) [...] I don't see such a failure in http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00497.html , so fixed now? Right, seems it got fixed between 20120921 and 20120928. Rainer
[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53518 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 12:28:56 UTC --- Fixed then.
[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 12:30:21 UTC --- Created attachment 28635 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28635 gcc48-pr54499.patch That change looks very much broken to me, this should hopefully fix it properly.
[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499 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 |
[Bug target/54564] [4.8 Regression] Broken __builtin_ia32_vfmadds[sd]3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 12:35:55 UTC --- Fixed.
[Bug middle-end/44786] -fcatch-undefined-behavior: Turn on runtime code generation to check for undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-08 12:53:17 UTC --- Just for fun, today I've build gcc trunk with: CC=clang -fsanitize=undefined -w CXX=clang++ -fsanitize=undefined -w ~/gcc/configure --disable-bootstrap --disable-werror --disable-multilib --enable-languages=c,c++ It didn't get very far (haven't looked deeper yet): gcc/libiberty/regex.c:6968:11: fatal error: left shift of negative value -1 gcc/gcc/genattrtab.c:625:27: fatal error: signed integer overflow: 4568797 * 613 cannot be represented in type 'int' gcc/gcc/genautomata.c:3510:23: fatal error: shift exponent 64 is too large for 64-bit type 'set_el_t' (aka 'unsigned long')
[Bug middle-end/55235] [4.8 Regression] FAIL: gcc.target/i386/pr44948-2a.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55235 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 13:12:56 UTC --- Fixed.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/44786] -fsanitize=undefined: Turn on runtime code generation to check for undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44786 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Summary|-fcatch-undefined-behavior: |-fsanitize=undefined: Turn |Turn on runtime code|on runtime code generation |generation to check for |to check for undefined |undefined behavior |behavior --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-08 13:21:54 UTC --- It didn't get very far (haven't looked deeper yet): This PR is for implementing those checks in GCC. For things broken in GCC, you should open new PRs. BTW, Clang now supports all these checks: -fsanitize=alignment: Use of a misaligned pointer or creation of a misaligned reference. -fsanitize=divide-by-zero: Division by zero. -fsanitize=float-cast-overflow: Conversion to, from, or between floating-point types which would overflow the destination. -fsanitize=null: Use of a null pointer or creation of a null reference. -fsanitize=object-size: An attempt to use bytes which the optimizer can determine are not part of the object being accessed. The sizes of objects are determined using __builtin_object_size, and consequently may be able to detect more problems at higher optimization levels. -fsanitize=return: In C++, reaching the end of a value-returning function without returning a value. -fsanitize=shift: Shift operators where the amount shifted is greater or equal to the promoted bit-width of the left hand side or less than zero, or where the left hand side is negative. For a signed left shift, also checks for signed overflow in C, and for unsigned overflow in C++. -fsanitize=signed-integer-overflow: Signed integer overflow, including all the checks added by -ftrapv, and checking for overflow in signed division (INT_MIN / -1). -fsanitize=unreachable: If control flow reaches __builtin_unreachable. -fsanitize=vla-bound: A variable-length array whose bound does not evaluate to a positive value. -fsanitize=vptr: Use of an object whose vptr indicates that it is of the wrong dynamic type, or that its lifetime has not begun or has ended. Incompatible with -fno-rtti.
[Bug fortran/54881] [4.8 Regression] [OOP] ICE in fold_convert_loc, at fold-const.c:2016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54881 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/55239] New: Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239
Bug #: 55239
Summary: Spurious unused variable warning on function-local
objects with a destructor and an initializer
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
In the code below, a function-local object is declared with a destructor whose
role is to ensure that some action is taken at the end of the scope, no matter
which route the function is exited.
#include stdio.h
void LoadSomeFile(const char* fn)
{
/* Open file */
FILE* fp = fopen(fn, rb);
/* Ensure that the file is automatically closed no matter which path
this function is exited */
struct closer { FILE* f; ~closer() { if(f) fclose(f); }
} autoclosefp = {fp};
/* Some code here that deals with fp, and may include several return;
clauses */
}
int main() { LoadSomeFile(__FILE__); } // test
Bug GCC gives a spurious unused variable 'autoclosefp' for this code,
implying that autoclosefp has no function. It does. Without it, the file would
not be closed and resources would be leaked.
The problem also occurs, when the code is rewritten like this:
#include stdio.h
void LoadSomeFile(const char* fn)
{
/* Open file */
FILE* fp = fopen(fn, rb);
/* Ensure that the file is automatically closed no matter which path
this function is exited */
struct closer { FILE* f; ~closer() { if(f) fclose(f); } };
closer autoclosefp = {fp};
/* Some code here that deals with fp, and may include several return;
clauses */
}
int main() { LoadSomeFile(__FILE__); } // test
Changing the = {fp} into C++11 style {fp} does not take away the warning,
either.
Only changing the initialization-by-initializer into an member-assignment takes
away the warning.
#include stdio.h
void LoadSomeFile(const char* fn)
{
/* Open file */
FILE* fp = fopen(fn, rb);
/* Ensure that the file is automatically closed no matter which path
this function is exited */
struct closer { FILE* f; ~closer() { if(f) fclose(f); } } autoclosefp;
autoclosefp.f = fp;
/* Some code here that deals with fp, and may include several return;
clauses */
}
int main() { LoadSomeFile(__FILE__); } // test
I would argue that this is inconvenient, and wrong behavior on GCC.
Tested and verified on GCC 3.3 through 4.7.1. The -Wunused-variable (or -Wall)
option is required.
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #7 from David Woodhouse dwmw2 at infradead dot org 2012-11-08 14:29:37 UTC --- Linux kernel patch to use the builtins at http://marc.info/?l=linux-archm=135212414925921w=2 I think I have the GCC version checks right there, for the availability of the builtins? That is, __builtin_bswap32() and __builtin_bswap64() since GCC 4.4, and __builtin_bswap16() since GCC 4.6 on PowerPC or GCC 4.9 on other platforms?
[Bug c++/55240] New: [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55240
Bug #: 55240
Summary: [c++0x] ICE on non-static data member initialization
using 'auto' variable from containing function
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
This code causes an ICE in GCC 4.7.1 and 4.7.2:
int main()
{
int q = 1;
struct test { int x = q; } instance;
}
tmpq.cc: In constructor 'constexpr main()::test::test()':
tmpq.cc:4:12: internal compiler error: in expand_expr_real_1, at expr.c:9122
It is notable that if the code is written like this, the error message changes.
int main()
{
int q = 1;
struct test { int x; test():x(q){} } instance;
}
tmpq.cc:5:35: error: use of 'auto' variable from containing function
tmpq.cc:3:9: error: 'int q' declared here
[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-08 14:43:41 UTC --- So, this now works as expected, the testcase is even in the testsuite. The creation of aggregate jump function is still quite rudimentary so it is possible that in more complex scenarios, the propagation might not take place (testcases welcome) and even in the propagation phase there are still a few things wanting. Nevertheless, those potential shortcomings should be subjects to separate requests/PRs/whatever. Thanks for reporting and for the testcase.
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-08 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-08 14:46:56 UTC --- Yes, annoying. Giving the type a user-defined constructor makes the warning go away. A user-defined destructor should have the same effect.
[Bug c++/55240] [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55240 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-08 Ever Confirmed|0 |1
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-08 15:00:05 UTC --- Note that after this feature works, we have to ensure that FORALL with a generated temporary works with different string lengths: type t character(len=:), pointer :: str end type t type(t), pointer :: strarry(:), strarray2 allocate(strarray(3), strarray2) allocate(character(len=5) :: strarray(1)%str, strarray2(1)%str) allocate(character(len=7) :: strarray(2)%str, strarray2(2)%str) allocate(character(len=2) :: strarray(2)%str, strarray2(3)%str) forall(i=1:3) strarray2(i)%str = strarray(i)%str
[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-08 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-08 15:01:27 UTC --- Confirmed and mine.
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 15:04:05 UTC --- I fixed this in mainline, didn't I?
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||bisqwit at iki dot fi --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 15:06:14 UTC --- *** Bug 55239 has been marked as a duplicate of this bug. ***
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 15:06:14 UTC --- Yes. *** This bug has been marked as a duplicate of bug 10416 ***
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||redi at gcc dot gnu.org --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-08 15:08:15 UTC --- templateunsigned N using Num = int; templatetypename... Types using Count = Numsizeof...(Types); Countint, char, void i; This claims sizeof is not a constant: e.C:5:37: error: integral expression 'sizeof (Types ...)' is not constant
[Bug c++/55241] New: [C++11] diagnostics show sizeof...(T) as sizeof(T...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55241 Bug #: 55241 Summary: [C++11] diagnostics show sizeof...(T) as sizeof(T...) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org templateunsigned N using Num = int; templatetypename... T using Count = Numsizeof...(T); Countint, char, void i; This is incorrectly rejected by current trunk due to Bug 54859, which reveals that the diagnostic shows sizeof(T...) not sizeof...(T) e.C:5:33: error: integral expression 'sizeof (T ...)' is not constant
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-08 15:14:25 UTC --- Oops, thanks, Paolo!
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 --- Comment #5 from Joel Yliluoma bisqwit at iki dot fi 2012-11-08 15:16:48 UTC --- Nice. I had no idea this was first reported in 2003 and fixed in 2012 in a version recent enough to be still unreleased :)
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 15:20:37 UTC --- Understandable: the kind of work I have been doing lately at times is pretty weird ;)
[Bug c++/55239] Spurious unused variable warning on function-local objects with a destructor and an initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55239 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-08 15:21:40 UTC --- Paolo's been very busy recently, cleaning up loads of longstanding bugs like that
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #28 from Tobias Schlüter tobi at gcc dot gnu.org 2012-11-08 15:46:13 UTC --- Author: tobi Date: Thu Nov 8 15:46:07 2012 New Revision: 193329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193329 Log: PR fortran/51727 * module.c (sorted_pointer_info): New. (gfc_get_sorted_pointer_info): New. (free_sorted_pointer_info_tree): New. (compare_sorted_pointer_info): New. (find_symbols_to_write): New. (write_symbol1_recursion): New. (write_symbol1): Collect symbols that need writing, output in order. (write_generic): Traverse tree in order. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-08 16:11:25 UTC --- I applied i386 change at http://gcc.gnu.org/bugzilla/attachment.cgi?id=28591 to compile it: [hjl@gnu-tools-1 tmp]$ /export/build/gnu/gcc/release/usr/gcc-4.8.0/bin/gcc -mtune=generic -march=x86-64 -maddress-mode=long -mx32 -O2 -fPIC rtld.c -std=gnu99 -fgnu89-inline -S [hjl@gnu-tools-1 tmp]$ egrep , -[0-9]*\(%rax rtld.s movl%ecx, -1073743664(%rax) movl%ecx, -1073742592(%rax) movl%edx, -1073743664(%rax) movl%edx, -1073742592(%rax) [hjl@gnu-tools-1 tmp]$ All those stores should be zero-extended. OK, thanks. Everything is correctly zero-extended until: case PLUS: case MULT: /* FIXME: For addition, we used to permute the conversion and addition operation only if one operand is a constant and converting the constant does not change it or if one operand is a constant and we are using a ptr_extend instruction (POINTERS_EXTEND_UNSIGNED 0) even if the resulting address may overflow/underflow. We relax the condition to include zero-extend (POINTERS_EXTEND_UNSIGNED 0) since the other parts of the compiler depend on it. See PR 49721. We can always safely permute them if we are making the address narrower. */ if (GET_MODE_SIZE (to_mode) GET_MODE_SIZE (from_mode) || (GET_CODE (x) == PLUS CONST_INT_P (XEXP (x, 1)) (POINTERS_EXTEND_UNSIGNED != 0 || XEXP (x, 1) == convert_memory_address_addr_space (to_mode, XEXP (x, 1), as return gen_rtx_fmt_ee (GET_CODE (x), to_mode, convert_memory_address_addr_space (to_mode, XEXP (x, 0), as), XEXP (x, 1)); break; It's clear that the distribution is invalid, whatever POINTERS_EXTEND_UNSIGNED is defined to. It becomes valid only under conditions of non-overflow that depend upon the value of POINTERS_EXTEND_UNSIGNED, as stated in the head comment of the function. If POINTERS_EXTEND_UNSIGNED, it's valid if there is no overflow in the address. If POINTERS_EXTEND_UNSIGNED 0, it's valid if either the constant is positive (and there is no overflow in the address) or the constant is negative and the variable part is sufficiently large. The condition aren't fulfilled here since the constant is very large negative and the variable part small. I think the most robust solution would be to always zero-extend the addresses for -mx32, i.e. output movl%ecx, -1073743664(%eax) even if the address is a PLUS in DImode. Otherwise, we're left with kludges...
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-08 16:14:23 UTC --- I think I have the GCC version checks right there, for the availability of the builtins? That is, __builtin_bswap32() and __builtin_bswap64() since GCC 4.4, and __builtin_bswap16() since GCC 4.6 on PowerPC or GCC 4.9 on other platforms? 4.8 on other platforms.
[Bug tree-optimization/55236] [4.8 Regression] gcc.c-torture/execute/pr22493-1.c FAILs with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55236 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-08 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 16:18:08 UTC --- Created attachment 28636 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28636 gcc48-pr55236.patch Started with my inter-bb range test optimization, but as the attached testcase shows, if written in a single stmt, even gcc 3.4 miscompiles it.
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #25 from Uros Bizjak ubizjak at gmail dot com 2012-11-08 16:24:12 UTC --- (In reply to comment #24) I think the most robust solution would be to always zero-extend the addresses for -mx32, i.e. output movl%ecx, -1073743664(%eax) even if the address is a PLUS in DImode. Otherwise, we're left with kludges... No, this would be one giant kludge by itself. The failure just shows that the controversial patch [1] for PR 49721 was wrong. Quote from [1]: --quote-- I am checking in this patch, which only affects x32 and nothing else. This one character change, from POINTERS_EXTEND_UNSIGNED 0 to POINTERS_EXTEND_UNSIGNED != 0 creates a working x32 GCC. This isn't perfect. I have tried many different approaches without any success. I will revisit it if we run into any problems with x32 applications. --/qoute-- So, we run into problem. [1] http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01618.html
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #26 from Uros Bizjak ubizjak at gmail dot com 2012-11-08 16:34:27 UTC --- I think the most robust solution would be to always zero-extend the addresses for -mx32, i.e. output movl%ecx, -1073743664(%eax) even if the address is a PLUS in DImode. Otherwise, we're left with kludges... Also, please note that the failure is with -maddress-mode=long. This flag was introduced with the intention to get rid of as many 0x67 address size prefixes as possible. The problem is even listed at the bottom of x32-abi project page [1]. [1] https://sites.google.com/site/x32abi/
[Bug lto/54966] Does LTO requires a larger inline-unit-growth?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-08 Ever Confirmed|0 |1 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-08 16:44:36 UTC --- The inline metrics for 4.8 was changed significandly, I would be curious if your application now behaves better (or worse)?
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #35 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-08 16:46:28 UTC --- Author: hubicka Date: Thu Nov 8 16:46:18 2012 New Revision: 193331 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193331 Log: PR middle-end/48636 * ipa-inline.c (big_speedup_p): New function. (want_inline_small_function_p): Use it. (edge_badness): Dump it. * params.def (inline-min-speedup): New parameter. * doc/invoke.texi (inline-min-speedup): Document. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/ipa-inline.c trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/winline-3.c
[Bug rtl-optimization/54850] [4.8 Regression] FAIL: gcc.c-torture/execute/20041113-1.c execution, -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54850 --- Comment #13 from Bernd Schmidt bernds at gcc dot gnu.org 2012-11-08 17:10:34 UTC --- Author: bernds Date: Thu Nov 8 17:10:26 2012 New Revision: 193332 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193332 Log: PR rtl-optimization/54850 * sched-deps.c (find_inc): Add all dependencies from the inc_insn to the mem_insn. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #27 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-08 17:17:35 UTC --- No, this would be one giant kludge by itself. The failure just shows that the controversial patch [1] for PR 49721 was wrong. Quote from [1]: --quote-- I am checking in this patch, which only affects x32 and nothing else. This one character change, from POINTERS_EXTEND_UNSIGNED 0 to POINTERS_EXTEND_UNSIGNED != 0 creates a working x32 GCC. This isn't perfect. I have tried many different approaches without any success. I will revisit it if we run into any problems with x32 applications. --/qoute-- So, we run into problem. It's not totally wrong, given the context of convert_memory_address_addr_space which is already optimistically correct only. The problem is that the case POINTERS_EXTEND_UNSIGNED 0 is trickier than POINTERS_EXTEND_UNSIGNED == 0 because RTL constants are sign-extended: in the latter case, everything is sign-extended so this is symmetric and simple; in the former case, one part is zero-extended and the other part sign-extended and, in order to make this work under the same hypothesis of non-overflow, one would need to know which part is bigger. In the case at hand, the code would be correct if the constant was zero-extended and the register sign-extended, not the reverse as currently.
[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-08 17:33:11 UTC --- Created attachment 28637 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28637 Untested patch This is the fix I am currently bootstrapping and testing.
[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-11-08 19:27:22 UTC --- gfortran -O3 also aborts on this testcase at the same location MODULE dbcsr_dist_operations TYPE dbcsr_type LOGICAL :: symmetry END TYPE CONTAINS SUBROUTINE get_stored_coordinates_type(matrix, transpose, processor) TYPE(dbcsr_type), INTENT(IN) :: matrix LOGICAL, INTENT(INOUT) :: transpose INTEGER, INTENT(OUT), OPTIONAL :: processor LOGICAL :: checker_tr IF (PRESENT (processor)) THEN IF (matrix%symmetry .AND. checker_tr()) THEN processor = dbcsr_distribution_processor () ENDIF ENDIF END SUBROUTINE get_stored_coordinates_type SUBROUTINE get_block_index_type(matrix, transpose) TYPE(dbcsr_type), INTENT(IN) :: matrix LOGICAL, INTENT(OUT) :: transpose transpose = .FALSE. CALL get_stored_coordinates_type (matrix, transpose) END SUBROUTINE get_block_index_type END MODULE dbcsr_dist_operations
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #44 from François Dumont fdumont at gcc dot gnu.org 2012-11-08 20:06:08 UTC --- Author: fdumont Date: Thu Nov 8 20:06:00 2012 New Revision: 193335 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193335 Log: 2012-11-08 François Dumont fdum...@gcc.gnu.org PR libstdc++/54075 * include/bits/hashtable.h (_Hashtable::rehash): Reset hash policy state if no rehash. * testsuite/23_containers/unordered_set/modifiers/reserve.cc (test02): New. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable.h branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/reserve.cc
[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:09:20 UTC --- Author: jakub Date: Thu Nov 8 20:09:14 2012 New Revision: 193336 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193336 Log: PR target/54308 * config/rs6000/rs6000.c (legitimate_indirect_address_p): Remove inline keyword. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2012-11-08 20:10:09 UTC --- (In reply to comment #3) If it is valid, the series of foldings that result into the overflow are first folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and later on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to -1 + (int) sizeof (int) + (int) 18446744073709551615UL. Under C++ semantics, this folding introduces implementation-defined behavior, not undefined behavior, so it's still a constant-expression; conversion to a signed integer is different from overflow in the language. I have been working around this difference between back end and language semantics in cxx_eval_constant_expression by unsetting TREE_OVERFLOW after folding NOP_EXPR, but that doesn't help this example. The semantics of overflow and conversion to signed integer are different in C as well; the only difference from C++ is that C allows the implementation to trap *or* produce an implementation-defined value. Perhaps we could distinguish them in the compiler as well...
[Bug driver/54789] [4.8 Regression] Error in GCC driver when defining GCC_COMPARE_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54789 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:13:17 UTC --- Author: jakub Date: Thu Nov 8 20:13:13 2012 New Revision: 193337 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193337 Log: PR driver/54789 * gcc.c (process_command): Use save_switch for synthesized -fcompare-debug=* option; mark the switch as known. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08
20:15:12 UTC ---
Author: jakub
Date: Thu Nov 8 20:15:06 2012
New Revision: 193338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193338
Log:
PR debug/54499
* cgraphunit.c (assemble_thunk): Don't call source_line debug hook
here, instead call insn_locations_{init,finalize} and initialize
prologue_location.
* g++.dg/debug/pr54499.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/debug/pr54499.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #45 from François Dumont fdumont at gcc dot gnu.org 2012-11-08 20:16:15 UTC --- Author: fdumont Date: Thu Nov 8 20:16:04 2012 New Revision: 193339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193339 Log: 2012-11-08 François Dumont fdum...@gcc.gnu.org PR libstdc++/54075 * include/bits/hashtable.h (_Hashtable::rehash): Reset hash policy state if no rehash. * testsuite/23_containers/unordered_set/modifiers/reserve.cc (test02): New. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h trunk/libstdc++-v3/testsuite/23_containers/unordered_set/modifiers/reserve.cc
[Bug c++/55137] [4.8 Regression] Unexpected static structure initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55137 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:16:54 UTC --- (In reply to comment #10) (In reply to comment #3) If it is valid, the series of foldings that result into the overflow are first folding sizeof (int) - 1UL into sizeof (int) + 18446744073709551615UL and later on conversion of -1 + (int) (sizeof (int) + 18446744073709551615UL) to -1 + (int) sizeof (int) + (int) 18446744073709551615UL. Under C++ semantics, this folding introduces implementation-defined behavior, not undefined behavior, so it's still a constant-expression; conversion to a signed integer is different from overflow in the language. I have been working around this difference between back end and language semantics in cxx_eval_constant_expression by unsetting TREE_OVERFLOW after folding NOP_EXPR, but that doesn't help this example. The semantics of overflow and conversion to signed integer are different in C as well; the only difference from C++ is that C allows the implementation to trap *or* produce an implementation-defined value. Perhaps we could distinguish them in the compiler as well... In this case I think it is really a bug in fold-const.c, as can be seen on the miscompiled testcase there (provided it is valid C resp. C++). See http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00636.html
[Bug debug/54499] [4.8 Regression] GCC produces wrong debugging information, failure while assembling generated .s file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54499 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:17:46 UTC --- Fixed.
[Bug driver/54789] [4.8 Regression] Error in GCC driver when defining GCC_COMPARE_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54789 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:18:15 UTC --- Fixed.
[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:19:00 UTC --- Fixed.
[Bug debug/53145] [4.8 Regression] gcc.dg/pch/save-temps-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53145 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:20:33 UTC --- Author: jakub Date: Thu Nov 8 20:20:10 2012 New Revision: 193340 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193340 Log: PR debug/53145 * dwarf2out.c (gen_compile_unit_die): Don't call gen_producer_string here, instead add if producer_string is NULL. (dwarf2out_finish): Call gen_producer_string here, unconditionally decrease refcount of the old indirect string and set val_str to find_AT_string result. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #46 from frs.dumont at gmail dot com 2012-11-08 20:21:15 UTC --- Attached patch applied to trunk and 4.7 branch. 2012-11-08 François Dumont fdum...@gcc.gnu.org PR libstdc++/54075 * include/bits/hashtable.h (_Hashtable::rehash): Reset hash policy state if no rehash. * testsuite/23_containers/unordered_set/modifiers/reserve.cc (test02): New. François On 11/08/2012 01:58 AM, Jonathan Wakely wrote: On 7 November 2012 22:02, François Dumont wrote: Ok to commit ? If so, where ? That patch is OK for trunk and 4.7, thanks.
[Bug debug/45882] No debug info for vars depending on unused parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45882 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-08 20:43:54 UTC --- Fixed for 4.7+.
[Bug preprocessor/55242] New: continued lines not always merged into one long line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55242
Bug #: 55242
Summary: continued lines not always merged into one long line
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jlm...@anl.gov
Created attachment 28639
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28639
Small source file demonstrating bug
The preprocessor sometimes incorrectly handles a line continuation by not
joining a following line with the current line.
Attached is a simple C file called continued-line-test.c that demonstrates the
problem. It contains the following three lines (the first two lines end with a
backslash):
struct {\
int x;\
};
Running gcc on this file with the -E option produces the following:
$ gcc -E continued-line-test.c
# 1 continued-line-test.c
# 1 command-line
# 1 continued-line-test.c
struct {
int x;};
As you can see, even though the first line in continued-line-test.c ended with
a backslash, the second line was not joined with the first line.
The preprocessor documentation
(http://gcc.gnu.org/onlinedocs/gcc-4.7.2/cpp/Initial-processing.html#Initial-processing)
says:
Continued lines are merged into one long line.
A continued line is a line which ends with a backslash, `\'. The backslash is
removed and the following line is joined with the current one. No space is
inserted, so you may split a line anywhere, even in the middle of a word. (It
is generally more readable to split lines only at white space.)
What I expected to see is the following:
$ gcc -E continued-line-test.c
# 1 continued-line-test.c
# 1 command-line
# 1 continued-line-test.c
struct { int x;};
Here's the version information from GCC:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt3/bin/gcc
COLLECT_LTO_WRAPPER=/opt3/libexec/gcc/x86_64-apple-darwin12/4.7.2/lto-wrapper
Target: x86_64-apple-darwin12
Configured with: ../gcc-4.7.2/configure --prefix=/opt3
--build=x86_64-apple-darwin12
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt3/lib/gcc47
--includedir=/opt3/include/gcc47 --infodir=/opt3/share/info
--mandir=/opt3/share/man --datarootdir=/opt3/share/gcc-4.7
--with-libiconv-prefix=/opt3 --with-local-prefix=/opt3 --with-system-zlib
--disable-nls --program-suffix=-mp-4.7
--with-gxx-include-dir=/opt3/include/gcc47/c++/ --with-gmp=/opt3
--with-mpfr=/opt3 --with-mpc=/opt3 --with-ppl=/opt3 --with-cloog=/opt3
--enable-cloog-backend=isl --disable-cloog-version-check
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt3/bin/as --with-ld=/opt3/bin/ld
--with-ar=/opt3/bin/ar --with-bugurl=https://trac.macports.org/newticket
--disable-ppl-version-check --with-pkgversion='MacPorts gcc47 4.7.2_2'
Thread model: posix
gcc version 4.7.2 (MacPorts gcc47 4.7.2_2)
I'm also able to reproduced this problem with GCC 4.6.3 on Ubuntu Linux 12.04.1
LTS.
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #47 from frs.dumont at gmail dot com 2012-11-08 21:19:05 UTC --- On 11/08/2012 03:25 AM, Paolo Carlini wrote: On 11/08/2012 02:56 AM, Paolo Carlini wrote: On the other hand, the old-old code for rehash didn't use _M_growth_factor in these computations, it just literally enforced the post-conditions of the Standard. Are we sure we aren't so to speak rehashing too much? For example, when the load factor is very low and doesn't count, it looks like a current rehash(n) accomplishes the same of an old rehash(n * 2)?!? Something seems wrong, can you double check that? In any case the comments before _M_next_bkt would need fixing. ... in other terms, I really think that the only uses of _S_growth_factor should return to be inside _M_need_rehash, because that's the function called by the inserts, when the container must automatically grow the number of buckets. Elsewhere, like the constructors, rehash, should not need to know about _S_growth_factor. Paolo. I haven't yet considered the following emails but based on those good remarks I have done the attached patch. Surprisingly it seems to have a good impact on performance even if before it testsuite/performance/23_containers/insert/unordered_set.cc was showing that new implementation was better. I have also starting to adapt tests so that it's possible to check unordered performance with std or std::tr1 implementations. Can I generalize it to other tests ? If so, is it a good approach ? François
[Bug c++/55240] [c++0x] ICE on non-static data member initialization using 'auto' variable from containing function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55240 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-08 21:33:48 UTC --- The ICE also exists for gcc 4.8.0 20121104 (experimental): 4|internal compiler error: in expand_expr_real_1, at expr.c:9280|
[Bug target/55243] New: STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 Bug #: 55243 Summary: STAMP variable is not defined in t-avr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rolf.ebert@gmx.de Building AVR cross compiler for Ada (GNAT) fails as t-avr contains no valid command in the STAMP variable easiest work-around is to replace it with 'echo' command. sed -i -e 's/$(STAMP)/echo timestamp /' gcc/config/avr/t-avr
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 21:47:54 UTC --- Author: steven Date: Thu Nov 8 21:47:50 2012 New Revision: 193341 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193341 Log: gcc/ PR tree-optimization/55191 * cfganal.c (connect_infinite_loops_to_exit): Call dfs_deadend here. (flow_dfs_compute_reverse_execute): Don't call it here. testsuite/ PR tree-optimization/55191 * gcc.dg/pr55191.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55191.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfganal.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 21:49:19 UTC --- .
[Bug web/55237] Please implement gcc.gnu.org/r123456 URL shorts for fast SVN revision access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-08 CC||gerald at gcc dot gnu.org, ||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 22:00:50 UTC --- Good idea!
[Bug target/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #2 from Rolf Ebert rolf.ebert.gcc at gmx dot de 2012-11-08 22:08:16 UTC --- A complete build instruction is in http://arduino.ada-language.com/building-avr-gnat-for-avr-ada.html I'll add a make output without the patch once I can build again (probably tomorrow)
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Tobias Schlüter tobi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #29 from Tobias Schlüter tobi at gcc dot gnu.org 2012-11-08 22:21:48 UTC --- I committed the C-only version of the patch as the issues mentioned in comment #27 couldn't be addressed before stage3.
[Bug rtl-optimization/53908] [4.6 Regression] csa removes needed memory load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #20 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 22:23:16 UTC --- .
[Bug tree-optimization/18046] Missed jump threading optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2012-03-18 10:29:57 |2012-11-08 10:29:57 --- Comment #17 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 22:29:45 UTC --- Will be addressed for GCC 4.9 by moving switch lowering to GIMPLE.
[Bug rtl-optimization/13355] Suboptimal code generated with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13355
--- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08
22:41:41 UTC ---
(In reply to comment #6)
A reduced testcase for the second case.
On mainline, i686-pc-linux-gnu.
/* -march=i686 -mtune=i686 -fomit-frame-pointer -O2 */
register int ebx asm (ebx);
register int dummy1 asm (esi);
register int dummy2 asm (ebp);
int
foo (int arg)
{
long long res = (long long) arg * (long long) ebx;
return (int) res;
}
Global variables take up three registers from IA-32!
GCC 4.1, GCC 4.3, and GCC 4.7 compile this to:
foo:
subl$12, %esp
movl16(%esp), %eax
imull %ebx
movl%eax, (%esp)
movl(%esp), %eax
movl%edx, 4(%esp)
addl$12, %esp
ret
Trunk r193340 compiles it to:
foo:
movl%ebx, %eax
imull 4(%esp)
ret
[Bug rtl-optimization/13355] Suboptimal code generated with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13355 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 22:46:53 UTC --- (In reply to comment #1) Created attachment 5301 [details] example .c file that shows behavior with gcc -march=i686 -mtune=i686 -fomit-frame-pointer -O2 test.c GCC 4.7.1 compiles the two interesting functions in the test case to: op_cmovl_EAX_T1_T0: testl %ebx, %ebx je .L2 movl%esi, 0(%ebp) .L2: ret op_imull_EAX_T0: subl$20, %esp movl0(%ebp), %eax imull %ebx movl%eax, (%esp) movl%eax, 0(%ebp) movl(%esp), %eax movl%edx, 4(%esp) movl%edx, 8(%ebp) movl%eax, %edx movl%eax, 8(%esp) sarl$31, %edx movl4(%esp), %eax movl%edx, 12(%esp) cmpl%eax, 12(%esp) setne %al movzbl %al, %eax movl%eax, 32(%ebp) addl$20, %esp ret Trunk r193340 produces the following: op_cmovl_EAX_T1_T0: testl %ebx, %ebx je .L2 movl%esi, 0(%ebp) .L2: ret op_imull_EAX_T0: subl$12, %esp movl%ebx, %eax imull 0(%ebp) movl%eax, 0(%ebp) movl%eax, (%esp) sarl$31, %eax movl%eax, 4(%esp) xorl%eax, %eax cmpl%edx, 4(%esp) movl%edx, 8(%ebp) setne %al movl%eax, 32(%ebp) addl$12, %esp ret
[Bug rtl-optimization/13355] Suboptimal code generated with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13355 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC|steven at gcc dot gnu.org | --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 22:50:51 UTC --- So, not quite the code of comment #3, but LRA does appear to improve things quite a bit. I'll leave it to the OP to decide whether this bug report is resolved sufficiently well to close it.
[Bug tree-optimization/18316] Missed IV optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2010-02-12 21:46:26 |2012-11-08 21:46:26 --- Comment #15 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 22:59:49 UTC --- Still a missed optimization as of trunk r193340: strength_test2: movl(%rdi), %ecx movl%ecx, %eax .p2align 4,,10 .p2align 3 .L3: movslq 8(%rdi), %rdx movl$2, (%rdi,%rdx,4) movl%eax, %edx addl%ecx, %eax cmpl4(%rdi), %edx jl .L3 rep ret strength_result2: movl(%rdi), %ecx xorl%eax, %eax .p2align 4,,10 .p2align 3 .L7: movslq 8(%rdi), %rdx addl%ecx, %eax movl$2, (%rdi,%rdx,4) cmpl4(%rdi), %eax jl .L7 rep ret
[Bug target/53087] [powerpc] Poor code from cstore expander
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53087 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 23:01:54 UTC --- Fixed according to comment #12.
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #28 from H.J. Lu hjl.tools at gmail dot com 2012-11-08 23:02:54 UTC --- So for POINTERS_EXTEND_UNSIGNED 0, we should transform (zero_extend:DI (plus:SI (FOO:SI) (const_int Y))) in such a way that it won't cause ICE and zero-extend the result. For X32, we just need to generate (plus:SI (REG:SI) (const_int Y))
[Bug tree-optimization/55238] ICE in find_aggregate_values_for_callers_subset, at ipa-cp.c:2908 building zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-11/msg00714.htm ||l --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-08 23:03:16 UTC --- I have submitted the patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00714.html
[Bug middle-end/41004] missed merge of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 23:07:36 UTC --- May be fixed by the patch that was applied for PR54364.
[Bug libstdc++/55244] New: char_traitschar compares characters as though unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244 Bug #: 55244 Summary: char_traitschar compares characters as though unsigned Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@danielrhouck.com Created attachment 28641 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28641 The preprocessed source code briefly demonstrating this behavior. According to the C++ standard, char_traits::compare's value is defined in terms of char_traits::lt's. The unspecialized version of the char_traits template implements this correctly. However, char_traitschar redefines compare based on __builtin_memcmp, and does not work correctly for characters not in the range [0, 127]. Specifically, it compares characters as though they were unsigned instead of signed. The attached preprocessed code was produced by g++ -v -save-temps testcase.cpp -o testcase executed on a simple file. The output of gcc is below: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3/g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /usr/portage-tmp/portage/sys-devel/gcc-4.5.3-r2/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/python --enable-checking=release --enable-java-awt=gtk --enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r2 p1.5, pie-0.4.7' Thread model: posix gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1plus -E -quiet -v -D_GNU_SOURCE testcase.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 -fpch-preprocess -o testcase.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/backward /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/cc1plus -fpreprocessed testcase.ii -quiet -dumpbase testcase.cpp -mtune=generic -march=x86-64 -auxbase testcase -version -o testcase.s GNU C++ (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) version 4.5.3 (x86_64-pc-linux-gnu) compiled by GNU C version 4.5.3, GMP version 5.0.2, MPFR version 3.0.1-p4, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Gentoo 4.5.3-r2 p1.5, pie-0.4.7) version 4.5.3 (x86_64-pc-linux-gnu) compiled by GNU C version 4.5.3, GMP version 5.0.2, MPFR version 3.0.1-p4, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3053bf2eb42d601ba6282eebbd0ccc30 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/as -V -Qy --64 -o testcase.o testcase.s GNU assembler version 2.21.1 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.21.1 COMPILER_PATH=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/libexec/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Last reconfirmed|2008-12-25 15:59:38 |2012-11-08 15:59:38 --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-11-08 23:17:40 UTC --- The compiler now produces a wonderful diagnostic for my original test case (comment #1), with one line of the diagnostic with a length of 30750 (!) characters. Nice, on that 80-chars wide terminal! :-) t.C: In instantiation of 'class std::vectorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocat. t.C:120:23: recursively required from 'class std::vectorstd::allocator__gnu_cxx::_Hashtable_nodestd::pairconst std::basic_stringchar, symbol *, std::allocatorstd::a. t.C:120:23: required from 'class std::vector__gnu_cxx::_Hashtable_nodestd::pairconst std::basic_stringchar, symbol *, std::allocator__gnu_cxx::_Hashtable_nodestd::pa.. t.C:445:18: required from 'class __gnu_cxx::hashtablestd::pairconst std::basic_stringchar, symbol, std::basic_stringchar, __gnu_cxx::hashstd::basic_stringchar , st. t.C:552:9: required from 'class __gnu_cxx::hash_mapstd::basic_stringchar, symbol' t.C:574:35: required from here t.C:121:38: error: no type named 'pointer' in 'class std::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd::allocatorstd typedef typename _Alloc::pointer pointer; ^
[Bug libstdc++/55244] char_traitschar compares characters as though unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244 --- Comment #1 from Daniel Houck GCC at DanielRHouck dot com 2012-11-08 23:19:27 UTC --- Created attachment 28642 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28642 The original source code before preprocessing I am including this because the problem lies with the standard library and not the compiler, and therefore it may be useful to know exactly how I included the standard library.
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #29 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-08 23:21:44 UTC --- So for POINTERS_EXTEND_UNSIGNED 0, we should transform (zero_extend:DI (plus:SI (FOO:SI) (const_int Y))) in such a way that it won't cause ICE and zero-extend the result. For X32, we just need to generate (plus:SI (REG:SI) (const_int Y)) The ICE is a minor detail, the real issue is convert_memory_address_addr_space and PR middle-end/49721. The unmodified compiler generates the same problematic instructions for the full testcase without -fPIC. It's clear that Richard's change, aka the un-sign-extension of sizetype constants, is an earthquake here.
[Bug libstdc++/55244] char_traitschar compares characters as though unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|GCC at DanielRHouck dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 23:45:40 UTC --- See: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467 Eh!
[Bug libstdc++/55244] char_traitschar compares characters as though unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 23:50:34 UTC --- In short, I think we are fine.
[Bug libstdc++/55244] char_traitschar compares characters as though unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244 --- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-08 23:52:52 UTC --- (In reply to comment #2) Agreed, looks like an invalid issue to me.
[Bug libstdc++/55244] char_traitschar compares characters as though unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55244 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-08 23:55:27 UTC --- Thanks Daniel.
[Bug go/55228] index.go should check size of int instead of GOARCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55228 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Ian Lance Taylor ian at airs dot com 2012-11-09 00:06:41 UTC --- Fixed on mainline.
[Bug c++/55245] New: Compiler segfault when compiling the small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
Bug #: 55245
Summary: Compiler segfault when compiling the small test case
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com
Compiling the following program without any option, gcc segfaults:
get.cc: In member function 'virtual void Test2::TestBody()':
get.cc:22:27: internal compiler error: Segmentation fault
The problem is that one array type Vector2_f[2]'s size field is reset to zero
during gimplify_type_sizes by one of its variant (which has null size).
The problem does not show up in trunk compiler. Was this fixed explicitly in
trunk or it happens to work by luck?
David
template typename VType class Vector2 { };
typedef Vector2float Vector2_f;
void GetR( const Vector2_f mosaic_position[3]);
class Test1 {
private: virtual void TestBody();
};
void Test1::TestBody() {
Vector2_f mosaic_position[2][1]; // (1)
}
class Test2 {
private: virtual void TestBody();
};
int tri;
void Test2::TestBody() {
Vector2_f mosaic_position[2][3] = { };
GetR(mosaic_position[tri]);
}
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #30 from H.J. Lu hjl.tools at gmail dot com 2012-11-09 00:35:28 UTC --- (In reply to comment #24) I think the most robust solution would be to always zero-extend the addresses for -mx32, i.e. output movl%ecx, -1073743664(%eax) even if the address is a PLUS in DImode. Otherwise, we're left with kludges... Since x32 runs in 64-bit mode, for address -0x4300(%rax), hardware sign-extends displacement from 32-bits to 64-bits and adds it to %rax. But x32 wants 32-bit -0x4300, not 64-bit -0x4300. I believe it is correct for GCC to use 32-bit registers instead of 64-bit registers when displacement is negative.
[Bug c++/55245] Compiler segfault when compiling the small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 davidxl xinliangli at gmail dot com changed: What|Removed |Added Version|4.7.3 |4.8.0 --- Comment #1 from davidxl xinliangli at gmail dot com 2012-11-09 00:42:55 UTC --- The problem actually exists in main line compiler too.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 00:44:06 UTC --- Do you know where it is looping? That sounds like a different and more serious issue than the pretty-printer for types not being able to summarize repetitive template instantiations (and that is already reported in a different PR). Clang doesn't loop but it still prints the long lines.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 00:58:20 UTC --- As I said in PR 43113, it would be wonderful if g++ detected that something is a recursive template instantiation and it didn't print the whole expansion but just the first recursion or some such. I wonder if clang++ has a PR open about this...
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-09 01:27:49 UTC --- (In reply to comment #12) Do you know where it is looping? That sounds like a different and more serious issue than the pretty-printer for types not being able to summarize repetitive template instantiations (and that is already reported in a different PR). To answer my own question, it loops (or it seems to take a very long time) in instantiate_pending_templates: #150 0x0069403f in emit_mem_initializers (mem_inits=0x77053c58) at /home/manuel/test1/pristine/gcc/cp/init.c:1085 #151 0x005a40ae in tsubst_expr (t=optimized out, args=args@entry=0x77041060, complain=complain@entry=3, in_decl=in_decl@entry=0x7758ca10, integral_constant_expression_p=integral_constant_expression_p@entry=false) at /home/manuel/test1/pristine/gcc/cp/pt.c:12671 #152 0x005a3964 in tsubst_expr (t=0x77416e70, args=args@entry=0x77041060, complain=complain@entry=3, in_decl=in_decl@entry=0x7758ca10, integral_constant_expression_p=integral_constant_expression_p@entry=false) at /home/manuel/test1/pristine/gcc/cp/pt.c:12849 #153 0x005a10aa in instantiate_decl (d=optimized out, d@entry=0x7703c800, defer_ok=optimized out, defer_ok@entry=0, expl_inst_class_mem_p=expl_inst_class_mem_p@entry=false) at /home/manuel/test1/pristine/gcc/cp/pt.c:18674 #154 0x005dbaa4 in instantiate_pending_templates (retries=optimized out) at /home/manuel/test1/pristine/gcc/cp/pt.c:18773 #155 0x00618ac9 in cp_write_global_declarations () at /home/manuel/test1/pristine/gcc/cp/decl2.c:3990 #156 0x00aadbd5 in compile_file () at /home/manuel/test1/pristine/gcc/toplev.c:558 #157 0x00aaf738 in do_compile () at /home/manuel/test1/pristine/gcc/toplev.c:1864 #158 toplev_main (argc=3, argv=0x7fffe738) at /home/manuel/test1/pristine/gcc/toplev.c:1940 #159 0x776261a6 in __libc_start_main () from /lib/libc.so.6 #160 0x0052f919 in _start () Jason, Joseph, why are we trying to do (cp_)write_global_declarations if we have already seen compilation errors? Can't we just abort earlier in compile_file()?
[Bug target/55246] New: Define a macro for 16*1024*1024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55246 Bug #: 55246 Summary: Define a macro for 16*1024*1024 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com i386 backend has i386.c: || INTVAL (op1) = 16*1024*1024 i386.c: || INTVAL (op1) -16*1024*1024) i386.c: if (INTVAL (op1) -16*1024*1024 i386.c: || INTVAL (op1) = 16*1024*1024) predicates.md: offset 16*1024*1024 predicates.md: offset 16*1024*1024 It is a magic number for 64-bit displacement. We should define a macro to make it consistent.
