[Bug other/38606] AIX: build failed in stage 2
--- Comment #13 from tammer at tammer dot net 2009-02-08 09:39 --- Hello, OK, I will try with an extended heap. Bye Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38606
[Bug bootstrap/38981] [4.4 regression] internal compiler error
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:09 --- Confirmed on Solaris 8, but neither on Solaris 9 nor on Solaris 10. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|wrong-code | Last reconfirmed|-00-00 00:00:00 |2009-02-08 10:09:42 date|| Summary|internal compiler error |[4.4 regression] internal ||compiler error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38981
[Bug target/38981] [4.4 regression] internal compiler error
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:11 --- Btw, the default extension for preprocessed sources is .i, just pass -save-temps to the compiler to get the file. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|bootstrap |target Last reconfirmed|2009-02-08 10:09:42 |2009-02-08 10:11:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38981
[Bug tree-optimization/39129] The meaning of 'BB' in too many BBs in loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-08 10:23 --- Confirmed. Even spelling out basic-block here isn't going to be too useful to the occasional programmer. I know that it is sometimes even just a non-empty latch block that triggers this, so even control flow in loop wouldn't be entirely correct (but may, in more complex cases, hint at the source of the problem). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at gcc dot gnu dot org, ||dorit at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-02-08 10:23:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39129
[Bug c/39128] GPC polygon clipping library fails with -O2
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-08 10:25 --- From the comments I suggest the code does floating point equality compares, which is a dangerous thing to do if you are not knowing what you do. A fix is to instead of x == y use fabs(x - y) = epsilon. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|gcc (GCC) 4.4.0 20090130| |(experimental) | GCC host triplet|Linux linux 2.6.11.4-21.17- | |smp #1 SMP Fri Apr 6| |08:42:34 UTC 200| GCC target triplet|gcc (GCC) 4.4.0 20090130| |(experimental) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39128
[Bug target/38981] [4.4 regression] internal compiler error
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:26 --- This is a bug in the qsort implementation on Solaris 8: Breakpoint 1, sort_coalesce_list (cl=0x1ce4b80) at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-coalesce.c:434 434 qsort (cl-sorted, num, sizeof (coalesce_pair_p), compare_pairs); (gdb) p cl-sorted $22 = (coalesce_pair_p *) 0x1cc4e88 (gdb) p num $23 = 8 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00f1bb00 in compare_pairs (p1=0x1cc4e84, p2=0x1cc4e8c) at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-coalesce.c:318 318 result = (* pp2)-cost - (* pp1)-cost; i.e. the comparator is invoked on cl-sorted[-1], which is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38981
[Bug target/38981] [4.4 regression] internal compiler error
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2009-02-08 10:58 --- This is a bug in the qsort implementation on Solaris 8: Browsing the Sun database shows several related tickets, but most have been closed as not a defect on the ground that the comparator function fails to impose a total order on the array. That's the case here because of overflow: (gdb) p cl-sorted[0].cost $29 = 2147483646 (gdb) p cl-sorted[1].cost $30 = -2147483644 (gdb) p cl-sorted[2].cost $31 = -2147483648 (gdb) p cl-sorted[3].cost $32 = 2 (gdb) p cl-sorted[4].cost $33 = -2147483648 (gdb) p cl-sorted[5].cost $34 = 2 (gdb) p cl-sorted[6].cost $35 = 2147483646 (gdb) p cl-sorted[7].cost $36 = 2147483646 Breakpoint 2, compare_pairs (p1=0x1cc4e88, p2=0x1cc4e8c) at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-coalesce.c:314 314 const_coalesce_pair_p const *const pp1 = (const_coalesce_pair_p const *) p1; (gdb) next 315 const_coalesce_pair_p const *const pp2 = (const_coalesce_pair_p const *) p2; (gdb) 318 result = (* pp2)-cost - (* pp1)-cost; (gdb) p (* pp2)-cost $46 = -2147483644 (gdb) p (* pp1)-cost $47 = 2147483646 (gdb) next 322 if (result == 0) (gdb) p result $48 = 6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38981
[Bug target/23322] [4.2/4.3/4.4 regression] performance regression
--- Comment #33 from hubicka at gcc dot gnu dot org 2009-02-08 11:32 --- Partial memory issues are fixed, but I think related to register pressure awareness of invariant motion we did not change much. Steven, what do you think? I can give it another run on 32bit tester. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug tree-optimization/17863] [4.2/4.3/4.4 Regression] performance loss (TER register presure and inlining limits problems)
--- Comment #46 from hubicka at gcc dot gnu dot org 2009-02-08 11:50 --- With new-RA we seem to do better on this testcase now: hubi...@occam:~$ time ./a.out-3.4 real0m5.448s user0m5.440s sys 0m0.012s hubi...@occam:~$ time ./a.out real0m5.834s user0m5.836s sys 0m0.000s hubi...@occam:~$ still there is small regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug middle-end/38981] [4.4 regression] internal compiler error
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-02-08 12:33 --- Recategorizing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38981
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #15 from hubicka at gcc dot gnu dot org 2009-02-08 12:36 --- I tested the patch on SPECfp and core and there is not much difference. I guess without somehow tweaking regalloc there is not much to do about this problem. Xuepeng, if the testcase is core2-variant sensitive, perhaps it is not related to uops count at all? It seems to me that the bottleneck should lie elsewhere anyway, as the testcase should be memory bound after all... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #16 from hubicka at gcc dot gnu dot org 2009-02-08 12:40 --- Since the splitting peep2 don't seem to be win in general (it wins only when copy propagation takes place afterwards) and we don't seem to understand what really makes the testcase faster I am unassigning myself until we get better idea what is going on here. Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|hubicka at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug middle-end/33699] [4.2/4.3/4.4 regression], missing optimization on const addr area store
--- Comment #4 from amylaar at gcc dot gnu dot org 2009-02-08 12:49 --- (In reply to comment #2) This is related to some work done in the past for auto-increment addressing modes Actually, the problem with constants that are loaded into registers - and in the same basic block, at that - is much simpler. If the targets rtx_cost works properly, then reload_cse_move2add should fix up this code. We need, however, some way to deal with the case where constants are expensive addresses; this is completely broken at the moment. Complete unrolling of loops accessing static arrays can create oodles of constant addresses; I've managed to split these up with LEGITIMIZE_ADDRESS, the movsi expander, and a patch to momory_address, however, gcse just recombines the costly constants, irrespective of what rtx_cost and address_cost says. And the havoc that gcse can wreak transcends basic blocks, so any attempt to clean up after if with lesser scope is bound to be inferior. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
[Bug target/37798] Unaligned memory access with multiple inheritance
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-02-08 13:01 --- Reproducible with every compiler I tried... -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |target Ever Confirmed|0 |1 Known to fail||3.4.3 4.2.4 4.3.4 4.4.0 Last reconfirmed|-00-00 00:00:00 |2009-02-08 13:01:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37798
[Bug target/37798] Unaligned memory access with multiple inheritance
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-02-08 13:01 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-02-08 13:01:39 |2009-02-08 13:01:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37798
[Bug target/37798] unaligned memory access with multiple inheritance
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Summary|Unaligned memory access with|unaligned memory access with |multiple inheritance|multiple inheritance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37798
[Bug target/18617] missed volatile variable optimizations
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-08 14:13 --- This is a really old bug. Since 2005, a lot has happened in GCC. Could someone interested in AVR please check whether this is still an issue? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18617
[Bug rtl-optimization/22031] Poor code from unrolled simple loop
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-08 14:15 --- This is a really old bug with no changes for a long time. Could someone check whether there still is an issue here, and if so, confirm the bug? Uros, I added you because you seem to be interested in Alpha lately... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22031
[Bug tree-optimization/26939] loop number of iterations analysis confused by what PRE did (PRE is doing its job)
--- Comment #16 from steven at gcc dot gnu dot org 2009-02-08 14:17 --- No news for almost three years. Where are we with this one today? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/31178] VRP can infer a range for b in a b and a b
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-08 14:20 --- No news since almost two years ago. Is this still a problem? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
[Bug tree-optimization/26939] loop number of iterations analysis not working
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-08 14:45
---
The situation is still worse than originally reported. Even without PRE we
have
Analyzing # of iterations of loop 2
exit condition [1, + , 1] = i1_6(D)
bounds on difference of bases: -1 ... 2147483646
result:
under assumptions i1_6(D) != 2147483647
# of iterations (unsigned int) i1_6(D), bounded by 2147483647
(set_nb_iterations_in_loop = scev_not_known))
for the inner loop which is just
bb 4:
bb 5:
# i_13 = PHI i_8(4), 0(9)
D.1244_7 = j_10 + 1;
bar (D.1244_7);
i_8 = i_13 + 1;
if (i1_6(D) = i_8)
goto bb 4;
else
goto bb 6;
...
bb 8:
# j_10 = PHI j_9(7), 0(3)
if (i1_6(D) = 0)
goto bb 9;
else
goto bb 6;
bb 9:
goto bb 5;
which means we cannot prove that with i_8 = {1, +, 1}_2 the loop
runs at least once if only i1_6 = 0 is known (remember its the number
of latch executions that are counted).
Smaller testcase:
void bar();
void foo(int i1)
{
int i;
for (i=0; i=i1; ++i)
bar();
}
It works once you change the loop exit condition to i i1. Same effects
with unsigned variables (adjust the lower bound to sth like 2 to avoid ill
effects).
I changed the Summary to what is more appropriate.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-08 14:45:08
date||
Summary|loop number of iterations |loop number of iterations
|analysis confused by what |analysis not working
|PRE did (PRE is doing its |
|job)|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug tree-optimization/31178] VRP can infer a range for b in a b and a b
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-08 14:47 --- No, it's now possible to implement this optimization (but yes, nobody has done so sofar). It's on my TODO (with tons of other stuff, of course). As this is an easy task for beginners ... whoever feels like doing it, I'll review the result. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-08 14:47:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31178
[Bug c++/39131] New: decimal float point: ICE on typeid( 0.dd )
The following, compiled with no further options (g++ t.cc), results in an
ICE:
#include typeinfo
int main() {
typeid( 0.dd );
}
Also, documentation on DFPs is not very good. When trying to use DFPs with C++,
constants are recognised, while _Decimal[32|64|128] are rejected. I'd
appreciate some more information on DFPs as them seem really useful to me.
--
Summary: decimal float point: ICE on typeid( 0.dd )
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39131
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #14 from manu at gcc dot gnu dot org 2009-02-08 15:46 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00285.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00285.html Keywords||patch Last reconfirmed|2008-03-21 12:49:51 |2009-02-08 15:46:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35711] bad text in -Wcast-qual warning (forgets volatile)
--- Comment #12 from manu at gcc dot gnu dot org 2009-02-08 15:51 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00806.html -- manu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|manu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00806.html Status|ASSIGNED|NEW Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
[Bug libgomp/36475] [gomp] register keyword in openmp handled for-loop fails
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-08 15:54 --- Patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01118.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg01118.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2009-02-08 15:54:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36475
[Bug c/36674] #include location is offset by one row in errors from preprocessed files
--- Comment #1 from manu at gcc dot gnu dot org 2009-02-08 15:56 --- Patch http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00875.html -- manu at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00875.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2009-02-08 15:56:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36674
[Bug tree-optimization/38819] [4.2/4.3 Regression] trapping expression wrongly hoisted out of loop
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2009-02-08 17:59 --- Still present on SPARC 32-bit on the mainline: FAIL: gcc.c-torture/execute/pr38819.c execution, -O2 FAIL: gcc.c-torture/execute/pr38819.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr38819.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/pr38819.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/pr38819.c execution, -O3 -g The culprit is RTL PRE GCSE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
[Bug target/39119] Update classification of aggregates with __m256
--- Comment #2 from hjl at gcc dot gnu dot org 2009-02-08 18:04 --- Subject: Bug 39119 Author: hjl Date: Sun Feb 8 18:03:58 2009 New Revision: 144017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144017 Log: gcc/ 2009-02-08 H.J. Lu hongjiu...@intel.com PR target/39119 * config/i386/i386.c (x86_64_reg_class): Remove X86_64_AVX_CLASS. (x86_64_reg_class_name): Removed. (classify_argument): Return 0 if bytes 32. Return 0 if the first one isn't X86_64_SSE_CLASS or any other ones aren't X86_64_SSEUP_CLASS when size 16bytes. Don't turn X86_64_SSEUP_CLASS into X86_64_SSE_CLASS if the preceded one is X86_64_SSEUP_CLASS. Set AVX modes to 1 X86_64_SSE_CLASS and 3 X86_64_SSEUP_CLASS. (construct_container): Remove X86_64_AVX_CLASS. Handle 4 registers with 1 X86_64_SSE_CLASS and 3 X86_64_SSEUP_CLASS. gcc/testsuite/ 2009-02-08 H.J. Lu hongjiu...@intel.com PR target/39119 * gcc.target/x86_64/abi/avx/abi-avx.exp: New. * gcc.target/x86_64/abi/avx/args.h: Likewise. * gcc.target/x86_64/abi/avx/asm-support.S: Likewise. * gcc.target/x86_64/abi/avx/avx-check.h: Likewise. * gcc.target/x86_64/abi/avx/test_m256_returning.c: Likewise. * gcc.target/x86_64/abi/avx/test_passing_m256.c: Likewise. * gcc.target/x86_64/abi/avx/test_passing_structs.c: Likewise. * gcc.target/x86_64/abi/avx/test_passing_unions.c: Likewise. Added: branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/ branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/abi-avx.exp branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/args.h branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/asm-support.S branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/avx-check.h branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/test_m256_returning.c branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/test_passing_m256.c branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/test_passing_structs.c branches/ix86/avx/gcc/testsuite/gcc.target/x86_64/abi/avx/test_passing_unions.c Modified: branches/ix86/avx/gcc/ChangeLog.avx branches/ix86/avx/gcc/config/i386/i386.c branches/ix86/avx/gcc/testsuite/ChangeLog.avx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39119
[Bug c/36432] [4.2/4.3 Regression] �incompatible pointer type� with pointer to array as a struct member
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-08 19:02 --- Subject: Bug 36432 Author: jsm28 Date: Sun Feb 8 19:01:57 2009 New Revision: 144018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144018 Log: PR c/36432 * c-decl.c (grokdeclarator): Don't treat [] declarators in fields as indicating flexible array members unless the field itself is being declarared as the incomplete array. testsuite: * gcc.dg/c90-flex-array-2.c, gcc.dg/c99-flex-array-6.c: New tests. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/c90-flex-array-2.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/c99-flex-array-6.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432
[Bug c/35434] [4.2/4.3/4.4 regression] ICE with attribute alias
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-08 19:03 --- Subject: Bug 35434 Author: jsm28 Date: Sun Feb 8 19:02:56 2009 New Revision: 144019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144019 Log: PR c/35434 * c-common.c (handle_alias_attribute): Disallow attribute for anything not a FUNCTION_DECL or VAR_DECL. testsuite: * gcc.dg/attr-alias-4.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/attr-alias-4.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-common.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35434
[Bug c/35434] [4.2 regression] ICE with attribute alias
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-08 19:04 --- Fixed for 4.3.4 and 4.4.0. Not planning to work on a backport to 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.2/4.3/4.4 regression] ICE|[4.2 regression] ICE with |with attribute alias|attribute alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35434
[Bug c/36432] [4.2 Regression] �incompatible pointer type� with pointer to array as a struct member
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-08 19:05 --- Fixed for 4.3.4 and 4.4.0. Not planning to work on a backport to 4.2. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jsm28 at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to fail|3.3.3 4.3.0 |3.3.3 4.3.0 4.3.3 Known to work|4.4.0 |4.3.4 4.4.0 Summary|[4.2/4.3 Regression]|[4.2 Regression] |incompatible pointer type |incompatible pointer type |with pointer to array as a |with pointer to array as a |struct member |struct member http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432
[Bug tree-optimization/39132] New: wrong code generated with -ftree-loop-disttribution
The following testcase calls abort when it is compiled with
-O3 -ftree-loop-distribution.
/* Derived from gcc.c-torture/execute/20010910-1.c. */
extern void abort(void);
struct epic_private
{
unsigned int *rx_ring;
unsigned int rx_skbuff[5];
};
int
main (void)
{
struct epic_private ep;
unsigned int rx_ring[5];
int i;
ep.rx_skbuff[0] = 5;
ep.rx_ring = rx_ring;
for (i = 0; i 5; i++)
{
ep.rx_ring[i] = i;
ep.rx_skbuff[i] = 0;
}
if (ep.rx_skbuff[0] != 0)
abort ();
return 0;
}
The loop distribution pass produces:
bb 2:
ep.rx_skbuff[0] = 5;
bb 8:
# i_22 = PHI i_36(9), 0(2)
D.1604_11 = (long unsigned int) i_22;
D.1605_30 = D.1604_11 * 4;
D.1606_31 = rx_ring + D.1605_30;
i.0_32 = (unsigned int) i_22;
*D.1606_31 = i.0_32;
i_36 = i_22 + 1;
if (i_36 = 4)
goto bb 9;
else
goto bb 10;
bb 9:
goto bb 8;
bb 10:
Invalid sum of outgoing probabilities 0.0%
D.1642_37 = ep + 8;
__builtin_memset (D.1642_37, 0, 20);
bb 5:
Invalid sum of incoming frequencies 0, should be 1667
D.1609_10 = ep.rx_skbuff[0];
if (D.1609_10 != 0)
goto bb 6;
else
goto bb 7;
bb 6:
abort ();
bb 7:
return 0;
dom2 in turn produces:
ep.rx_skbuff[0] = 5;
rx_ring[0] = 0;
D.1606_47 = rx_ring[1];
rx_ring[1] = 1;
D.1606_59 = rx_ring[2];
rx_ring[2] = 2;
D.1606_71 = rx_ring[3];
rx_ring[3] = 3;
D.1606_31 = rx_ring[4];
rx_ring[4] = 4;
D.1642_37 = ep + 8;
__builtin_memset (D.1642_37, 0, 20);
D.1609_10 = 5;
abort ();
Note that the end of the function is replaced with an unconditional
abort.
GCC puts an unconditional abort at the rtl level when compiling The
original gcc.c-torture/execute/20010910-1.c. Once I remove extra
source code, I can observe an unconditional abort at the tree level.
The compiler probably does not notice that the value of
ep.rx_skbuff[0] changes across __builtin_memset. This sounds like an
alias problem of some sort.
--
Summary: wrong code generated with -ftree-loop-disttribution
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
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=39132
[Bug web/39125] trunk revision 143992 - Too many Testsuite FAILs = email 400K = bounce
--- Comment #1 from joseph at codesourcery dot com 2009-02-08 19:16 --- Subject: Re: New: trunk revision 143992 - Too many Testsuite FAILs = email 400K = bounce On Sat, 7 Feb 2009, rob1weld at aol dot com wrote: This causes a bounce reply message which _might_ mean that tests with the most failures (and require fixing quicker) will not be included in: http://gcc.gnu.org/ml/gcc-testresults/2009-02/ The purpose of the gcc-testresults list is not for humans to read and identify bugs to fix; it is so that if you have a failure you can do a search and see what subset of platforms it appears on and when it appeared on those platforms, and maybe learn more about the underlying cause that way. If a target is *completely or substantially broken*, a failure of a test there is unlikely to be related to a failure of that test on a target that is not completely or substantially broken, so results for such targets add little value, and the filter serves a useful purpose in avoiding cluttering gcc-testresults with completely broken results and wasting bandwidth and disk space for copies of completely broken results. If your tests show such substantial breakage that the results bounce, you should fix the problems shown until the results are clean enough, or file a clear and specific bug report about the issues shown *only if you can make sure it really is the target support that is broken, not the test environment on your specific system*. (Such breakage can easily be a problem with your system, not with GCC. For example, if you have a broken version of expect that truncates output, as discussed in bug 12096.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39125
[Bug c++/28501] ICE with __real__ and implicit type conversion
--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-02-08 20:53
---
Paolo --
I didn't realize that something like __real__ 3 was valid GNU C; I thought
that the argument had to have complex type. But, it looks like that is not the
case.
Given that, yes, I think the test case should be accepted, as a GNU extension.
When __real__ (or __imag__) is applied to an expression with class type, we
should see if the expression can be converted to any of the built-in types to
which __real__ can ordinarily be applied. If there is only one such type, then
we should use that conversion; if there is more than one, then we should report
the same kind of error used when we have an ambiguous overload. I don't think
we should be trying to deduce anything from the context in which the __real__
expression is being used.
So, your patch looks like a fine start. I'm not sure what it will do for cases
like:
struct A {
operator int();
operator __complex__ double();
template typename T operator __complex__ T();
};
though. As above, I think those cases should be errors, since there's no way
to know which conversion operator to prefer.
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28501
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #8 from ubizjak at gmail dot com 2009-02-08 21:00 --- We should plug this for 4.3 and 4.4, so due to comment 6 I think this is a regression. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00372.html Status|NEW |ASSIGNED Last reconfirmed|2009-02-06 13:45:35 |2009-02-08 21:00:58 date|| Summary|x86_64 red zone violation |[4.3/4.4 Regression] x86_64 ||red zone violation Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug c++/39133] New: wrong optimization produces output of false warning
piece of code inside contained in class methode (starting line 263):
---
char *buf;
if (!strncmp(in-loc.path,/translators/,strlen(/translators/)))
{
translator_c *xl = translator_from_path(in-loc.path);
if (xl)
{
char *loc =
in-loc.path+strlen(/translators/)+strlen(xl-name);
LOG_DEBUG(log, control_get_data, xl '%s', loc '%s', xl-name,
loc);
buf = xl-control_get_data(loc);
}
}
else
{
char *loc = in-loc.path;
LOG_DEBUG(log, control_get_data, internal, loc '%s', loc);
buf = control_get_data(loc);
}
if (buf)
{
MEM_NEW(persistent, persistent_c());
persistent-read_mode = true;
persistent-data = buf;
persistent-data_len = strlen(persistent-data);
out-ref = (xl_ref_t) persistent;
out-op_errno = 0;
}
else
{
out-op_errno = ENOENT;
}
---
compiling with the following options works fine (no warnings, no errors):
---
CFLAGS=-Wall -Werror -fPIC -pthread -I../common -I../../common
-I../../../common -I../shared -I../../shared -I../../../shared -O0 -g
---
compiling with the following options produces a warning (=error);
---
CFLAGS=-Wall -Werror -fPIC -pthread -I../common -I../../common
-I../../../common -I../shared -I../../shared -I../../../shared -O3 -ffast-math
---
cc1plus: warnings being treated as errors
main.cpp: In member function »virtual void main_c::fop_open(stack_frame_t*)«:
main.cpp:263: Warnung: »buf« könnte in dieser Funktion uninitialisiert
verwendet werden
make: *** [main.o] Fehler 1
---
Fehler = Error
»buf« könnte in dieser Funktion uninitialisiert verwendet werden = buf could
be used uninitialized in this function
---
as you can clearly see, buf could never be used uninitialized so this must be a
compiler/optimizer bug.
--
Summary: wrong optimization produces output of false warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corinl at gmx dot de
GCC build triplet: 4.2.3-2ubuntu7
GCC host triplet: x86_64
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39133
[Bug c++/39133] wrong optimization produces output of false warning
--- Comment #1 from corinl at gmx dot de 2009-02-08 22:07 --- Oh sorry, I just see that buf could be used uninitialized for sure (if xl==NULL). but well, shouldn't this warning then be issued all the times? so the bug is now reversed - missing warning instead of false warning ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39133
[Bug c++/39133] wrong optimization produces output of false warning
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-08 22:18 --- The warning should be there at -O0 starting with G++ 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39133
[Bug libstdc++/21321] [4.2/4.3/4.4 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test
--- Comment #8 from hp at gcc dot gnu dot org 2009-02-08 22:19 --- Sorry, not yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter
--- Comment #21 from mmitchel at gcc dot gnu dot org 2009-02-08 22:35 --- Paolo -- My earlier suggestion to try grok_array_decl may indeed have been misguided. Some of the grok_* functions do more parser-style analysis than we want when processing templates. In theory, the way this ought to work is that we parse for a while, until we know what the user meant, and then call a function that actually generates code. When processing a template, we call that same underlying function after substitution. But, in practice, we may not always have organized things that tidily. In that case, the best fix is to factor out syntactic dismabiguation bits from grok_array_decl, and make a new underlying function that is called from both the parser and the template machinery. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-08 22:40 --- Many thanks Mark for your detailed feedback on this PR and the other one. I'll try to work along the lines you suggested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397
[Bug c++/34758] [4.2/4.3/4.4 regression] Bad diagnostic for circular dependency in constructor default argument
--- Comment #6 from manu at gcc dot gnu dot org 2009-02-08 23:07 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00308.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||02/msg00308.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
[Bug tree-optimization/26939] loop number of iterations analysis not working
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-02-08 14:45:08 |2009-02-09 00:54:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26939
[Bug c/39134] New: front end does not reject sizeof on function types
The following:
#include stddef.h
void test(void)
{
size_t s1 = sizeof(test);
size_t s2 = sizeof(void (void));
}
should not compile with -std=c99. According to the C99 standard section
6.5.3.4.1 The sizeof operator shall not be applied to an expression that has
function type or an incomplete type, to the parenthesized name of such a type,
or to an expression that designates a bit-field member.
I would expect gcc to produce an error in this case. sizeof actually
returns 1 and no error.
--
Summary: front end does not reject sizeof on function types
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at gcc dot gnu dot org
GCC host triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39134
[Bug libstdc++/39136] New: std::mem_fun_ref fails to accept a member function whose second argument with default value
std::mem_fun_ref fails to accept a member function whose second argument can be
bound to a default value. In this example, I use vector::resize.
Test case:
#include vector
#include functional
#include algorithm
using std::vector;
using std::mem_fun_ref;
using std::bind2nd;
using std::for_each;
typedef vectorint int_vec;
Test case:
typedef vectorint_vec matrix;
void
test(void) {
matrix M;
M.resize(4);
for_each(M.begin(), M.end(),
bind2nd(mem_fun_ref(int_vec::resize), 4));
}
Compile: g++ -O3 -W -Wall -Werror -ansi -pedantic-errors -c vector.cc -o
vector.o
Diagnostic:
vector.cc: In function 'void test()':
vector.cc:18: error: no matching function for call to 'mem_fun_ref(void
(std::vectorint, std::allocatorint ::*)(long unsigned int, int))'
make: *** [vector.o] Error 1
Known to work: 4.0.1
Fail: 4.3.2 4.3.3
I'm not sure if this is valid code. However, the standard seems to indicate
that resize(size_type), is a required member function (or at least interface)
of std::vector. Does the standard (20.6.13) allow mem_fun_ref and such to bind
to member functions with default values in the tail position?
--
Summary: std::mem_fun_ref fails to accept a member function whose
second argument with default value
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39136
[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value
--- Comment #1 from fang at csl dot cornell dot edu 2009-02-09 07:39 --- also Fails: 4.2.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39136
