[Bug c/45317] struct union misalignment
--- Comment #1 from schwab at linux-m68k dot org 2010-08-18 08:19 --- That's how it is defined by the respective ABIs. On i386-linux a struct field has at most 32-bit alignment. Add explicit padding or compile with -malign-double if you want to be compatible to the mingw32 ABI, but that won't be the only difference between those ABIs. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45317
[Bug debug/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
--- Comment #7 from iains at gcc dot gnu dot org 2010-08-18 08:21 --- Subject: Bug 42487 Author: iains Date: Wed Aug 18 08:21:43 2010 New Revision: 163326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163326 Log: PR debug/42487 * lib/target-supports.exp (check_effective_target_function_sections): New. * gcc.dg/debug/dwarf2/aranges-fnsec-1.c: Check that the target supports function sections before proceding. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/aranges-fnsec-1.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug middle-end/45316] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-18 08:45 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-08-18 03:36:29 |2010-08-18 08:45:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45316
[Bug middle-end/45316] [4.6 Regression] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -O1 -ftree-pre -fnon-call-exceptions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45316
[Bug middle-end/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-18 08:55 --- Doing binary search shouldn't be too hard, just build two separate kernel trees, one with the problematic patch applied, one without, with make V=1 output put into some log file in each case. Then just start with the final link line and replace half of the objects/libraries there with matching objects/libraries from the second build and vice versa, test that kernel and depending on the results continue narrowing it down to half of the object files/libraries etc., repeat until you have e.g. working kernel with all objects with the patch applied except one (or non-working kernel with all objects without the patch applied except one). Or, if you suspect particular object files, try to change just those immediately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45315
[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-18 09:16 --- With 4.5.1 I get (checking enabled) VM.cpp: In member function 'gnash::VM::RNG gnash::VM::randomNumberGenerator() const': VM.cpp:126:1: error: statement marked for throw in middle of block # .MEM_19 = VDEF .MEM_18 D.294844_12 = OBJ_TYPE_REF(D.294843_10;D.294841_8-0) (D.294841_8); VM.cpp:126:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. and with trunk I get VM.cpp: In member function 'gnash::VM::RNG gnash::VM::randomNumberGenerator() const': VM.cpp:126:1: internal compiler error: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1207 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. 4.4.4 works. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.5.1 4.6.0 Known to work||4.4.4 Last reconfirmed|-00-00 00:00:00 |2010-08-18 09:16:16 date|| Summary|ICE: error: in |[4.5/4.6 Regression] ICE: |remove_unreachable_handlers,|error: in |at tree-sh.c:3294 with -O2 -|remove_unreachable_handlers, |floop-interchange |at tree-sh.c:3294 with -O2 - ||floop-interchange Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-08-18 10:34 --- Subject: Bug 42575 Author: mkuvyrkov Date: Wed Aug 18 10:34:02 2010 New Revision: 163334 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163334 Log: gcc/ PR rtl-optimization/42575 * optabs.c (expand_doubleword_mult): Generate new pseudos to shorten live ranges. gcc/testsuite/ PR rtl-optimization/42575 * gcc.target/pr42575.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr42575.c Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-08-18 10:43 --- Bernd did all the heavy lifting for this patch. The above patch fixes the last piece of the problem -- extra move when compiling for ARMv7-A. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-18 10:50 --- So the scheduler uses cselib to get a better view of the address, but cselib doesn't actually give a better address. And the solution is to just give up in that case? It seems to me that if cselib doesn't give a better address than XEXP(MEM,0) then the original address should be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-18 12:32 --- This is broken for more than month, by a change which didn't fix any bug, nor improved code generation nor compilation time; I'd say DECL_CHAIN should drop the DECL_MINIMAL_CHECK test unless this is resolved soon, either by reverting those places to use TREE_CHAIN again instead of DECL_CHAIN, or use if (DECL_P (x)) ... DECL_CHAIN (x) ... else ... TREE_CHAIN (x) ...; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45049
[Bug target/45094] [arm] wrong instructions for dword move in some cases
--- Comment #6 from qiyao at gcc dot gnu dot org 2010-08-18 12:34 ---
Subject: Bug 45094
Author: qiyao
Date: Wed Aug 18 12:33:43 2010
New Revision: 163338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163338
Log:
gcc/
PR target/45094
* config/arm/arm.c (output_move_double): Fix typo generating
instructions ('ldr'-'str').
gcc/testsuite/
PR target/45094
* gcc.target/arm/pr45094.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/arm/pr45094.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094
[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux
--- Comment #11 from hjl at gcc dot gnu dot org 2010-08-18 13:36 --- Subject: Bug 45292 Author: hjl Date: Wed Aug 18 13:35:46 2010 New Revision: 163339 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163339 Log: Expand pending pops before trying the optab. 2010-08-18 Paolo Bonzini bonz...@gnu.org PR middle-end/45292 * optabs.c (expand_bool_compare_and_swap): Expand pending pops before trying the optab. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
[Bug fortran/45318] New: Do more parenthesis simplification with -fno-protect-parens
Fortran preserves () in expressions - in many cases, it shouldn't need to do so if -fno-protect-parens is specified. The option currently affects only the middle end, but there might be some cases where it is preserved without needing to be. (Though, I might be wrong and everything is already properly simplified). Note: The out most parenthesis can not always be removed without changing the semantics, e.g. call copy ( (a), a) contains subroutine copy (x, y) intent(in) :: x intent(out) :: y is valid but only works if the (a) [- temporary] is not optimized to a. In some cases, one might need to check for the unsave_math_optimization flag before changing, e.g., 2+(a-2) to a - or rather (a). -- Summary: Do more parenthesis simplification with -fno-protect- parens Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318
[Bug c++/45303] Compile error when not using -ftree-ter
--- Comment #7 from jobnoorman at gmail dot com 2010-08-18 14:03 --- (In reply to comment #3) Looking at the diagnostics issued when -pedantic is added, I think the right conversion is (void*)(plain_foobar_t)Foo::foobar That still uses the G++ extension, and doesn't give the asm error even without optimisation. That looks like a workaround to me. How could it ever be that (void*)some_expression is accepted as a constant expression when some_expression is not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
[Bug preprocessor/45319] New: FAIL: libgomp.fortran/vla4.f90
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90 -B/mnt/gnu/gcc/objdir/hp pa2.0w-hp-hpux11.11/./libgomp/ -B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./lib gomp/.libs -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgomp -I/mnt/gnu/gcc/ gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O0 -B/mnt/gnu/gcc/objdi r/hppa2.0w-hp-hpux11.11/./libgomp/../libgfortran/.libs -L/mnt/gnu/gcc/objdir/h ppa2.0w-hp-hpux11.11/./libgomp/.libs -lgomp -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hp ux11.11/./libgomp/../libgfortran/.libs -lgfortran -lm -o ./vla4.exe (timeou t = 300) /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90: In function 'foo': /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90:96:0: warning: barri er region may not be closely nested inside of work-sharing, critical, ordered, m aster or explicit task region output is: /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90: In function 'foo': /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90:96:0: warning: barri er region may not be closely nested inside of work-sharing, critical, ordered, m aster or explicit task region FAIL: libgomp.fortran/vla4.f90 -O0 (test for warnings, line 97) FAIL: libgomp.fortran/vla4.f90 -O0 (test for excess errors) /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla4.f90:96:0: warning: barri er region may not be closely nested inside of work-sharing, critical, ordered, m aster or explicit task region Appears warning points to wrong line number. -- Summary: FAIL: libgomp.fortran/vla4.f90 Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45319
[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-18 14:23 --- (In reply to comment #0) In some cases, one might need to check for the unsave_math_optimization flag before changing, e.g., 2+(a-2) to a - or rather (a). The whole point of PAREN_EXPR in the middle-end is to avoid transforming 2 + (a - 2) even _with_ -funsafe-math-optimizations / -ffast-math! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318
[Bug fortran/45319] [4.5 Regression] FAIL: libgomp.fortran/vla4.f90
--- Comment #1 from danglin at gcc dot gnu dot org 2010-08-18 14:32 --- Similar fails: FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for warnings, line 11) FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for excess errors) Excess errors: /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.35.4.f90:9:0: warni ng: barrier region may not be closely nested inside of work-sharing, critical, o rdered, master or explicit task region FAIL: libgomp.fortran/vla5.f90 -O0 (test for warnings, line 69) FAIL: libgomp.fortran/vla5.f90 -O0 (test for excess errors) Excess errors: /mnt/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/vla5.f90:68:0: warning: barri er region may not be closely nested inside of work-sharing, critical, ordered, m aster or explicit task region -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45319
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #24 from bernds at gcc dot gnu dot org 2010-08-18 14:36 --- It should be possible to do better in cselib_subst_to_values - for POST_* we could look up the value of the inner expression, and for PRE_* we could probably construct a PLUS of some kind. That would be an enhancement, but it's unrelated to the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90
--- Comment #28 from mikael at gcc dot gnu dot org 2010-08-18 14:40 --- (In reply to comment #27) This is a very good suggestion. I will have a think about how to implement it and will come back to you. It is consistent with what I had in mind to improve the efficiency of module reading. ie. read_module proceeds as follows: (i) On encountering a USE statement, look for the module gsym. If it does not exist, use read_module, as at present, to construct the namespace, without any exclusions or renames; (ii) In the current scope, create symtrees using the ONLY and the renames and point to the symbols in the gsym namespace; (iii) Subsequent USEs of the same module proceed by using the gsym namespace. Hello, I have been trying a similar approach before. One problem you may encounter is that symbols have non-shareable parts. For examples symbol attributes such as access or use_rename can differ between symbols associated to the same entity. I tried to split gfc_symbol into an entity-specific part and a symbol-specific part but that led to huge changes throughout the frontend and to the associated regressions, so that I eventually gave up. A possible way might be to clone the symbol, and keep a pointer to the original one so that we can get the original backend_decl from it. Maybe you will have a different path and won't encounter this problem at all. Good luck anyway, that seems the way to go :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
[Bug c/45320] New: Strict-aliasing misdetection
The following code fails to detect breaking of strict-aliasing rules correctly:
#include stdio.h
int main()
{
int i;
float A[20];
for (i = 0; i 20; i++)
{
A[i] = i;
unsigned int *p = (unsigned int *)A[i];
printf(%d\t%.24f\t0x%08x\n, i, A[i], *p);
}
return 0;
}
gcc only gives a warning when compiling with '-Wall -O1'. Yet, compiling with
'-Wall -fstrict-aliasing' seems to produce correct results, even though '-Wall
-O2' breaks the code.
--
Summary: Strict-aliasing misdetection
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: strikosn at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45320
[Bug libstdc++/45276] Need to document _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE
--- Comment #2 from paolo at gcc dot gnu dot org 2010-08-18 15:22 --- Subject: Bug 45276 Author: paolo Date: Wed Aug 18 15:21:56 2010 New Revision: 163342 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163342 Log: 2010-08-18 Kostya Serebryany k...@google.com Paolo Carlini paolo.carl...@oracle.com PR libstdc++/45276 * doc/xml/manual/debug.xml ([debug.races]): Add. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/debug.xml -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45276
[Bug libstdc++/45276] Need to document _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-18 15:24 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45276
[Bug c/45320] Strict-aliasing misdetection
--- Comment #1 from paolo dot carlini at oracle dot com 2010-08-18 15:28 --- In general terms, ins't true that the warnings produced at -O0 are often much weaker than when optimizing? I don't see anything aliasing-specific here... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45320
[Bug bootstrap/45321] New: [4.6 regression] ARM bootstrap failure due to stdarg_p change
Attempting to bootstrap gcc-4.6-20100814 (r163252) on arm-linux-gnueabi fails due to a warning in stage2 and the default use of -Werror there: /home/mikpe/gcc-4.6-20100814/gcc/config/arm/arm.c: In function 'arm_get_pcs_model': /home/mikpe/gcc-4.6-20100814/gcc/config/arm/arm.c:3720:7: error: passing argument 1 of 'stdarg_p' discards 'const' qualifier from pointer target type [-Werror] /home/mikpe/gcc-4.6-20100814/gcc/tree.h:4829:13: note: expected 'tree' but argument is of type 'const_tree' cc1: all warnings being treated as errors make[3]: *** [arm.o] Error 1 make[3]: Leaving directory `/home/mikpe/objdir46/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 Presumably caused by r163033: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00244.html -- Summary: [4.6 regression] ARM bootstrap failure due to stdarg_p change Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC host triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
--- Comment #1 from mikpe at it dot uu dot se 2010-08-18 15:43 --- Created an attachment (id=21511) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21511action=view) proposed fix The issue is that stdarg_p has a non-const parameter but the call site in the ARM backend has a const value it wants to pass. The right solution seems to be to make stdarg_p accept a const parameter, but then the problem is that the parameter is stored in the iterator's fntype field. Nothing uses that field, so removing it and then making the parameter const fixes the issue. ARM bootstrap still fails for me with comparison failures, however. (I'm in an email black hole at the moment so can't easily submit this to gcc-patches.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-08-18 16:06 --- Subject: Bug 45049 Author: froydnj Date: Wed Aug 18 16:05:40 2010 New Revision: 163344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163344 Log: gcc/cp/ PR c++/45049 * name-lookup.c (push_overloaded_decl): Change DECL_CHAIN to TREE_CHAIN. gcc/testsuite/ PR c++/45049 * g++.dg/pr45049-1.C: New test. * g++.dg/pr45049-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr45049-1.C trunk/gcc/testsuite/g++.dg/pr45049-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45049
[Bug c++/45049] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in push_overloaded_decl, at cp/name-lookup.c:2160
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-08-18 16:07 --- Fixed. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45049
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug c/45320] Strict-aliasing misdetection
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-18 16:10 --- At -O2 -Wstrict-aliasing=1 warns for me. I can't reproduce warnings with -O0 or with -O1 because at those levels strict-aliasing isn't enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45320
[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589
--- Comment #6 from fang at csl dot cornell dot edu 2010-08-18 16:30 --- Created an attachment (id=21512) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21512action=view) test case, semi-reduced, day 3 day 3 of reducing, 4.5k lines -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
[Bug fortran/45318] Do more parenthesis simplification with -fno-protect-parens
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-18 17:44 --- (In reply to comment #1) (In reply to comment #0) In some cases, one might need to check for the unsave_math_optimization flag before changing, e.g., 2+(a-2) to a - or rather (a). The whole point of PAREN_EXPR in the middle-end is to avoid transforming 2 + (a - 2) even _with_ -funsafe-math-optimizations / -ffast-math! Well, I am talking about FE optimizations with -fno-protect-parens (note the no-). The PAREN_EXPR protection *is* and *should* one done with -fprotect-parens (which is the default setting). In terms of the middle end, -fno-protect-parens and -fprotect-parens are both properly handled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45318
[Bug c++/45303] Compile error when not using -ftree-ter
--- Comment #8 from ian at airs dot com 2010-08-18 17:44 --- Just for the record, I'm with Jakub: the general rule should be that r always works for a value that fits in a register, and anything else requires enabling optimization to work reliably. I don't see why we should sign up to handle all constants for inline asm when not optimizing. It seems like an unusual edge case, a bunch of work for really minimal benefit. Changing the example in comment #5 to reliably fail will break real code for no useful benefit and is thus contra-indicated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
[Bug fortran/45295] intrinsic.texi: SELECTED_CHAR_KIND should mention wide-char support
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-18 18:06 --- Subject: Bug 45295 Author: burnus Date: Wed Aug 18 18:05:58 2010 New Revision: 163347 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163347 Log: 2010-08-18 Tobias Burnus bur...@net-b.de PR fortran/45295 * intrinsic.texi (selected_char_kind): Document ISO_10646 support. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45295
[Bug fortran/45295] intrinsic.texi: SELECTED_CHAR_KIND should mention wide-char support
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-18 18:07 --- FIXED -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45295
[Bug fortran/44735] ICE on FORALL with character array pointer
--- Comment #2 from pault at gcc dot gnu dot org 2010-08-18 18:55 --- Created an attachment (id=21513) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21513action=view) The beginings of a fix This PR is going to drive me mad! The immediate cause is a failure to get the TYPE_SIZE_UNIT to calculate the size of the temporary needed for the assignment. This fixes that part of the problem but moves the focus to the assignment itself. Something is badly wrong with the temporary's TREE_TYPE but I do not see what it is right now. Let this be the record of where I got to Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #25 from jakub at gcc dot gnu dot org 2010-08-18 19:00 --- Alex Oliva posted some patches to make cselib handle autoinc stuff. No idea whether http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01038.html is the latest version or if he has a newer one. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug java/45322] New: libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
libtool: compile: libobj name `ltdl.lo' may not contain shell special characters. make[4]: *** [ltdl.lo] Error 1 make[4]: Leaving directory `/home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libjava/libltdl' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libjava/libltdl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/jayk/obj/gcc451' bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls -prefix=/home/jayk Thread model: posix gcc version 4.5.0 (GCC) bash-4.1$ uname -a OSF1 hostname V5.1 732 alpha alpha Tru64 I'll retry without Java. -- Summary: libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322
[Bug libfortran/45323] New: warnings compiling libgfortran/io/write.c: array subscript has type 'char'
Just warnings, not errors. /home/jayk/src/gcc-4.5.1/libgfortran/io/write.c: In function 'nml_write_obj': /home/jayk/src/gcc-4.5.1/libgfortran/io/write.c:1504:8: warning: array subscript has type 'char' /home/jayk/src/gcc-4.5.1/libgfortran/io/write.c:1511:4: warning: array subscript has type 'char' /home/jayk/src/gcc-4.5.1/libgfortran/io/write.c: In function 'namelist_write': /home/jayk/src/gcc-4.5.1/libgfortran/io/write.c:1760:7: warning: array subscript has type 'char' libtool: compile: /home/jayk/obj/gcc451/./gcc/xgcc -B/home/jayk/obj/gcc451/./gcc/ -B/home/jayk/alphaev67-de bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls -prefix=/home/jayk Thread model: posix gcc version 4.5.0 (GCC) bash-4.1$ uname -a OSF1 hostname V5.1 732 alpha alpha Tru64 $HOME/src/gcc-4.5.1/configure -prefix=$HOME -disable-nls -verbose Just warnings, not errors. -- Summary: warnings compiling libgfortran/io/write.c: array subscript has type 'char' Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45323
[Bug fortran/29785] Fortran 2003: POINTER Rank Remapping
--- Comment #9 from domob at gcc dot gnu dot org 2010-08-18 19:34 --- Created an attachment (id=21514) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21514action=view) Partial patch. This implements rank remapping and also bounds remapping as for PR 45016. Tests seem to be successful, although it's not yet been fully regtested. I still have to / want to add a compile-time and -fcheck=bounds test for too small target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29785
[Bug libfortran/45323] warnings compiling libgfortran/io/write.c: array subscript has type 'char'
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-18 19:40 --- That's the lines: 1472char cup; 1467size_t dim_i; 1504cup = toupper (base_name[dim_i]); 1511cup = toupper (obj-var_name[dim_i]); and 1743char c; 1741index_type i; 1760c = toupper (dtp-namelist_name[i]); (with: typedef ssize_t index_type;) According to POSIX, toupper is defined as: int toupper(int c); I am not sure I understand the message itself: array subscript has type 'char' because in those lines I do not see how the array subscript can be 'char'. It might be due to the way Tru64 Unix implements toupper. Does it help to cast the argument to (int)? I mean: -cup = toupper (base_name[dim_i]); +cup = toupper ((int) base_name[dim_i]); for all three toupper? (Note: The trunk has the same toupper calls.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45323
[Bug middle-end/44206] [4.6 Regression] ICE: Inline clone with address taken
--- Comment #3 from changpeng dot fang at amd dot com 2010-08-18 19:43 --- *** Bug 45269 has been marked as a duplicate of this bug. *** -- changpeng dot fang at amd dot com changed: What|Removed |Added CC||changpeng dot fang at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44206
[Bug c++/45269] CPU2006 450.soplex: verify_cgraph_node failed with -fprofile-generate
--- Comment #2 from changpeng dot fang at amd dot com 2010-08-18 19:43 --- http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html Verified. If I back out the above change, the bug goes away. So it is a duplicate of bug 44206 *** This bug has been marked as a duplicate of 44206 *** -- changpeng dot fang at amd dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45269
[Bug middle-end/45312] GCC 4.4.4 miscompiles (?) the Linux kernel, makes kernel unusable
--- Comment #7 from t dot artem at mailcity dot com 2010-08-18 20:00 --- I bet this bug can be triggered in a VM (e.g. in VirtualBox) too, so I'll try to debug it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #26 from ubizjak at gmail dot com 2010-08-18 20:13 --- Splitting to LEA was fixed in r163351 [1] with patch at [2]. [1] http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00562.html [2] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01394.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589
--- Comment #7 from fang at csl dot cornell dot edu 2010-08-18 20:13 --- Created an attachment (id=21515) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21515action=view) test case, day 3b yet smaller -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
[Bug testsuite/45324] New: gcc.target/i386/volatile-bitfields-1.c doesn't work with i586-linux
When gcc is configured with i586-linux, I got FAIL: gcc.target/i386/volatile-bitfields-1.c scan-assembler movzbl.*bits I don't see anything wrong with .cfi_startproc movbbits, %al sarb%al movsbl %al, %eax ret .cfi_endproc I think we should also check movb. -- Summary: gcc.target/i386/volatile-bitfields-1.c doesn't work with i586-linux Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45324
[Bug middle-end/45325] New: target attribute doesn't work with -march=i586
[...@gnu-36 gcc]$ cat
../../../../src-trunk/gcc/testsuite/gcc.target/i386/pr38240.c
/* { dg-do compile } */
typedef float V
__attribute__ ((__vector_size__ (16), __may_alias__));
V __attribute__((target(sse))) f(const V *ptr) { return *ptr; }
V g(const V *ptr) { return *ptr; }
[...@gnu-36 gcc]$ ../../xgcc -B../../
../../../../src-trunk/gcc/testsuite/gcc.target/i386/pr38240.c -S -march=i586
-m32
../../../../src-trunk/gcc/testsuite/gcc.target/i386/pr38240.c: In function g:
../../../../src-trunk/gcc/testsuite/gcc.target/i386/pr38240.c:8:21: internal
compiler error: in convert_move, at expr.c:326
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-36 gcc]$
--
Summary: target attribute doesn't work with -march=i586
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug middle-end/45325] target attribute doesn't work with -march=i586
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-18 20:31 --- Well - obviously global typedefs keep their BLKmode. The target attribute can't work this way - it's broken by design. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug middle-end/45325] target attribute doesn't work with -march=i586
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-18 20:58 --- WONTFIX for an ICE seems a bit odd to me. Just needs a diagnostic to reject nonsense target attributes, or a sorry. But not an ICE. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug middle-end/37565] __optimize__ attribute doesn't work correctly
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-18 20:59:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux
--- Comment #12 from hjl at gcc dot gnu dot org 2010-08-18 21:08 --- Subject: Bug 45292 Author: hjl Date: Wed Aug 18 21:08:24 2010 New Revision: 163353 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163353 Log: Expand pending pops before trying the optab. 2010-08-18 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-08-18 Paolo Bonzini bonz...@gnu.org PR middle-end/45292 * optabs.c (expand_bool_compare_and_swap): Expand pending pops before trying the optab. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/optabs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
[Bug middle-end/45325] target attribute doesn't work with -march=i586
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-18 21:18 --- Well, I think we should back out support for that option. The set of nonsensical options doesn't include sse - but all options are included in the set of broken options. At least I expect that you can create a testcase with such ICEs for every one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug bootstrap/45326] New: gmp's use of C99 keeps breaking my compiles, suggest set autoconf variables to avoid inttypes/stdint
I seem to keep running into inttypes.h/stdint.h that aren't quite adequate,
esp. for gmp. For example, in mpfr:
https://gforge.inria.fr/scm/viewvc.php/trunk/get_uj.c?view=logroot=mpfrpathrev=7083#rev7082
Anyway, I suggest this to reduce the problem:
bash-4.1$ diff -u Makefile.in.orig Makefile.in
--- Makefile.in.orig2010-08-18 11:33:42 -0700
+++ Makefile.in 2010-08-18 11:33:13 -0700
@@ -16308,7 +16308,7 @@
libsrcdir=$$s/gmp; \
$(SHELL) $${libsrcdir}/configure \
$(HOST_CONFIGARGS) --build=${build_alias}
--host=none-${host_vendor}-${host_os} \
- --target=none-${host_vendor}-${host_os} $${srcdiroption}
--disable-shared \
+ --target=none-${host_vendor}-${host_os} $${srcdiroption}
--disable-shared ac_cv_header_inttypes_h=no ac_cv_header_stdint_h=no \
|| exit 1
@endif gmp
Slightly tested.
I tried setting the ac_* variables around the entire gcc configure but that
broke's libiberty's use of intptr_t.
--
Summary: gmp's use of C99 keeps breaking my compiles, suggest set
autoconf variables to avoid inttypes/stdint
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45326
[Bug bootstrap/45326] gmp's use of C99 keeps breaking my compiles, suggest set autoconf variables to avoid inttypes/stdint
--- Comment #1 from jay dot krell at cornell dot edu 2010-08-18 21:27 --- example error: file included from /home/jayk/src/gcc-4.5.1/gmp/assert.c:27:0: /home/jayk/src/gcc-4.5.1/gmp/gmp-impl.h:188:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gmp_uint_least32_t' In file included from /home/jayk/src/gcc-4.5.1/gmp/assert.c:27:0: /home/jayk/src/gcc-4.5.1/gmp/gmp-impl.h:3413:7: error: expected specifier-qualifier-list before 'gmp_uint_least32_t' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45326
[Bug target/45327] New: [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496) with -O1 -funroll-loops -fnon-call-exceptions
Command line:
$ gcc -O1 -funroll-loops -fnon-call-exceptions testcase.c
Valgrind output:
==17265== Invalid read of size 2
==17265==at 0x82C2FB: rtx_equal_p (rtl.c:495)
==17265==by 0xA6781A: ix86_swap_binary_operands_p (i386.c:14395)
==17265==by 0xA8F448: ix86_binary_operator_ok (i386.c:14534)
==17265==by 0xDDE88E: recog (i386.md:8432)
==17265==by 0xECF613: recog_for_combine (combine.c:10165)
==17265==by 0xEFB8FF: try_combine (combine.c:3012)
==17265==by 0xF05BE3: rest_of_handle_combine (combine.c:1153)
==17265==by 0x7BF13B: execute_one_pass (passes.c:1567)
==17265==by 0x7BF3D4: execute_pass_list (passes.c:1622)
==17265==by 0x7BF3E6: execute_pass_list (passes.c:1623)
==17265==by 0x901335: tree_rest_of_compilation (tree-optimize.c:452)
==17265==by 0xABD765: cgraph_expand_function (cgraphunit.c:1643)
==17265== Address 0xabababababababab is not stack'd, malloc'd or (recently)
free'd
==17265==
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
testcase.c
int
foo (int a, int b)
{
return (a == 0 b == 0);
}
Tested revisions:
r163261 - crash
r158969 - crash
r158095 - OK
4.5 r160526 - OK
--
Summary: [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496)
with -O1 -funroll-loops -fnon-call-exceptions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
[Bug target/45327] [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496) with -O1 -funroll-loops -fnon-call-exceptions
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-18 21:49 --- Hm, Bernd - you recently touched that code. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
[Bug c++/45293] ICE in iterative_hash_template_arg, at cp/pt.c:1589
--- Comment #8 from fang at csl dot cornell dot edu 2010-08-18 22:05
---
reduced test case (manually reduced after delta):
===
typedef long unsigned int size_t;
template class T struct never_ptr {
T* ptr;
T* operator - () const throw() {
return ptr;
}
};
namespace HAC {
template class class instance_collection_pool_bundle;
template class Tag class footprint_base {
typedef instance_collection_pool_bundleTag collection_pool_bundle_type;
protected: const never_ptrcollection_pool_bundle_type
collection_pool_bundle;
};
struct process_tag;
template class Tag class instance_collection;
template class struct class_traits;
template class Tag class instance_alias_info;
}
namespace std {
template class T struct default_vector {
typedef size_t type;
};
}
namespace HAC {
class footprint : private footprint_baseprocess_tag {
void operator [] ( const size_t ) const;
};
class physical_instance_collection;
template class, size_t class instance_array;
typedef instance_collectionprocess_tag process_instance_collection;
typedef instance_alias_infoprocess_tag process_instance_alias_info;
template class class general_collection_type_manager;
template struct class_traitsprocess_tag {
typedef process_tag tag_type;
typedef process_instance_alias_info instance_alias_info_type;
typedef process_instance_collection instance_collection_generic_type;
typedef physical_instance_collection instance_collection_parent_type;
typedef general_collection_type_managertag_type
collection_type_manager_parent_type;
};
class instance_collection_base {
};
class physical_instance_collection : public instance_collection_base {
};
template class Tag class collection_interface : public
class_traitsTag::instance_collection_parent_type {
};
template class Tag class instance_collection : public
collection_interfaceTag, public
class_traitsTag::collection_type_manager_parent_type {
public: typedef class_traitsTag traits_type;
typedef typename traits_type::instance_alias_info_type
instance_alias_info_type;
typedef never_ptrconst instance_alias_info_type
const_instance_alias_info_ptr_type;
};
template class Tag class general_collection_type_manager {
};
template class T class instance_collection_pool_wrapper {
public: typedef T collection_type;
typedef typename collection_type::traits_type::tag_type tag_type;
};
template class Tag struct instance_collection_pool_bundle : public
instance_collection_pool_wrapperinstance_arrayTag, 0 {
void lookup_collection(void) const;
};
template class Tag, size_t D class instance_array : public
instance_collectionTag {
public: typedef class_traitsTag traits_type;
typedef typename traits_type::instance_collection_generic_type
parent_type;
typedef typename parent_type::const_instance_alias_info_ptr_type
const_instance_alias_info_ptr_type;
void get_all_aliases(typename
std::default_vectorconst_instance_alias_info_ptr_type::type) const;
};
template class Tag class instance_arrayTag,0 : public
instance_collectionTag {
public: typedef class_traitsTag traits_type;
typedef typename traits_type::instance_collection_generic_type
parent_type;
typedef typename parent_type::const_instance_alias_info_ptr_type
const_instance_alias_info_ptr_type;
void get_all_aliases(typename
std::default_vectorconst_instance_alias_info_ptr_type::type) const;
};
void footprint::operator [] ( const size_t ) const {
footprint_baseprocess_tag::collection_pool_bundle-lookup_collection();
}
}
===
This should be a valid test case, passes g++-4.0.1.
reducing script:
#!/bin/sh -e
# must be valid for g++-4.0.1! (powerpc-apple-darwin8)
g++ -o footprint.o -c footprint.ii /dev/null 21
# then fail specifically with ICE
g++-fsf-4.5 -o footprint.o -c footprint.ii footprint.err 21 || :
grep -q internal compiler error: in iterative_hash_template_arg, at
cp/pt.c:1589 footprint.err
keywords: ICE-on-valid-code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
[Bug target/45327] [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496) with -O1 -funroll-loops -fnon-call-exceptions
--- Comment #2 from ubizjak at gmail dot com 2010-08-18 22:13 ---
Patch that fixes the failure:
Index: i386.md
===
--- i386.md (revision 163353)
+++ i386.md (working copy)
@@ -8456,7 +8452,7 @@
(const_int 0)))
(clobber (match_scratch:SWI 0 =r))]
ix86_match_ccmode (insn, CCNOmode)
-ix86_binary_operator_ok (CODE, MODEmode, operands)
+!(MEM_P (operands[1]) MEM_P (operands[2]))
logic{imodesuffix}\t{%2, %0|%0, %2}
[(set_attr type alu)
(set_attr mode MODE)])
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-18 22:13:05
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
[Bug target/45327] [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496) with -O1 -funroll-loops -fnon-call-exceptions
--- Comment #3 from ubizjak at gmail dot com 2010-08-18 22:24 ---
(In reply to comment #2)
Patch that fixes the failure:
This is actually {i,x}or_{qi,hi,si,di}_3 pattern.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
[Bug fortran/45290] [F08] pointer initialization
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-18 22:32 --- Subject: Bug 45290 Author: janus Date: Wed Aug 18 22:32:22 2010 New Revision: 163356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163356 Log: 2010-08-19 Janus Weil ja...@gcc.gnu.org PR fortran/45290 * gfortran.h (gfc_add_save): Modified prototype. * decl.c (add_init_expr_to_sym): Defer checking of proc pointer init. (match_pointer_init): New function to match F08 pointer initialization. (variable_decl,match_procedure_decl,match_ppc_decl): Use 'match_pointer_init'. (match_attr_spec): Module variables are implicitly SAVE. (gfc_match_save): Modified call to 'gfc_add_save'. * expr.c (gfc_check_assign_symbol): Extra checks for pointer initialization. * primary.c (gfc_variable_attr): Handle SAVE attribute. * resolve.c (resolve_structure_cons): Add new argument and do pointer initialization checks. (gfc_resolve_expr): Modified call to 'resolve_structure_cons'. (resolve_values): Call 'resolve_structure_cons' directly with init arg. (resolve_fl_variable): Handle SAVE_IMPLICIT. * symbol.c (gfc_add_save,gfc_copy_attr,save_symbol): Handle SAVE_IMPLICIT. * trans-decl.c (gfc_create_module_variable): Module variables with TARGET can already exist. * trans-expr.c (gfc_conv_variable): Check for 'current_function_decl'. (gfc_conv_initializer): Implement non-NULL pointer initialization. 2010-08-19 Janus Weil ja...@gcc.gnu.org PR fortran/45290 * gfortran.dg/proc_ptr_comp_3.f90: Modified. * gfortran.dg/pointer_init_2.f90: New. * gfortran.dg/pointer_init_3.f90: New. * gfortran.dg/pointer_init_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_2.f90 trunk/gcc/testsuite/gfortran.dg/pointer_init_3.f90 trunk/gcc/testsuite/gfortran.dg/pointer_init_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug c++/45328] New: bug w/ typedefs and std::initializer_listT
Given this code,
#include initializer_list
typedef std::initializer_listint init_list;
struct A {
A (init_list list) { }
};
struct B {
B (std::initializer_listint list) { }
};
int main (void) {
A a { 0, 1, 1, 2}; // compiler error
B b { 0, 1, 1, 2};
}
I get a compiler error when trying to brace initialize an instance of struct A.
The specific error:
initializer_bug.cpp: In function âint main()â:
initializer_bug.cpp:14:19: error: no matching function for call to
âA::A(brace-enclosed initializer list)â
initializer_bug.cpp:6:3: note: candidates are: A::A(init_list)
initializer_bug.cpp:5:10: note: A::A(const A)
Compiled example code with g++ --std=c++0x initializer_bug.cpp -o
initializer_bug.
Using gcc version 4.5.1 20100617 (prerelease) (Debian 4.5.0-6)
--
Summary: bug w/ typedefs and std::initializer_listT
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: admin at thefireflyproject dot us
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
[Bug fortran/45290] [F08] pointer initialization
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-18 22:37 --- r163356 implements pointer initialization. Leftover To-Do items: (1) ICE on module m implicit none integer, target, save :: t1 integer, pointer :: p1 = t integer, pointer :: p2 = p1! ICE end module m (2) Making global variables in a program SAVE_IMPLICIT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
[Bug c++/45315] [4.4/4.5/4.6 Regression] ICE: tree check: expected aggr_init_expr, have call_expr in build_value_init, at cp/init.c:317
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-08-18 00:49:20 |2010-08-18 22:41:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45315
[Bug c++/45303] Compile error when not using -ftree-ter
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-18 22:42 --- *** This bug has been marked as a duplicate of 23200 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
[Bug inline-asm/23200] [4.3/4.4/4.5/4.6 Regression] rejects i(var + 1)
--- Comment #44 from pinskia at gcc dot gnu dot org 2010-08-18 22:42 --- *** Bug 45303 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jobnoorman at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug target/45327] [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496) with -O1 -funroll-loops -fnon-call-exceptions
--- Comment #4 from uros at gcc dot gnu dot org 2010-08-18 22:37 --- Subject: Bug 45327 Author: uros Date: Wed Aug 18 22:37:03 2010 New Revision: 163357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163357 Log: PR target/45327 * config/i386/i386.md (any_or:codeSWI:mode_3): Do not use ix86_binary_operator_ok. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md --- Comment #5 from uros at gcc dot gnu dot org 2010-08-18 22:43 --- Subject: Bug 45327 Author: uros Date: Wed Aug 18 22:42:54 2010 New Revision: 163358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163358 Log: PR target/45327 * config/i386/i386.md (any_or:codeSWI:mode_3): Do not use ix86_binary_operator_ok. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
[Bug target/45327] [4.6 Regression] ICE: SIGSEGV in rtx_equal_p (rtl.c:496) with -O1 -funroll-loops -fnon-call-exceptions
--- Comment #6 from ubizjak at gmail dot com 2010-08-18 22:47 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45327
[Bug c++/45328] bug w/ typedefs and std::initializer_listT
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-18 22:54 --- possibly related to Bug 44703, although that's fixed in 4.5.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
[Bug middle-end/45292] [4.5/4.6 regression] libgomp test failures for i586-linux
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-18 23:08 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
[Bug c++/45328] [C++0x] bug w/ typedefs and std::initializer_listT
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-18 23:11 --- Let's CC Jason. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Summary|bug w/ typedefs and |[C++0x] bug w/ typedefs and |std::initializer_listT|std::initializer_listT http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
[Bug c++/45328] [C++0x] bug w/ typedefs and std::initializer_listT
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-18 23:19 --- Actually, both mainline and the released 4.5.1 work, most likely a duplicate of PR 44703 indeed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|jason at gcc dot gnu dot org| Status|UNCONFIRMED |RESOLVED Known to fail||4.5.0 Known to work||4.6.0 4.5.1 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-08-19 02:36 --- Subject: Bug 41859 Author: jvdelisle Date: Thu Aug 19 02:35:45 2010 New Revision: 163363 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163363 Log: 2010-08-19 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41859 * resolve.c (resolve_transfer): Traverse operands and set expression to be checked to a non EXPR_OP type. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/45108] Namelist read: Not aborted when reading from STDIN
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-08-19 03:52 --- Created an attachment (id=21516) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21516action=view) Proposed patch This patch will generate an error. If IOSTAT or IOMSG is used, the read will continue in the loop after an error, but the error status variables will be set so that one will know an error occurred when the READ has completed. Any thoughts Tobias? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45108
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-08-19 04:01 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug c++/45329] New: When printing a list of candidate functions, explain why each function failed to match.
Consider the following sample program:
struct S
{
int x;
int y;
};
int foo(int x, int y)
{
return x+y;
}
int foo(const S s)
{
return s.x + s.y;
}
int foo2(int x)
{
foo(x);
}
When compiling this, clang prints:
# clang ./tst.cc
./tst.cc:19:3: error: no matching function for call to 'foo'
foo(x);
^~~
./tst.cc:12:5: note: candidate function not viable: no known conversion from
'int' to 'struct S const' for 1st argument
int foo(const S s)
^
./tst.cc:7:5: note: candidate function not viable: requires 2 arguments, but 1
was provided
int foo(int x, int y)
^
3 diagnostics generated.
Notice that each failed match is clearly explained. By comparison, gcc prints:
# ./install/bin/gcc -c ./tst.cc
./tst.cc: In function int foo2(int):
./tst.cc:19:8: error: no matching function for call to foo(int)
./tst.cc:7:5: note: candidates are: int foo(int, int)
./tst.cc:12:5: note: int foo(const S)
In this case, it is easy to see what's going on. However, many C++ functions
contain multiple template arguments. In those cases, it can be difficult to
parse the diagnostics and understand what is wrong.
GCC should clearly indicate why each match failed.
--
Summary: When printing a list of candidate functions, explain why
each function failed to match.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaw at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329
[Bug c++/45330] New: Suggest likely nested-name-specifiers for undeclared identifiers.
Consider this code sample:
namespace N
{
int foo;
}
int bar()
{
return foo;
}
GCC, generates the following error:
tst.cc: In function int bar():
tst.cc:8:10: error: foo was not declared in this scope
It would be nice if it suggested that the user might mean N::foo.
--
Summary: Suggest likely nested-name-specifiers for undeclared
identifiers.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaw at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45330
[Bug c++/45331] New: Generate clear diagnostics when a semicolon is missing at the end of a class definition
Consider this sample code:
# cat tst.cc
class X
{
public:
int a;
}
int foo(const X x)
{
return x.a;
}
The clang front end generates a very nice warning (which is actually color
coded for ease of readability):
# clang ./tst.cc
./tst.cc:5:2: error: expected ';' after class
}
^
;
1 diagnostic generated.
By comparison, this is what gcc generates (in both Crosstool v14 and the
current upstream trunk):
# ./install/bin/gcc -c tst.cc
tst.cc:1:1: error: new types may not be defined in a return type
tst.cc:1:1: note: (perhaps a semicolon is missing after the definition of X)
tst.cc:7:19: error: two or more data types in declaration of foo
True, it *does* mention that there is likely a missing semicolon, but does it
really need to mention the other cruft, too? Why not just emit an error about
the semicolon, add the missing semicolon to the input stream, and continue
parsing the file?
--
Summary: Generate clear diagnostics when a semicolon is missing
at the end of a class definition
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaw at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45331
[Bug c++/45332] New: Generate clear diagnostics when a terminating semicolon is missing from a class member declaration.
Consider the following sample code:
# cat tst.cc
class C
{
int x
const int foo() { return x; }
};
Clang generates the following diagnostics:
# clang tst.cc
tst.cc:3:8: error: expected ';' at end of declaration list
int x
^
;
1 diagnostic generated.
By comparison, gcc generates:
# ./install/bin/gcc tst.cc
tst.cc:5:3: error: expected ; before const
tst.cc:6:1: error: expected ; before } token
gcc should associate the first diagnostic with the end of line number 3, not
the beginning of 5, and the second diagnostic is nonsensical.
--
Summary: Generate clear diagnostics when a terminating semicolon
is missing from a class member declaration.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaw at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45332
[Bug c++/45333] New: Include macros in instantiation backtraces
Consider the following code sample:
#define ZERO(c) c.set(0)
struct S
{
int a;
int b;
};
template class T
class C
{
T t;
public:
void set(int x) { t = x; }
};
void foo(CS c)
{
ZERO(c);
}
When compiled with clang, the instantiation backtrace shows the point of
instantiation within the ZERO macro:
# clang ./tst.cc
./tst.cc:15:23: error: no viable overloaded '='
void set(int x) { t = x; }
~ ^ ~
./tst.cc:20:3: note: in instantiation of member function 'Cstruct S::set'
requested here
ZERO(c);
^
./tst.cc:1:19: note: instantiated from:
#define ZERO(c) c.set(0)
^
./tst.cc:3:8: note: candidate function (the implicit copy assignment operator)
not viable: no known conversion from 'int' to 'struct S const' for 1st
argument
struct S
^
3 diagnostics generated.
By contract, gcc ignores the macro completely:
# ./install/bin/gcc -c ./tst.cc
./tst.cc: In member function void CT::set(int) [with T = S]:
./tst.cc:20:3: instantiated from here
./tst.cc:15:21: error: no match for operator= in this-CS::t = x
./tst.cc:3:8: note: candidate is: S S::operator=(const S)
GCC should include macros in instantiation backtraces like clang does.
--
Summary: Include macros in instantiation backtraces
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaw at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45333
