[Bug c++/37217] [4.4 Regression] -Wconversion causes ICE with __builtin_strcmp with one char compare
--- Comment #12 from manu at gcc dot gnu dot org 2008-08-26 07:58 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01913.html Please test that it fixes the ICE in i686-pc-cygwin. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
[Bug tree-optimization/36449] Incorrect code generated for access to a large struct
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-26 09:06 --- Created an attachment (id=16147) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16147&action=view) gcc41-pr36449.patch 4.1 patch which doesn't kill the optimization altogether, but instead fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36449
[Bug libstdc++/34015] warning in backward_warning.h is illegible
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-26 11:13 --- (In reply to comment #7) > The goal for warnings should be to use an attribute on the specific class or > function in question, not on a per-file basis. Care to elaborate? I don't understand what you mean here. > Unfortunately this does not work at the moment. So, the backwards_warning.h > file has been adjusted to make it a bit more clear as to what is going on, and > what should be used for deprecated items. I thought we handled newlines "\n" within strings given to #error. Is this forbidden by any standard? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34015
[Bug tree-optimization/37239] New: peeling last iteration of a <= loop
If the condition of the loop is tested within the loop with == or !=, it may be
beneficial to peel off the final iteration of the loop by changing the
condition to <.
This happens in the attached benchmark's heapsort function where
while ((maxIdx += maxIdx) <= last) {
if (maxIdx != last && numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++;
if (tmp >= numbers[maxIdx]) break;
numbers[top] = numbers[maxIdx];
top = maxIdx;
}
can become
while ((maxIdx += maxIdx) <= last) {
if (numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++;
if (tmp >= numbers[maxIdx]) break;
numbers[top] = numbers[maxIdx];
top = maxIdx;
}
if (maxIdx == last && tmp < numbers[maxIdx]) {
numbers[top] = numbers[maxIdx];
top = maxIdx;
}
enabling in turn if-conversion of the first branch.
Performance of the benchmark is (-O3)
basic 2.990
peeling only2.730
if-conversion only 2.290
peel+if-convert 2.010 (faster than quicksort!!)
ICC does this optimization.
--
Summary: peeling last iteration of a <= loop
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239
[Bug tree-optimization/37239] peeling last iteration of a <= loop
--- Comment #1 from bonzini at gnu dot org 2008-08-26 11:36 --- Created an attachment (id=16148) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16148&action=view) benchmark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239
[Bug rtl-optimization/37240] New: missed if-conversion opportunity
In the attached code, changing if (numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++; to maxIdx += numbers[maxIdx] < numbers[maxIdx + 1]; gives a 10% performance speedup at -O3. -- Summary: missed if-conversion opportunity Product: gcc Version: 4.3.2 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org GCC target triplet: x86_64-pc-linux-gnu BugsThisDependsOn: 37239 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37240
[Bug rtl-optimization/37240] missed if-conversion opportunity
--- Comment #1 from bonzini at gnu dot org 2008-08-26 11:39 --- Created an attachment (id=16149) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16149&action=view) benchmark this is a modified version of the PR37239 testcase, with the optimization requested there performed manually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37240
[Bug target/37241] New: [4.4 Regression]: FAIL: g++.dg/abi/key2.C
On Darwin, we have the following since at least revision 136913 (revision 136903 seems the most likely candidate, the others being 136899, 136905, and 136912): FAIL: g++.dg/abi/key2.C scan-assembler .globl __ZTI1fn\\t.weak_definition __ZTI1fn\\t.section __DATA,__const_coal,coalesced The corresponding part of the assembly code reads: 42 - .long __ZN1f1hEv 43 - .globl __ZTI1f 44 : .weak_definition __ZTI1f 45 + .align 2 46 + __ZTI1f: Revision 136903 Author: hubicka Date: Wed Jun 18 19:07:51 2008 UTC (2 months, 1 week ago) Log Message: * c-opts.c (c_common_post_options): PCH is not compatible with no-unit-at-a-time. * opts.c (handle_options): Enable unit-at-a-time at O0 along with -fno-toplevel-reorder by default now. * gcc.dg/weak/weak-2.c: We no longer complain about incompatibilty. * gcc.dg/weak/weak-3.c: We no longer complain about incompatibilty. * gcc.dg/weak/weak-4.c: We no longer complain about incompatibilty. * gcc.dg/weak/weak-5.c: We no longer complain about incompatibilty. * gcc.dg/weak/weak-6.c: Fix thinko in previous change. * gcc.dg/weak/weak-7.c: Likewise. -- Summary: [4.4 Regression]: FAIL: g++.dg/abi/key2.C Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug tree-optimization/37242] New: missed load PRE-like opportunity
In the attached code, the if-conversion opportunity in PR37240 does not benefit
a Pentium 4. However, there is another optimization possible on both systems,
namely changing
while ((maxIdx += maxIdx) < last) {
if (numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++;
if (tmp >= numbers[maxIdx]) break;
numbers[top] = numbers[maxIdx];
top = maxIdx;
}
to
while ((maxIdx += maxIdx) < last) {
int a = numbers[maxIdx], b = numbers[maxIdx + 1];
if (a < b) maxIdx++, a = b;
if (tmp >= a) break;
numbers[top] = a;
top = maxIdx;
}
It seems to me that numbers[maxIdx] is partially redundant (it is available if
maxIdx++ is not executed). If an additional load of numbers[maxIdx + 1] is
inserted in the "then" branch, it can also be found to be fully redundant so
that copy propagation generates the optimized code.
This gives a ~3% performance increase on i686-pc-linux-gnu for this benchmark.
--
Summary: missed load PRE-like opportunity
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
BugsThisDependsOn: 37239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
[Bug tree-optimization/37242] missed load PRE-like opportunity
--- Comment #1 from bonzini at gnu dot org 2008-08-26 11:55 --- Created an attachment (id=16150) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16150&action=view) benchmark same as the attachment to 37240 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #55 from dominiq at lps dot ens dot fr 2008-08-26 11:57 --- > FeaPR-creep is strictly frowned upon: open a new PR. This now pr37241. With the patch in comment #54 all the failures reported in comment #40 are gone without regressions (currently regtesting gfortran). Thanks for the patch(es). Just in case, I am bootstraping gcc on ppc darwin9 with the patch. It should finish tonight (GMT+2) and regtesting results available tomorrow morning. I'll report any problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug tree-optimization/37242] missed FRE opportunity
--- Comment #2 from bonzini at gnu dot org 2008-08-26 12:02 --- This is missed because this: maxIdx.1_15 = (unsigned int) maxIdx_59; D.1923_20 = maxIdx.1_15 + 1; D.1924_21 = D.1923_20 * 4; D.1925_22 = numbers_9(D) + D.1924_21; and this: maxIdx_24 = maxIdx_59 + 1; pretmp.36_86 = (unsigned int) maxIdx_24; pretmp.36_88 = pretmp.36_86 * 4; pretmp.38_90 = numbers_9(D) + pretmp.36_88; do not match. The first has the arithmetic done as unsigned, the second as signed. This could be due to array indexing lowered to POINTER_PLUS_EXPR. -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Summary|missed load PRE-like|missed FRE opportunity |opportunity | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
[Bug target/36904] [4.4 Regression] vector context sensitive keyword vs macros
--- Comment #2 from bje at au1 dot ibm dot com 2008-08-26 12:29 --- Subject: Re: [4.4 Regression] vector context sensitive keyword vs macros > Partial fix, which fixes the testcase from this PR, but still other cases > in the made up testcase fail and I don't know if they are meant to > work or not. If it does not make things worse, should we apply this patch? Ben -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36904
[Bug tree-optimization/37102] [4.3/4.4 Regression] possible integer codegen bug
--- Comment #4 from cnstar9988 at gmail dot com 2008-08-26 13:38 ---
gcc 4.3.2 20080826 failed.
#include
unsigned int g_24;
unsigned int g_37 = 1;
unsigned char g_225;
int main (void)
{
int l_289;
for (l_289 = 1; l_289 < 5; l_289 += 1) {
if (g_225) {
g_24 = g_37;
}
}
g_24 = g_37;
unsigned short context = g_24 << 1;
do {
if (context)
context = (context << 1) ^ 1;
} while (0);
printf ("%d\n", (int)context);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug middle-end/37243] New: [4.4 Regression] Revision 139590 caused many regressions
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
On Linux/x86-64, revision 139590 caused the following regressions:
+FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
+FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: gcc.target/i386/pr36246.c scan-assembler-not movq
+FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer execution test
+FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
+FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
with
# make check RUNTESTFLAGS="--target_board 'unix{-m32,}'"
--
Summary: [4.4 Regression] Revision 139590 caused many regressions
Product: gcc
Version: 4.4.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=37243
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-26 15:07 --- Those are Linux/ia32 only regressions: +FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test +FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test +FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test +FAIL: g++.old-deja/g++.eh/ia64-1.C execution test +FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa +FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer execution test +FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test +FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-loops execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug c++/37208] C++0x deleted functions and SFINAE
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-26 16:48:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37208
[Bug libstdc++/37244] New: libstdc++ fails to build
Some of the headers are not created? This is the first bits the fails: --- make[2]: Entering directory `/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3' ... make[3]: Entering directory `/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3' Making all in include make[4]: Entering directory `/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include' mkdir -p ./alphaev68-dec-osf5.1a/bits/extc++.h.gch /home/htl10/tmp-build/obj-dir/./gcc/xgcc -shared-libgcc -B/home/htl10/tmp-build/obj-dir/./gcc -nostdinc++ -L/home/htl10/tmp-build/o bj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/src -L/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/src/.libs -B/usr/l ocal/alphaev68-dec-osf5.1a/bin/ -B/usr/local/alphaev68-dec-osf5.1a/lib/ -isystem /usr/local/alphaev68-dec-osf5.1a/include -isystem /usr/local/alphaev68-dec-osf5.1a/sys-include -Winvalid-pch -x c++-header -O2 -g -g -O2 -mieee -I/home/htl10/tmp-build/obj-dir/alp haev68-dec-osf5.1a/libstdc++-v3/include/alphaev68-dec-osf5.1a -I/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/in clude -I/home/htl10/tmp-build/gcc-4.3.1/libstdc++-v3/libsupc++ -O2 -g /home/htl10/tmp-build/gcc-4.3.1/libstdc++-v3/include/precompi led/extc++.h -o alphaev68-dec-osf5.1a/bits/extc++.h.gch/O2g.gch In file included from /home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/ext/pb_ds/detail/standard_policies.h pp:51, from /home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/ext/pb_ds/assoc_container.hpp:52, from /home/htl10/tmp-build/gcc-4.3.1/libstdc++-v3/include/precompiled/extc++.h:60: /home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:57:87: error: ext/pb_ds/detail/r esize_policy/hash_load_check_resize_trigger_size_base.hpp: No such file or directory /home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/ext/pb_ds/hash_policy.hpp:395:93: error: ext/pb_ds/detail/ resize_policy/cc_hash_max_collision_check_resize_trigger_imp.hpp: No such file or directory ...make[4]: *** [alphaev68-dec-osf5.1a/bits/extc++.h.gch/O2g.gch] Error 1 make[4]: Leaving directory `/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/htl10/tmp-build/obj-dir' make: *** [bootstrap] Error 2 --- I have the full ../gcc-4.3.1/configure && make bootstrap >& log if somebody wants to look at it. I had looked at the buildstat and it doesn't look as if anybody has tried to build gcc on Tru64 since 4.1.1? -- Summary: libstdc++ fails to build Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: htl10 at users dot sourceforge dot net GCC build triplet: alphaev68-dec-osf5.1a GCC host triplet: alphaev68-dec-osf5.1a GCC target triplet: alphaev68-dec-osf5.1a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37244
[Bug ada/37245] New: GDB reports "No definition of "var1" in current context." for an existing variable
Initially reported as a GDB bug: http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2512 but changing the compiler to GCC 4.2 eliminates the problem, so this is a GCC bug. Bug description reproduced here for convenience: Steps to reproduce: 1) Save the attached file "gdb_bug_2.adb" 2) gnatmake -ggdb3 -O0 gdb_bug_2 3) gdb ./gdb_bug_2 4) break breakpoint 5) run 6) print var1 7) print var2 Expected results: 6) gdb prints 42 as the value of var1 7) gdb prints 43 as the value of var2 Actual results 6) gdb prints "No definition of "var1" in current context." 7) gdb prints 43 as the value of var2 More info: 1) Fun2 is not called at all. However, if I remove fun2 from the program gdb is able to print the value of var1 correctly. 2) Fitg5 does not use its arguments. However, if I change the type of argument from real_vector to natural gdb is again able to print the value of var1 correctly. 3) Versions of relevant debian packages are ii gcc-4.3 4.3.1-9 The GNU C compiler ii gdb 6.8-3 The GNU Debugger ii gnat-4.3 4.3.1-2 The GNU Ada compiler 4) Please let me know if you can't reproduce the problem, I am happy to provide more info! From: Rod Kay <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: ada/2512: can not find definition of an ada variable with gdb Date: Tue, 26 Aug 2008 14:02:42 +1000 Results on Ubuntu 'Hardy' (up-to-date): - Linux orth 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux - gcc version 4.1.3 20080522 for GNAT GPL 2008 (20080521) - GNU gdb 6.6 for GNAT GPL 2008 (20080521) [rev:131253] (gdb) print var1 $1 = 42 (gdb) print var2 $2 = 43 Hope this helps ... cheers, Charlie. From: Timo Juhani Lindfors <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: ada/2512: can not find definition of an ada variable with gdb Date: Tue, 26 Aug 2008 09:42:25 +0300 ubuntu hardy ii gcc-4.2 4.2.3-2ubuntu7 The GNU C compiler ii gdb 6.8-1ubuntu2 The GNU Debugger ii gnat 4.2.3-1ubuntu6 The GNU Ada compiler => "$1 = 42" ubuntu hardy ii gcc-4.1 4.1.2-21ubuntu1 The GNU C compiler ii gdb 6.8-1ubuntu2 The GNU Debugger ii gnat-4.1 4.1.2-16ubuntu3 The GNU Ada compiler => "$1 = 1" debian unstable ii gcc-4.1 4.1.2-23 The GNU C compiler ii gdb 6.8-3 The GNU Debugger ii gnat-4.1 4.1.2-20 The GNU Ada compiler => "$1 = 1" debian unstable ii gcc-snapshot 20080802-1 A SNAPSHOT of the GNU Compiler Collection => "No definition of "var1" in current context." -- Summary: GDB reports "No definition of "var1" in current context." for an existing variable Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245
[Bug ada/37245] GDB reports "No definition of "var1" in current context." for an existing variable
--- Comment #1 from ludovic at ludovic-brenta dot org 2008-08-26 17:43 --- Created an attachment (id=16151) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16151&action=view) Source file that reproduces the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245
[Bug libstdc++/37244] libstdc++ fails to build
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-26 17:45 --- >Some of the headers are not created? What tar did you use? Because the filename for this file goes past the limit of a POSIX tar, GNU tar is required to untar the GCC now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37244
[Bug ada/37245] GDB reports "No definition of "var1" in current context." for an existing variable
--- Comment #2 from ludovic at ludovic-brenta dot org 2008-08-26 17:49 --- Note that 4.1.2 fails in a different way than 4.3.1 and trunk. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Known to fail||4.1.2 4.3.1 4.4.0 Known to work||4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245
[Bug libstdc++/37244] libstdc++ fails to build
--- Comment #2 from htl10 at users dot sourceforge dot net 2008-08-26 18:04 --- Oh dear, sorry about the noise - Looking at my own error message about the missing files and where they are, I found that it is the vendor tar which is broken - it truncates file path names to 100 characters - this is normally not noticeable except in the libstdc++ dir where there are a lot of files with long names. e.g. gnu tar: - $ ls gcc-4.3.1/libstdc++-v3/include/ext/pb_ds/detail/resize_policy cc_hash_max_collision_check_resize_trigger_imp.hpp hash_standard_resize_policy_imp.hpp hash_exponential_size_policy_imp.hppsample_resize_policy.hpp hash_load_check_resize_trigger_imp.hpp sample_resize_trigger.hpp hash_load_check_resize_trigger_size_base.hppsample_size_policy.hpp hash_prime_size_policy_imp.hpp vendor tar: $ ls gcc-4.3.1/libstdc++-v3/include/ext/pb_ds/detail/resize_policy cc_hash_max_collision_check_resize_tri hash_standard_resize_policy_imp.hpp hash_exponential_size_policy_imp.hppsample_resize_policy.hpp hash_load_check_resize_trigger_imp.hpp sample_resize_trigger.hpp hash_load_check_resize_trigger_size_ba sample_size_policy.hpp hash_prime_size_policy_imp.hpp -- Can somebody update the platform-specific notes please: http://gcc.gnu.org/install/specific.html ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37244
[Bug libstdc++/37244] libstdc++ fails to build
--- Comment #3 from htl10 at users dot sourceforge dot net 2008-08-26 18:06 --- Yes, mid-air collision - I realised the problem as soon as I looked at my own bug report and looked at the directory again. Still, the POSIX tar vs GNU tar issue could be spelt out a bit :-(. (spent a few days on this...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37244
[Bug libstdc++/37244] libstdc++ fails to build
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-26 18:10 --- > Can somebody update the platform-specific notes please: > http://gcc.gnu.org/install/specific.html ? > Still, the POSIX tar vs GNU tar issue could be spelt out a bit :-(. > (spent a few days on this...) It is spelled out on http://gcc.gnu.org/install/prerequisites.html :). >From that link: GNU tar version 1.14 (or later) Necessary (only on some platforms) to untar the source code. Many systems' tar programs will also work, only try GNU tar if you have problems. -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37244
[Bug libstdc++/37244] libstdc++ fails to build
--- Comment #5 from htl10 at users dot sourceforge dot net 2008-08-26
18:19 ---
(In reply to comment #4)
> From that link:
> GNU tar version 1.14 (or later)
> Necessary (only on some platforms) to untar the source code. Many systems' tar
> programs will also work, only try GNU tar if you have problems.
That's so not obvious :-( ("many system's tar will work") - particularly since
I had built gcc (3.4.x) on the same machine before. I have taken the trouble to
install binutils, mpfr, gmp (because gcc 4.x needs those)... and even the GNU
bash/GNU make requirement were easy, since ./configure && make fails very early
- but the long path is not obvious, since it fails very late - and possibly
only in the stdc++ and java stuff - gcc and gfortran are not affected.
Can I suggest a line be added to http://gcc.gnu.org/install/specific.html,
saying HP/DEC tar does not work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37244
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-26 18:22 --- These are regressions on Linux/ia64: +FAIL: g++.dg/opt/eh3.C execution test +FAIL: gfortran.dg/list_read_8.f90 -O0 execution test +FAIL: gfortran.dg/list_read_8.f90 -O1 execution test +FAIL: gfortran.dg/list_read_8.f90 -O2 execution test +FAIL: gfortran.dg/list_read_8.f90 -O3 -fomit-frame-pointer execution test +FAIL: gfortran.dg/list_read_8.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test +FAIL: gfortran.dg/list_read_8.f90 -O3 -fomit-frame-pointer -funroll-loops execution test +FAIL: gfortran.dg/list_read_8.f90 -O3 -g execution test +FAIL: gfortran.dg/list_read_8.f90 -Os execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug testsuite/25241] [C++] DejaGNU does not distinguish between errors and warnings
--- Comment #61 from janis at gcc dot gnu dot org 2008-08-26 18:28 --- I've got a huge patch now that modifies 359 tests to use the correct one of dg-error, dg-warning, or dg-message, and splits combined checks into multiple checks. In the tests I've modified I've also added some of the text from the message into the directive, although sometimes it's only a word or two. The first patch is http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01966.html. When I've received feedback about that I'll submit other patches and check them in immediately if they are obvious or wait for feedback if that seems appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug rtl-optimization/37219] [4.3/4.4 Regression] fwprop1 is broken for addresses
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-26 19:03 --- Subject: Bug 37219 Author: pinskia Date: Tue Aug 26 19:02:05 2008 New Revision: 139605 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139605 Log: 2008-08-26 Andrew Pinski <[EMAIL PROTECTED]> PR rtl-opt/37219 * fwprop.c (fwprop): Check that the loop_father is the outer loop. (fwprop_addr): Check that the loop_father is not the outer loop. Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
[Bug rtl-optimization/37219] [4.3 Regression] fwprop1 is broken for addresses
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.2 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-26 20:03 --- On Linux/ia32, it also miscompiled 416.gamess in SPEC CPU 2006. with -O2 -msse2 -mfpmath=sse -ffast-math. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||Joey dot ye at intel dot ||com, weiliang dot lin at ||intel dot com, xuepeng dot ||guo at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-26 20:09 --- We got Running 416.gamess ref base lnx32-gcc default 416.gamess: copy #0 non-zero return code (rc=0, signal=11) 416.gamess: copy #0 non-zero return code (rc=0, signal=11) 416.gamess: copy #0 non-zero return code (rc=0, signal=11) We will try to find a small testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug c/37246] New: Updated spec for freebsd7.0
The diff adds support for dl_iterate_phdr from FreeBSD 7.0 libc, and also uses --as-needed when linking to libgcc_s. The main spec source is the FreeBSD spec from their cvs. The extras for dl_iterate_phdr adapted (they set -D__GLIBC__=3 on the cmdline/Makefile) on the code/config. This is only for i[3456]86 tho. Don't have the hardware to complete/test the x64/sparc64 (missing) parts. -- Summary: Updated spec for freebsd7.0 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: the_paya at gentoo dot org GCC build triplet: i686-gentoo-freebsd7.0 GCC host triplet: i686-gentoo-freebsd7.0 GCC target triplet: i686-gentoo-freebsd7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
[Bug c/37246] Updated spec for freebsd7.0
--- Comment #1 from the_paya at gentoo dot org 2008-08-26 20:28 --- Created an attachment (id=16152) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16152&action=view) patch against gcc-4.3.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
[Bug target/37246] Updated spec for freebsd7.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-26 20:39 --- Patches go to [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug target/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug rtl-optimization/37240] missed if-conversion opportunity
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-26 20:46 --- I think this is a dup of bug 30521. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37240
[Bug middle-end/37221] GCC for Cell SPU produces poor code when there is load-after-store in different loops
--- Comment #5 from tehila at il dot ibm dot com 2008-08-26 20:47 --- (In reply to comment #3) > The meaning here is to the second > for (j = 0; j < 4; j++) > loop. > It's loop #4 in cunrolli pass. > > cunrolli doesn't recognize # of iterations = 4. > > I think it doesn't recognize it starts from 0. We think the problem is that j=0 are somewhere before got hoisted into some part above. If I add 'printf' before the loop (i.e., after the if) the loop does get unrolled and with SRA optimization the performance get improved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37221
[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-26 21:16 ---
>This could be due to array indexing lowered to POINTER_PLUS_EXPR.
Array indexing is never lowered using POINTER_PLUS_EXPR, only for pointers it
is. Though it looks like
we are doing the math in unsigned in one case but signed in another but we
don't consider them the same for PRE.
Simple testcase:
int f(int a)
{
unsigned b = a;
b++;
a++;
return a + b;
}
We should just get return a*2 + 2; (which we do at the RTL level) but we get:
b = (unsigned int) a;
return (int) ((b + 1) + (unsigned int) (a + 1));
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-08-26 21:16:06
date||
Summary|missed FRE opportunity |missed FRE opportunity
||because of signedness of
||addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
[Bug c/37247] New: Function address passed as argument is incremented by 1
when calling a function with an function call address as argument, the address
is passed incremented by 1. it may work some times, but often crashes.
It can be verified in the dumpfile (.dm), the error is also present in hex
file.
the function call is "netif_add" (see below) argument "ethernetif_init" real
address is 0x0001261c, but in the table after the code (at 0x2050) we can find
0x0001261d. Of course, when calling the function, which then has an odd
address, the target generates a data error. Same problem with the last argument
"tcpip_input"
I have found same problems in other projects, I don't understand how they can
work.
Can it be a linker problem ? Why is the address incremented by 1? is there a
bad option in the makefile ? I think it can be a bug. not all function
addresses are affected.
project is based on lwip stack with freeRTOS. target : AT91SAM7X512 (or 256).
part extracted from .DM file:
===
1f40 :
1f40: b530push{r4, r5, lr}
1f42: b091sub sp, #68
1f44: ab03add r3, sp, #12
.
netif_add(&EMAC_if, &xIpAddr, &xNetMast, &xGateway, NULL, ethernetif_init,
tcpip_input);
1f7c: 46ecmov ip, sp
1f7e: 4b34ldr r3, [pc, #208] (2050
)
1f80: 4660mov r0, ip
1f82: 6043str r3, [r0, #4]
1f84: 46ecmov ip, sp
1f86: 4b33ldr r3, [pc, #204] (2054
)
1f88: 4660mov r0, ip
2038: 2296movsr2, #150
203a: 1c23addsr3, r4, #0
203c: f017 f9b4 bl 193a8
2040: e7c6b.n 1fd0
2042: 46c0nop (mov r8, r8)
2044: c0a8002d.word 0xc0a8002d
2048: c0a800fe.word 0xc0a800fe
204c: 0020ab68.word 0x0020ab68
2050: 0001261d.word 0x0001261d
2054: f70d.word 0xf70d
2058: 00023ff8.word 0x00023ff8
205c: 1ebd.word 0x1ebd
===
0001261c :
1261c: b500push{lr}
1261e: b083sub sp, #12
12620: ab01add r3, sp, #4
...
126a2: bc02pop {r1}
126a4: 4708bx r1
126a6: 46c0nop (mov r8, r8)
126a8: 000124bd.word 0x000124bd
126ac: 000122a9.word 0x000122a9
126b0: 1388.word 0x1388
126b4: 000125f5.word 0x000125f5
126b8: 4720bx r4
126ba: 46c0nop (mov r8, r8)
===
f70c :
* to an IP header (if netif doesn't got NETIF_FLAG_ETHARP flag)
* @param inp the network interface on which the packet was received
*/
err_t
tcpip_input(struct pbuf *p, struct netif *inp)
{
f70c: b500push{lr}
f70e: b084sub sp, #16
...
f7a2: b004add sp, #16
f7a4: bc02pop {r1}
f7a6: 4708bx r1
f7a8: 0021570c.word 0x0021570c
makefile used:
#
***
# See http://www.FreeRTOS.org for documentation, latest information,
license
# and contact details. Please ensure to read the configuration and
relevant
# port sections of the online documentation.
#
***
CC=arm-elf-gcc
AS=arm-elf-gcc -x assembler-with-cpp
OBJCOPY=arm-elf-objcopy
ARCH=arm-elf-ar
DEBUG=-g
OPTIM=-O0
LDSCRIPT=atmel-rom.ld
#jlb -S: intermix C with Assembler
ODFLAGS = -f -p -x -h -t -s -D -S -r -G -W
OBJDUMP = arm-elf-objdump
#Project and main binary file name
PROJECT = InterfaceIP_V1
#
# CFLAGS common to both the THUMB and ARM mode builds
#
#jlb : remove one level '../' before Source
CFLAGS= \
-I. \
-I./Include \
-I./EMAC \
-I../Common/include \
-I./USB \
-I./lwip-1.3.0/src/include \
-I./lwip-1.3.0/contrib/port/FreeRTOS/AT91SAM7X \
-I./lwip-1.3.0/contrib/port/FreeRTOS/AT91SAM7X\arch \
-I../Source/include \
-I../Source/portable/GCC/ARM7_AT91SAM7S \
-I./lwip-1.3.0/src/include/ipv4 \
-I./Txs_generic \
-I./Txs_custom \
-I./Txs_http \
-Wall \
-Wextra \
-Wstrict-prototypes \
-Wmissing-prototypes \
-Wmissing-declarations \
-Wno-strict-aliasing \
-D SAM7_GCC \
-D THUMB_INTERWORK \
-mthumb-interwork \
-mcpu=arm7tdmi \
-T$(LDSCRIPT) \
$(DEBUG) \
$(OPTIM) \
-fomit-frame-pointer
THUMB_FLAGS=-mthumb
LINKER_FLAGS=-Xlinker -o$(PROJECT).elf -Xlinker -M -Xlinker -Map=$(PROJECT).map
--cref
#jlb
# Define ASM defines here
# List all d
[Bug target/37247] Function address passed as argument is incremented by 1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|blocker |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37247
[Bug target/37246] Updated spec for freebsd7.0
--- Comment #3 from the_paya at gentoo dot org 2008-08-26 21:43 --- My bad, sent. http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01988.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-26 22:24 --- Linux/x86-64 only regressions are +FAIL: g++.old-deja/g++.eh/rethrow6.C execution test +FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2 +FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa +FAIL: gcc.target/i386/pr36246.c scan-assembler-not movq -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug middle-end/37248] New: regression 4.3.1 -> 4.3.2-rc transformation bitfield to individual bytes
In short, when passing a bitfield as parameter, each bit is converted to bytes
before being tested instead of a simple mask and test.
Is there a way to disable bit to bytes conversion by a compilation switch,
I have never seen that producing better code up to now?
$ cat tmp2.c
struct mouse_button_str {
unsigned char left : 1;
unsigned char right : 1;
unsigned char middle: 1;
} button;
char fct (struct mouse_button_str newbutton)
{
return (newbutton.left && newbutton.right && newbutton.middle);
}
$ ./toolchain/bin/gcc --version
gcc (GCC) 4.3.2 20080819 (prerelease)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./toolchain/bin/gcc -Os tmp2.c -S -o tmp2.s
$ cat tmp2.s
.file "tmp2.c"
.text
.globl fct
.type fct, @function
fct:
pushl %ebp
movl%esp, %ebp
movb8(%ebp), %al
movb%al, %cl
movb%al, %dl
shrb%cl
shrb$2, %dl
andl$1, %ecx
andl$1, %edx
testb $1, %al
je .L2
testb %cl, %cl
je .L2
movl%edx, %eax
andl$1, %eax
jmp .L3
.L2:
xorl%eax, %eax
.L3:
popl%ebp
ret
.size fct, .-fct
.comm button,1,1
.ident "GCC: (GNU) 4.3.2 20080819 (prerelease)"
.section.note.GNU-stack,"",@progbits
$ ./toolchain-4.3.1/bin/gcc --version
gcc (GCC) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./toolchain-4.3.1/bin/gcc -Os tmp2.c -S -o tmp2.s
$ cat tmp2.s
.file "tmp2.c"
.text
.globl fct
.type fct, @function
fct:
pushl %ebp
movl%esp, %ebp
movb8(%ebp), %al
popl%ebp
andl$7, %eax
cmpb$7, %al
sete%al
ret
.size fct, .-fct
.comm button,1,1
.ident "GCC: (GNU) 4.3.1"
.section.note.GNU-stack,"",@progbits
--
Summary: regression 4.3.1 -> 4.3.2-rc transformation bitfield to
individual bytes
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
GCC build triplet: i386-linux-fedora
GCC host triplet: i386-linux-fedora
GCC target triplet: i386-linux-fedora
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37248
[Bug middle-end/37248] [4.3/4.4 Regression] regression 4.3.1 -> 4.3.2-rc transformation bitfield to individual bytes
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-26 22:50 --- BIT_FIELD_REF was removed because it caused wrong code. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-linux-fedora | GCC host triplet|i386-linux-fedora | GCC target triplet|i386-linux-fedora | Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-08-26 22:50:34 date|| Summary|regression 4.3.1 -> 4.3.2-rc|[4.3/4.4 Regression] |transformation bitfield to |regression 4.3.1 -> 4.3.2-rc |individual bytes|transformation bitfield to ||individual bytes Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37248
[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions
--- Comment #6 from hjl dot tools at gmail dot com 2008-08-27 00:05 --- On Linux/Intel64, I got Running 434.zeusmp ref base lnx32e-gcc default 434.zeusmp: copy #0 non-zero return code (rc=0, signal=11) with -O2 -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug c/37249] New: gcc does not warn on trucate of int64_t to int32_t
This bug is related to bug 2707. I think the following code should generate a warning: int64_t i = 9223372036854775807ll; int32_t j = i; It does not generate any warnings with "gcc-4.2.1 -Wall -Wextra". -- Summary: gcc does not warn on trucate of int64_t to int32_t Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sean dot c dot rhea at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37249
[Bug c/37249] gcc does not warn on trucate of int64_t to int32_t
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-27 02:34 --- try -Wconversion, which works like what you want it to work in 4.3 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37249
[Bug other/37250] New: GCC documentation lists unavailable ia32 intrinsics
Since at least 4.0, some or all of the following functions are no longer available in GCC, yet they're still in the documentation. See also comments in bug #20049. Could someone please remove references to them? __builtin_ia32_loadaps __builtin_ia32_loadddup __builtin_ia32_loadsss [__builtin_ia32_loadss] __builtin_ia32_movddup __builtin_ia32_pextrw __builtin_ia32_pfrsqrtit1 __builtin_ia32_pinsrw __builtin_ia32_storeaps __builtin_ia32_storess -- Summary: GCC documentation lists unavailable ia32 intrinsics Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jtoomim at jtoomim dot org GCC build triplet: N/A GCC host triplet: N/A GCC target triplet: N/A http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37250
[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389
--- Comment #5 from astrange at ithinksw dot com 2008-08-27 04:27 --- Fixed. -- astrange at ithinksw dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36673
[Bug rtl-optimization/36672] IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829
--- Comment #4 from astrange at ithinksw dot com 2008-08-27 04:28 --- Fixed. -- astrange at ithinksw dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36672
[Bug rtl-optimization/36663] IRA ICE in save_call_clobbered_regs at caller-save.c:1949
--- Comment #4 from astrange at ithinksw dot com 2008-08-27 04:28 --- Fixed. -- astrange at ithinksw dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36663
[Bug rtl-optimization/37240] missed if-conversion opportunity
--- Comment #3 from bonzini at gnu dot org 2008-08-27 04:40 --- *** This bug has been marked as a duplicate of 30521 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37240
[Bug middle-end/30521] "if (i == n) ++i;" or "i += i == n;"?
--- Comment #3 from bonzini at gnu dot org 2008-08-27 04:40 --- *** Bug 37240 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug middle-end/30521] "if (i == n) ++i;" or "i += i == n;"?
--- Comment #4 from bonzini at gnu dot org 2008-08-27 04:40 --- see PR37240 for another testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax
--- Comment #3 from astrange at ithinksw dot com 2008-08-27 04:41 --- Now it is. -- astrange at ithinksw dot com changed: What|Removed |Added Summary|IRA doesn't allocate asm|[4.4 regression] IRA doesn't |output being returned to eax|allocate asm output being ||returned to eax http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539
[Bug rtl-optimization/37251] New: [4.4 Regression] ICE with ira: delete_allocno_from_bucket
The following triggered with CP2K: gfortran -v -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native xc_xbecke88_lr_adiabatic.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data/vondele/gcc_bench/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_bench/gcc_trunk/build --enable-languages=c,fortran Thread model: posix gcc version 4.4.0 20080826 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O3' '-ffast-math' '-funroll-loops' '-ftree-vectorize' /data/vondele/gcc_bench/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 xc_xbecke88_lr_adiabatic.f90 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -quiet -dumpbase xc_xbecke88_lr_adiabatic.f90 -auxbase xc_xbecke88_lr_adiabatic -O3 -version -ffast-math -funroll-loops -ftree-vectorize -fintrinsic-modules-path /data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/cci09Vqi.s GNU Fortran (GCC) version 4.4.0 20080826 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080826 (experimental), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 xc_xbecke88_lr_adiabatic.f90: In function xb88_lr_adiabatic_lda_calc: xc_xbecke88_lr_adiabatic.f90:492: internal compiler error: in delete_allocno_from_bucket, at ira-color.c:619 testcase to be attached. Using -march=opteron (which I used to test the ira branch) is enough to avoid it, so the -march=xxx and so on parameters are relevant. Full sources can be downloaded: http://cp2k.berlios.de/gfortran/ ftp://ftp.berlios.de/pub/cp2k/gfortran/gcc_bench.tgz -- Summary: [4.4 Regression] ICE with ira: delete_allocno_from_bucket Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk OtherBugsDependingO 29975 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
[Bug rtl-optimization/37251] [4.4 Regression] ICE with ira: delete_allocno_from_bucket
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-27 06:26 --- Created an attachment (id=16153) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16153&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
[Bug rtl-optimization/37251] [4.4 Regression] ICE with ira: delete_allocno_from_bucket
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition
--- Comment #4 from bonzini at gnu dot org 2008-08-27 06:41 ---
Minimized testcase:
int m(int *y, int x)
{
int a = y[x + 1];
int b = y[++x];
return a - b;
}
should be optimized to "return 0"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
