HIRLAM with -ftree-loop-distribution.
Sebastian, Here are, in addition, the numbers for compiling and running HIRLAM with -ftree-loop-distribution (after applying your patch, obviously). There something weird going on with the count of the loops not vectorized - every successfully vectorized loop gets an additional message: note: not vectorized: vectorization may not beprofitable. which rather defeats the purpose of the not vectorized messages. In short, almost 1900 more loops are vectorized, but that's of course certainly due to the fact that loop distribution *makes* more loops. In run time it has little (but positive) effect. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003 Baseline, no source changes: Mon Dec 10 17:45:19 UTC 2007 (revision 130746) Compilation flags: CCFLAGS := -g -O3 $(MACHINECPP) -ffast-math -fno-associative-math -march=native -mtune=native -ftree-vectorizer-verbose=2 FCFLAGS := -g -O3 -fbacktrace -ffpe-trap=invalid,zero,overflow -ffast-math -fno-associative-math -march=native -mtune=native -ftree-vectorizer-verbose=2 Loops vectorized: 5675 Loops not vectorized: 13705 Timings: 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK12.7488 SECONDS 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK 2445.9609 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 259.3362 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK12.4408 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 305.9351 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 262.1124 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK12.7448 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 2323.3733 SECONDS 20061201_12r/HL_Cycle_2006120112r.html: FORECAST TOOK 412.7058 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 264.5685 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK12.6648 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 306.7352 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 261.5164 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK12.7688 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 2325.3774 SECONDS 20061202_00r/HL_Cycle_2006120200r.html: FORECAST TOOK 413.8739 SECONDS Baseline, no source changes, with -ftree-loop-linear: Mon Dec 10 17:45:19 UTC 2007 (revision 130746) Compilation flags: CCFLAGS := -g -O3 $(MACHINECPP) -ftree-loop-linear -ffast-math -fno-associative-math -march=native -mtune=native -ftree-vectorizer-verbose=2 FCFLAGS := -g -O3 -ftree-loop-linear -fbacktrace -ffpe-trap=invalid,zero,overflow -ffast-math -fno-associative-math -march=native -mtune=native -ftree-vectorizer-verbose=2 This compilation got one ICE: rttov_aitosu.f90: In function 'rttov_aitosu': rttov_aitosu.f90:4: error: definition in block 262 does not dominate use in block 134 for SSA_NAME: pretmp.240_59 in statement: prephitmp.220_58 = PHI pretmp.240_59(134), D.1480_1373(138) PHI argument pretmp.240_59 for PHI node prephitmp.220_58 = PHI pretmp.240_59(134), D.1480_1373(138) rttov_aitosu.f90:4: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Worked around by compiling this file without -ftree-loop-linear Loops vectorized: 5671 Loops not vectorized: 13655 Timings: 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK12.5648 SECONDS 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK 2444.1208 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 259.3402 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK12.4728 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 307.8672 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 260.0323 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK12.8608 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 2310.2485 SECONDS 20061201_12r/HL_Cycle_2006120112r.html: FORECAST TOOK 411.3977 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 261.1283 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK12.7248 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 308.1313 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 262.7564 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK12.6528 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 2336.5620 SECONDS 20061202_00r/HL_Cycle_2006120200r.html: FORECAST TOOK 410.6577 SECONDS Baseline, with -ftree-loop-distribution changes: Mon Dec 10 17:45:19 UTC 2007 (revision 130746M) Compilation flags: CCFLAGS := -g -O3 $(MACHINECPP) -ftree-loop-distribution -ffast-math -fno-associative-math -march=native -mtune=native
Re: HIRLAM with -ftree-loop-distribution.
Hello! There something weird going on with the count of the loops not vectorized - every successfully vectorized loop gets an additional message: note: not vectorized: vectorization may not beprofitable. This is due to switching on vector cost model by default for x86. BTW: Attached patch fixed the message by adding the space between be and profitable.. Patch was commited to SVN after bootstrappnig on x86_64. 2007-12-16 Uros Bizjak [EMAIL PROTECTED] * tree-vect-transform.c (conservative_cost_threshold): Add missing space to not vectorized message. Uros. Index: tree-vect-transform.c === --- tree-vect-transform.c (revision 130987) +++ tree-vect-transform.c (working copy) @@ -6552,7 +6552,7 @@ th = (unsigned) min_profitable_iters; if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS)) -fprintf (vect_dump, not vectorized: vectorization may not be +fprintf (vect_dump, not vectorized: vectorization may not be profitable.); if (th vect_print_dump_info (REPORT_DETAILS))
Re: Designs for better debug info in GCC
On Dec 16, 2007, Daniel Berlin [EMAIL PROTECTED] wrote: There is no portion of the DWARF3 spec which requires you output information that is correct or useful. The same way the C standard does not require you to write correct programs, only valid ones, the DWARF3 spec does not require you to output correct information, only information that is encoded properly. But if a C compiler translated programs to garbage, that would be wrong. By the same reasoning, if a Dwarf producer created garbage, that would be wrong. It's true that most of Dwarf 3 attributes are optional. But when it says if you output this attribute, its operand must be such and such, if you output the attribute with operands that don't match the specification, that's a bug. It is certainly a goal of DWARF3 to allow producers to provide correct info Exactly. And where's the permission to provide incorrect info, rather than merely leaving it out? I've heard this intrusiveness argument be pointed out so many times, by so many people that claim to not have been able to keep up with the thread, and who claim to have not looked at the patches at all, that I'm more and more convinced it's just fear of the unknown than any actual rational evaluation of the impact of the changes. Well, no. You yourself have shown it to be intrusiveness in the extreme, in the very next paragraphs! At some point you have to face reality and see that such information isn't kept around by magic, it takes some effort, and this effort is needed at every location where there are changes that might affect debug information. And that's pretty much everywhere. So, everywhere needs to change. That's pretty intrusiveness, no? No. Looks like selective attention, because you're reasoning out the part in which I discussed using the strength of the optimizers against the problem, by letting them do what they are already used to on the debug information too. If we add a new RTL code or a new TREE code, is that intrusive because now every optimization pass will deal with the new node types in very much the same way they've dealt with other similar node types forever? Of course not. And if we have to add a few exceptions here and there to deal with the specifics of this new node type, does that become too intrusive then? I don't think so. Then what's the fuss about the new node types? Do you want to count the number of places in which INSN_P remains there, lexically unchanged, and compare with the number of places in which I've added a !DEBUG_INSN_P after it? Having to stop and think at every point in an optimization about the debug info, Well, sorry, writing compilers is hard. You have to think about several things at the same time. Shall we just go shopping instead? I'm trying to make it as simple as possible. The fact that nearly 100% of the code is unchanged seems to indicate to me that it's not such a bad an approach, but if you want something that just magically works, you're up for much disappointment. (having to stop and think about debug info at every single point of every single optimization). Information doesn't come out of thin air, and thin air doesn't maintain information accurate just because we wish it does. We have to work to create and update the information throughout compilation, at every transformation, and my reasoning is precisely that optimizers already do this all the time, so why not use them for what we need? You don't need to be this intrusiveness to stop outputting the incorrect info we do. What do you have to back your statement up? Let me help you: sure we don't. We can just refrain from outputting any debug information whatsoever. Then, it will be compliant with the standard. But it won't be useful. I've never seen this documented as such, and we've never worked toward these stated goals. Who is we? I certainly have worked exactly towards these goals. As have almost all the authors of the current debugging info framework. Oh, wow, I guess I just wasn't welcome into the club, because I didn't get the guidelines book. How unfortunate, now I have to give up my plan of doing better and abide by the unpublished and undocumented goals of some small cabal. Or do I? If you look in the mailing list archives, you will even discover Diego is not the first one have exactly the viewpoint about what should and should not be debuggable, and that the community has consistenly worked towards exactly the viewpoint diego describes. I've seen several different viewpoints from the community. Anyway, I give up on reading this thread. It has turned into a mess. You really need to step back Oh, do I? Why is that? and see that you have not achieved any sort of consensus of what levels of optimization should be how debuggable, Why would I expect to get any consensus on that? I haven't even tried, and I won't. This is not what the issue is about. The issue is about not emitting incorrect
Re: Rant about ChangeLog entries and commit messages
On Dec 16, 2007, NightStrike [EMAIL PROTECTED] wrote: On 12/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: ... a good example of compliance with the GPL: 5. Conveying Modified Source Versions. a) The work must carry prominent notices stating that you modified it, and giving a relevant date. Maybe Changelogs should be reserved for important changes. For instance, something like Fixed a typo is a complete waste. I doubt anyone looks ta a Changelog to see if someone fixed a typo recently or at any point in the past. I've done that, while backporting patches. Oftentimes there are small fixes on top of larger patches, and you want to credit those who made the small fixes, and you want to be sure you caught them next time you look at the patch. ChangeLogs for these are useful for this purpose. Perhaps there could be some criteria so that not every single iota gets a log entry. How would leaving changes out comply with 5a above? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: HIRLAM with -ftree-loop-distribution.
Uros Bizjak wrote: note: not vectorized: vectorization may not beprofitable. This is due to switching on vector cost model by default for x86. Ah, but my hidden critique of the message was: -ftree-vectorizer-verbose=2 should *only* tell us: 1. Which loops are vectorized. 2. Which are not - and why (in a single sentence). For more detailed logging, one should use -ftree-vectorizer-verbose=n with n2, IMNSHO. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
libgfortran, libgomp not compiled with BOOT_CFLAGS.
L.S., Recently, I've begun to bootstrap with make BOOT_CFLAGS=flags, basically to get the run time libraries (libgfortran, libgomp) compiled with -mcpu=native -mtune=native (the speed of the compiler doesn't interest me that much). However, I see that almost everything is compiled with -mcpu=native -mtune=native, *except* the run time libraries ... Is that because they're target libraries - if so, how would one get them compiled optimally if not building a cross-compiler ? Thanks in advance for any insight. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: HIRLAM with -ftree-loop-distribution.
Uros Bizjak wrote: note: not vectorized: vectorization may not beprofitable. This is due to switching on vector cost model by default for x86. Ah, but my hidden critique of the message was: -ftree-vectorizer-verbose=2 should *only* tell us: 1. Which loops are vectorized. 2. Which are not - and why (in a single sentence). For more detailed logging, one should use -ftree-vectorizer-verbose=n with n2, IMNSHO. yes, you are right. this printing should be either removed (as it's anyhow already being printed also under REPORT_DETAILS), or we may want to add a new verbosity level (lower than REPORT_DETAILS) for cost-model info (REPORT_COST). dorit Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: HIRLAM and -ftree-loop-linear
Sebastian Pop wrote: I wrote: rttov_aitosu.f90: In function 'rttov_aitosu': rttov_aitosu.f90:4: error: definition in block 262 does not dominate use in block 134 Worked around by compiling this file without -ftree-loop-linear Could you verify that the attached patch fixes also this problem? Unfortunately, it doesn't; I get exactly the same error message as before. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
RE: Help with another constraint
On Wed, 12 Dec 2007, Dave Korn wrote: On 12 December 2007 12:14, Revital1 Eres wrote: It seems that the pair m and I is missing (which indicate the memory = constant instruction). So doesn't the question then become Why isn't reload reloading the constant into a register? Yes. And the answer AFAIK is because it doesn't see a way to move a constant into a register; it understands r, not p and q. So bviyer, add an r alternative. See also the * and # qualifiers. No need for bogus 0 -to- memory alternatives. brgds, H-P
Re: HIRLAM and -ftree-loop-linear
Sebastian, Here are (attached) results for testing HIRLAM with and without -ftree-loop-linear. As you can see, the results are neutral: 4 loops fewer vectorized, but about 50 fewer recognized. any chance you kept the dumps and can report which loops were not vectorized/recognized with -ftree-loop-linear (so we could see if these represent missed vectorization opportunities?) thanks, dorit Now I like to redo that test with -ftree-loop-distribution. Can you send me a patch against the trunk (otherwise it won't be a fair comparison). Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003 Baseline, no source changes: Mon Dec 10 17:45:19 UTC 2007 (revision 130746) Compilation flags: CCFLAGS := -g -O3 $(MACHINECPP) -ffast-math -fno-associative-math - march=native -mtune=native -ftree-vectorizer-verbose=2 FCFLAGS := -g -O3 -fbacktrace -ffpe-trap=invalid,zero,overflow - ffast-math -fno-associative-math -march=native -mtune=native -ftree- vectorizer-verbose=2 Loops vectorized: 5675 Loops not vectorized: 13705 Timings: 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK12.7488 SECONDS 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK 2445.9609 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 259.3362 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK12.4408 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 305.9351 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 262.1124 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK12.7448 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 2323.3733 SECONDS 20061201_12r/HL_Cycle_2006120112r.html: FORECAST TOOK 412.7058 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 264.5685 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK12.6648 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 306.7352 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 261.5164 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK12.7688 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 2325.3774 SECONDS 20061202_00r/HL_Cycle_2006120200r.html: FORECAST TOOK 413.8739 SECONDS Baseline, no source changes, with -ftree-loop-linear: Mon Dec 10 17:45:19 UTC 2007 (revision 130746) Compilation flags: CCFLAGS := -g -O3 $(MACHINECPP) -ftree-loop-linear -ffast-math -fno- associative-math -march=native -mtune=native -ftree-vectorizer-verbose=2 FCFLAGS := -g -O3 -ftree-loop-linear -fbacktrace -ffpe-trap=invalid, zero,overflow -ffast-math -fno-associative-math -march=native - mtune=native -ftree-vectorizer-verbose=2 This compilation got one ICE: rttov_aitosu.f90: In function 'rttov_aitosu': rttov_aitosu.f90:4: error: definition in block 262 does not dominate use in block 134 for SSA_NAME: pretmp.240_59 in statement: prephitmp.220_58 = PHI pretmp.240_59(134), D.1480_1373(138) PHI argument pretmp.240_59 for PHI node prephitmp.220_58 = PHI pretmp.240_59(134), D.1480_1373(138) rttov_aitosu.f90:4: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Worked around by compiling this file without -ftree-loop-linear Loops vectorized: 5671 Loops not vectorized: 13655 Timings: 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK12.5648 SECONDS 20061201_00/HL_Cycle_2006120100.html: FORECAST TOOK 2444.1208 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 259.3402 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK12.4728 SECONDS 20061201_06/HL_Cycle_2006120106.html: FORECAST TOOK 307.8672 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 260.0323 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK12.8608 SECONDS 20061201_12/HL_Cycle_2006120112.html: FORECAST TOOK 2310.2485 SECONDS 20061201_12r/HL_Cycle_2006120112r.html: FORECAST TOOK 411.3977 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 261.1283 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK12.7248 SECONDS 20061201_18/HL_Cycle_2006120118.html: FORECAST TOOK 308.1313 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 262.7564 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK12.6528 SECONDS 20061202_00/HL_Cycle_2006120200.html: FORECAST TOOK 2336.5620 SECONDS 20061202_00r/HL_Cycle_2006120200r.html: FORECAST TOOK 410.6577 SECONDS
Re: HIRLAM with -ftree-loop-distribution.
Here's a tentative patch to do that:
- removes the confusing printing not vectorized: vectorization may not be
profitable from REPORT_UNVECTORIZED_LOOPS
- instead print vectorization may not be profitable under a new verbosity
level REPORT_COST
- change (hopefully all) other cost-model printings to be printed under
REPORT_COST
I'll test it later this week. I assume this kind of thing is an ok stage 3
material (it's a regression fix cause this confusion in the dump reports
was introduced with the cost model patches during 4.3)
dorit
--- tree-vect-transform.c 2007-12-16 14:09:20.0 +0200
+++ tree-vect-transform.cost_verbose.c 2007-12-16 16:07:09.0 +0200
@@ -134,7 +134,7 @@
/* Cost model disabled. */
if (!flag_vect_cost_model)
{
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model disabled.);:
return 0;
}
@@ -153,7 +153,7 @@
/* FIXME: Make cost depend on complexity of individual check. */
vec_outside_cost +=
VEC_length (tree, LOOP_VINFO_MAY_MISALIGN_STMTS (loop_vinfo));
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model: Adding cost of checks for loop
versioning to treat misalignment.\n);
}
@@ -163,7 +163,7 @@
/* FIXME: Make cost depend on complexity of individual check. */
vec_outside_cost +=
VEC_length (ddr_p, LOOP_VINFO_MAY_ALIAS_DDRS (loop_vinfo));.
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model: Adding cost of checks for loop
versioning aliasing.\n);
}
@@ -224,14 +224,14 @@
if (byte_misalign 0)
{
peel_iters_prologue = vf/2;
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model:
prologue peel iters set to vf/2.);
/* If peeling for alignment is unknown, loop bound of main loop
becomes
unknown. */
peel_iters_epilogue = vf/2;
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model:
epilogue peel iters set to vf/2 because
peeling for alignment is unknown .);
@@ -261,7 +261,7 @@
if (!LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo))
{
peel_iters_epilogue = vf/2;
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model:
epilogue peel iters set to vf/2 because
loop iterations are unknown .);
@@ -391,7 +391,7 @@
/* vector version will never be profitable. */
else
{
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, cost model: vector iteration cost = %d
is divisible by scalar iteration cost = %d by a factor
greater than or equal to the vectorization factor =
%d .,
@@ -399,7 +399,7 @@
return -1;
}
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
{
fprintf (vect_dump, Cost model analysis: \n);
fprintf (vect_dump, Vector inside of loop cost: %d\n,
@@ -425,7 +425,7 @@
then skip the vectorized loop. */
min_profitable_iters--;
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, Profitability threshold = %d\n,
min_profitable_iters);
@@ -465,7 +465,7 @@
vectype = get_vectype_for_scalar_type (TREE_TYPE (reduction_op));
if (!vectype)
{
- if (vect_print_dump_info (REPORT_DETAILS))
+ if (vect_print_dump_info (REPORT_COST))
{
fprintf (vect_dump, unsupported data-type );
print_generic_expr (vect_dump, TREE_TYPE (reduction_op),
TDF_SLIM);
@@ -520,7 +520,7 @@
STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info) = outer_cost;
- if (vect_print_dump_info (REPORT_DETAILS)))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, vect_model_reduction_cost: inside_cost = %d,
outside_cost = %d ., STMT_VINFO_INSIDE_OF_LOOP_COST
(stmt_info),
STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info));
@@ -541,7 +541,7 @@
/* prologue cost for vec_init and vec_step. */
STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info) = 2 *
TARG_SCALAR_TO_VEC_COST;
- if (vect_print_dump_info (REPORT_DETAILS)))
+ if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, vect_model_induction_cost: inside_cost = %d,
outside_cost = %d ., STMT_VINFO_INSIDE_OF_LOOP_COST
(stmt_info),
STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info));
@@ -570,7 +570,7 @@
Re: porting gcc to tic54x
On Wed, 12 Dec 2007, a2220333 wrote: hi, I have been porting tic54x to gcc. I use gcc-4.2.2 version. I write some simplest c54x.h and c54x.c and a empty md, and I I think the answer is right there ^^ compile it to generate the tic54x-gcc compiler. But when I execute the compiler I generate I got a segmentation fault error. Is there anything must be define in c54x.c or c54x.h that could make the simplest compiler with no correct output and no errors? Because I want to add functions from this basic port. If that wasn't the bug, I suggest you start up gdb and step through cc1, but I'd be surprised if you get anywhere without the prerequisite move, add, and control flow insns in the .md. brgds, H-P
Re: HIRLAM and -ftree-loop-linear
Dorit Nuzman wrote: any chance you kept the dumps and can report which loops were not vectorized/recognized with -ftree-loop-linear (so we could see if these represent missed vectorization opportunities?) I haven't, but it wouldn't be too much effort do this. I'll try stage 1 tonight - i.e., to establish a base (with the latest trunk check-out, not using -ftree-loop-linear), and then subsequently using that flag. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
RE: Help with another constraint
On Sun, 16 Dec 2007, Hans-Peter Nilsson wrote: On Wed, 12 Dec 2007, Dave Korn wrote: On 12 December 2007 12:14, Revital1 Eres wrote: It seems that the pair m and I is missing (which indicate the memory = constant instruction). So doesn't the question then become Why isn't reload reloading the constant into a register? Yes. And the answer AFAIK is because it doesn't see a way to move a constant into a register; it understands r, not p and q. I think I have to correct myself; register allocation and reload *should* understand p and q as register constraints, given e.g. a correct REG_CLASS_FROM_LETTER definition and correct regclass macros. The latter were not disclosed and are usually a source of hard-to-find errors. Besides, if you can't directly move between p and q (as your constraints indicate) then as Rask says, you also need to tell GCC through the secondary-reload mechanisms. I can't help but thinking the best suggetion is for bviyer to let gdb answer the question by stepping through cc1 instead of relying on indirect debugging. That's what people do. ;) brgds, H-P
Re: HIRLAM with -ftree-loop-distribution.
On Dec 16, 2007 4:24 AM, Toon Moene [EMAIL PROTECTED] wrote: Here are, in addition, the numbers for compiling and running HIRLAM with -ftree-loop-distribution (after applying your patch, obviously). In short, almost 1900 more loops are vectorized, but that's of course certainly due to the fact that loop distribution *makes* more loops. In run time it has little (but positive) effect. Wow! Thanks for the numbers. I guess from your message that there were no ICEs or other problems with the loop distribution patch. Mark, is the loop distribution patch okay for trunk? Thanks, Sebastian -- AMD - GNU Tools
Problem with SSA inlining and default defs
Hi, How SSA inlining and default defs for uninitialized variables are supposed to interact? Suppose you have the following situation BB0 ... | \ (ab) |BB1 s_2 = f(s_1(D)) | / BB2 s_3 = PHI s_1(D), s2 in a function that gets inlined into a loop. The liveness of s_1(D) in BB0 will propagate to BB2 along the backwards edge and you get overlapping live ranges for s_1(D) and s_3. If s_1(D) is SSA_NAME_OCCURS_IN_ABNORMAL_PHI, the compilation will abort during SSA coalescing because they must be coalesced. This is on the mainline, Ada testcase attached, run 'gnatchop' on it and compile at -O -gnatp. Thanks in advance. -- Eric Botcazou package Q is procedure Read(S : out Integer); procedure Restore(S : in out Integer); end Q; package P is type Int_Ptr is access all Integer; procedure Exec(P : Int_Ptr); end P; with Q; use Q; package body P is procedure Lock is S : Integer; begin Read(S); Restore(S); exception when others = Restore(S); end; procedure Exec(P : Int_Ptr) is begin while P /= NULL loop Lock; end loop; end; end P;
Re: Problem with SSA inlining and default defs
On Sun, Dec 16, 2007 at 06:54:29PM +0100, Eric Botcazou wrote: How SSA inlining and default defs for uninitialized variables are supposed to interact? Suppose you have the following situation BB0 ... | \ (ab) |BB1 s_2 = f(s_1(D)) | / BB2 s_3 = PHI s_1(D), s2 in a function that gets inlined into a loop. The liveness of s_1(D) in BB0 will propagate to BB2 along the backwards edge and you get overlapping live ranges for s_1(D) and s_3. If s_1(D) is SSA_NAME_OCCURS_IN_ABNORMAL_PHI, the compilation will abort during SSA coalescing because they must be coalesced. This sounds like PR31081. Jakub
Re: Problem with SSA inlining and default defs
This sounds like PR31081. Indeed, the C++ testcase is the exact translation of my Ada testcase. :-) The problem seems to arise relatively often in Ada, I think the PR should be made critical. -- Eric Botcazou
Re: libgfortran, libgomp not compiled with BOOT_CFLAGS.
Toon Moene [EMAIL PROTECTED] writes: L.S., Recently, I've begun to bootstrap with make BOOT_CFLAGS=flags, basically to get the run time libraries (libgfortran, libgomp) compiled with -mcpu=native -mtune=native (the speed of the compiler doesn't interest me that much). However, I see that almost everything is compiled with -mcpu=native -mtune=native, *except* the run time libraries ... Is that because they're target libraries - if so, how would one get them compiled optimally if not building a cross-compiler ? Yeah, try adding appropriate FCFLAGS into environment. Also CXXFLAGS, GCJFLAGS affect some of resulting binaries or libraries when bootstrapping, and CFLAGS (don't remember about this one for sure).
Re: Rant about ChangeLog entries and commit messages
On 12/16/07, Alexandre Oliva [EMAIL PROTECTED] wrote: On Dec 16, 2007, NightStrike [EMAIL PROTECTED] wrote: On 12/15/07, Alexandre Oliva [EMAIL PROTECTED] wrote: ... a good example of compliance with the GPL: 5. Conveying Modified Source Versions. a) The work must carry prominent notices stating that you modified it, and giving a relevant date. Maybe Changelogs should be reserved for important changes. For instance, something like Fixed a typo is a complete waste. I doubt anyone looks ta a Changelog to see if someone fixed a typo recently or at any point in the past. I've done that, while backporting patches. Oftentimes there are small fixes on top of larger patches, and you want to credit those who made the small fixes, and you want to be sure you caught them next time you look at the patch. ChangeLogs for these are useful for this purpose. Perhaps there could be some criteria so that not every single iota gets a log entry. How would leaving changes out comply with 5a above? It wouldn't without some creative interpretations.
Re: HIRLAM with -ftree-loop-distribution.
Sebastian Pop wrote: Wow! Thanks for the numbers. I guess from your message that there were no ICEs or other problems with the loop distribution patch. Exactly. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ GNU Fortran's path to Fortran 2003: http://gcc.gnu.org/wiki/Fortran2003
Re: Problem with SSA inlining and default defs
On Sun, Dec 16, 2007 at 07:11:49PM +0100, Eric Botcazou wrote: This sounds like PR31081. Indeed, the C++ testcase is the exact translation of my Ada testcase. :-) The problem seems to arise relatively often in Ada, I think the PR should be made critical. Yeah, to me this looks like the most worrisome P1 4.3 regression. Jakub
Re: Problem with posix threads
Please forgive me if this is off-topic:
I've written a simple test program with posix threads and a 'glibc'
attempt was detected.
The code:
-main.c---
#include stdio.h
#include stdlib.h
#include pthread.h
#include sys/socket.h
#include sys/types.h
#include errno.h
#include unistd.h
#include stack.c
/*
* THREAD EXPERIMENT
*
* There are various threads:
* I, II and main
* thread I repeatly pushes to 'stck' a value (NTIMES times)
* thread II then pop repeatly and show the value (NTIMES-1 times)
* main thread then pushes the last values and quit
*/
#define NTIMES 1000
#define die(msg) do { perror(msg); exit(1); } while(0)
void * doPush(void * data);
void * doPop(void * data);
struct pack{
Stack stck;
pthread_mutex_t mutex;
};
int main(int argc, char *argv[]){
void *trashbin;
pthread_t peer[2];
struct pack pck;
//initialize pck mutex
if( pthread_mutex_init(( pck.mutex), NULL) != 0 )
die(pthread_mutex_init);
//and make it multi-threaded
if( pthread_create(peer[0], NULL, doPush, (void*)pck) != 0 )
die(pthread_create);
if( pthread_create(peer[1], NULL, doPop, (void*)pck) != 0 )
die(pthread_create);
//wait all threads do their stuff
pthread_join(peer[0],trashbin);
pthread_join(peer[1],trashbin);
pthread_mutex_lock( (pck.mutex) );
printf(Last one: %c\n, pop( (pck.stck) ));
pthread_mutex_unlock( (pck.mutex) );
//destroy pck mutex
if( pthread_mutex_destroy( ( pck.mutex) ) != 0 )
die(pthread_mutex_destroy);
return 0;
}
void * doPush(void * data){
struct pack * pck = (struct pack *)data;
int x;
for(x=0;xNTIMES;x++){
int chr;
chr = x%('z'-'a'+1);
chr += 'a';
//try to push the data... using mutex!
pthread_mutex_lock( (pck-mutex) );
push( (pck-stck), (void*)chr );
pthread_mutex_unlock( (pck-mutex) );
}
pthread_exit( NULL );
}
void * doPop(void * data){
struct pack * pck = (struct pack *)data;
int x;
for(x=0;x(NTIMES-1);x++){
pthread_mutex_lock( (pck-mutex) );
printf(%c , pop( (pck-stck) ) );
pthread_mutex_unlock( (pck-mutex) );
}
printf(\n);
pthread_exit( NULL );
}
--
-stack.c---
#ifndef STACK_C
#define STACK_C 1
#include stdlib.h
struct stack {
void * el;
struct stack *next;
};
typedef struct stack * Stack;
void stackInit(Stack * stck){
*stck = NULL;
return;
}
//pushes an element to the stack
void push(Stack * stck, void * el){
struct stack * ne;
ne = malloc(sizeof(struct stack));
ne-el = el;
ne-next = *stck;
*stck = ne;
return;
}
//pops an element from stack
//return NULL if there's no element in the stack
void * pop(Stack * stck){
struct stack * de;
void * el;
de = *stck;
*stck = (*stck)-next;
if(de != NULL ){
el = de-el;
free(de);
}
else
el = NULL;
return el;
}
#endif
--
unable to find a register to spill in class ‘MD_REGS’
Dear GCC Developers/Users,
I am working on a port of a target backend to PISA architecture (a MIPS-IV like
ISA used by the SimpleScalar simulator). When compiling libgcc2 for __muldi3:
#ifdef L_muldi3
DWtype
__muldi3 (DWtype u, DWtype v)
{
const DWunion uu = {.ll = u};
const DWunion vv = {.ll = v};
DWunion w = {.ll = __umulsidi3 (uu.s.low, vv.s.low)};
w.s.high += ((UWtype) uu.s.low * (UWtype) vv.s.high
+ (UWtype) uu.s.high * (UWtype) vv.s.low);
return w.ll;
}
#endif
I get the following error:
../.././gcc/libgcc2.c: In function ‘__muldi3’:
../.././gcc/libgcc2.c:542: error: unable to find a register to spill in class
‘MD_REGS’
../.././gcc/libgcc2.c:542: error: este es el insn:
(insn 37 36 38 2 (set (reg:DI 116)
(mult:DI (zero_extend:DI (reg:SI 3 v1 [orig:117 __ul ] [117]))
(zero_extend:DI (reg:SI 2 v0 [orig:118 __vl ] [118] 14
{umulsidi3_32bit_internal} (nil)
(expr_list:REG_DEAD (reg:SI 3 v1 [orig:117 __ul ] [117])
(expr_list:REG_DEAD (reg:SI 2 v0 [orig:118 __vl ] [118])
(nil
I have compile it with -da and the dumps are:
greg:
Spilling for insn 37.
Using reg 4 for reload 0
reload failure for reload 1
Reloads for insn # 37
Reload 0: GR_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
Reload 1: reload_out (DI) = (reg:DI 116)
MD_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg:DI 116)
secondary_out_reload = 0
lreg:
[...]
Register 116 costs: LEA_REGS:1000 GR_REGS:1000 MEM:8000
[...]
Register 116 used 2 times across 2 insns in block 2; set 1 time; 8 bytes;
NO_REGS or none.
[...]
(insn 37 36 38 2 (set (reg:DI 116)
(mult:DI (zero_extend:DI (reg:SI 117 [ __ul ]))
(zero_extend:DI (reg:SI 118 [ __vl ] 14
{umulsidi3_32bit_internal} (nil)
(expr_list:REG_DEAD (reg:SI 117 [ __ul ])
(expr_list:REG_DEAD (reg:SI 118 [ __vl ])
(nil
[...]
I have read a thread of a guy having a paroblem like this but it has not helped
me. If anybody would tell me where the problem could be, I would be very
pleased.
Regards,
Rodrigo González
Re: Designs for better debug info in GCC
Alexandre Oliva wrote: Yes, please. I would very much like to see an abstract design document on what you are trying to accomplish. Other than the ones I've already posted, here's one: http://dwarfstd.org/Dwarf3Std.php Seriously. There is a standard for this stuff. That's the specification for the encoding format. I agree with you that emitting incorrect debugging information, in the sense of declaring that the location of a variable is in one place, even though its value is not available in that place, is bad. In -O0 code, I consider it a serious bug. In -O2 code, I think it's still a bug, but with our current infrastructure, we may have little choice: we either deny all knowledge of the variable's location, or give one that's sometimes incorrect. Which alternative is better depends on what you're trying to do with the information; for interactive debugging, mostly-right is probably better than nothing, whereas for some programmatic activities, the opposite may be true. If your goal is to avoid the information ever being wrong -- without worrying about whether it is complete -- there is of course a trivial solution: do not emit the information. That is not a serious suggestion, but it does provide a path to a serious suggestion, which I gave earlier: conservatively emit location information you provide based on what you can prove at the time you generate debugging information. For example, if the value of x is in a register, and you cross a call which might clobber that register value, then emit debugging information that says that at that point the value is unavailable. You could probably do this kind of thing with relatively few changes to the GCC internal representation; you would run a pass before debug-information generation that attempted to prove dataflow properties about variables and told you where values could reliably be found. Your earlier messages, however, suggest that you are trying to do something harder: emit information that is essentially both complete (in the sense of providing as much information as possible about the locations and values of variables) and correct (in the sense of never giving incorrect information). If you want to do that, you're going to have to answer the harder questions, like what line number corresponds to this address? and what should the debugging information say that the value of a variable is when it has been optimized away? If that's still your goal, then pointing at the DWARF3 specification doesn't help. Diego and I are asking you to confront these fundamental questions about what information you want to provide and what the correctness criteria are. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Problem with posix threads
Why does it happen?
Re: Problem with posix threads
On Sun, Dec 16, 2007 at 07:20:37PM -0300, Lucas Prado Melo wrote: Why does it happen? This list is for the development of GCC. Try gcc-help or some other programming forum, please. -- Daniel Jacobowitz CodeSourcery
Re: Designs for better debug info in GCC
It is obvious that you misunderstood what I want, and how intrusive the approach is. Yes Alexandre, everyone who disagrees with you must not understand! That's really the problem here. None of us understand but you.
Re: Designs for better debug info in GCC
On Sun, Dec 16, 2007 at 08:12:07PM -0500, Daniel Berlin wrote: It is obvious that you misunderstood what I want, and how intrusive the approach is. Yes Alexandre, everyone who disagrees with you must not understand! That's really the problem here. None of us understand but you. I have some sympathy for going in Alexandre's direction, in that it would be nice to have a mode that provided optimization as well as accurate debugging. However, since preserving accurate debug information has a cost, I think it would be better to turn -O1, not -O2, into the mode that Alexandre wants, where debug information is preserved. Trying to rework all optimizations to keep perfect debug information is going to take forever and make the compiler worse.
Re: Designs for better debug info in GCC
On Dec 16, 2007, at 20:27, Joe Buck wrote:
I have some sympathy for going in Alexandre's direction, in that it
would be nice to have a mode that provided optimization as well as
accurate debugging. However, since preserving accurate debug
information
has a cost, I think it would be better to turn -O1, not -O2, into the
mode that Alexandre wants, where debug information is preserved.
Trying
to rework all optimizations to keep perfect debug information is going
to take forever and make the compiler worse.
Right, at the moment -O1 is far too much like -O2.
There is room for an optimization mode that is mostly local,
scales well far large programs and allows for high-quality debug
information. Fortunately, these goals seem all to match.
We could conceptually have inspection points between each source
statement and declaration, which would roughly correspond to a
use of all memory and all source variables, wether in memory or
in registers.
These inspections points would be considered potentially trapping.
This approach would still allow some scheduling. For example, loads
and arithmetic operations that are known not to trap could still
be done early. On the other hand, when breaking at any statement,
all variables can be printed.
Also, since no user-visible state can be modified by speculatively
executed instructions such as loads, such instructions should not
be tagged with their original source location information.
This would prevent the very annoying and unhelpful jumping around
the program during debugging.
The method I describe here, which roughly corresponds to the semantics
of Ada's pragma Inspection_Point, seems relatively easy to implement
using an empty asm or similar.
-Geert
PS. For convenience, I'm including a snippet of the Ada 2005 standard,
the full version of which is freely available on the web.
H.3.2 Pragma Inspection_Point
1 An occurrence of a pragma Inspection_Point identifies a set of
objects
each of whose values is to be available at the point(s) during program
execution corresponding to the position of the pragma in the
compilation unit.
The purpose of such a pragma is to facilitate code validation.
Syntax
2 The form of a pragma Inspection_Point is as follows:
3 pragma Inspection_Point[(object_name {, object_name})];
Legality Rules
4 A pragma Inspection_Point is allowed wherever a declarative_item
or
statement is allowed. Each object_name shall statically denote the
declaration
of an object.
Static Semantics
5/2 An inspection point is a point in the object code corresponding
to the
occurrence of a pragma Inspection_Point in the compilation unit. An
object is
inspectable at an inspection point if the corresponding pragma
Inspection_Point either has an argument denoting that object, or has no
arguments and the declaration of the object is visible at the inspection
point.
Dynamic Semantics
6 Execution of a pragma Inspection_Point has no effect.
Implementation Requirements
7 Reaching an inspection point is an external interaction with
respect to
the values of the inspectable objects at that point (see 1.1.3).
Documentation Requirements
8 For each inspection point, the implementation shall identify a
mapping
between each inspectable object and the machine resources (such as
memory
locations or registers) from which the object's value can be obtained.
NOTES
9/2 7 The implementation is not allowed to perform dead store
elimination on the last assignment to a variable prior to a
point where the
variable is inspectable. Thus an inspection point has the
effect of an
implicit read of each of its inspectable objects.
108 Inspection points are useful in maintaining a correspondence
between
the state of the program in source code terms, and the machine
state
during the program's execution. Assertions about the values of
program
objects can be tested in machine terms at inspection points.
Object code
between inspection points can be processed by automated tools
to verify
programs mechanically.
119 The identification of the mapping from source program objects
to
machine resources is allowed to be in the form of an annotated
object
listing, in human-readable or tool-processable form.
[Bug tree-optimization/34413] gfortran.dg/ltrans-7.f90 doesn't work
--- Comment #5 from sebpop at gmail dot com 2007-12-16 08:31 --- Subject: Re: gfortran.dg/ltrans-7.f90 doesn't work On 16 Dec 2007 03:23:17 -, jvdelisle at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-12-16 03:23 --- I think Sebastian committed this patch with the intent to fix the bug. Usually we don't commit test cases until after we have it fixed and use the PR to track the issue. So I think we just wait for Sebastian to finish. If its going to be a while, we can XFAIL it. Is this correct Sebastian? Yes, I'm going to fix this tomorrow, either xfailing the test or better, fix the testcase with a patch for loop-linear. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
[Bug fortran/34482] FAIL: gfortran.dg/nan_4.f90 -O tests for errors
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
[Bug ada/34489] Compilation of applicationservices-qd-quickdraw.ads fails
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-12-16 08:45 --- Already fixed. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34489
[Bug ada/34489] Compilation of applicationservices-qd-quickdraw.ads fails
--- Comment #5 from rogermc at iinet dot net dot au 2007-12-16 08:51 --- (In reply to comment #4) Already fixed. How or where can I obtain the fix? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34489
[Bug ada/34489] Compilation of applicationservices-qd-quickdraw.ads fails
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-12-16 08:59 --- How or where can I obtain the fix? Probably the same way you obtained the previous compiler, the fix is revision 130665. Or from the SVN tree directly, see http://gcc.gnu.org/svn.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34489
[Bug rtl-optimization/34490] [4.3 Regression] r128833 causes miscompilation of glibc clock_gettime.c
--- Comment #1 from jakub at gcc dot gnu dot org 2007-12-16 09:38 ---
Simpler testcase:
/* PR rtl-optimization/34490 */
extern void abort (void);
static int x;
int
__attribute__((noinline))
bar (void)
{
return x;
}
int
foo (void)
{
long int b = bar ();
if ((unsigned long) b -4095L)
return b;
if (-b != 38)
b = -2;
return b + 1;
}
int
main (void)
{
x = 26;
if (foo () != 26)
abort ();
x = -39;
if (foo () != -1)
abort ();
x = -38;
if (foo () != -37)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34490
[Bug rtl-optimization/34490] [4.3 Regression] r128833 causes miscompilation of glibc clock_gettime.c
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-16 09:50 --- simplify_const_relational_operation (LEU, DImode, (sign_extend:DI (reg:SI 59)), (const_int -4096)) returns (const_int 1), which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34490
[Bug rtl-optimization/34415] [4.3 Regression] Possible miscompilation on MIPS
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-12-16 09:54 --- Subject: Bug 34415 Author: rsandifo Date: Sun Dec 16 09:54:34 2007 New Revision: 130987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130987 Log: gcc/ PR rtl-optimization/34415 * df.h (DF_LR_IN, DF_LR_OUT): Update comments. * resource.c (mark_target_live_regs): Use DF_LR_IN rather than df_get_live_in. Don't handle pseudos. gcc/testsuite/ PR rtl-optimization/34415 * gcc.c-torture/execute/pr34415.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr34415.c Modified: trunk/gcc/ChangeLog trunk/gcc/df.h trunk/gcc/resource.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34415
[Bug rtl-optimization/34415] [4.3 Regression] Possible miscompilation on MIPS
--- Comment #7 from rsandifo at gcc dot gnu dot org 2007-12-16 09:58 --- Fixed on trunk. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34415
[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)
--- Comment #12 from mmokrejs at ribosome dot natur dot cuni dot cz 2007-12-16 11:06 --- Please update the docs first and update configure to check for at least some of the required features. Users are not going to realize their utilities do not conform to POSIX completely. And so far you have not heard what is exactly required and why. I have installed myself the whole busybox, filed a bug in it and still cannot use stage1 compiler, but those are another 2 bugs in gcc-4.2.2. -- mmokrejs at ribosome dot natur dot cuni dot cz changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34474
[Bug bootstrap/34494] New: -V option should be compatible with -B at least, possible others as well
After completing stage1 build, the xgcc binary is being used. Unfortunately, the -V option used in objdir/intl/configure breaks the build. Below is a relevant snippet from objdir/intl/config.log: configure:1771: checking for armv5tejl-unknown-linux-gnu-gcc configure:1797: result: /scratch/gcc-4.2.2/objdir/./prev-gcc/xgcc -B/scratch/gcc-4.2.2/objdir/./prev-gcc/ -B/usr/local/armv5tejl-unknown-linux-gnu/bin/ configure:2079: checking for C compiler version configure:2082: /scratch/gcc-4.2.2/objdir/./prev-gcc/xgcc -B/scratch/gcc-4.2.2/objdir/./prev-gcc/ -B/usr/local/armv5tejl-unknown-linux-gnu/bin/ --version /dev/null 5 xgcc (GCC) 4.2.2 Copyright (C) 2007 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. configure:2085: $? = 0 configure:2087: /scratch/gcc-4.2.2/objdir/./prev-gcc/xgcc -B/scratch/gcc-4.2.2/objdir/./prev-gcc/ -B/usr/local/armv5tejl-unknown-linux-gnu/bin/ -v /dev/null 5 Reading specs from /scratch/gcc-4.2.2/objdir/./prev-gcc/specs Target: armv5tejl-unknown-linux-gnu Configured with: ../configure --with-float=soft --enable-languages=c,c++,objc --disable-nls --with-newlib Thread model: posix gcc version 4.2.2 configure:2090: $? = 0 configure:2092: /scratch/gcc-4.2.2/objdir/./prev-gcc/xgcc -B/scratch/gcc-4.2.2/objdir/./prev-gcc/ -B/usr/local/armv5tejl-unknown-linux-gnu/bin/ -V /dev/null 5 xgcc: '-V' must come at the start of the command line configure:2095: $? = 1 configure:2118: checking for C compiler default output file name configure:2121: /scratch/gcc-4.2.2/objdir/./prev-gcc/xgcc -B/scratch/gcc-4.2.2/objdir/./prev-gcc/ -B/usr/local/armv5tejl-unknown-linux-gnu/bin/ -g -O2 conftest.c 5 configure:2124: $? = 0 configure:2170: result: a.out configure:2175: checking whether the C compiler works configure:2181: ./a.out /scratch/gcc-4.2.2/intl/configure: line 2182: ./a.out: No such file or directory configure:2184: $? = 127 configure:2193: error: cannot run C compiled programs. For completeness, I did: objdir$ rm -rf * objdir$ ../configure --with-float=soft --enable-languages=c,c++,objc \ --disable-nls --with-newlib objdir$ make bootstrap -- Summary: -V option should be compatible with -B at least, possible others as well Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmokrejs at ribosome dot natur dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34494
[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well
--- Comment #1 from mmokrejs at ribosome dot natur dot cuni dot cz 2007-12-16 11:21 --- Created an attachment (id=14776) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14776action=view) config.statuses_and_logs.tgz tar cvf - ./prev-libiberty/config.status ./prev-libdecnumber/config.status ./config.status ./prev-intl/config.status ./build-armv5tejl-unknown-linux-gnu/libiberty/config.status ./build-armv5tejl-unknown-linux-gnu/fixincludes/config.status ./prev-libcpp/config.status ./prev-gcc/config.status ./prev-libiberty/config.log ./prev-libdecnumber/config.log ./config.log ./prev-intl/config.log ./build-armv5tejl-unknown-linux-gnu/libiberty/config.log ./build-armv5tejl-unknown-linux-gnu/fixincludes/config.log ./prev-libcpp/config.log ./intl/config.log| gzip -c /root/config.statuses_and_logs.tgz -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34494
[Bug rtl-optimization/34490] [4.3 Regression] r128833 causes miscompilation of glibc clock_gettime.c
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-16 11:33 --- Created an attachment (id=14777) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14777action=view) gcc43-pr34490.patch Patch I'll be testing. For unsigned comparison, reducing the range using num_sign_bit_copies is just wrong. If op0 is sign extended, compared using GTU/GEU/LTU/LEU, then op0 ranges are two subranges, 0 ... 0x000..7f.. and 0xfff..80.. ... 0xfff..ff.., so op0 could be 0, or it could be GET_MODE_BITMASK (mode). -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34490
[Bug fortran/33888] ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg
--- Comment #4 from pault at gcc dot gnu dot org 2007-12-16 11:34 --- Subject: Bug 33888 Author: pault Date: Sun Dec 16 11:34:08 2007 New Revision: 130988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130988 Log: 2007-12-16 Paul Thomas [EMAIL PROTECTED] PR fortran/31213 PR fortran/33888 PR fortran/33998 * trans-array.c (gfc_trans_array_constructor_value): If the iterator variable does not have a backend_decl, use a local temporary. (get_elemental_fcn_charlen): New function to map the character length of an elemental function onto its actual arglist. (gfc_conv_expr_descriptor): Call the above so that the size of the temporary can be evaluated. * trans-expr.c : Include arith.h and change prototype of gfc_apply_interface_mapping_to_expr to return void. Change all references to gfc_apply_interface_mapping_to_expr accordingly. (gfc_free_interface_mapping): Free the 'expr' field. (gfc_add_interface_mapping): Add an argument for the actual argument expression. This is copied to the 'expr' field of the mapping. Only stabilize the backend_decl if the se is present. Copy the character length expression and only add it's backend declaration if se is present. Return without working on the backend declaration for the new symbol if se is not present. (gfc_map_intrinsic_function) : To simplify intrinsics 'len', 'size', 'ubound' and 'lbound' and then to map the result. (gfc_map_fcn_formal_to_actual): Performs the formal to actual mapping for the case of a function found in a specification expression in the interface being mapped. (gfc_apply_interface_mapping_to_ref): Remove seen_result and all its references. Remove the inline simplification of LEN and call gfc_map_intrinsic_function instead. Change the order of mapping of the actual arguments and simplifying intrinsic functions. Finally, if a function maps to an actual argument, call gfc_map_fcn_formal_to_actual. (gfc_conv_function_call): Add 'e' to the call to gfc_add_interface_mapping. * dump-parse-tree.c (gfc_show_symbol_n): New function for diagnostic purposes. * gfortran.h : Add prototype for gfc_show_symbol_n. * trans.h : Add 'expr' field to gfc_add_interface_mapping. Add 'expr' to prototype for gfc_show_symbol_n. * resolve.c (resolve_generic_f0): Set specific function as referenced. 2007-12-16 Paul Thomas [EMAIL PROTECTED] PR fortran/31213 PR fortran/33888 PR fortran/33998 * gfortran.dg/mapping_1.f90: New test. * gfortran.dg/mapping_2.f90: New test. * gfortran.dg/mapping_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mapping_1.f90 trunk/gcc/testsuite/gfortran.dg/mapping_2.f90 trunk/gcc/testsuite/gfortran.dg/mapping_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #11 from pault at gcc dot gnu dot org 2007-12-16 11:34 --- Subject: Bug 31213 Author: pault Date: Sun Dec 16 11:34:08 2007 New Revision: 130988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130988 Log: 2007-12-16 Paul Thomas [EMAIL PROTECTED] PR fortran/31213 PR fortran/33888 PR fortran/33998 * trans-array.c (gfc_trans_array_constructor_value): If the iterator variable does not have a backend_decl, use a local temporary. (get_elemental_fcn_charlen): New function to map the character length of an elemental function onto its actual arglist. (gfc_conv_expr_descriptor): Call the above so that the size of the temporary can be evaluated. * trans-expr.c : Include arith.h and change prototype of gfc_apply_interface_mapping_to_expr to return void. Change all references to gfc_apply_interface_mapping_to_expr accordingly. (gfc_free_interface_mapping): Free the 'expr' field. (gfc_add_interface_mapping): Add an argument for the actual argument expression. This is copied to the 'expr' field of the mapping. Only stabilize the backend_decl if the se is present. Copy the character length expression and only add it's backend declaration if se is present. Return without working on the backend declaration for the new symbol if se is not present. (gfc_map_intrinsic_function) : To simplify intrinsics 'len', 'size', 'ubound' and 'lbound' and then to map the result. (gfc_map_fcn_formal_to_actual): Performs the formal to actual mapping for the case of a function found in a specification expression in the interface being mapped. (gfc_apply_interface_mapping_to_ref): Remove seen_result and all its references. Remove the inline simplification of LEN and call gfc_map_intrinsic_function instead. Change the order of mapping of the actual arguments and simplifying intrinsic functions. Finally, if a function maps to an actual argument, call gfc_map_fcn_formal_to_actual. (gfc_conv_function_call): Add 'e' to the call to gfc_add_interface_mapping. * dump-parse-tree.c (gfc_show_symbol_n): New function for diagnostic purposes. * gfortran.h : Add prototype for gfc_show_symbol_n. * trans.h : Add 'expr' field to gfc_add_interface_mapping. Add 'expr' to prototype for gfc_show_symbol_n. * resolve.c (resolve_generic_f0): Set specific function as referenced. 2007-12-16 Paul Thomas [EMAIL PROTECTED] PR fortran/31213 PR fortran/33888 PR fortran/33998 * gfortran.dg/mapping_1.f90: New test. * gfortran.dg/mapping_2.f90: New test. * gfortran.dg/mapping_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mapping_1.f90 trunk/gcc/testsuite/gfortran.dg/mapping_2.f90 trunk/gcc/testsuite/gfortran.dg/mapping_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug fortran/33998] ICE in make_decl_rtl, at varasm.c:1263
--- Comment #6 from pault at gcc dot gnu dot org 2007-12-16 11:34 --- Subject: Bug 33998 Author: pault Date: Sun Dec 16 11:34:08 2007 New Revision: 130988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130988 Log: 2007-12-16 Paul Thomas [EMAIL PROTECTED] PR fortran/31213 PR fortran/33888 PR fortran/33998 * trans-array.c (gfc_trans_array_constructor_value): If the iterator variable does not have a backend_decl, use a local temporary. (get_elemental_fcn_charlen): New function to map the character length of an elemental function onto its actual arglist. (gfc_conv_expr_descriptor): Call the above so that the size of the temporary can be evaluated. * trans-expr.c : Include arith.h and change prototype of gfc_apply_interface_mapping_to_expr to return void. Change all references to gfc_apply_interface_mapping_to_expr accordingly. (gfc_free_interface_mapping): Free the 'expr' field. (gfc_add_interface_mapping): Add an argument for the actual argument expression. This is copied to the 'expr' field of the mapping. Only stabilize the backend_decl if the se is present. Copy the character length expression and only add it's backend declaration if se is present. Return without working on the backend declaration for the new symbol if se is not present. (gfc_map_intrinsic_function) : To simplify intrinsics 'len', 'size', 'ubound' and 'lbound' and then to map the result. (gfc_map_fcn_formal_to_actual): Performs the formal to actual mapping for the case of a function found in a specification expression in the interface being mapped. (gfc_apply_interface_mapping_to_ref): Remove seen_result and all its references. Remove the inline simplification of LEN and call gfc_map_intrinsic_function instead. Change the order of mapping of the actual arguments and simplifying intrinsic functions. Finally, if a function maps to an actual argument, call gfc_map_fcn_formal_to_actual. (gfc_conv_function_call): Add 'e' to the call to gfc_add_interface_mapping. * dump-parse-tree.c (gfc_show_symbol_n): New function for diagnostic purposes. * gfortran.h : Add prototype for gfc_show_symbol_n. * trans.h : Add 'expr' field to gfc_add_interface_mapping. Add 'expr' to prototype for gfc_show_symbol_n. * resolve.c (resolve_generic_f0): Set specific function as referenced. 2007-12-16 Paul Thomas [EMAIL PROTECTED] PR fortran/31213 PR fortran/33888 PR fortran/33998 * gfortran.dg/mapping_1.f90: New test. * gfortran.dg/mapping_2.f90: New test. * gfortran.dg/mapping_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/mapping_1.f90 trunk/gcc/testsuite/gfortran.dg/mapping_2.f90 trunk/gcc/testsuite/gfortran.dg/mapping_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33998
[Bug fortran/33888] ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg
--- Comment #5 from pault at gcc dot gnu dot org 2007-12-16 11:41 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
[Bug fortran/33998] ICE in make_decl_rtl, at varasm.c:1263
--- Comment #7 from pault at gcc dot gnu dot org 2007-12-16 11:42 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33998
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #12 from pault at gcc dot gnu dot org 2007-12-16 11:42 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug fortran/34396] Length of substrings defined by expressions not correctly computed in constructors
--- Comment #7 from pault at gcc dot gnu dot org 2007-12-16 11:45 --- OK then, I'll give it a try! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-09 06:20:24 |2007-12-16 11:45:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34396
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #28 from steven at gcc dot gnu dot org 2007-12-16 12:01 --- Created an attachment (id=14778) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14778action=view) Change worklist solver to double queue algorithm I re-read Cooper, Harvey and Kennedy, who wrote a nice paper about various work list based dataflow solvers. The attached patch modifies df_worklist_dataflow to a double queue algorithm, while retaining the property that basic blocks are added to the queue in RPO order. This approach gives me a speedup comparable to (but slightly less than) the hybrid search algorithm. This is not really surprising because the double queue work list algorithm also completes full iterations over the CFG before considering the second queue. Seongbae, what are your ideas about the double queue approach (or maybe other algorithms suggested by Harvey)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #7 from rask at gcc dot gnu dot org 2007-12-16 12:55 --- It's the dataflow merge (125624) that broke it. Revision 125623 with 130333 on top is fine, but 125624 with 125851 (so it builds) and 130333 on top fails. The patch in comment #6 has one testsuite regression on arm-unknown-elf: FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-12-16 12:58 --- Well it is we assume a lot of things are POSIX support so I don't see why we have to document find here really. Yes we document we need a POSIX shell but that is because a semi common target (Solaris)'s /bin/sh is not POSIX compatible. It is not common to find a non POSIX compatible find (or one that does not support the find options). The main reason why I don't want to see two finds is because find is actually can be expensive. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34474
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #8 from pinskia at gmail dot com 2007-12-16 13:00 --- Subject: Re: [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612 On 16 Dec 2007 12:55:21 -, rask at gcc dot gnu dot org [EMAIL PROTECTED] wrote: The patch in comment #6 has one testsuite regression on arm-unknown-elf: FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error) FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors) That is not a regression Just an already existing failure. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #7 from John dot Tytgat at aaug dot net 2007-12-16 13:04 --- Indeed fixed thanks. -- John dot Tytgat at aaug dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug tree-optimization/34445] [4.3 Regression] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98
--- Comment #4 from dorit at gcc dot gnu dot org 2007-12-16 13:06 ---
testing this patch:
*** tree-vect-transform.c (revision 130987)
--- tree-vect-transform.c (working copy)
*** vect_estimate_min_profitable_iters (loop
*** 197,214
factor = 1;
for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (si))
! {
! tree stmt = bsi_stmt (si);
! stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
! if (!STMT_VINFO_RELEVANT_P (stmt_info)
!!STMT_VINFO_LIVE_P (stmt_info))
! continue;
! scalar_single_iter_cost += cost_for_stmt (stmt) * factor;
! vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
factor;
/* FIXME: for stmts in the inner-loop in outer-loop vectorization,
some of the outside costs are generated inside the outer-loop.
*/
! vec_outside_cost += STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info);
! }
}
/* Add additional cost for the peeled instructions in prologue and epilogue
--- 197,215
factor = 1;
for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (si))
! {
! tree stmt = bsi_stmt (si);
! stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
! /* Skip stmts that are not vectorized inside the loop. */
! if (!STMT_VINFO_RELEVANT_P (stmt_info)
! STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def)
! continue;
! scalar_single_iter_cost += cost_for_stmt (stmt) * factor;
! vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
factor;
/* FIXME: for stmts in the inner-loop in outer-loop vectorization,
some of the outside costs are generated inside the outer-loop.
*/
! vec_outside_cost += STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info);
! }
}
/* Add additional cost for the peeled instructions in prologue and epilogue
(It fixes both testcases)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34445
[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well
--- Comment #2 from schwab at suse dot de 2007-12-16 13:31 --- This test will always fail with gcc because -V requires an argument, but this is ok because it's only there to provide some information about the compiler in the log file, but is otherwise ignored. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34494
[Bug fortran/34495] New: [4.3 Regression] accepts invalid initialization expressions with -std=f95
Adapted from a test case from c.l.f, from James van Buskirk : $ cat foo.f90 program main integer, parameter :: ipi = 1078530011 real pi parameter(pi=transfer(ipi,pi)) real, parameter :: z = transfer(ipi,z) real, parameter :: y = real(1,kind(y)) write(*,*) pi, z, y end $ gfortran -std=f95 -pedantic foo.f90 $ ./a.out 3.1415927 3.1415927 1. JvB's explanation: # the second # and third treat transfer as a specification inquiry even thought # that is not permitted even in f03, and the fourth has that pesky # REAL intrinsic, which is not an elemental function of type integer # or character. gfortran 4.2 still generates some error messages: $ gfortran-4.2 foo.f90 foo.f90:4.29: parameter(pi=transfer(ipi,pi)) 1 Error: Parameter 'pi' at (1) has not been declared or is a variable, which does not reduce to a constant expression foo.f90:5.35: real, parameter :: z = transfer(ipi,z) 1 Error: TRANSFER intrinsic not implemented for initialization at (1) -- Summary: [4.3 Regression] accepts invalid initialization expressions with -std=f95 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34495
[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin
--- Comment #16 from dominiq at lps dot ens dot fr 2007-12-16 13:38 --- The patch in comment #14 fix the problem for me. Thanks Jack for the debugging and the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34025
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #9 from rask at gcc dot gnu dot org 2007-12-16 13:39 --- That is not a regression Just an already existing failure. Unmodified trunk revision 130944 doesn't have it: diff -u build/arm-unknown-elf-results-unpatched/summary build/arm-unknown-elf-results-patched/summary --- build/arm-unknown-elf-results-unpatched/summary 2007-12-15 02:26:10.0 +0100 +++ build/arm-unknown-elf-results-patched/summary 2007-12-16 04:17:59.0 +0100 @@ -17,6 +17,9 @@ FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized nasty_local 0 FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll Expanding Accumulator FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll Expanding Accumulator +FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error) +FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors) +UNRESOLVED: gcc.dg/struct/wo_prof_malloc_size_var.c compilation failed to produce executable FAIL: gcc.dg/struct/wo_prof_single_str_global.c execution test FAIL: gcc.dg/struct/wo_prof_single_str_local.c execution test FAIL: gcc.dg/struct/wo_prof_single_str_pointer.c execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #29 from zadeck at naturalbridge dot com 2007-12-16 13:56 --- Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions steven at gcc dot gnu dot org wrote: --- Comment #28 from steven at gcc dot gnu dot org 2007-12-16 12:01 --- Created an attachment (id=14778) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14778action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14778action=view) Change worklist solver to double queue algorithm I re-read Cooper, Harvey and Kennedy, who wrote a nice paper about various work list based dataflow solvers. The attached patch modifies df_worklist_dataflow to a double queue algorithm, while retaining the property that basic blocks are added to the queue in RPO order. This approach gives me a speedup comparable to (but slightly less than) the hybrid search algorithm. This is not really surprising because the double queue work list algorithm also completes full iterations over the CFG before considering the second queue. Seongbae, what are your ideas about the double queue approach (or maybe other algorithms suggested by Harvey)? The bottom line here is that all of these are heuristics. There are no tight time bounds here. Each of these will have good cases and each will have bad case. So the only way that anyone can talk about best is in term of the set of graphs they used to measure output. Seongbae chose a technique that tends to work very well if the programs are normal and the expense that fully connected programs are quite bad. The class of techniques that were used in hybrid search and that you are looking at tend to do better for bad graphs but will be a little slower on the normal cases. If you can come up with some fast heuristic test to distinguish the difference cases you can select between them. Of course you only have to do the tests once per function because the chances that optimization will change the heuristic are vanishingly small. This gives you a little more room in terms of implementation cost. I think that I would vote for the any bad back edges plan to distinguish the two because i think that Seonbae's technique was designed to work well on that class of graphs. But Seonbae may have other thoughts especially if his technique requires only shallow maximum nesting to really shine. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
[Bug ada/34496] New: [4.2 regression] prefixed notation allows changing the value of a constant
with text_io; procedure test1 is package pak3 is type T1 is tagged record x0: integer; end record; procedure p1 (x1: access T1; val: integer); x2: aliased constant T1 := (x0 = 3); x3: access constant T1 := x2'access; end pak3; package body pak3 is procedure p1 (x1: access T1; val: integer) is begin x1.x0 := val; end p1; end pak3; begin text_io.put_line(integer'image(pak3.x2.x0)); pak3.x2.p1(5); -- line 25 text_io.put_line(integer'image(pak3.x2.x0)); pak3.x3.all.p1(7); -- line 27 -- pak3.x3.p1(7); -- this one is detected text_io.put_line(integer'image(pak3.x2.x0)); end test1; GCC 4.1.2: $ gnatmake -gnat05 test1 gcc-4.1 -c -gnat05 test1.adb test1.adb:25:08: expected an access type with designated type T1 defined at line 5 test1.adb:25:08: found type T1 defined at line 5 test1.adb:27:12: expected an access type with designated type T1 defined at line 5 test1.adb:27:12: found type T1 defined at line 5 The error messages are not very good (they should say something like found type constant T1) but the program is indeed illegal. GCC 4.2.2: $ gnatmake -gnat05 test1 gcc-4.2 -c -gnat05 test1.adb gnatbind -x test1.ali gnatlink test1.ali $ ./test1 3 5 7 -- Summary: [4.2 regression] prefixed notation allows changing the value of a constant Product: gcc Version: 4.2.0 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=34496
[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well
--- Comment #3 from mmokrejs at ribosome dot natur dot cuni dot cz 2007-12-16 14:00 --- ??? But how is the bootstrap supposed to continue? Or was it caused by another error which I have overlooked? I am sorry then. :( -- mmokrejs at ribosome dot natur dot cuni dot cz changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34494
[Bug ada/15605] invalid program not detected, RM 8.3(22)
--- Comment #4 from ludovic at ludovic-brenta dot org 2007-12-16 14:04 --- As of 4.2.2, only the first of the two errors is detected. Reopening. The second error violates 8.5.4(6): A name that denotes a formal parameter of the subprogram_specification is not allowed within the callable_entity_name. and is not diagnosed. GCC 4.1.2: gnatmake -gnat05 pak1 gcc-4.1 -c -gnat05 pak1.ads pak1.ads:8:15: formal parameter list cannot be used before end of specification GCC 4.2.2: gnatmake -gnat05 pak1 gcc-4.2 -c -gnat05 pak1.ads pak1.ads:8:15: formal parameter list cannot be used before end of specification -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15605
[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions with -std=f95
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-16 14:35 --- Confirm. Though other compilers have better error messages than 4.2 had. (These are all shown by default, i.e. none of the compilers below accepts it.) NAG f95: Error: PARAMETER PI used before its definition is complete g95: Error: PARAMETER value is used before being defined at (1) ifort: Error: A PARAMETER must not be defined in terms of itself. [PI] (sunf95 and openf95 have also not a good message.) I think for -std=f95 one needs another error. NAG f95 prints: Error: The REAL function is not permitted in an initialisation expression I am also not sure whether I would call the following a regression: Error: TRANSFER intrinsic not implemented for initialization at (1) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-16 14:35:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34495
[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions with -std=f95
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-16 15:14 --- Created an attachment (id=14779) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14779action=view) Patch - only for the REAL()/CMPLX() diagnostics -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34495
[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #10 from rask at gcc dot gnu dot org 2007-12-16 15:18 --- That is not a regression Just an already existing failure. OK, looks like an intermittent failure which happens about one out of four times. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug target/34473] casting negative __int128_t to float/double rounds to nearest multiple of 2048
--- Comment #3 from ubizjak at gmail dot com 2007-12-16 16:02 ---
From libgcc2.c, __floatdisf():
/* Protect against double-rounding error.
Represent any low-order bits, that might be truncated by a bit that
won't be lost. The bit can go in anywhere below the rounding position
of the SFmode. A fixed mask and bit position handles all usual
configurations. It doesn't handle the case of 128-bit DImode, however.
*/
Please note that di in fact represents TImode for 64bit x86_64. I guess that
__floatdidf() also can't handle 128bit DImode values properly.
This works OK for 4.3.0, beacuse 4.3 branch implements 128bit TFmode floating
point mode and _floatdi{s,d}f function is changed to use this mode.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work||4.3.0
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34473
[Bug middle-end/26061] error and warning count
--- Comment #16 from ismail at pardus dot org dot tr 2007-12-16 16:12
---
Created an attachment (id=14780)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14780action=view)
Unbreak lib{gomp,stdc++,ffi} tests
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
Attachment #14769|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug middle-end/26061] error and warning count
--- Comment #17 from ismail at pardus dot org dot tr 2007-12-16 16:14 --- Created an attachment (id=14781) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14781action=view) Fix typo in the last patch -- ismail at pardus dot org dot tr changed: What|Removed |Added Attachment #14780|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug target/34473] casting negative __int128_t to float/double rounds to nearest multiple of 2048
--- Comment #4 from joseph at codesourcery dot com 2007-12-16 16:44 ---
Subject: Re: casting negative __int128_t to float/double
rounds to nearest multiple of 2048
On Sun, 16 Dec 2007, ubizjak at gmail dot com wrote:
This works OK for 4.3.0, beacuse 4.3 branch implements 128bit TFmode floating
point mode and _floatdi{s,d}f function is changed to use this mode.
I think the fix was actually
2005-12-15 Joseph S. Myers [EMAIL PROTECTED]
PR other/25028
* libgcc2.h (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Define.
* libgcc2.c (__floatdixf, __floatundixf, __floatditf,
__floatunditf): Use #error if type sizes don't match requirements
of implementation.
(__floatdisf, __floatdidf): Unify. Possibly use XFmode or TFmode
as wider floating-point type. Use #error if type sizes don't
match requirements of implementation. Avoid overflow in computing
Wtype_MAXp1_F * Wtype_MAXp1_F. When special casing conversion,
shift one more bit. Cast 1 to DWtype or UDWtype for shifting.
(__floatundisf, __floatundidf): Likewise.
* config/ia64/hpux.h (XF_SIZE, TF_SIZE): Define.
* config/ia64/ia64.c (ia64_init_libfuncs): Use
_U_Qfcnvfxt_quad_to_quad and _U_Qfcnvxf_quad_to_quad for
TFmode-TImode conversions.
* doc/tm.texi (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Document.
(which is in 4.2) and that this is a duplicate of that bug. If software
TFmode is being used internally in conversions for narrower modes, that's
a bug caused by x86_64 not defining WIDEST_HARDWARE_FP_SIZE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34473
[Bug middle-end/26061] error and warning count
--- Comment #18 from manu at gcc dot gnu dot org 2007-12-16 16:51 --- Ismail, I am pretty sure that this won't be accepted for GCC 4.3, since it is not a regression fix. Actually, I am unsure it would be accepted at all following the comments to my original patch. Nevertheless, if you want to take the risk of wasting your time, some advice: * My original patch modified several testsuite files: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01190.html, I guess you would need something equivalent. * Joseph pointed that: A human readable message can't just be passed to fprintf like that, you need to arrange for it to be extracted for translation and translated into the user's language. Calling existing diagnostic functions does that, otherwise the string needs surrounding with _(). * Also he suggested: this change to output should perhaps be off by default, with a new option to enable it people wanting this style can put in their Makefiles. Good luck! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug middle-end/26061] error and warning count
--- Comment #19 from ismail at pardus dot org dot tr 2007-12-16 16:55 --- Hi, (In reply to comment #18) * My original patch modified several testsuite files: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01190.html, I guess you would need something equivalent. I added a flag to disable this to testsuite files (-fno-show-error-count) * Joseph pointed that: A human readable message can't just be passed to fprintf like that, you need to arrange for it to be extracted for translation and translated into the user's language. Calling existing diagnostic functions does that, otherwise the string needs surrounding with _(). True, I'll fix. * Also he suggested: this change to output should perhaps be off by default, with a new option to enable it people wanting this style can put in their Makefiles. I really don't want to make it default off as it's really useful. I hope to fix the patch and make it default on for gcc 4.4 at least. Thanks for the suggestions, ismail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well
--- Comment #4 from schwab at suse dot de 2007-12-16 17:02 --- This has nothing to do with the topic of this bug. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34494
[Bug c/34497] New: failures on i686-apple-darwin9 in sse4 testcases
On i686-apple-darwin9, we are seeing failures in the following sse4 related test cases... FAIL: gcc.target/i386/sse4_1-blendvpd.c (test for excess errors) WARNING: gcc.target/i386/sse4_1-blendvpd.c compilation failed to produce executable FAIL: gcc.target/i386/sse4_1-blendvps.c (test for excess errors) WARNING: gcc.target/i386/sse4_1-blendvps.c compilation failed to produce executable FAIL: gcc.target/i386/sse4_1-insertps-1.c (test for excess errors) WARNING: gcc.target/i386/sse4_1-insertps-1.c compilation failed to produce executable FAIL: gcc.target/i386/sse4_1-insertps-2.c (test for excess errors) WARNING: gcc.target/i386/sse4_1-insertps-2.c compilation failed to produce executable FAIL: gcc.target/i386/sse4_1-pblendvb.c (test for excess errors) WARNING: gcc.target/i386/sse4_1-pblendvb.c compilation failed to produce executable FAIL: gcc.target/i386/sse4_2-popcntl.c (test for excess errors) WARNING: gcc.target/i386/sse4_2-popcntl.c compilation failed to produce executable FAIL: gcc.target/i386/sse4_2-popcntq.c (test for excess errors) WARNING: gcc.target/i386/sse4_2-popcntq.c compilation failed to produce executable The actual failures in gcc.log look like... Executing on host: /sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_obj dir/gcc/ /sw/src/fink.build/gcc43-4.2.999-20071214/gcc-4.3-20071214/gcc/testsuite/gcc.target/i386/sse4_1-insertps-2.c -O2 -msse4.1 -fno- show-column -lm -m32 -o ./sse4_1-insertps-2.exe(timeout = 300) :161:suffix or operands invalid for `insertps' :164:suffix or operands invalid for `insertps' :167:suffix or operands invalid for `insertps' :168:suffix or operands invalid for `insertps' compiler exited with status 1 output is: :161:suffix or operands invalid for `insertps' :164:suffix or operands invalid for `insertps' :167:suffix or operands invalid for `insertps' :168:suffix or operands invalid for `insertps' FAIL: gcc.target/i386/sse4_1-insertps-2.c (test for excess errors) Excess errors: :161:suffix or operands invalid for `insertps' :164:suffix or operands invalid for `insertps' :167:suffix or operands invalid for `insertps' :168:suffix or operands invalid for `insertps' WARNING: gcc.target/i386/sse4_1-insertps-2.c compilation failed to produce executable -- Summary: failures on i686-apple-darwin9 in sse4 testcases Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug c/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2007-12-16 17:19 --- These same make check failures occur at both -m32 and -m64.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug middle-end/34130] [4.1/4.2 Regression] the builtin abs() gives wrong result when used in some expression
--- Comment #7 from belyshev at depni dot sinp dot msu dot ru 2007-12-16 18:08 --- Fixed on active branches. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34130
[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-12-16 18:12 --- Ada testcase at http://gcc.gnu.org/ml/gcc/2007-12/msg00470.html -- 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=31081
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-16 19:23 --- This might be a bug in Apple's assembler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
Fix PR 34305 - ICE on invalid real array bound
Hello world,
this straightforward patch removes an unneeded ICE when
we already had emitted a perfectly valid error message.
OK for trunk?
Thomas
2007-12-16 Thomas Koenig [EMAIL PROTECTED]
PR fortran/34305
* resolve.c (compare_bound): If either of the types of
the arguments isn't INTEGER, return CMP_UNKNOWN.
2007-12-16 Thomas Koenig [EMAIL PROTECTED]
PR fortran/34305
* gfortran.dg/real_dimension_1.f: New test case.
Index: resolve.c
===
--- resolve.c (revision 130913)
+++ resolve.c (working copy)
@@ -3147,8 +3147,11 @@ compare_bound (gfc_expr *a, gfc_expr *b)
|| b == NULL || b-expr_type != EXPR_CONSTANT)
return CMP_UNKNOWN;
+ /* If either of the types isn't INTEGER, we must have
+ raised an error earlier. */
+
if (a-ts.type != BT_INTEGER || b-ts.type != BT_INTEGER)
-gfc_internal_error (compare_bound(): Bad expression);
+return CMP_UNKNOWN;
i = mpz_cmp (a-value.integer, b-value.integer);
! { dg-do compile }
! PR 34305 - make sure there's an error message for specifying a
program test
parameter (datasize = 1000)
dimension idata (datasize) ! { dg-error must be of INTEGER type|must have constant shape }
idata (1) = -1
end
[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31081
[Bug ada/15605] invalid program not detected, RM 8.3(22), 8.5.4(6)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15605
[Bug libstdc++/34498] New: FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test
Executing on host: /mnt/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/mnt/gnu/gcc/o bjdir/./gcc -nostdinc++ -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3 /src -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/g nu/gcc/gcc-4.2.3/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.2.3/hppa2.0w-hp -hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.2.3/hppa2.0w-hp-hpux11.11/include -i system /opt/gnu/gcc/gcc-4.2.3/hppa2.0w-hp-hpux11.11/sys-include -g -O2 -D_GLIBCX X_ASSERT -fmessage-length=0 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/mnt/gnu/gcc/ob jdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu /gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/mnt/gnu/gcc/gcc/libstd c++-v3/libsupc++ -I/mnt/gnu/gcc/gcc/libstdc++-v3/include/backward -I/mnt/gnu/gcc /gcc/libstdc++-v3/testsuite/util /mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/22_loca le/global_templates/standard_facet_hierarchies.cc-include bits/stdc++.h ./li btestc++.a -lm -o ./standard_facet_hierarchies.exe(timeout = 600) PASS: 22_locale/global_templates/standard_facet_hierarchies.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc:/mnt/gnu/gcc/objdir/hppa2.0w -hp-hpux11.11/./libstdc++-v3/src/.libs::/mnt/gnu/gcc/objdir/gcc:/mnt/gnu/gcc/obj dir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test -- Summary: FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34498
[Bug fortran/21881] ICE instead of error for large arrays in derived types
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-12-16 19:38 --- I'll do this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-10-01 10:52:19 |2007-12-16 19:38:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21881
[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test
--- Comment #1 from hp at gcc dot gnu dot org 2007-12-16 19:45 --- Exactly the same for cris-elf. -- hp at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11, cris- ||elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34498
[Bug testsuite/34499] New: FAIL: g++.dg/ext/visibility/namespace2.C (test for excess errors)
Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/mnt/gnu/gc c/objdir/gcc/testsuite/g++/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visi bility/namespace2.C -nostdinc++ -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib stdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11 .11/libstdc++-v3/include -I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/mnt/gnu/gc c/gcc/libstdc++-v3/include/backward -I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/ut il -fmessage-length=0 -fvisibility=hidden -S -o namespace2.s(timeout = 30 0) /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C: In member fun ction 'void Test::test()': /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C:20: warning: v isibility attribute not supported in this configuration; ignored output is: /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C: In member fun ction 'void Test::test()': /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C:20: warning: v isibility attribute not supported in this configuration; ignored FAIL: g++.dg/ext/visibility/namespace2.C (test for excess errors) Excess errors: /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C:20: warning: v isibility attribute not supported in this configuration; ignored -- Summary: FAIL: g++.dg/ext/visibility/namespace2.C (test for excess errors) Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34499
[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-16 20:06 --- Subject: Re: FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test Exactly the same for cris-elf. There's probably a missing check for named locales. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34498
[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test
--- Comment #3 from pcarlini at suse dot de 2007-12-16 20:22 --- Already noticed here: http://gcc.gnu.org/ml/libstdc++/2007-12/msg00059.html I'm adding Benjamin in CC. -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-12-16 20:22:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34498
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2007-12-16 20:23 --- Created an attachment (id=14782) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14782action=view) preprocessed source file from sse3_1-insertps-2.c testcase on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2007-12-16 20:24 --- Created an attachment (id=14783) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14783action=view) assembly file from sse3_1-insertps-2.c testcase on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug fortran/34246] gfortran.dg/bind_c_usage_16.f03 doesn't work
--- Comment #14 from burnus at gcc dot gnu dot org 2007-12-16 20:24 --- Subject: Bug 34246 Author: burnus Date: Sun Dec 16 20:24:32 2007 New Revision: 130991 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130991 Log: 2007-12-16 Tobias Burnus [EMAIL PROTECTED] PR fortran/34246 * trans-types.c (gfc_init_types): Change build_type_variant to build_qualified_type. (gfc_sym_type): Return gfc_character1_type_node for character-returning bind(C) functions. * trans-expr.c (gfc_conv_function_call): Do not set se-string_length for character-returning bind(c) functions. (gfc_trans_string_copy,gfc_trans_scalar_assign): Support also single characters. 2007-12-16 Tobias Burnus [EMAIL PROTECTED] PR fortran/34246 * gfortran.dg/bind_c_usage_16.f03: Extend test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_usage_16.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #17 from rakdver at gcc dot gnu dot org 2007-12-16 20:29 --- A possible way how to solve the problem: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00769.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug fortran/34500] New: Bind(C): Character returning function with ENTRY gives ICE
Test case:
function test() bind(C)
use iso_c_binding
implicit none
character(len=1,kind=c_char) :: test, bar
entry bar() bind(C)
end function test
ICE occurs if either test() or bar() or both are bind(c).
The ENTRY fix needs to go into build_entry_thunks:
if (thunk_sym-attr.function)
{
if (gfc_return_by_reference (ns-proc_name))
{
This branch is entered as the master function, proc_name, is is_bind_c ==
false, but it fails currently if (thunk_sym-attr.is_bind_c
thunk_sym-ts.type == BT_CHARACTER).
The proper tree should looks more or less as follows:
test2 ()
{
character(kind=1) tmp[1:1];
integer(kind=4) len;
master.0.test2 (0, tmp, len);
return tmp[1];
That is test() itself returns a scalar character, but master.0.test2 takes the
string as argument, which allows to combine bind(C) with non-bind(C) functions
and allows for different string lengths of ENTRY and function (cf. PR 34421).
--
Summary: Bind(C): Character returning function with ENTRY gives
ICE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32630
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34500
[Bug fortran/34246] gfortran.dg/bind_c_usage_16.f03 doesn't work
--- Comment #15 from burnus at gcc dot gnu dot org 2007-12-16 20:37 --- FIXED on the trunk (4.3.0). Please open a new bug if there are new/remaining problems. The Bind(C) ENTRY part of this PR is now tracked as PR 34500. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
[Bug tree-optimization/34501] New: The vector cost model does not seem suited for Intel Core2Duo
For the induct.f90 test case from the polyhedron test suite, I get the following timings (revision 130990): [ibook-dhum] lin/source% time gfc -O3 -ffast-math -funroll-loops induct.f90 11.226u 0.496s 0:12.42 94.2%0+0k 0+54io 15pf+0w [ibook-dhum] lin/source% time a.out tmp 91.148u 0.092s 1:31.27 99.9%0+0k 0+9io 12pf+0w [ibook-dhum] lin/source% time gfc -O3 -ffast-math -funroll-loops --param min-vect-loop-bound=1 induct.f90 11.205u 0.492s 0:11.84 98.7%0+0k 0+27io 0pf+0w [ibook-dhum] lin/source% time a.out tmp 91.145u 0.096s 1:31.24 99.9%0+0k 0+4io 0pf+0w [ibook-dhum] lin/source% time gfc -O3 -ffast-math -funroll-loops --param min-vect-loop-bound=2 induct.f90 11.101u 0.491s 0:11.78 98.3%0+0k 0+17io 0pf+0w [ibook-dhum] lin/source% time a.out tmp 73.596u 0.054s 1:13.65 99.9%0+0k 0+9io 0pf+0w Am I correct to understand that for this revisions -O3 implies vectorization+cost_model? If yes, it seems that the cost model should be tuned for the Intel Core2Duo. -- Summary: The vector cost model does not seem suited for Intel Core2Duo Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34501
[Bug fortran/34305] ICE with array(real) declaration
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-12-16 21:09 --- Subject: Bug 34305 Author: tkoenig Date: Sun Dec 16 21:09:34 2007 New Revision: 130993 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130993 Log: 2007-12-16 Thomas Koenig [EMAIL PROTECTED] PR fortran/34305 * resolve.c (compare_bound): If either of the types of the arguments isn't INTEGER, return CMP_UNKNOWN. 2007-12-16 Thomas Koenig [EMAIL PROTECTED] PR fortran/34305 * gfortran.dg/real_dimension_1.f: New test case. Added: trunk/gcc/testsuite/gfortran.dg/real_dimension_1.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34305
[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-12-16 21:11 --- I disagree with Andrew's Comment #4. Once we implement a feature in the compiler, users should reasonably expect it to be correct. We cannot simultaneously say Look, we have exciting new C++0x features! and Oh, you found a bug? That's not very serious, since it's just a new C++0x feature. Thus, I've upgraded this to P1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33943
[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |enhancement Component|tree-optimization |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34501
[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2007-12-16 21:27 --- Filed as Radar Problem ID: 5650346. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34497
[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-12-16 21:27 --- (In reply to comment #5) I disagree with Andrew's Comment #4. Once we implement a feature in the compiler, users should reasonably expect it to be correct. We cannot simultaneously say Look, we have exciting new C++0x features! and Oh, you found a bug? That's not very serious, since it's just a new C++0x feature. I seriously disagree, this is not a regression in that code never was supported before and really C++0x support should not block the release just because people feel this is an important feature of 4.3.0. Also another thing is that we have some ODR violations in libstdc++ that the libstdc++ folks have not replied to me about yet. See http://gcc.gnu.org/ml/libstdc++/2007-08/msg00032.html and some others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33943
