[Bug bootstrap/27794] stack explosion
--- Comment #11 from cnstar9988 at gmail dot com 2008-05-02 09:14 --- I think it is a duplicate of PR 35169. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug bootstrap/27794] stack explosion
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-05-02 09:19 --- I think it is a duplicate of PR 35169. All the more so that this was reported on the same machine. :-) *** This bug has been marked as a duplicate of 35169 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-05-02 09:19 --- *** Bug 27794 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169
[Bug tree-optimization/36098] [4.4 Regression] 435.gromacs miscompares at -O3
--- Comment #3 from rguenther at suse dot de 2008-05-02 09:02 --- Subject: Re: [4.4 Regression] 435.gromacs miscompares at -O3 On Fri, 2 May 2008, hjl dot tools at gmail dot com wrote: --- Comment #2 from hjl dot tools at gmail dot com 2008-05-02 05:05 --- Revision 134730: http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00959.html is the cause. That was my guess as well. An interesting thing would be to know if the failure goes away with -fno-tree-vectorize. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36098
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #11 from jakub at gcc dot gnu dot org 2008-05-02 09:34 --- The unexpected address is created by simplify_plus_minus on (plus:DI (reg:DI 2 2) (const:DI (minus:DI (symbol_ref/u:DI (*.LC1) [flags 0x2]) (symbol_ref:DI (*.LCTOC1) and (const_int 8 [0x8]) where the .LCTOC1 and +8 pair is simplified together. Unfortunately, if we refuse it in rs6000_legitimate_address, fwprop doesn't try harder (LEGITIMIZE_ADDRESS/memory_address isn't called) and nothing afterwards propagates it either, so we end up with: la 9,[EMAIL PROTECTED](2) ld 0,8(9) instead of ld 0,[EMAIL PROTECTED](2) So I'm afraid we want to accept it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36103] gfortran 4.4.0-20060501 failed to compile this program
--- Comment #8 from burnus at gcc dot gnu dot org 2008-05-02 09:48 --- Works for me for 4.4.0 20080424 on a X86-64 openSUSE Factory (approx. oS 11.0beta2) with a glibc 2.8 (20080410). I wonder whether it has something to do with the recent sign/decimal comma work. Could those for whose it fails try to find out which of the various LC_* options fails? For instance: LC_ALL=C LC_NUMERIC=zh_CN.UTF-8 or LC_CTYPE=zh_CN.UTF-8 or ... It is a regression on 4.4, it works on 4.3. I assume a 4.3 program with a 4.4 library also fails? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #12 from jakub at gcc dot gnu dot org 2008-05-02 09:46 --- Created an attachment (id=15561) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15561action=view) gcc44-pr36090.patch Untested patch that 1) tightens the checking in legitimate_constant_pool_address_p - previously it could accept e.g. two symrefs, two tocrefs or say MINUS (tocref, symref) etc. 2) should be able to output everything that is accepted by that routine. All I've tested so far is that it fixes this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36103] gfortran 4.4.0-20060501 failed to compile this program
--- Comment #9 from dominiq at lps dot ens dot fr 2008-05-02 10:08 --- Could those for whose it fails try to find out which of the various LC_* options fails? For instance: LC_ALL=C LC_NUMERIC=zh_CN.UTF-8 or LC_CTYPE=zh_CN.UTF-8 or ... Although I did not exhaust all the combinations, I saw the problem with LC_ALL=zh_CN.*. The zh_(HK|TW).* I have tested work and the different LC_(.not.ALL)=zh_CN.UTF-8 tested also work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #48 from rguenth at gcc dot gnu dot org 2008-05-02 10:28 --- Btw, on x86_64 leslie3d performance is now above that from before r126326. The differences you mention can be seen on x86_64 as well, but they are not related to aliasing or partitioning but due to differences in what IVOPTs produces. The first difference at all on the tree level is with mergephi2 that is able to remove a single forwarder BB if --param max-aliased-vops=1 is _not_ specified. First real changes happen when DOM is able to CSE some loads with --param max-aliased-vops=1 but not without: - D.1747_808 = D.1747_763; - D.1748_809 = D.1748_764; - D.1749_811 = D.1749_766; - D.1750_812 = D.1749_766 * D.1644_799; + D.1747_808 = pav.data; + D.1748_809 = (real(kind=8)[0:] *) D.1747_808; + D.1749_811 = pav.dim[0].stride; + D.1750_812 = D.1644_799 * D.1749_811; and as PRE itself is not alias-oracle aware as well further missed optimizations occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-05-02 11:09 --- Subject: Bug 36100 Author: hubicka Date: Fri May 2 11:08:22 2008 New Revision: 134885 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134885 Log: PR bootstrap/36100 * ipa-inline.c (inline_generate_summary): Make static. (inline_transform): Do not call inlining at -O0; make static. * passes.c (execute_todo): Add sanity check. (execute_one_ipa_transform_pass): Execute proper flags. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/passes.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #4 from hubicka at ucw dot cz 2008-05-02 11:11 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
Hi,
I am testing the following patch that restores inlining at -O0.
Index: tree-pass.h
===
*** tree-pass.h (revision 134885)
--- tree-pass.h (working copy)
*** extern struct rtl_opt_pass pass_final;
*** 501,506
--- 501,507
extern struct rtl_opt_pass pass_rtl_seqabstr;
extern struct gimple_opt_pass pass_release_ssa_names;
extern struct gimple_opt_pass pass_early_inline;
+ extern struct gimple_opt_pass pass_O0_always_inline;
extern struct gimple_opt_pass pass_inline_parameters;
extern struct gimple_opt_pass pass_all_early_optimizations;
extern struct gimple_opt_pass pass_update_address_taken;
Index: ipa-inline.c
===
*** ipa-inline.c(revision 134885)
--- ipa-inline.c(working copy)
*** inline_transform (struct cgraph_node *no
*** 1588,1601
todo = optimize_inline_calls (current_function_decl);
timevar_pop (TV_INTEGRATION);
}
- /* In non-unit-at-a-time we must mark all referenced functions as needed.
*/
- if (!flag_unit_at_a_time)
- {
- struct cgraph_edge *e;
- for (e = node-callees; e; e = e-next_callee)
- if (e-callee-analyzed)
- cgraph_mark_needed_node (e-callee);
- }
return todo | execute_fixup_cfg ();
}
--- 1588,1593
*** struct ipa_opt_pass pass_ipa_inline =
*** 1628,1631
--- 1620,1681
NULL,/* variable_transform */
};
+
+ /* When inlining shall be performed. */
+ static bool
+ cgraph_gate_O0_always_inline (void)
+ {
+ return !optimize || !flag_unit_at_a_time;
+ }
+
+ static unsigned int
+ cgraph_O0_always_inline (void)
+ {
+ struct cgraph_node *node = cgraph_node (current_function_decl);
+ unsigned int todo = 0;
+ bool inlined;
+
+ if (sorrycount || errorcount)
+ return 0;
+ /* We might need the body of this function so that we can expand
+ it inline somewhere else. */
+ inlined = cgraph_decide_inlining_incrementally (node, INLINE_SPEED, 0);
+ if (cgraph_preserve_function_body_p (current_function_decl))
+ save_inline_function_body (node);
+ if (inlined || warn_inline)
+ {
+ timevar_push (TV_INTEGRATION);
+ todo = optimize_inline_calls (current_function_decl);
+ timevar_pop (TV_INTEGRATION);
+ }
+ /* In non-unit-at-a-time we must mark all referenced functions as needed.
*/
+ if (!flag_unit_at_a_time)
+ {
+ struct cgraph_edge *e;
+ for (e = node-callees; e; e = e-next_callee)
+ if (e-callee-analyzed)
+ cgraph_mark_needed_node (e-callee);
+ }
+ return todo;
+ }
+
+ struct gimple_opt_pass pass_O0_always_inline =
+ {
+ {
+ GIMPLE_PASS,
+ always_inline,/* name */
+ cgraph_gate_O0_always_inline, /* gate */
+ cgraph_O0_always_inline,/* execute */
+ NULL, /* sub */
+ NULL, /* next */
+ 0, /* static_pass_number */
+ TV_INLINE_HEURISTICS, /* tv_id */
+ 0, /* properties_required */
+ PROP_cfg, /* properties_provided */
+ 0, /* properties_destroyed */
+ 0, /* todo_flags_start */
+ TODO_dump_func /* todo_flags_finish */
+ }
+ };
+
#include gt-ipa-inline.h
Index: passes.c
===
*** passes.c(revision 134885)
--- passes.c(working copy)
*** init_optimization_passes (void)
*** 553,558
--- 553,559
/* These passes are run after IPA passes on every function that is being
output to the assembler file. */
p = all_passes;
+ NEXT_PASS (pass_O0_always_inline);
NEXT_PASS (pass_all_optimizations);
{
struct opt_pass **p = pass_all_optimizations.pass.sub;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug middle-end/36106] New: #pragma omp atomic issues with floating point types
Attached testcases fail on x86_64 (with cmpxchg16b) or i386 (with cmpxchg8b), in both cases the problem is that reading the original value using FPU and storing it into a temporary doesn't mean bitwise identical copy (in the first case because long double is said to be a 16 byte type, even when the copy through FPU actually copies just 80 bits, and in the latter case because the copy turns the signalling NaN into a corresponding quiet NaN). This means both testcases hang. Will work on a fix. -- Summary: #pragma omp atomic issues with floating point types Product: gcc Version: 4.3.1 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36106
[Bug middle-end/36106] #pragma omp atomic issues with floating point types
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-02 11:40 --- Created an attachment (id=15562) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15562action=view) gcc44-pr36106-test.patch Testcases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36106
[Bug c++/36107] New: weak constructor product unvalid asm
When using __attribute__((weak)) on a constructor, the produced assembly file
contains an extra *INTERNAL* on the constructor declaration line.
- Here is my test code:
class Test {
public:
Test() __attribute__((weak));
};
int test() {
Test test;
}
- The compilation output:
$ g++ test.cc
/tmp/cchKRpYD.s: Assembler messages:
/tmp/cchKRpYD.s:22: Error: junk at end of line, first unrecognized character is
`*'
- The corresponding asm line 22:
.weak _ZN4TestC1Ev *INTERNAL*
I have tried this with and it does not work for:
- gcc (GCC) 4.3.0 (compiled from sources)
- gcc-4.2 (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
- gcc-4.1 (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
It works without problems with:
- gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
If I manually remove the '*INTERNAL*' from the asm file, it compiles correctly.
I found a similar old bug (6418) from the GCC3.04 version
--
Summary: weak constructor product unvalid asm
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: william dot fink at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36107
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #49 from rguenth at gcc dot gnu dot org 2008-05-02 12:16
---
Missing jump-threading causes quite a number of missed FRE opportunities, we
have
if (i2 = 0)
{
... = load X
}
if (i2 = 0)
{
... = load X
}
where we figure out the redundancy but don't do the replacement because
the result of the first load is not available at the place of the second load.
Some pass reordering may fix this and similar problems but of course may
have other side-effects. My suggestion is to move passes from
fre, vrp, ch
to
ch, vrp, fre
and dropping the final dom pass in favor of another FRE one (DOM has
weaker memory optimization but in addition does some jump threading and
cond expr combining, both of which don't happen a lot after loop
optimizations).
But pass reordering has to wait until after the statistics patch has
been approved.
Note that teaching DOM about the alias-oracle is very difficult and
unlikely to happen - I'd rather get rid of DOM completely.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||34416, 35972
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #50 from dnovillo at google dot com 2008-05-02 12:32 --- Subject: Re: [4.3/4.4 Regression] Revision 126326 causes 12% slowdown On 05/02/08 08:16, rguenth at gcc dot gnu dot org wrote: and dropping the final dom pass in favor of another FRE one (DOM has weaker memory optimization but in addition does some jump threading and cond expr combining, both of which don't happen a lot after loop optimizations). Along these lines, I think we would really benefit from doing a thorough study of pass reordering using the techniques in GCC-ICI (GCC Summit 2008) and COLE (CGO 2008). Both have found significant improvements with different optimization pipelines. Note that teaching DOM about the alias-oracle is very difficult and unlikely to happen - I'd rather get rid of DOM completely. Agreed. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug middle-end/36099] [4.4 Regression] early loop unrolling pass prevents vectorization, SLP doesn't do its job
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-02 12:36 --- With a = b(k,:) - c manually unrolled the loop over k is unrolled with the early loop unrolling pass which exposes the unvectorizable calls to sin/cos, respective the complex temporaries introduced by the sincos pass to the vectorizer which then punts. The early unroller at -O3 is just limited by the maximum final loop size and the trip count (400 and 8) and the unroller estimates Loop 4 iterates 8 times. Loop size: 40 Estimated size after unrolling: 216 SLP also doesn't handle vectorization of register operations but needs memory source and destination operands(?). Likewise SLP shouldn't be confused by unvectorizable data types? On x86_64 you can reproduce the missed vectorization with -O3 -ffast-math. bb 7: # ivtmp.40_261 = PHI 9(6), ivtmp.40_240(8) # sum1_5 = PHI 0.0(6), sum1_90(8) # j_2 = PHI 1(6), j_94(8) D.1032_55 = (real(kind=8)) j_2; D.1033_56 = D.1032_55 * 6.9813170079773179121929160828585736453533172607421875e-1; sincostmp.16_28 = __builtin_cexpi (D.1033_56); D.1034_57 = REALPART_EXPR sincostmp.16_28; D.1035_58 = sini_48 * D.1034_57; D.1036_59 = D.1035_58 * 5.0e-1; D.1037_62 = IMAGPART_EXPR sincostmp.16_28; D.1038_63 = sini_48 * D.1037_62; D.1039_64 = D.1038_63 * 5.0e-1; D.1044_128 = pretmp.30_150 - D.1036_59; D.1047_132 = pretmp.30_154 - D.1039_64; D.1052_137 = __builtin_pow (D.1044_128, 2.0e+0); D.1054_138 = __builtin_pow (D.1047_132, 2.0e+0); D.1044_149 = pretmp.30_168 - D.1036_59; D.1047_153 = pretmp.30_172 - D.1039_64; D.1052_158 = __builtin_pow (D.1044_149, 2.0e+0); D.1054_159 = __builtin_pow (D.1047_153, 2.0e+0); D.1044_170 = pretmp.30_188 - D.1036_59; D.1047_174 = pretmp.30_192 - D.1039_64; D.1052_179 = __builtin_pow (D.1044_170, 2.0e+0); D.1054_180 = __builtin_pow (D.1047_174, 2.0e+0); D.1044_191 = pretmp.30_206 - D.1036_59; D.1047_195 = pretmp.30_210 - D.1039_64; D.1052_200 = __builtin_pow (D.1044_191, 2.0e+0); D.1054_201 = __builtin_pow (D.1047_195, 2.0e+0); D.1044_212 = pretmp.30_218 - D.1036_59; D.1047_216 = pretmp.30_230 - D.1039_64; D.1052_221 = __builtin_pow (D.1044_212, 2.0e+0); D.1054_222 = __builtin_pow (D.1047_216, 2.0e+0); D.1044_233 = pretmp.30_238 - D.1036_59; D.1047_237 = pretmp.30_248 - D.1039_64; D.1052_242 = __builtin_pow (D.1044_233, 2.0e+0); D.1054_243 = __builtin_pow (D.1047_237, 2.0e+0); D.1044_254 = pretmp.30_256 - D.1036_59; D.1047_258 = pretmp.30_260 - D.1039_64; D.1052_263 = __builtin_pow (D.1044_254, 2.0e+0); D.1054_264 = __builtin_pow (D.1047_258, 2.0e+0); D.1044_275 = pretmp.30_276 - D.1036_59; D.1047_279 = pretmp.30_280 - D.1039_64; D.1052_284 = __builtin_pow (D.1044_275, 2.0e+0); D.1054_285 = __builtin_pow (D.1047_279, 2.0e+0); D.1044_71 = pretmp.30_68 - D.1036_59; D.1047_76 = pretmp.30_73 - D.1039_64; D.1052_83 = __builtin_pow (D.1044_71, 2.0e+0); D.1054_85 = __builtin_pow (D.1047_76, 2.0e+0); D.1055_86 = D.1054_85 + D.1052_83; dotp_89 = D.1055_86 + pretmp.33_294; dotp_288 = dotp_89 + D.1052_137; D.1055_286 = dotp_288 + D.1054_138; sum1_289 = pretmp.33_249 + D.1055_286; dotp_267 = sum1_289 + D.1052_158; D.1055_265 = dotp_267 + D.1054_159; sum1_268 = pretmp.33_228 + D.1055_265; dotp_246 = sum1_268 + D.1052_179; D.1055_244 = dotp_246 + D.1054_180; sum1_247 = pretmp.33_207 + D.1055_244; dotp_225 = sum1_247 + D.1052_200; D.1055_223 = dotp_225 + D.1054_201; sum1_226 = pretmp.33_186 + D.1055_223; dotp_204 = sum1_226 + D.1052_221; D.1055_202 = dotp_204 + D.1054_222; sum1_205 = pretmp.33_165 + D.1055_202; dotp_183 = sum1_205 + D.1052_242; D.1055_181 = dotp_183 + D.1054_243; sum1_184 = pretmp.33_144 + D.1055_181; dotp_162 = sum1_184 + D.1052_263; D.1055_160 = dotp_162 + D.1054_264; sum1_163 = pretmp.33_123 + D.1055_160; dotp_141 = sum1_163 + D.1052_284; D.1055_139 = dotp_141 + D.1054_285; sum1_142 = D.1055_139 + pretmp.33_292; sum1_90 = sum1_142 + sum1_5; j_94 = j_2 + 1; ivtmp.40_240 = ivtmp.40_261 - 1; if (ivtmp.40_240 == 0) goto bb 9; else goto bb 8; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||irar at il dot ibm dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-05-02 12:36:33 date|| Summary|[4.4 Regression] early loop |[4.4 Regression] early loop |unrolling pass prevents |unrolling pass prevents |vectorization |vectorization, SLP doesn't ||do its job Target Milestone|---
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #13 from dje at gcc dot gnu dot org 2008-05-02 12:41 --- fwprop cannot be modified to produce the preferred RTL with the symbol_refs on the inside and the constant on the outside instead of teaching another part of the compiler how to print this peculiar construct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug bootstrap/36108] New: [4.4 Regression]: revision 134865 breaks gcc bootstrap
Revision 134865:
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01945.html
breaks gcc bootstrap:
cc1: warnings being treated as errors
/export/gnu/src/gcc/gcc/gcc/real.c: In function real_to_integer2:
/export/gnu/src/gcc/gcc/gcc/real.c:1387: error: array subscript is negative
/export/gnu/src/gcc/gcc/gcc/real.c: In function real_from_integer:
/export/gnu/src/gcc/gcc/gcc/real.c:2066: error: array subscript is negative
make[5]: *** [real.o] Error 1
make[5]: *** Waiting for unfinished jobs
The code looks like
if ((8 * 8) == (8 * 8))
{
high = t.sig[((128 + (8 * 8)) / (8 * 8))-1];
low = t.sig[((128 + (8 * 8)) / (8 * 8))-2];
}
else
{
((void)(!((8 * 8) == 2*(8 * 8)) ? fancy_abort
(/export/gnu/src/gcc/gcc/gcc/real.c, 1380, __FUNCTION__), 0 : 0));
high = t.sig[((128 + (8 * 8)) / (8 * 8))-1];
high = high ((8 * 8) - 1) 1;
high |= t.sig[((128 + (8 * 8)) / (8 * 8))-2];
low = t.sig[((128 + (8 * 8)) / (8 * 8))-3];
low = low ((8 * 8) - 1) 1;
low |= t.sig[((128 + (8 * 8)) / (8 * 8))-4];
}
We have
low |= t.sig[((128 + (8 * 8)) / (8 * 8))-4];
which is
low |= t.sig[-1];
But it never reached.
--
Summary: [4.4 Regression]: revision 134865 breaks gcc bootstrap
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: bootstrap
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=36108
[Bug bootstrap/36108] [4.4 Regression]: revision 134865 breaks gcc bootstrap
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 Version|4.3.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
[Bug bootstrap/36108] [4.4 Regression]: revision 134865 breaks gcc bootstrap
--- Comment #1 from hjl dot tools at gmail dot com 2008-05-02 12:44 --- It happens on Linux/Intel64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
[Bug middle-end/36099] [4.4 Regression] early loop unrolling pass prevents vectorization, SLP doesn't do its job
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-02 12:46 ---
The vectorizer doesn't know to vectorize __builtin_cexpi or
{REAL,IMAG}PART_EXPR
either.
IMHO rather than somehow tweaking the early unroller the vectorizer should
know how to deal with complex types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36099
[Bug bootstrap/36108] [4.4 Regression]: revision 134865 breaks gcc bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2008-05-02 12:48 ---
A simple testcase:
bash-3.2$ cat x.c
int foo [10];
int
bar (int i)
{
if (8 == 8)
return foo [1];
else
return foo [-1];
}
bash-3.2$ ./xgcc -B./ -O2 x.c -c -Wall -Werror
cc1: warnings being treated as errors
x.c: In function bar:
x.c:9: error: array subscript is negative
bash-3.2$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #51 from rguenther at suse dot de 2008-05-02 12:55 --- Subject: Re: [4.3/4.4 Regression] Revision 126326 causes 12% slowdown On Fri, 2 May 2008, dnovillo at google dot com wrote: --- Comment #50 from dnovillo at google dot com 2008-05-02 12:32 --- Subject: Re: [4.3/4.4 Regression] Revision 126326 causes 12% slowdown On 05/02/08 08:16, rguenth at gcc dot gnu dot org wrote: and dropping the final dom pass in favor of another FRE one (DOM has weaker memory optimization but in addition does some jump threading and cond expr combining, both of which don't happen a lot after loop optimizations). Along these lines, I think we would really benefit from doing a thorough study of pass reordering using the techniques in GCC-ICI (GCC Summit 2008) and COLE (CGO 2008). Both have found significant improvements with different optimization pipelines. If somebody wants to do the legwork ... (the study probably needs to be re-done and weight passes properly with we like this pass and we don't like this pass). Just by visual inspection and reasoning I can come up with some reasonable changes -- that probably expose missed optimizations that can and should be fixed in the proper passes rather than relying on others to cleanup (see the CCP bugs I tackled over the last month -- I expect similar stuff in other passes). The question is how to go forward here. As any re-ordering that makes sense appearantly needs thorough analysis of regressions that happen this isn't an automatic process. Automatic processes either require perfect passes or will come up with solutions that either still regress or contain a lot more passes than we like (in possible un-intuitive order). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #5 from hjl dot tools at gmail dot com 2008-05-02 12:59 --- Gcc can't bootstrap due to PR 36108. Jan, you should revert revision 134865 when you do testing. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||36108 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug bootstrap/36102] [4.4 Regression] internal compiler error: verify_cgraph_node failed
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-05-02 13:06 --- I believe those issues are fixed now. Can someone please confirm it? (I've managed to swap two versions of patches and commit development version of it) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36102
[Bug bootstrap/36102] [4.4 Regression] internal compiler error: verify_cgraph_node failed
--- Comment #7 from hjl dot tools at gmail dot com 2008-05-02 13:09 --- (In reply to comment #6) I believe those issues are fixed now. Can someone please confirm it? (I've managed to swap two versions of patches and commit development version of it) Gcc is broken due to PR 36108. I am testing gcc now by reverting revision 134865. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||36108 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36102
[Bug middle-end/36109] New: GET_MODE_SIZE is inefficient for constants
GET_MODE_SIZE always does an array lookup. This is inefficient for mode constants; in this case, it would be better to compare for equality for each mode and then decide on the actual size. When workingh with mode macros, this would allow conditionals to be folded to 0 or 1, and thus save both compiler code size and compilation time. -- Summary: GET_MODE_SIZE is inefficient for constants Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36109
[Bug translation/36103] gfortran crash with zh_CN locale
--- Comment #10 from burnus at gcc dot gnu dot org 2008-05-02 13:40 --- I can finally reproduce this - but for some reason not with 4.4 but with 4.3. (I somehow misread the description how one should reproduce it.) The problem is surely in http://gcc.gnu.org/viewcvs/trunk/gcc/po/zh_TW.po respectively in http://translationproject.org/latest/gcc/zh_CN.po I believe the problem is that something goes wrong with the % strings. For instance in the following, for %s %s %L the output order is changed to %3$L %1$s %2$s. The following is correct, but for one of the other strings there is something wrong - the n$ might be missing or the number is wrong or similar. The task is now to find the place. Afterwards, the Chinese translation team needs to fix it (http://translationproject.org/team/zh_CN.html) - it should be transferred to the Component Translation in bugzilla. msgid Arithmetic overflow converting %s to %s at %L. This check can be disabled with the option -fno-range-check msgstr %3$L#22788;#23558; %1$s #36716;#25442;#21040; %2$s #26102;#31639;#26415;#28322;#20986;#12290;#36825;#19968;#26816;#26597;#21487;#29992; -fno-range-check #36873;#39033;#20851;#38381; Is someone able to get a backtrace? One can then try to find the string which makes the problem. (I currently cannot as my GCC-developer computer is turned off.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|fortran |translation Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-05-02 13:40:05 date|| Summary|gfortran 4.4.0-20060501 |gfortran crash with zh_CN |failed to compile this |locale |program | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug translation/36103] gfortran crash with zh_CN locale
--- Comment #11 from burnus at gcc dot gnu dot org 2008-05-02 13:44 --- (In reply to comment #10) The problem is surely in http://gcc.gnu.org/viewcvs/trunk/gcc/po/zh_TW.po I meant: http://gcc.gnu.org/viewcvs/trunk/gcc/po/zh_CN.po -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug target/36004] alpha doesn't see stores, through other variables, for struct hack
--- Comment #1 from falk at debian dot org 2008-05-02 13:55 --- I can reproduce this with 4.1, but not with 4.2.3 or 4.3.1 20080401. So it seems to be fixed. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36004
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #52 from mmitchel at gcc dot gnu dot org 2008-05-02 14:16 --- Yes, the perfect pass problem is what concerns me too. For example, if we try to do dynamic reordering of passes, or allow users to specify that, we have to worry that, in practice, the compiler will crash or generate wrong code. We'll have no good way of ever validating even a small set of the possible combinations. Perhaps we need to make the passes fast, so we can run them more often? Or weave some of them together, even though of course it's nice if each pass is logically separate and does a single thing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug bootstrap/36108] [4.4 Regression]: revision 134865 breaks gcc bootstrap
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-02 14:35 --- confirmed on x86_64-unknown-linux-gnu -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-02 14:35:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
[Bug bootstrap/36102] [4.4 Regression] internal compiler error: verify_cgraph_node failed
--- Comment #8 from dominiq at lps dot ens dot fr 2008-05-02 14:36 --- (In reply to comment #6 and #7) I believe those issues are fixed now. Can someone please confirm it? Incremental builds now work. Gcc is broken due to PR 36108. I am testing gcc now by reverting revision 134865. This problem seems restricted to 64 bit platforms. I have touched gcc/real.c and rebuild without error. However I have now two new f951: internal compiler error: Bus error (not with rev. 134837). One of them with the original code of pr29921. I don't know yet if it is linked to changes in gfortran or elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36102
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-02 14:53 ---
It looks sub-optimal. But we should try to figure out why and what is wrong.
The optimality can be fixed with
Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c (revision 134885)
+++ tree-ssa-loop-ivopts.c (working copy)
@@ -4716,7 +4716,8 @@ try_add_cand_for (struct ivopts_data *da
{
cand = iv_cand (data, i);
- if (cand-iv-base_object != NULL_TREE)
+ if (cand-iv-base_object != NULL_TREE
+ || POINTER_TYPE_P (TREE_TYPE (cand-iv-base)))
continue;
if (iv_ca_cand_used_p (ivs, cand))
or similar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown
--- Comment #53 from rguenther at suse dot de 2008-05-02 15:05 --- Subject: Re: [4.3/4.4 Regression] Revision 126326 causes 12% slowdown On Fri, 2 May 2008, mmitchel at gcc dot gnu dot org wrote: --- Comment #52 from mmitchel at gcc dot gnu dot org 2008-05-02 14:16 --- Yes, the perfect pass problem is what concerns me too. For example, if we try to do dynamic reordering of passes, or allow users to specify that, we have to worry that, in practice, the compiler will crash or generate wrong code. We'll have no good way of ever validating even a small set of the possible combinations. True. Still if we don't have this ability to easily re-order passes we'll never know ;) So I still would like to have our pass-manager scripted, if it is only for development purposes of GCC. Perhaps we need to make the passes fast, so we can run them more often? Or weave some of them together, even though of course it's nice if each pass is logically separate and does a single thing? Most of the cleanup passes are fast, and one of the most important things in my view is maintainability which helps to reduce possible wrong-code bugs. This of course is easier with passes that do one single thing. One thing we should consider is to keep more information around across passes to make passes simpler. For example VRP throws away range information - we could separate out jump threading if we didn't do that, likewise other passes could benefit from this information. FRE and PRE compute value numbers which are also thrown away. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32921
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #14 from dje at gcc dot gnu dot org 2008-05-02 15:10 ---
The problematic transformation in simplify_plus_minus() is:
/* We suppressed creation of trivial CONST expressions in the
combination loop to avoid recursion. Create one manually now.
The combination loop should have ensured that there is exactly
one CONST_INT, and the sort will have ensured that it is last
in the array and that any other constant will be next-to-last. */
if (n_ops 1
GET_CODE (ops[n_ops - 1].op) == CONST_INT
CONSTANT_P (ops[n_ops - 2].op))
{
rtx value = ops[n_ops - 1].op;
if (ops[n_ops - 1].neg ^ ops[n_ops - 2].neg)
value = neg_const_int (mode, value);
ops[n_ops - 2].op = plus_constant (ops[n_ops - 2].op, INTVAL (value));
n_ops--;
}
If that transformation is avoided, the preferred RTL is generated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36110] New: Segmentation fault when compiling lapack with fortran 4.4.0-20060501
segmentation fault when compiling sgtrfs.f
my make.inc of lapack 3.1.1:
--
SHELL = /bin/sh
VERSION = 3.1.1
FORTRAN = gfortran
OPTS = ${FFLAGS}
DRVOPTS = $(OPTS)
NOOPT=
LOADER = $(FORTRAN)
LOADOPTS = $(OPTS)
TIMER= INT_ETIME
my $FFLAGS:
-ffixed-line-length-0 -ffree-line-length-0 -fimplicit-none -frange-check
-fmax-identifier-length=63 -Wall -fmax-errors=0 -Wimplicit-interface
-Wunused-parameter -Wconversion -Wcharacter-truncation -Wunderflow -fbacktrace
-fdump-core -ffpe-trap= -finit-integer=- -finit-real=nan
-finit-logical=false -finit-character=122 -pipe -ggdb3 -limf -lsvml -O3
-march=pentium4 -mfpmath=sse -funswitch-loops -ftree-loop-distribution
-ftree-loop-linear -ftree-loop-im -fivopts -funroll-loops
-fvariable-expansion-in-unroller -fsplit-ivs-in-unroller -ftree-vectorize
-ftree-vect-loop-version -fvect-cost-model -fgcse-sm -fgcse-las
-fsched-spec-load -fsched-stalled-insns=0 -fsched-stalled-insns-dep=0
-fbounds-check
--
Summary: Segmentation fault when compiling lapack with fortran
4.4.0-20060501
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linuxl4 at sohu dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36110
[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility
--- Comment #5 from jb at gcc dot gnu dot org 2008-05-02 15:37 --- Working on a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #15 from dje at gcc dot gnu dot org 2008-05-02 15:43 ---
This patch groups RTX_CONST_OBJ before CONST_INT.
Index: simplify-rtx.c
===
*** simplify-rtx.c (revision 134851)
--- simplify-rtx.c (working copy)
*** simplify_plus_minus (enum rtx_code code,
*** 3676,3682
if (n_ops 1
GET_CODE (ops[n_ops - 1].op) == CONST_INT
!CONSTANT_P (ops[n_ops - 2].op))
{
rtx value = ops[n_ops - 1].op;
if (ops[n_ops - 1].neg ^ ops[n_ops - 2].neg)
--- 3676,3684
if (n_ops 1
GET_CODE (ops[n_ops - 1].op) == CONST_INT
!CONSTANT_P (ops[n_ops - 2].op)
!(n_ops 3
! || !CONSTANT_P (ops[n_ops - 3].op)))
{
rtx value = ops[n_ops - 1].op;
if (ops[n_ops - 1].neg ^ ops[n_ops - 2].neg)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #16 from dje at gcc dot gnu dot org 2008-05-02 15:45 --- Copying Bonzini for him to comment on the precedence and canonicalization issue. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug middle-end/36110] ICE (segmentation fault) with -ftree-loop-distribution
--- Comment #1 from burnus at gcc dot gnu dot org 2008-05-02 15:48 --- This GCC version does not make sense: 4.4.0-20060501. I assume you mean 20080501. The mentioned file is available at: http://www.netlib.org/lapack/single/sgtrfs.f I can reproduce the crash with: $ gfortran -S -O2 -ftree-loop-distribution sgtrfs.f sgtrfs.f: In function sgtrfs: sgtrfs.f:1: internal compiler error: Segmentation fault Valgrind shows: ==32764== Use of uninitialised value of size 8 ==32764==at 0x4D4520: bitmap_bit_p (bitmap.c:548) ==32764==by 0xAB76DE: compute_dominance_frontiers (cfganal.c:1273) ==32764==by 0x74F70E: update_ssa (tree-into-ssa.c:3281) ==32764==by 0x7F2D29: rewrite_into_loop_closed_ssa (tree-ssa-loop-manip.c:377) ==32764==by 0x754967: tree_loop_distribution (tree-loop-distribution.c:1029) ==32764==by 0x678576: execute_one_pass (passes.c:1136) ==32764==by 0x6787B4: execute_pass_list (passes.c:1191) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||ice-on-valid-code Summary| Segmentation fault when|ICE (segmentation fault) |compiling lapack with |with -ftree-loop- |fortran 4.4.0-20060501 |distribution http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36110
[Bug middle-end/36110] ICE (segmentation fault) with -ftree-loop-distribution
--- Comment #2 from linuxl4 at sohu dot com 2008-05-02 15:56 --- ¡µThis GCC version does not make sense: 4.4.0-20060501. I assume you mean ¡µ20080501. yes. sorry for the wrong typing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36110
[Bug bootstrap/36108] [4.4 Regression]: revision 134865 breaks gcc bootstrap
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-02 16:02 --- See this is why I did not want this warning in the front-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build, diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #17 from bonzini at gnu dot org 2008-05-02 16:29 ---
I wonder if your patch would be a problem because it sometimes removes a CONST
wrapping. It could also be possible to precede the CONST_INT optimization with
another test for two adjacent CONSTANT_P:
if (GET_CODE (ops[n_ops - 1]) == CONST_INT)
i = n_ops - 2;
else
i = n_ops - 1;
if (i = 1
ops[i].neg
!ops[i - 1].neg
CONSTANT_P (ops[i].op)
GET_CODE (ops[i].op) == GET_CODE (ops[i - 1].op))
{
ops[i - 1].op = gen_rtx_MINUS (mode, ops[i - 1].op, ops[i].op);
ops[i - 1].op = gen_rtx_CONST (mode, ops[i - 1].op);
if (i n_ops - 1)
ops[i] = op[i + 1];
n_ops--;
}
Keeping together a (minus (symbol_ref) (symbol_ref)), which could also be a
(minus (label_ref (label_ref)), seems like a good idea.
Does this work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug fortran/36103] gfortran crash with zh_CN locale - error_print error ?
--- Comment #12 from burnus at gcc dot gnu dot org 2008-05-02 16:38 --- I'm not sure whether there are other problems, but at least the following is wrong. Maybe this is enough to fix the bug. Could someone check? I'll write the translation team to fix it there. msgid '%s' argument of '%s' intrinsic at %L must be less than rank %d msgstr %3$L#22788;#20869;#24314;#20989;#25968;%2$s#30340;#23454;#21442;%1$s#31209;#24517;#39035;#23567;#20110; %d The last item must be %4$d and not %d. (See POSIX standard for printf which mandates that either %n$f or %f has to be used, but no mixture between both.) This is wrong too: msgid Fortran 2003: %s specifier in %s statement at %C has value '%s' msgstr Fortran 2003#65306;%3$ #22788; %2$ #35821;#21477;#20013;#30340; %1$s #38480;#23450;#31526;#20540;#20026;%4$s The 's' and the 'C' are missing. msgid '%s' at %L is not a function msgstr %2L#22788;#30340;%1$s#19981;#26159;#19968;#20010;#20989;#25968; Here, a '$' is missing. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Summary|gfortran crash with zh_CN |gfortran crash with zh_CN |locale |locale - error_print error ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug libfortran/36094] Runtime error show_locus not working correctly
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-02 16:50 --- Fixed -- 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=36094
[Bug c/36111] New: GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
openmpi-1.2.6 -- cd openmpi-1.2.6 mkdir i95;cd i95;../configure --prefix=/usr/local/openmpi-1.2.6 make my $CFLAGS: -pipe -ggdb3 -limf -lsvml -O3 -march=pentium4 -mfpmath=sse -funswitch-loops -ftree-loop-distribution -ftree-loop-linear -ftree-loop-im -fivopts -funroll-loops -fvariable-expansion-in-unroller -fsplit-ivs-in-unroller -ftree-vectorize -ftree-vect-loop-version -fvect-cost-model -fgcse-sm -fgcse-las -fsched-spec-load -fsched-stalled-insns=0 -fsched-stalled-insns-dep=0 -fbounds-check when compile openmpi-1.2.6/opal/mca/memory/ptmalloc2/malloc.c - libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../../../opal/mca/memory/ptmalloc2 -DMALLOC_DEBUG=0 -D_GNU_SOURCE=1 -DUSE_TSD_DATA_HACK=1 -DMALLOC_HOOKS=1 -I../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread -I../../../../../opal/mca/memory/ptmalloc2/sysdeps/generic -I../../../../.. -I../../../.. -I../../../../../opal/include -I../../../../../orte/include -I../../../../../ompi/include -DNDEBUG -pipe -ggdb3 -limf -lsvml -O3 -march=pentium4 -mfpmath=sse -funswitch-loops -ftree-loop-distribution -ftree-loop-linear -ftree-loop-im -fivopts -funroll-loops -fvariable-expansion-in-unroller -fsplit-ivs-in-unroller -ftree-vectorize -ftree-vect-loop-version -fvect-cost-model -fgcse-sm -fgcse-las -fsched-spec-load -fsched-stalled-insns=0 -fsched-stalled-insns-dep=0 -fbounds-check -finline-functions -fno-strict-aliasing -pthread -MT malloc.lo -MD -MP -MF .deps/malloc.Tpo -c ../../../../../opal/mca/memory/ptmalloc2/malloc.c -fPIC -DPIC -o .libs/malloc.o ../../../../../opal/mca/memory/ptmalloc2/malloc.c: In function 'malloc_trim': ../../../../../opal/mca/memory/ptmalloc2/malloc.c:3902: error: invalid rtl sharing found in the insn (insn 11 9 12 3 ../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread/malloc-machine.h:51 (parallel [ (set (reg/v:SI 80 [ r ]) (asm_operands/v:SI (xchgl %0, %1) (=r) 0 [ (reg:SI 85) (mem/s/v/j/c:SI (plus:SI (reg:SI 3 bx) (const:SI (unspec:SI [ (symbol_ref:SI (main_arena) [flags 0x2] var_decl 0xb7e18898 main_arena) ] 1))) [0 main_arena.mutex.lock+0 S4 A256]) ] [ (asm_input:SI (0) 0) (asm_input:SI (m) 0) ] 2207718)) (set (mem/s/v/j/c:SI (plus:SI (reg:SI 3 bx) (const:SI (unspec:SI [ (symbol_ref:SI (main_arena) [flags 0x2] var_decl 0xb7e18898 main_arena) ] 1))) [0 main_arena.mutex.lock+0 S4 A256]) (asm_operands/v:SI (xchgl %0, %1) (=m) 1 [ (reg:SI 85) (mem/s/v/j/c:SI (plus:SI (reg:SI 3 bx) (const:SI (unspec:SI [ (symbol_ref:SI (main_arena) [flags 0x2] var_decl 0xb7e18898 main_arena) ] 1))) [0 main_arena.mutex.lock+0 S4 A256]) ] [ (asm_input:SI (0) 0) (asm_input:SI (m) 0) ] 2207718)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) (clobber (mem:BLK (scratch) [0 A8])) ]) -1 (expr_list:REG_DEAD (reg:SI 85) (expr_list:REG_UNUSED (reg:QI 18 fpsr) (expr_list:REG_UNUSED (reg:QI 17 flags) (nil) ../../../../../opal/mca/memory/ptmalloc2/malloc.c:3902: error: shared rtx (const:SI (unspec:SI [ (symbol_ref:SI (main_arena) [flags 0x2] var_decl 0xb7e18898 main_arena) ] 1)) ../../../../../opal/mca/memory/ptmalloc2/malloc.c:3902: internal compiler error: internal consistency failure Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [malloc.lo] Error 1 -- Summary: GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug fortran/36103] gfortran crash with zh_CN locale - error_print error ?
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2008-05-02 17:34 --- GCC translation bug reports are taken care of by the translation project (http://translationproject.org/). I have sent a mail to the chinese team coordinator (LI Daobing) and GCC translation maintainer (Meng Jie); their email addresses are on the chinese team webpage (http://translationproject.org/team/zh_CN.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #18 from dje at gcc dot gnu dot org 2008-05-02 17:36 ---
Yes, the patch works, modulo typos.
if (GET_CODE (ops[n_ops - 1].op) == CONST_INT)
i = n_ops - 2;
else
i = n_ops - 1;
if (i = 1
ops[i].neg
!ops[i - 1].neg
CONSTANT_P (ops[i].op)
GET_CODE (ops[i].op) == GET_CODE (ops[i - 1].op))
{
ops[i - 1].op = gen_rtx_MINUS (mode, ops[i - 1].op, ops[i].op);
ops[i - 1].op = gen_rtx_CONST (mode, ops[i - 1].op);
if (i n_ops - 1)
ops[i] = ops[i + 1];
n_ops--;
}
plus_constant strips the inner CONST and the earlier version also wrapped
everything in CONST.
Does it make sense to group any two RTX_CONST_OBJ together of not the same
type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug middle-end/36110] ICE (segmentation fault) with -ftree-loop-distribution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-02 18:47:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36110
[Bug inline-asm/36111] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-02 18:48 --- Please attach pre-processed source of the offending source file which you can obtain by appending -save-temps on the gcc command-line. The pre-processed file will be named $FILE.i. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
[Bug inline-asm/36092] [4.4 Regression] invalid rtl sharing found in the insn
--- Comment #4 from ubizjak at gmail dot com 2008-05-02 18:48 --- This doesn't fail for me when compiling preprocessed file with (please note -m32 compile flag on 64bit host): ~/gcc-build-fast/gcc/cc1 -m32 -march=pentium -mno-tls-direct-seg-refs pr36092.i -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -quiet -Wstrict-prototypes where ~/gcc-build-fast/gcc/cc1 --version GNU C (GCC) version 4.4.0 20080502 (experimental) [trunk revision 134885] (x86_64-unknown-linux-gnu) configured with: --enable-checking=all Can you try latest SVN version of 4.4 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36092
[Bug fortran/36103] gfortran crash with zh_CN locale - error_print error ?
--- Comment #14 from lidaobing at gmail dot com 2008-05-02 18:50 --- an updated zh_CN.po uploaded to TP[1], please help check whether it can fix this bug. PS. in emacs's po-mode, po-validate does not warning in this case, any script to check this po file? thanks. [1] http://translationproject.org/PO-files/zh_CN/gcc-4.3.0.zh_CN.po -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36103
[Bug fortran/36112] New: Bounds-checking on character length not working for array-constructors
Bounds-checking for correct character length in array-constructors without F2003 typespec (all strings are required to have the same length) does not work sometimes, for instance the code call test (this is long) contains subroutine test(s) character(len=*) :: s character(len=128) :: arr(2) arr = (/ s, abc /) end subroutine test end Should give a runtime-error when compiled with -fbounds-check and run but it doesn't; swapping the array constructor to be arr = (/ abc, s /) does, however (which is presumably correct). -- Summary: Bounds-checking on character length not working for array-constructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36112
[Bug c/36113] New: fix C enumerators
For compatibility with C++ and more reasonable GNU semantics, would we place
make the below program not print 0. Essentially, the type of all the
enumerators should be the underlying type of the enum, not the type that fits
the init.
#include stdio.h
#include stdint.h
#include stdlib.h
#include inttypes.h
int main(void) {
enum {
dummy = (1ULL63),
SomeConstant = 0x1
} MyEnum;
#define MY_MACRO(value) ((value) 60)
printf(MY_MACRO(SomeConstant) == 0x%llx.\n, MY_MACRO(SomeConstant));
return 0;
}
--
Summary: fix C enumerators
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug c/36113] fix C enumerators
--- Comment #1 from mrs at apple dot com 2008-05-02 20:16 --- Radar 5881867 -- mrs at apple dot com changed: What|Removed |Added CC||mrs at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug c/36113] fix C enumerators
-- mrs at apple dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #19 from bonzini at gnu dot org 2008-05-02 21:08 --- Subject: Re: [4.3/4.4 Regression] ppc64 cacoshl miscompilation Yes, the patch works, modulo typos. It was not tested indeed. Does it make sense to group any two RTX_CONST_OBJ together of not the same type? I don't know, but replacing the second test with CONSTANT_P should also be safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #20 from dje at gcc dot gnu dot org 2008-05-02 21:23 --- How do we proceed? Your initial patch is fine with me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug bootstrap/36108] [4.4 Regression]: revision 134865 breaks gcc bootstrap
--- Comment #5 from hjl dot tools at gmail dot com 2008-05-02 21:35 --- Fixed by revision 134889. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36108
[Bug c++/33911] attribute deprecated vs. templates
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-02 21:41:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
[Bug c++/33979] support for char16_t, char32_t
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979
[Bug c++/34939] [4.1/4.2 regression] ICE with friend and attribute weak
--- Comment #3 from jason at gcc dot gnu dot org 2008-05-02 21:44 --- *** This bug has been marked as a duplicate of 34937 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34939
[Bug c++/34937] [4.1/4.2 regression] ICE with attribute weak
--- Comment #4 from jason at gcc dot gnu dot org 2008-05-02 21:44 --- *** Bug 34939 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34937
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #6 from hubicka at ucw dot cz 2008-05-02 21:44 --- Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0 Just for record, I am still testing the patch. The testing scripts I used broke in a way that they ended up testing empty patches (this is obviously why the original patch passed at first place ;), so I had to start over. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #7 from hjl dot tools at gmail dot com 2008-05-02 21:49 --- FYI, revision 134889 has following regressions on Linux/ia32: FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ;; Function 2 FAIL: gcc.c-torture/execute/va-arg-pack-1.c compilation, -O0 FAIL: gcc.dg/attr-alwaysinline.c scan-assembler-not sabrina FAIL: gcc.dg/winline-4.c (test for warnings, line 4) FAIL: gcc.dg/winline-4.c (test for warnings, line 7) FAIL: gcc.dg/torture/nested-fn-1.c -O0 scan-assembler-not should_not_appear FAIL: gcc.target/i386/20060512-1.c (test for excess errors) FAIL: gcc.target/i386/20060512-3.c (test for excess errors) I think they are all related to revision 134859. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug tree-optimization/36100] [4.4 Regression] always_inline attribute is broken at -O0
--- Comment #8 from hubicka at ucw dot cz 2008-05-02 21:59 --- Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0 FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ;; Function 2 FAIL: gcc.c-torture/execute/va-arg-pack-1.c compilation, -O0 FAIL: gcc.dg/attr-alwaysinline.c scan-assembler-not sabrina FAIL: gcc.dg/winline-4.c (test for warnings, line 4) FAIL: gcc.dg/winline-4.c (test for warnings, line 7) FAIL: gcc.dg/torture/nested-fn-1.c -O0 scan-assembler-not should_not_appear FAIL: gcc.target/i386/20060512-1.c (test for excess errors) FAIL: gcc.target/i386/20060512-3.c (test for excess errors) All C failures I get with the patch applied are the following: FAIL: gcc.c-torture/compile/packed-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O0 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O1 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O2 (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/builtin-math-4.c -Os (test for excess errors) FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE So hopefully all of those are fixed now. I will look into pr30965.C now. My apologizes for the breakage. Testing empty patches is obviously easy job :( Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36100
[Bug fortran/36114] New: [4.4 Regression] f951: internal compiler error: Bus error due to revision 134867
The following codes from pr29921 and pr35770:
ibook-dhum] f90/bug% cat pr29921.f90
! { dg-do compile }
SUBROUTINE foo
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
LOGICAL MASWRK
COMMON /FRAME / W1,W2,W3
COMMON /FRAMES/ X1,Y1,Z1,X2,Y2,Z2,X3,Y3,Z3
PARAMETER (ZERO=0.0D+00, ONE=1.0D+00)
IF (IGROUP .EQ. 1) GO TO 600
IF (IGROUP .EQ. 2) GO TO 620
600 NT = 1
620 CONTINUE
IF (RHO .GT. TOL) THEN
Y3 = RFIND('Y3 ',IERR)
IF(IERR.NE.0) CALL ABRT
Z3 = RFIND('Z3 ',IERR)
IF(IERR.NE.0) CALL ABRT
IF (MASWRK) WRITE (IP,9048) X3,Y3,Z3
ELSE
X1 = ZERO
Y1 = ZERO
Z1 = ZERO
Z3 = ZERO
X2 = ONE
Y3 = ONE
END IF
W2 = (Z2-Z1)*(X3-X1)-(Z3-Z1)*(X2-X1)
9048 FORMAT(9F10.5)
END
[ibook-dhum] f90/bug% cat pr35770.f90
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]
!maybe also see 34784?
implicit character (s) ! removing this fixes the problem
REAL RDA(10)
RDA = 0
RDA(J1) = S_REAL_SQRT_I(RDA(J1))
CONTAINS
ELEMENTAL FUNCTION S_REAL_SQRT_I(X) RESULT (R)
REAL, INTENT(IN) :: X
REAL :: R
R = 0.0
END FUNCTION S_REAL_SQRT_I !internal procedure
END
gives f951: internal compiler error: Bus error after revision 134867. The bus
errors disappear if I revert the revision, while pr35770 gives:
RDA(J1) = S_REAL_SQRT_I(RDA(J1))
1
Error: Can't convert CHARACTER(1) to REAL(4) at (1)
--
Summary: [4.4 Regression] f951: internal compiler error: Bus
error due to revision 134867
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: *-apple-darwin9
GCC host triplet: *-apple-darwin9
GCC target triplet: *-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36114
[Bug c++/36115] New: wrong code generated with optimization on x86-64
This small program:
// built using g++ -o test -O2 main.cpp
#include iostream
struct stuff
{
int x;
};
class MyException : public std::exception
{
public:
MyException() { }
};
// make this global so conditional below doesn't get eliminated
bool should_throw = false;
void calc_x(stuff s, int n)
{
// set s.x to max(s.x, n, 2)
s.x = std::max(n, s.x);
s.x = std::max(2, s.x);
// bogus throw needed to generate error
if(should_throw)
{
// throw MyException() won't trigger bug - must be separate lines
// also, something like std::runtime_error won't trigger either
MyException ex;
throw ex;
}
}
int main(int argc, char* argv[])
{
stuff s = { 0 };
int n = atoi(argv[1]);
calc_x(s, n);
std::cout s.x \n;
std::cout (s.x == n ? SUCCESS : FAILURE) \n;
}
will fail when passed any value greater than 2.
calc_x should be returning the maximum of s.x, n and 2, but for values of n
2, always returns the original value of s.x.
Output:
-
% ./test 0
2
% ./test 1
2
% ./test 2
2
% ./test 3
0
I've attempted to distill it to a smaller example than this, but eliminating
almost anything causes it to start functioning again.
Looking at the generated assembly, gcc is generating two conditional moves,
corresponding to the two std::max calls. In the bad code, the final move is
moving the address of s.x into a register, which then gets dereferenced and
assigned into s.x. However, the intermediate result of the first comparison was
not stored in s.x, but a scratch temporary on the stack. Therefore, s.x is
being dereferenced and assigned to itself.
movl%esi, 12(%rsp) --- tmp1 = n
cmpl(%rdi), %esi --- compare s.x and n
leaq12(%rsp), %rax --- rax = tmp1
cmovl %rdi, %rax --- rax = s if n s.x
movl(%rax), %edx --- edx = *rax
leaq28(%rsp), %rax --- rax = tmp2
movl$2, 28(%rsp) --- tmp2 = 2
cmpl$2, %edx
cmovg %rdi, %rax --- rax = s.x (!!!) if edx 2
cmpb$0, should_throw(%rip)
movl(%rax), %eax --- eax = *rax
movl%eax, (%rdi) --- s.x = eax
This is using gcc 4.2.3 as distributed with Ubuntu 8.04, however I've also
verified the same results using an unpatched gcc 4.2.3, as well as the latest
gcc-4_2-branch branch from subversion.
Thanks,
Brett Polivka
% g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
--
Summary: wrong code generated with optimization on x86-64
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brett dot polivka at magnetar dot com
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=36115
[Bug c++/36115] wrong code generated with optimization on x86-64
--- Comment #1 from brett dot polivka at magnetar dot com 2008-05-02 22:31 --- Created an attachment (id=15563) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15563action=view) preprocessed output of test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36115
[Bug c++/36115] wrong code generated with optimization on x86-64
-- brett dot polivka at magnetar dot com changed: What|Removed |Added Severity|normal |major Known to fail||4.2.3 Known to work||4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36115
[Bug target/36115] wrong code generated with optimization on x86-64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36115
[Bug target/36115] wrong code generated with optimization on x86-64
--- Comment #2 from brett dot polivka at magnetar dot com 2008-05-02 22:37 --- Created an attachment (id=15564) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15564action=view) preprocessed output of test program Previous version was from wrong code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36115
[Bug rtl-optimization/23490] [4.0 Regression] Long compile time for array initializer with inlined constructor
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-05-03 00:09 --- hehe: tree DSE : 4.79 (14%) usr 0.05 ( 6%) sys 5.11 (14%) wall 2 kB ( 0%) ggc tree PRE : 9.79 (29%) usr 0.12 (14%) sys 10.32 (29%) wall 2016 kB ( 1%) ggc tree FRE : 9.68 (29%) usr 0.10 (12%) sys 10.09 (28%) wall 112 kB ( 0%) ggc Note this is with checking enabled so they might not be good numbers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23490
[Bug middle-end/35305] Speculative PRE support missing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35305
[Bug tree-optimization/36116] New: ICE with -O2 -ftree-loop-distribution -funsafe-loop-optimizations -m32
When the attached example is compiled by the gcc version 4.4.0 20080430 (experimental) (GCC) using gcc -O2 -ftree-loop-distribution -funsafe-loop-optimizations -m32 -c png2theora.c.c -o x.o it produces the following error: png2theora.c: In function 'main': png2theora.c:405: 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. -- Summary: ICE with -O2 -ftree-loop-distribution -funsafe-loop- optimizations -m32 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin dot drab at fjfi dot cvut dot cz GCC build triplet: x86_64-pc-linux-gnu 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=36116
[Bug tree-optimization/36116] ICE with -O2 -ftree-loop-distribution -funsafe-loop-optimizations -m32
--- Comment #1 from martin dot drab at fjfi dot cvut dot cz 2008-05-03 02:27 --- Created an attachment (id=15565) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15565action=view) Triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36116
[Bug inline-asm/36111] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.
--- Comment #2 from linuxl4 at sohu dot com 2008-05-03 04:09 --- Created an attachment (id=15566) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15566action=view) malloc.i ok.please see the attachment file. cd openmpi-1.2.6/i95/opal/mca/memory/ptmalloc2/ gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -I../../../../orte/include -I../../../../ompi/include -I../../../../../opal/mca/memory/ptmalloc2 -DMALLOC_DEBUG=0 -D_GNU_SOURCE=1 -DUSE_TSD_DATA_HACK=1 -DMALLOC_HOOKS=1 -I../../../../../opal/mca/memory/ptmalloc2/sysdeps/pthread -I../../../../../opal/mca/memory/ptmalloc2/sysdeps/generic -I../../../../.. -I../../../.. -I../../../../../opal/include -I../../../../../orte/include -I../../../../../ompi/include -DNDEBUG -pipe -ggdb3 -limf -lsvml -O3 -march=pentium4 -mfpmath=sse -funswitch-loops -ftree-loop-distribution -ftree-loop-linear -ftree-loop-im -fivopts -funroll-loops -fvariable-expansion-in-unroller -fsplit-ivs-in-unroller -ftree-vectorize -ftree-vect-loop-version -fvect-cost-model -fgcse-sm -fgcse-las -fsched-spec-load -fsched-stalled-insns=0 -fsched-stalled-insns-dep=0 -fbounds-check -finline-functions -fno-strict-aliasing -pthread -MT malloc.lo -MD -MP -MF .deps/malloc.Tpo -c ../../../../../opal/mca/memory/ptmalloc2/malloc.c -fPIC -DPIC -o .libs/malloc.o -save-temps same error ocered when compile glibc 2.7's malloc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36111
