[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use
--- Comment #16 from rakdver at gcc dot gnu dot org 2007-06-17 06:38 --- (In reply to comment #12) So this is now an enhancement request for sccp to honor loop roll count or basic-block frequency and cost of the replacement. we used to take the cost of the replacement into account. It caused so many missed-optimization PRs that I decided to just disable it. The main problem is that while theoretically you can determine whether replacement is more costly then performing the computation in the loop (although even this is nontrivial in practice), it is very difficult to estimate the gains of enabling further optimizations. One possible solution would be to annotate the division by the expected value of the result. Division expanders then may decide whether to expand to machine instruction/libcall or to check for small values of the result in if-guards first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug fortran/32239] optimize power in loops, use __builtin_powi instead of _gfortran_pow_r4_i4
--- Comment #2 from jb at gcc dot gnu dot org 2007-06-17 06:39 --- Assigning to myself, this should be easy to fix. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-08 10:11:40 |2007-06-17 06:39:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32239
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-17 06:54 --- Size of the compilers, efficiency of both compiler and generated code are clearly secondary Do you even know why I added POINTER_PLUS_EXPR? Did you even read my reply to Jeff Law on why I started working on this project? My reply to Jeff explains that generated code was my reason. On SPU, you have only loads that are only 128 bit long and the alignment is 128 bits only. So we need better alignment information prograted down from the tree level to the RTL level. http://gcc.gnu.org/ml/gcc/2007-05/msg00691.html I guess you did not look at the other bug reports or commented on due to pointer_plus either? Where the code gen has been improved. I guess you are making comments to just make comments. And what does pointer_plus, SSE, Altivec have in common. Besides me caring about 2 of those. Nothing. In fact the later two have less in common than you think. Yes they are both vector extensions. I will mention about Altivec (VMX for me), I work on the PS3 toolchain and I really really do care about code generation and performance of the compiler. I work mostly on the PPU (PowerPC) side of things but every once in a while I work on the SPU side. If you want to compile only standards conforming code, then use -pedantic-errors as documented in the GCC manual which it seems you don't read. This is not a bug as --disable-decimal-float disables the C/C++ interfaces to the underlaying GCC support. Guess you don't understand that GCC is more than a C/C++ compiler. GCC stands for GNU Compiler Collection and NOT GNU C Compiler. One more thing about pointer plus, have you seen how much time I actually spent on working on this project? It took more around 6.5 months (including time working on other stuff). I guess you don't care that I needed approval from my manager to work on this project and then get approval to apply it and also review time also? If you don't see the last two, then you need to read the GCC lists better. I was very open about what currently works and what I could test. I don't think you have a right to tell me that my work is shit when you obviously did not read anything I have done about being straight forward about this project. Yes pointer plus was a big project, it was needed to allow GCC to complete with other compilers, even to get code generation back to where it was in 3.4 in many many cases. Take a look at PR 18412, PR 29708, PR 32273, PR 16913 (which still has issues but the main issue is solved by pointer_plus), PR 20643 (which is improved by pointer_plus but I don't know if it is all the way fixed), PR 21485 (where the original testcase fixed by pointer_plus), PR 28690 is helped by pointer plus (got SPEC results for Power6 with pointer plus vs without). So what more do you want? that is 7 code generation issues, some of them are regressions fixed/helped by pointer_plus. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug rtl-optimization/32372] New: [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
I'm getting the following ICE with trunk on x86_64. It compiles fine
on ia64 and powerpc.
(sid)2653:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2
mplayer-mpegvideo.c
mplayer-mpegvideo.c: In function 'MPV_encode_init':
mplayer-mpegvideo.c:21: internal compiler error: in df_refs_verify, at
df-scan.c:4065
Please submit a full bug report,
Testcase:
typedef struct AVCodecContext
{
int flags;
void *priv_data;
char codec_name[32];
}
AVCodecContext;
typedef struct ScanTable
{
int obmc;
int umvplus;
int h263_aic;
}
MpegEncContext;
MPV_encode_init (AVCodecContext *avctx)
{
MpegEncContext *s = avctx-priv_data;
s-umvplus = (avctx-flags 0x0200) ? 1 : 0;
s-h263_aic = (avctx-flags 0x0100) ? 1 : 0;
s-h263_aic = s-obmc || s-umvplus;
}
--
Summary: [4.3 Regression] ICE in df_refs_verify, at df-
scan.c:4065
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug rtl-optimization/32372] [4.3 Regression] ICE in df_refs_verify, at df-scan.c:4065
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #5 from rask at sygehus dot dk 2007-06-17 08:43 --- I agree that the insn is invalid. It probably should be something like this: (parallel [ (set (reg:PSI 7 fb) (mem:PSI (reg:PSI 7 fb) [0 S4 A8])) (set (reg:PSI 8 sp) (plus:PSI (reg:PSI 7 fb) (const_int 2 [0x2]))) (return) ]) I.e. one set of sp and fb each. The faulty pattern is named epilogue_exitd. The two patterns prologue_enter_16 and prologue_enter_24 are also broken in that they use (parallel [ ... (pre_dec (SP_REGNO)) (set (SP_REGNO) ...) ]) which is just another invalid use of PARALLEL. DJ? On the AVR, my bets are on the define_insn call_prologue_saves with two sets of (reg:HI SP_REG) inside the implicit parallel. -- rask at sygehus dot dk changed: What|Removed |Added GCC target triplet|m32c-unknown-elf|m32c-unknown-elf avr- ||unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug tree-optimization/32093] BOOT_CFLAGS=-O2 -g -msse2 -ftree-vectorize causes dfp tests to fail
--- Comment #3 from ubizjak at gmail dot com 2007-06-17 08:53 --- (In reply to comment #2) i'm wondering if this could be related to a problem we're seeing with segfaults caused by misaligned movdqa instructions in zlib compiled with -ftree-vectorize. Please open a new bug for this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32093
[Bug rtl-optimization/32366] [4.3 Regression] Segfault in significand_size with -ftree-vectorize
--- Comment #4 from ubizjak at gmail dot com 2007-06-17 11:34 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01171.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg01171.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2007-06-17 11:34:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32366
[Bug fortran/32239] optimize power in loops, use __builtin_powi instead of _gfortran_pow_r4_i4
--- Comment #3 from patchapp at dberlin dot org 2007-06-17 11:40 --- Subject: Bug number PR32239 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01172.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32239
[Bug tree-optimization/32367] [4.3 Regression] internal compiler error: in build_polynomial_chrec, at tree-chrec.h:113
--- Comment #9 from spop at gcc dot gnu dot org 2007-06-17 13:38 ---
Subject: Re: [4.3 Regression] internal compiler error: in
build_polynomial_chrec, at tree-chrec.h:113
{{BinomialCoefficients[0], +, 4}_1, +, {0, +, 4}_1}_1
does not look good: the left part should be invariant in loop_1.
It's most certainly the code in scev analysis that is in fault here.
I'll have a look. Thanks for pointing me to the bug.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32367
[Bug middle-end/32349] [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-17 13:51
---
Subject: Re: [4.3 Regression] ICE in df_refs_verify
with -O2 -fmodulo-sched for spec tests
This patch fixes the df issues with modulo scheduling. It simply never
worked and was not tested because there is no default test coverage for it.
I have added the testcase that janis sent me, but this is a completely
inadequate test for this pass.
Janis did test this fix with the spec benchmarks on the ppc and it did
work.
The last frag was suggested by stevenb. If you free the dominance info
before gettting out of cfglayout it is faster since the dominance does
not have to be updated.
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32349
* modulo-sched (generate_reg_moves): Added rescan parameter and if
this is true, rescan insn being modified.
(sms_schedule): Added rescan parameter.
(rest_of_handle_sms): Moved freeing of dominance info to before
getting out of cfg_layout.
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
* gcc.c-torture/compile/pr32349.c: New testcase.
ok to commit?
Kenny
Index: testsuite/gcc.c-torture/compile/pr32349.c
===
--- testsuite/gcc.c-torture/compile/pr32349.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr32349.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-options -O2 -fmodulo-sched } */
+
+
+extern long *x1, *x2, *x3;
+
+int
+foo ()
+{
+ /* Switching the following two lines prevents the ICE. */
+ long *p1, *p2;
+ long m, n, i;
+
+ p1 = x1;
+ p2 = x2;
+ n = 0;
+ for (i = *x3; 0 i; i--)
+{
+ m = (*p1++) ^ (*p2++);
+ m = (m 0x) + ((m 1) 0x);
+ m = (m 0x) + ((m 2) 0x);
+ m = (m + (m 4)) 0x0f0f0f0f;
+ m = (m + (m 8));
+ n += m;
+}
+ return n;
+}
Index: modulo-sched.c
===
--- modulo-sched.c (revision 125775)
+++ modulo-sched.c (working copy)
@@ -426,7 +426,7 @@ calculate_maxii (ddg_ptr g)
ii { 1 if not.
*/
static struct undo_replace_buff_elem *
-generate_reg_moves (partial_schedule_ptr ps)
+generate_reg_moves (partial_schedule_ptr ps, bool rescan)
{
ddg_ptr g = ps-g;
int ii = ps-ii;
@@ -523,6 +523,8 @@ generate_reg_moves (partial_schedule_ptr
}
replace_rtx (g-nodes[i_use].insn, old_reg, new_reg);
+ if (rescan)
+ df_insn_rescan (g-nodes[i_use].insn);
}
prev_reg = new_reg;
@@ -1151,7 +1153,7 @@ sms_schedule (void)
/* Generate the kernel just to be able to measure its cycles. */
permute_partial_schedule (ps, g-closing_branch-first_note);
- reg_move_replaces = generate_reg_moves (ps);
+ reg_move_replaces = generate_reg_moves (ps, false);
/* Get the number of cycles the new kernel expect to execute in. */
new_cycles = kernel_number_of_cycles (BB_HEAD (g-bb), BB_END
(g-bb));
@@ -1201,7 +1203,7 @@ sms_schedule (void)
/* The life-info is not valid any more. */
df_set_bb_dirty (g-bb);
- reg_move_replaces = generate_reg_moves (ps);
+ reg_move_replaces = generate_reg_moves (ps, true);
if (dump_file)
print_node_sched_params (dump_file, g-num_nodes);
/* Generate prolog and epilog. */
@@ -2481,8 +2483,8 @@ rest_of_handle_sms (void)
FOR_EACH_BB (bb)
if (bb-next_bb != EXIT_BLOCK_PTR)
bb-aux = bb-next_bb;
- cfg_layout_finalize ();
free_dominance_info (CDI_DOMINATORS);
+ cfg_layout_finalize ();
#endif /* INSN_SCHEDULING */
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
--- Comment #6 from zadeck at naturalbridge dot com 2007-06-17 14:01 --- Subject: Re: libgcc build failure, ICE in cselib_record_set, at cselib.c:1508 rask at sygehus dot dk wrote: --- Comment #5 from rask at sygehus dot dk 2007-06-17 08:43 --- I agree that the insn is invalid. It probably should be something like this: (parallel [ (set (reg:PSI 7 fb) (mem:PSI (reg:PSI 7 fb) [0 S4 A8])) (set (reg:PSI 8 sp) (plus:PSI (reg:PSI 7 fb) (const_int 2 [0x2]))) (return) ]) I.e. one set of sp and fb each. The faulty pattern is named epilogue_exitd. The two patterns prologue_enter_16 and prologue_enter_24 are also broken in that they use (parallel [ ... (pre_dec (SP_REGNO)) (set (SP_REGNO) ...) ]) which is just another invalid use of PARALLEL. DJ? On the AVR, my bets are on the define_insn call_prologue_saves with two sets of (reg:HI SP_REG) inside the implicit parallel. i assume that you will resolve this with the port maintainers and contact me when you hit the next dataflow related problem. Good luck. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug fortran/32373] New: not vectorized: can't determine dependence (equivalence)
gfortran -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -c k90.f90 Shows missed vectorization at source lines 125,332,380, 638 These problems appear to be associated with the EQUIVALENCE (source line 92), which names one or more of the arrays involved. -- Summary: not vectorized: can't determine dependence (equivalence) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #17 from rob1weld at aol dot com 2007-06-17 14:07 --- Due to the bugs in mpfr ( http://www.mpfr.org/mpfr-2.2.1/#bugs ) we should probably _require_ a recent version. It would be kind of someone else to make that patch - I am kinda busy at the moment. The section File: mpfr.info, Node: Miscellaneous Functions provides the macros. Mpfr p5 may have bugs in it but it is the newest available so we should require that version at least. Using an old version (without an expect script to print a WARNING: line in the testsuite) will drive people buggy trying to find out why their code is broken when in fact it is the user's library that is needing fixing. Applying these changes can clean a few errors off the testsuite and put us a step closer to a release. Please don't prefer patching the testsuite to skip tests on the basis that the user has an old unsupported version of mpfr. The lines in configure that need changes are: #if MPFR_VERSION MPFR_VERSION_NUM(2,2,0) #if MPFR_VERSION MPFR_VERSION_NUM(2,2,1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug fortran/32373] not vectorized: can't determine dependence (equivalence)
--- Comment #1 from tprince at computer dot org 2007-06-17 14:11 --- Created an attachment (id=13718) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13718action=view) source code which reproduces problem with equivalence This source code is derived from the public version posted at http://www.llnl.gov/asci_benchmarks/asci/limited/lfk/README.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
[Bug middle-end/32349] [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
--- Comment #3 from paolo dot bonzini at lu dot unisi dot ch 2007-06-17 14:14 --- Subject: Re: [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests ok to commit? Yes. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug rtl-optimization/32374] New: dataflow bug: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
Current mainline GCC ICEs when compiling attached testcase:
g++ -O2 037.cpp
037.cpp: In function void unix_parse_conf_file(FILE*, const char*, bool):
037.cpp:58: error: insn does not satisfy its constraints:
(insn 50 45 10 2 (set (reg/f:DI 54 virtual-stack-vars)
(reg:DI 0 ax)) 82 {*movdi_1_rex64} (nil))
037.cpp:58: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
This invalid RTL is created by new init-regs pass, trying to initialize
virtual-stack-vars:
(insn 45 6 9 2 (set (reg/f:DI 54 virtual-stack-vars)
(const_int 0 [0x0])) -1 (nil))
(insn 9 45 10 2 037.cpp:50 (clobber (mem/s/c:BLK (plus:DI (reg/f:DI 54
virtual-stack-vars)
(const_int -16 [0xfff0])) [4 A128])) -1 (nil))
--
Summary: dataflow bug: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
GCC build triplet: x86_64-pc-gnu-linux
GCC host triplet: x86_64-pc-gnu-linux
GCC target triplet: x86_64-pc-gnu-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug rtl-optimization/32374] dataflow bug: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #1 from ubizjak at gmail dot com 2007-06-17 14:50 --- Created an attachment (id=13719) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13719action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug fortran/32375] New: not vectorized: can't determine dependence (array sections)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s414a.f The source and destination sections of aa(:,:) do not overlap, unless there is a subscript over-run. Even that case could be taken care of by loop reversal. This is a simplification of a case from: http://www.netlib.org/benchmark/vectors -- Summary: not vectorized: can't determine dependence (array sections) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
[Bug fortran/32375] not vectorized: can't determine dependence (array sections)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:04 --- Created an attachment (id=13720) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13720action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
[Bug fortran/32376] New: can't determine dependence (array with variable initial index)
The original case from http://www.netlib.org/benchmark/vectors is split into 2 array assignments which should be easily vectorizable. The first assignment, which starts at the base of the arrays, is vectorized. The second assignment, which begins where the first left off, is not vectorized. -- Summary: can't determine dependence (array with variable initial index) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32376
[Bug fortran/32376] can't determine dependence (array with variable initial index)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:15 --- Created an attachment (id=13721) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13721action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32376
[Bug fortran/32377] New: can't determine dependence (source/destination overlap)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s243.f The first array assignment is vectorized. The second, which involves overlap between source and destination, should be no problem to vectorize as long as the loop is not reversed. Significant advantage should be gained by fusion. Simplified from http://www.netlib.org/benchmark/vectors -- Summary: can't determine dependence (source/destination overlap) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/32377] can't determine dependence (source/destination overlap)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:26 --- Created an attachment (id=13722) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13722action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #5 from patchapp at dberlin dot org 2007-06-17 15:35 --- Subject: Bug number PR32236 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01185.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug fortran/32378] New: can't determine dependence (distinct sections of an array)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s174.f The two sections of the array are clearly distinct, so it should be vectorized. -- Summary: can't determine dependence (distinct sections of an array) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug fortran/32378] can't determine dependence (distinct sections of an array)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:36 --- Created an attachment (id=13723) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13723action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug fortran/32379] New: can't determine dependence (loop reversal required)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s112.f The case could be vectorized by taking the array elements in reverse order (as specified in the source). ifort vectorizes by creating a temporary array (when the reversal is removed from the source), losing performance. -- Summary: can't determine dependence (loop reversal required) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32379
[Bug fortran/32379] can't determine dependence (loop reversal required)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:45 --- Created an attachment (id=13724) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13724action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32379
[Bug fortran/32380] New: reports unaligned store and can't determine dependence
gfortran -O2 -fcray-pointer -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v unal.f There are several reports of unsupported unaligned store or can't determine dependence between .. The loops which report unaligned store vectorize OK when taken in isolation. The reports of can't determine dependence appear to refer to the use of multiple sections of the same array. These sections cannot overlap unless there is a subscript range violation. Even if there were such a violation, it could be taken care of by changing the order. -- Summary: reports unaligned store and can't determine dependence Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
[Bug fortran/32380] reports unaligned store and can't determine dependence
--- Comment #1 from tprince at computer dot org 2007-06-17 16:29 --- Created an attachment (id=13725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13725action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
[Bug fortran/25079] No error on assignment to unassociated pointer component
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-17 17:12 --- This is fixed somehow: $ gfc pr25079.f90 pr25079.f90:5.5: a=T0(1) 1 Error: The element in the derived type constructor at (1), for pointer component 'i' should be a POINTER or a TARGET -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25079
[Bug rtl-optimization/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|dataflow bug: internal |[4.3 Regression] internal |compiler error: in |compiler error: in |reload_cse_simplify_operands|reload_cse_simplify_operands |, at postreload.c:396 |, at postreload.c:396 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug tree-optimization/32367] [4.3 Regression] internal compiler error: in build_polynomial_chrec, at tree-chrec.h:113
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-17 17:32
---
{{BinomialCoefficients[0], +, 4}_1, +, {0, +, 4}_1}_1
does not look good: the left part should be invariant in loop_1.
It's most certainly the code in scev analysis that is in fault here.
I'll have a look. Thanks for pointing me to the bug.
Ok, thanks. Just to let people know, {{BinomialCoefficients[0], +, 4}_1, +,
{0, +, 4}_1}_1 was also showing up on the trunk before the pointer_plus was
merged in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32367
[Bug middle-end/32349] [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
--- Comment #4 from zadeck at gcc dot gnu dot org 2007-06-17 17:51 --- Subject: Bug 32349 Author: zadeck Date: Sun Jun 17 17:51:25 2007 New Revision: 125776 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125776 Log: 2007-06-17 Kenneth Zadeck [EMAIL PROTECTED] PR middle-end/32349 * modulo-sched (generate_reg_moves): Added rescan parameter and if this is true, rescan insn being modified. (sms_schedule): Added rescan parameter. (rest_of_handle_sms): Moved freeing of dominance info to before getting out of cfg_layout. 2007-06-17 Kenneth Zadeck [EMAIL PROTECTED] * gcc.c-torture/compile/pr32349.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32349.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug middle-end/32349] [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-17 17:52
---
Subject: Re: [4.3 Regression] ICE in df_refs_verify
with -O2 -fmodulo-sched for spec tests
committed as revision 125776
Kenneth Zadeck wrote:
This patch fixes the df issues with modulo scheduling. It simply never
worked and was not tested because there is no default test coverage for it.
I have added the testcase that janis sent me, but this is a completely
inadequate test for this pass.
Janis did test this fix with the spec benchmarks on the ppc and it did
work.
The last frag was suggested by stevenb. If you free the dominance info
before gettting out of cfglayout it is faster since the dominance does
not have to be updated.
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32349
* modulo-sched (generate_reg_moves): Added rescan parameter and if
this is true, rescan insn being modified.
(sms_schedule): Added rescan parameter.
(rest_of_handle_sms): Moved freeing of dominance info to before
getting out of cfg_layout.
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
* gcc.c-torture/compile/pr32349.c: New testcase.
ok to commit?
Kenny
Index: testsuite/gcc.c-torture/compile/pr32349.c
===
--- testsuite/gcc.c-torture/compile/pr32349.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr32349.c (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-options -O2 -fmodulo-sched } */
+
+
+extern long *x1, *x2, *x3;
+
+int
+foo ()
+{
+ /* Switching the following two lines prevents the ICE. */
+ long *p1, *p2;
+ long m, n, i;
+
+ p1 = x1;
+ p2 = x2;
+ n = 0;
+ for (i = *x3; 0 i; i--)
+{
+ m = (*p1++) ^ (*p2++);
+ m = (m 0x) + ((m 1) 0x);
+ m = (m 0x) + ((m 2) 0x);
+ m = (m + (m 4)) 0x0f0f0f0f;
+ m = (m + (m 8));
+ n += m;
+}
+ return n;
+}
Index: modulo-sched.c
===
--- modulo-sched.c(revision 125775)
+++ modulo-sched.c(working copy)
@@ -426,7 +426,7 @@ calculate_maxii (ddg_ptr g)
ii { 1 if not.
*/
static struct undo_replace_buff_elem *
-generate_reg_moves (partial_schedule_ptr ps)
+generate_reg_moves (partial_schedule_ptr ps, bool rescan)
{
ddg_ptr g = ps-g;
int ii = ps-ii;
@@ -523,6 +523,8 @@ generate_reg_moves (partial_schedule_ptr
}
replace_rtx (g-nodes[i_use].insn, old_reg, new_reg);
+ if (rescan)
+ df_insn_rescan (g-nodes[i_use].insn);
}
prev_reg = new_reg;
@@ -1151,7 +1153,7 @@ sms_schedule (void)
/* Generate the kernel just to be able to measure its cycles. */
permute_partial_schedule (ps, g-closing_branch-first_note);
- reg_move_replaces = generate_reg_moves (ps);
+ reg_move_replaces = generate_reg_moves (ps, false);
/* Get the number of cycles the new kernel expect to execute in. */
new_cycles = kernel_number_of_cycles (BB_HEAD (g-bb), BB_END
(g-bb));
@@ -1201,7 +1203,7 @@ sms_schedule (void)
/* The life-info is not valid any more. */
df_set_bb_dirty (g-bb);
- reg_move_replaces = generate_reg_moves (ps);
+ reg_move_replaces = generate_reg_moves (ps, true);
if (dump_file)
print_node_sched_params (dump_file, g-num_nodes);
/* Generate prolog and epilog. */
@@ -2481,8 +2483,8 @@ rest_of_handle_sms (void)
FOR_EACH_BB (bb)
if (bb-next_bb != EXIT_BLOCK_PTR)
bb-aux = bb-next_bb;
- cfg_layout_finalize ();
free_dominance_info (CDI_DOMINATORS);
+ cfg_layout_finalize ();
#endif /* INSN_SCHEDULING */
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug middle-end/32349] [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
--- Comment #6 from zadeck at naturalbridge dot com 2007-06-17 17:53 --- fixed as committed. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #14 from pault at gcc dot gnu dot org 2007-06-17 17:54 --- A slight modification of the example in comment #2: MODULE TEST CONTAINS FUNCTION s2a_3(s1) RESULT(a) CHARACTER(LEN=*), INTENT(IN) :: s1 CHARACTER(LEN=LEN(s1)) :: a(3) a(1)=s1 END FUNCTION END MODULE USE TEST character(LEN=1000) :: b(3) b=s2a_3(REPEAT(1,101)) write(6,*) b(1) END yields something that works at any level of optimization. Note that the main program remains untouched, except for all the code that comes from the interface evaluation of the character length. Oddly, the POINTER_PLUS bit remains unchanged. I have stared at the code, trying to understand where an optimization senstivity might come in, with no success. Perhaps, somebody smarter than me will see the difference. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug rtl-optimization/32374] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-17 18:00 ---
Reduced testcase:
typedef long unsigned int size_t;
extern int *stderr;
void f(int *, const char *, ...);
void g (const char *conf_name)
{
typedef struct
{
const char *label;
const int value;
} Section;
const Section sections[2] =
{ {, 0}, {, 1} };
f (stderr, , , conf_name, 0, sections[0]);
f (stderr, , , conf_name, 0, sections[0]);
}
--- cut
Note I think the orginal reduced testcase had undefined code at runtime
invoking fprintf with %s with a struct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-17 18:00:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32374
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #9 from malitzke at metronets dot com 2007-06-17 18:01 --- Thank you for your very informative post. What we have between us is really a philosophical difference. To me C is a portable assembler and my extensive review of Ritchie's writings and acceptance speech for the Turing award leads me to believe that the correct code generation under absolute control of the programmer was paramount. Even the portability issue came much later at Bell Labs. That was when to my reckoning Ritche handed over C to the PCC (portable C compiler) crowd using LEX YACC etc. Yes, to me there is profound truth in Optimize, don't. Instead look for a better algorithm. And, as as an engineer a soldering iron and a screwdriver (a better CPU and support chips like the Cell processor) are among the best optimization tools. FORTRAN was actually my first high level language and my first significant FORTRAN (formula translation) ran on the day President Kennedy was murdered, and the computer center closed. I worked on systems with triple computer redundancy and and majority voting. Boy, would I have loved a Ritchie type C compiler. One of my best accomplishments was cutting the interrupt line and and making that central office telephone exchange into scanning system and handle the contractual specified 95000 calls per hour instead of 67000. It lso made me the best hated guy in that development lab and led to a very profitable job change. Yes, I consider JAVA an abomination, I still harbor a remnant of respect for SUN because of the NFS (network file system). When Dr. hc. William Gates admitted that C++ set back Microsoft two years; it my made not only my day but my whole month. His genius is in motivating nerds to work 12-16 hours a day producing lousy code and not as progamer (somebody else wrote a vital part of the BASIC interpreter). C with classes is fantastic to somebody whose thesis contained a discrete event simulation package written in FORTRAN and assembly. Microsoft and Academia reduced C++ to the recent quip When your tool is C++, the world is reduced to thumbs (half-assed quote). KR second program Fahrenheit-Celsius uses integers and not floating point. Based on that and knowing that existed no decent FORTRAN compilers on the early UNIX machines I take it that floating point was more a political necessity than a technical requirement. I would love to eliminate floating point from C and use fortran-95 for my numerical solutions of stiff partial differential equations. Now your first four paragraphs and my previous comment realy express the same thing, but from different perspective. Let me quote great because it makes GCC more transparent and comprehensible What I meant with this is that GCC now has one more leg built on sound principle instead of a (perheaps jumble of ad-hoc stuff. This in creases my confidence the addresses generated point to the right object. This put you as the lead guy into the same league as Diego Novillo, Sebastian Pop, Palo Carlini, Zdenek Dvorak I had the priviledge of helping in a small way. In my book this a big step up from bug-man. To system houses, chip manufacturers, gcc collegues obsessed with optimization you had to stress the speed-up. I want assurance that the code generated produces the right result, even if it makes the compiled bigger and the code generated for small arrays a tad slower. To me POINTER_PLUS affects code throughout the compiler collection and not just some instruction on some architecture. I am quite willing to write you a glowing recommendations should you think it appropriate. That we rub each other at times the wrong way is unfortunate bu no really relevant. Proof that you are doing great, from my perspective, Is that when I checked the Changelog after svn I searched and found your technical write-up, understood that this good stuff and immediately did a a bootstrap. It certainly produced no discernable degradation which is great no a new fundamental step. Altivec and SSE really produce benefits in a relatively small corner of the overal picture, They are, again in my book, part of their architectures more for competive reason than producing fundamental improvements. However changes to the config tree and to code generation to me far outweigh the benefits overall. But it seems imppossible to quarantine them. I have to admit that DFA really rubs me the wrong way for C. Finally, there exists huge, to me bloated, file called cc1. This is the C compiler and not GCC. Again I admit that I really only care about cc2 and f951, I tolerate cc1plus, and the rest have no place on my machines, I own those machines and aunder the GNU and UNIX philosophy that is up to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug tree-optimization/32367] [4.3 Regression] internal compiler error: in build_polynomial_chrec, at tree-chrec.h:113
--- Comment #11 from spop at gcc dot gnu dot org 2007-06-17 19:13 ---
Subject: Re: [4.3 Regression] internal compiler error: in
build_polynomial_chrec, at tree-chrec.h:113
The ptrplus patch contains the following code:
*** interpret_rhs_modify_stmt (struct loop *
*** 1611,1616
--- 1615,1630
switch (TREE_CODE (opnd1))
{
+ case POINTER_PLUS_EXPR:
+ opnd10 = TREE_OPERAND (opnd1, 0);
+ opnd11 = TREE_OPERAND (opnd1, 1);
+ chrec10 = analyze_scalar_evolution (loop, opnd10);
+ chrec11 = analyze_scalar_evolution (loop, opnd11);
+ chrec10 = chrec_convert (type, chrec10, at_stmt);
+ chrec11 = chrec_convert (sizetype, chrec11, at_stmt);
+ res = chrec_fold_plus (type, chrec10, chrec11);
+ break;
+
case PLUS_EXPR:
opnd10 = TREE_OPERAND (opnd1, 0);
opnd11 = TREE_OPERAND (opnd1, 1);
At this point we have the following values:
(gdb) call debug_generic_expr (chrec10)
{ptr_7, +, (unsigned int) (n_20 + 65535) * 4}_1
(gdb) call debug_generic_expr (chrec11)
(unsigned int) {n_6 + 65535, +, 1}_1 * 4
(gdb) call debug_generic_expr (res)
{ptr_7 + (unsigned int) {n_6 + 65535, +, 1}_1 * 4, +, (unsigned int)
(n_20 + 65535) * 4}_1
chrec_fold_plus is completely disturbed by the complicated MULT_EXPR
{}_1 * 4, and just considers this expression to be constant, and
finally it builds ptr_7 + (unsigned int) {n_6 + 65535, +, 1}_1 * 4.
The code in chrec_fold_multiply that is producing this MULT_EXPR is:
return fold_build2 (MULT_EXPR, type, op0, op1);
(gdb) p op0
$42 = (tree) 0xb7c27444
(gdb) pgs
4
(gdb) p op1
$43 = (tree) 0xb7ccf6a0
(gdb) pgs
(unsigned int) (n_20 + 65535);
(gdb) pt
nop_expr 0xb7ccf6a0
type integer_type 0xb7c36000 unsigned int public unsigned sizetype SI
size integer_cst 0xb7c27658 constant invariant 32
unit size integer_cst 0xb7c27444 constant invariant 4
align 32 symtab 0 alias set -1 canonical type 0xb7c3c0d8
precision 32 min integer_cst 0xb7c27674 0 max integer_cst
0xb7c27c08 -1
arg 0 plus_expr 0xb7c2d948
type integer_type 0xb7c36288 short unsigned int
sizes-gimplified public unsigned HI
size integer_cst 0xb7c275b0 constant invariant 16
unit size integer_cst 0xb7c275cc constant invariant 2
align 16 symtab 0 alias set -1 canonical type 0xb7c36288
precision 16 min integer_cst 0xb7c275e8 0 max integer_cst
0xb7c27594 65535
arg 0 ssa_name 0xb7cdb5e4 type integer_type 0xb7c36288 short
unsigned int
var var_decl 0xb7cd70b8 n def_stmt gimple_modify_stmt
0xb7cda770
version 20
arg 1 integer_cst 0xb7c27594 constant invariant 65535
And here, unfortunately fold_build2 does not further simplify this
expression because of the cast to uint around the PLUS_EXPR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32367
[Bug tree-optimization/32367] [4.3 Regression] internal compiler error: in build_polynomial_chrec, at tree-chrec.h:113
--- Comment #12 from spop at gcc dot gnu dot org 2007-06-17 19:16 ---
Subject: Re: [4.3 Regression] internal compiler error: in
build_polynomial_chrec, at tree-chrec.h:113
Ok, thanks. Just to let people know, {{BinomialCoefficients[0], +, 4}_1, +,
{0, +, 4}_1}_1 was also showing up on the trunk before the pointer_plus was
merged in.
In the fix for this bug, I'm going to include the following assert
such that this inconsistency will not occur anymore.
Index: tree-chrec.h
===
--- tree-chrec.h(revision 125771)
+++ tree-chrec.h(working copy)
@@ -83,6 +83,7 @@ extern bool tree_contains_chrecs (tree,
extern bool evolution_function_is_affine_multivariate_p (tree, int);
extern bool evolution_function_is_univariate_p (tree);
extern unsigned nb_vars_in_chrec (tree);
+extern bool evolution_function_is_invariant_p (tree, int);
/* Determines whether CHREC is equal to zero. */
@@ -114,6 +115,8 @@ build_polynomial_chrec (unsigned loop_nu
else
gcc_assert (TREE_TYPE (left) == TREE_TYPE (right));
+ gcc_assert (evolution_function_is_invariant_p (left, loop_num));
+
if (chrec_zerop (right))
return left;
@@ -140,7 +143,6 @@ evolution_function_is_constant_p (tree c
}
}
-extern bool evolution_function_is_invariant_p (tree, int);
/* Determine whether the given tree is an affine evolution function or not.
*/
static inline bool
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32367
[Bug rtl-optimization/32366] [4.3 Regression] Segfault in significand_size with -ftree-vectorize
--- Comment #5 from uros at gcc dot gnu dot org 2007-06-17 19:23 --- Subject: Bug 32366 Author: uros Date: Sun Jun 17 19:23:30 2007 New Revision: 125777 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125777 Log: PR rtl-optimization/32366 * simplify-rtx.c (simplify_unary_operation_1) [FLOAT_TRUNCATE, FLOAT_EXTEND]: Prevent non-scalar modes from entering significand_size. testsuite/ChangeLog: PR rtl-optimization/32366 * testsuite/gcc.dg/vect/pr32366.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr32366.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32366
[Bug c/32381] New: m68k undefined symbol __cmpsf2_internal
This bug has been introduced by Paul Brook on 29/12/2005. See the diffs here : http://gcc.gnu.org/viewcvs/branches/gcc-4_2-branch/gcc/config/m68k/lb1sf68.asm?r1=109143r2=109145diff_format=h It occurs when building some executables on m68k targets where __USER_LABEL_PREFIX__ is not defined or not empty. When ld tries to link a program with _float.o inside libgcc.a, it fails with : ...lb1sf68.asm:3759: relocation truncated to fit: DISP16 against undefined symbol `__cmpsf2_internal' The problem is in the file gcc/config/m68k/lb1sf68.asm, in the definition of the function SYM (__cmpsf2). There is function call using bsr (__cmpsf2_internal), but the target function was defined with SYM (__cmpdf2_internal) The macro SYM prepends __USER_LABEL_PREFIX__ to its argument. If __USER_LABEL_PREFIX__ is defined to an empty string (like ELF), the bug is not visible. But if it is defined to something else (like _ by default), the bsr references a symbol named __cmpsf2_internal which will stay undefined because the actual definition contains 3 leading underscores. This problem is present in the definition of the function __cmpsf2, but the similar function __cmpdf2 is ok. -- Summary: m68k undefined symbol __cmpsf2_internal Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vincent dot riviere at freesbee dot fr GCC target triplet: m68k-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32381
[Bug c/32381] m68k undefined symbol __cmpsf2_internal
--- Comment #1 from vincent dot riviere at freesbee dot fr 2007-06-17 20:03 --- Created an attachment (id=13726) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13726action=view) Correct call to SYM (__cmpsf2_internal) The attached patch fixes this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32381
[Bug rtl-optimization/32355] [4.3 Regression] ICE in df_lr_verify_transfer_functions, at df-problems.c:1924
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-17 20:13
---
Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
There are possibly two problems here. Fixing the first one fixes this ice.
The first problem is that after a call to cse_main, a call to
df_finish_pass is needed to get out of deferred rescanning mode and get
everything up to date.
The possible second problem is that something in one of
delete_trivially_dead_insns
rebuild_jump_labels
cleanup_cfg
may not work in deferred rescanning mode. This will wait for another
bug report.
It is too hard to debug this without first cleaning up what cse_main did
and that makes the bug go away.
ok to commit?
Kenny
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/32355
* gcse (rest_of_handle_gcse): Add call to df_finish_pass after
cse_main.
* df-problems.c (df_note_bb_compute): Fix dumping info.
2007-06-17 Kenneth Zadeck [EMAIL PROTECTED]
* gcc.c-torture/compile/pr32355.c: New testcase.
Index: testsuite/gcc.c-torture/compile/pr32355.c
===
--- testsuite/gcc.c-torture/compile/pr32355.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr32355.c (revision 0)
@@ -0,0 +1,33 @@
+/* { dg-options -O3 } */
+
+typedef struct
+{
+}
+__sigset_t;
+typedef struct
+{
+char coredump;
+}
+EMode;
+extern EMode Mode;
+struct sigaction
+{
+ __sigset_t sa_mask;
+ int sa_flags;
+};
+doSignalsSetup (void)
+{
+ static const int signals[] = {
+1, 2 , 3, 4, 6, 8, 11, 13, 14, 15, 10, 12, 17, 7
+ };
+ unsigned int i, sig;
+ struct sigaction sa;
+ for (i = 0; i sizeof (signals) / sizeof (int); i++)
+{
+ sig = signals[i];
+ if (Mode.coredump (sig == 4 || sig == 8))
+continue;
+ sa.sa_flags = (sig == 17);
+ sigemptyset (sa.sa_mask);
+}
+}
Index: gcse.c
===
--- gcse.c (revision 125777)
+++ gcse.c (working copy)
@@ -6704,6 +6704,7 @@ rest_of_handle_gcse (void)
{
timevar_push (TV_CSE);
tem2 = cse_main (get_insns (), max_reg_num ());
+ df_finish_pass ();
purge_all_dead_edges ();
delete_trivially_dead_insns (get_insns (), max_reg_num ());
timevar_pop (TV_CSE);
Index: df-problems.c
===
--- df-problems.c (revision 125777)
+++ df-problems.c (working copy)
@@ -3867,8 +3867,10 @@ df_note_bb_compute (unsigned int bb_inde
for (def_rec = df_get_artificial_defs (bb_index); *def_rec; def_rec++)
{
struct df_ref *def = *def_rec;
+#ifdef REG_DEAD_DEBUGGING
if (dump_file)
fprintf (dump_file, artificial def %d\n, DF_REF_REGNO (def));
+#endif
if ((DF_REF_FLAGS (def) DF_REF_AT_TOP) == 0)
bitmap_clear_bit (live, DF_REF_REGNO (def));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32355
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #18 from rob1weld at aol dot com 2007-06-17 20:46 --- Page: http://gcc.gnu.org/install/prerequisites.html says: MPFR Library version 2.2.1 (or later) Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The version of MPFR that is bundled with GMP 4.1.x contains numerous bugs. Although GCC may appear to function with the buggy versions of MPFR, there are a few bugs that will not be fixed when using this version. ... If we want that page to be correct then the MPFR_VERSION_NUM(2,2,0) must be changed to at least MPFR_VERSION_NUM(2,2,1) (mandatory) and the second [MPFR_VERSION_NUM(2,2,1)] should require p5 (good idea). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug fortran/32382] missed optimization in internal read
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-17 20:47 --- I will explore this a bit. Its interesting. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-17 20:47:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #24 from rob1weld at aol dot com 2007-06-17 20:52 --- http://gcc.gnu.org/gcc-4.3/changes.html#mpfropts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug fortran/32382] New: missed optimization in internal read
This is a followup to BUG 32257. Above Bug has been resolved as invalid, but how comes that the loop variable i has the value 101 at the end of the read? consider C234567 program internalread implicit none integer m CC parameter(m=100) parameter(m=100) character value*10 integer i,j,intvalues(m) DO j=1,100 write(value,'(i3,a5)') j, 5 69 write(*,*) value read(value,*,end=20,err=20) (intvalues(i),i=1,m) 20 write(*,*) j ENDDO end program internalread (There is no access to i after the loop, so this program should be valid) m=100: gfortran needs 0.003s g77 needs 0.002s m=100: gfortran needs 0.8s g77 needs 0.002s So gfortran loops to its bitter end, although it could shortcut the loop. g77 seems to exit the loop at i=3, as BUG 32257 shows as well. -- Summary: missed optimization in internal read Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/20373] INTRINSIC symbols can be given the wrong type
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-06-17 21:26 --- Forget the attempt to correct this given in comment #4. Got something more useful :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|patch | Last reconfirmed|2005-12-30 19:11:01 |2007-06-17 21:26:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
[Bug middle-end/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-06-17 21:40 --- We have an extra: (insn 39 38 40 t.f90:7 (parallel [ (set (reg:SI 73) (ashift:SI (reg:SI 68 [ _s1 ]) (const_int 2 [0x2]))) (clobber (reg:CC 17 flags)) ]) -1 (nil)) After the patch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-06-17 21:45 --- I was wrong in marking this as a middle-end issue. We have: char[0:D.1026][1:4] * __result.0; char * temp.87; ... temp.87 = (*__result.0)[0]; __builtin_memset (temp.87 + (unnamed-unsigned:32) _s1, 32, 4 - _s1); --- cut -- The midde-end thinks it can combine (*__result.0)[0] + (unnamed-unsigned:32) _s1 to just (*__result.0)[(unnamed-unsigned:32) _s1] when it should have combined it to (*__result.0)[0][(unnamed-unsigned:32) _s1] So (*__result.0)[0] is wrong, it should have been: (*__result.0)[0][0]. Let me see if I can figure out where to fix the front-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|middle-end |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-06-17 22:08
---
Here is the fix which I am testing, basically instead of creating
(typeof(array[0] *)array we create array[lb]:
Index: trans.c
===
--- trans.c (revision 125777)
+++ trans.c (working copy)
@@ -266,7 +266,14 @@ gfc_build_addr_expr (tree type, tree t)
TREE_CODE (base_type) == ARRAY_TYPE
TYPE_MAIN_VARIANT (TREE_TYPE (type))
== TYPE_MAIN_VARIANT (TREE_TYPE (base_type)))
-natural_type = type;
+{
+ tree min_val = size_zero_node;
+ tree type_domain = TYPE_DOMAIN (base_type);
+ if (type_domain TYPE_MIN_VALUE (type_domain))
+ min_val = TYPE_MIN_VALUE (type_domain);
+ t = build4 (ARRAY_REF, TREE_TYPE (type), t, min_val, NULL_TREE,
NULL_TREE);
+ natural_type = type;
+}
else
natural_type = build_pointer_type (base_type);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug tree-optimization/32383] New: [4.3 regression] ICE with reciprocals and -ffast-math
The following code snippet triggers an ICE on mainline when compiled with
g++ -O -ffast-math:
=
struct A
{
~A();
};
double foo();
inline void bar (double d) { foo() /= d; }
void baz()
{
A a;
bar(2);
}
=
This is a very recent regression (not present in 4.3-20070607).
Uros, I'd guess your patch is responsible for the regression:
2007-06-16 Uros Bizjak
PR middle-end/31723
* hooks.c (hook_tree_tree_bool_null): New hook.
* hooks.h (hook_tree_tree_bool_null): Add prototype.
* tree-pass.h (pass_convert_to_rsqrt): Declare.
* passes.c (init_optimization_passes): Add pass_convert_to_rsqrt.
* tree-ssa-math-opts.c (execute_cse_reciprocals): Scan for a/func(b)
and convert it to reciprocal a*rfunc(b).
--
Summary: [4.3 regression] ICE with reciprocals and -ffast-math
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
OtherBugsDependingO 31723
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
[Bug c++/32384] New: [4.1/4.2/4.3 regression] Pseudo-dtor in template class rejected
The following valid code snippet is rejected since GCC 3.4.0:
=
templatetypename struct A
{
typedef int T;
T foo();
A() { foo().~T(); }
};
Aint a;
=
The error message is:
bug.cc: In constructor 'A template-parameter-1-1 ::A()':
bug.cc:6: error: expected class-name before '(' token
The code compiles if A is a non-template class, or if I remove the typedef
and call the anonymous template parameter T instead.
--
Summary: [4.1/4.2/4.3 regression] Pseudo-dtor in template class
rejected
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32384
[Bug c++/32384] [4.1/4.2/4.3 regression] Pseudo-dtor in template class rejected
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32384
[Bug tree-optimization/32383] [4.3 regression] ICE with reciprocals and -ffast-math
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-06-17 23:21 --- Btw., the error message is: bug.cc: In function 'void baz()': bug.cc:10: internal compiler error: tree check: expected ssa_name, have real_cst in execute_cse_reciprocals, at tree-ssa-math-opts.c:510 Please submit a full bug report, [etc.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32383
[Bug c++/32385] New: [4.3 regression] ICE with struct in default argument of template function
The following code snippet triggers a segfault since GCC 4.0.0:
=
struct A
{
templateint void foo(int = ((struct { int i; }) {0}).i);
};
=
bug.cc:3: error: template class without a name
bug.cc:3: error: 'struct A::anonymous' does not declare a template type
bug.cc:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with struct in default argument of
template function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32385
[Bug c++/32385] [4.1/4.2/4.3 regression] ICE with struct in default argument of template function
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] ICE with |[4.1/4.2/4.3 regression] ICE |struct in default argument |with struct in default |of template function|argument of template ||function Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32385
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #10 from malitzke at metronets dot com 2007-06-17 23:29 --- Let me reiterate: I am not admitted to the bar in any USA state, nor the District of Columbia. Hence, I can not and I am not offering any legal advice. For legal advice see a lawyer admitted to the bar. Yes, I have worked extensively with lawyers preparing contracts, briefs and filings to regulatory agencies and also provided sworn depositions and know some of the jargon. Lets us start with a package, GLIBC, that I consider consistent and which gives me corresponding reassurance. First a randomly selected introductory paragraph and the the paragraph that comes close to the stated GCC exception because of the reference to the GNU Lesser General Public License. Copyright (C) 1991, 1995, 1996, 1997, 2002 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. COPYING and COPYING.LIB are in the root directory of the package, and I assume these two apply to the package as a whole. COPYING has as its title GNU General Public License and COPYING.LIB has as its tile GNU Lesser General Public License. Section 6 I take as the essence of is termed the GGC-exception. But, to me it is section 13: 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. that really gives me confort and that is missing in the GCC verbiage. Now even in the directory gcc, ever since gcc-3.3.6 gcc-3.3.6_except_libgcc_c In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine (sic) executable.) gcc-3.3.6_except_libgcc_h As a special exception, if you link this library with other files, some of which are compiled with GCC, to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. the two cited parapgraphs are not equal and they imperfectly convey some of the idea of COPYING.LIB, which should then be removed from the root directory. As each release is really a new work the exception paragraph could be removed with a simple sed script. This then would bring back the dreaded viral property as advocated by Mr. Stallman. However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline. In conclusion, the GCC_exception paragraph needs the something like section 13 quoted above -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-17 23:34 --- Actually no it does not, anyways the exception was written by lawyers. If you want to change the exception, go talk to the FSF (and RMS) and not us as we don't control the license. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug preprocessor/11242] [mingw32] #include memory takes my memory directory instead of the standard memory header file
--- Comment #7 from dannysmith at users dot sourceforge dot net 2007-06-17 23:40 --- Fixed by: 2007-06-09 Vladimir Prus [EMAIL PROTECTED] * files.c (open_file): Account for the fact that on windows, opening a directory gives EACCES. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242
[Bug c++/22238] Awful error messages with virtual functions
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-06-17 23:40
---
Andrew, Gaby's testcase from comment #4 gets an even worse diagnostic
since the merge of the ptr_plus stuff:
=
struct A
{
void foo();
};
struct B : virtual A
{
void bar() { if (foo()) ; }
};
=
bug.cc: In member function 'void B::bar()':
bug.cc:8: error: could not convert '#'pointer_plus_expr' not supported by
dump_expr#expression error-A::foo()' to 'bool'
Would you mind having a look?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug c++/22238] Awful error messages with virtual functions
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-17 23:42 --- Would you mind having a look? I was going to fix the pretty printing of pointer_plus_expr for C++ after I returned from Japan. I already have a testcase which is better than the one here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22238
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #12 from malitzke at metronets dot com 2007-06-18 00:06 --- Did you even read comment 9? -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug c/32314] for gcc-4.2gcc-4disable-decimal-float not working on i686, powerpc, sparc. gcc-4.3.0
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-06-18 00:26 --- Altivec and SSE really produce benefits in a relatively small corner of the overal picture Why do you think that? It is not true. This is all getting offtopic from the original issue. The original question has to do with --disable-decimal-float not turning off dfp. If we look at that issue alone, the option does turn off the C/C++ interface which is what it is documented as doing, from the install docs: Enable (or disable) support for the C decimal floating point extension that is in the IEEE 754R extension to the IEEE754 floating point standard. This is enabled by default only on PowerPC, i386, and x86_64 GNU/Linux systems. Other systems may also support it, but require the user to specifically enable it. You can optionally control which decimal floating point format is used (either `bid' or `dpd'). The `bid' (binary integer decimal) format is default on i386 and x86_64 systems, and the `dpd' (densely packed decimal) format is default on PowerPC systems. It never said disable the internal support for dfp, yes you might assume that is true but it would make things more complex inside GCC. So going back to the orignal issue, this bug is invalid based on what the option does exactly what the documentation says it does. Next time please read the documentation and check that stuff is working correctly before submitting a bug report. PS now you are using this bug report, I have no idea what and to complain about who can understand what any more. Also C is and has never been a high level assembly. Please read the C standard to understand that was never true. If you want a real small cc1, go back to the days of GCC 1.x where GCC actually stood for GNU C Compiler. Even back then GCC was bloated. Also POinter Plus reduced the size of cc1 :) The diffstat on the patch would have told you that. But all of this offtopic from the original issue. If you want to complain about not disabling the internal part for dfp, please either submit a patch (read http://gcc.gnu.org/contribute.html for more info) or submit a new bug but note it will be marked as an enchement because it is actually hard to do (I already looked into doing it after you and someone else noticed it). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32314
[Bug fortran/32386] New: Pure function not allowed in specification expression
The following program seems to me to be valid Fortran 95, because the f95 standard 5.1.1.5 and 7.1.6.2 say a CHARACTER(n) declaration is OK if n is a scalar integer restricted expression, in which each primary is a constant, the intrinsic LEN is allowed, and so are pure functions that are not intrinsic, not internal, not statement functions, do not have dummy procedure arguments, and are not recursive. But gfortran won't compile it. Evidence: [EMAIL PROTECTED] test system: ~/Jfh/Test 52 cat testspec.f90 MODULE halvestring ! Can halfit be in a specification expression? CONTAINS PURE FUNCTION halfit(s1) RESULT (s2) CHARACTER(*),INTENT(IN):: s1 CHARACTER(len(s1)/2) :: s2 s2 = s1 END FUNCTION halfit END MODULE halvestring ! --- PROGRAM testspec USE halvestring CHARACTER(*),PARAMETER :: stringa = 'abcdeedcba' CHARACTER(len(halfit(stringa))) :: stringb stringb = halfit(stringa) PRINT (I4,A), len(stringb),' '//stringb//'' ! 5 abcde END PROGRAM testspec [EMAIL PROTECTED] test system: ~/Jfh/Test 53 gfortran -v testspec.f90 Driving: gfortran -v testspec.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-52) /usr/libexec/gcc/i386-redhat-linux/4.1.1/f951 testspec.f90 -quiet -dumpbase testspec.f90 -mtune=generic -auxbase testspec -version -I /usr/lib/gcc/i386-redhat-linux/4.1.1/finclude -o /tmp/ccUf0R9I.s GNU F95 version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux) compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 In file testspec.f90:13 CHARACTER(len(halfit(stringa))) :: stringb 1 Error: 'stringb' at (1) must have constant character length in this context [EMAIL PROTECTED] test system: ~/Jfh/Test 54 -- Summary: Pure function not allowed in specification expression Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot harper at vuw dot ac dot nz GCC build triplet: ? GCC host triplet: ? GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-18 01:00 --- Not saying whether this is valid or not. However Intel ifort says: fortcom: Error: john.f90, line 13: An automatic object is invalid in a main program. [STRINGB] CHARACTER(len(halfit(stringa))) :: stringb ---^ compilation aborted for john.f90 (code 1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug fortran/32377] can't determine dependence (source/destination overlap)
--- Comment #2 from tprince at computer dot org 2007-06-18 01:36 --- Performance change due to complete vectorization is not significant on Core 2 Duo. My apologies for submitting at normal priority. -- tprince at computer dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #7 from jwakely dot gcc at gmail dot com 2007-06-18 01:36
---
Confirmed on x86-linux, sparc-solaris and ppc-AIX so I've removed the Target.
Also verified that valgrind shows the uninitialised memory reads.
This bug breaks common idioms like:
template typename A, typename B
struct compressed_pair : A {
compressed_pair() : A(), second_() { }
A first() { return *this; }
B second() { return second_; }
private:
B second_;
};
--
jwakely dot gcc at gmail dot com changed:
What|Removed |Added
GCC target triplet|sparc-sun-solaris2.9|
Known to fail||4.2.0 4.1.1 3.4.3 3.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug fortran/32378] can't determine dependence (distinct sections of an array)
--- Comment #2 from tprince at computer dot org 2007-06-18 01:39 --- Performance change for full vectorization is not significant on Core 2 Duo; suggest reduced ;priority, apologies for submitting at normal severity -- tprince at computer dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #2 from kargl at gcc dot gnu dot org 2007-06-18 01:46 --- According to Lahey, the code is invalid. Lahey/Fujitsu Fortran 95 Source Check Output Compiling program unit halvestring at line 1: Compiling program unit testspec at line 9: 2049-S: SOURCE.F90, line 13: Automatic object 'stringb' cannot be specified in the main program unit. Encountered 1 error, 0 warnings, 0 informations in file SOURCE.F90. Compiling file SOURCE.F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug fortran/32140] [4.3 Regression] Miscompilation with -O1
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-06-18 01:49 --- Patch tested OK on x86-64-Gnu-Linux. I am also able to compile and run cp2k where before I was getting a segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
[Bug c/32387] New: back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
Taking the exceptional backport of TPA to gcc-4.2.x I request studying the possibility of doing the same for POINTER_PLUS. -- Summary: back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug rtl-optimization/18995] delete_trivially_dead_insns fails to update the liveness information
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-18 01:57 --- delete_trivially_dead_insns is gone now that the dataflow branch has been merged in. So closing as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18995
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Comment #36 from pinskia at gcc dot gnu dot org 2007-06-18 02:03 --- Just removing patch keyword as the patch is no longer applies after the dataflow branch merge. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |09/msg01176.html| Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug middle-end/24429] Remove unnecessary lhd_* hooks where a corresponding hook_* exists
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 02:05 --- Any news on this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24429
[Bug tree-optimization/30393] [4.3 Regression] ice for legal code with -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-18 02:16 --- This has been working since 4.3.0 20070122 so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30393
[Bug target/30383] [4.3 Regression] ice for legal code on x86_64 in ix86_expand_movmem
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-18 02:18 --- This has been working since 4.3.0 20070131 so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30383
[Bug tree-optimization/30175] [4.3 Regression] Runtime regressions with mem-ssa merge in Polyhedron and tramp3d-v4
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-18 02:22 --- I almost think we can declare this one as fixed. Richard, what do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30175
[Bug target/30757] [4.3 Regression] ICE with -march=athlon-xp -mfpmath=sse
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-18 02:24 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30757
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-18 02:27 --- Unlike the TPA backport, pointer plus does not fix any regression (except from 3.4.0). Also it is a huge patch which is still going through some bug fixes (C++ one and IV-OPTS one, and a SCEV one). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #3 from John dot Harper at mcs dot vuw dot ac dot nz 2007-06-18 02:42 --- Subject: Re: Pure function not allowed in specification expression On Mon, 18 Jun 2007, jvdelisle at gcc dot gnu dot org wrote: Date: 18 Jun 2007 01:00:47 - From: jvdelisle at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug fortran/32386] Pure function not allowed in specification expression --- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-06-18 01:00 --- Not saying whether this is valid or not. However Intel ifort says: fortcom: Error: john.f90, line 13: An automatic object is invalid in a main program. [STRINGB] CHARACTER(len(halfit(stringa))) :: stringb ---^ compilation aborted for john.f90 (code 1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. I think Intel is wrong because my stringb is not an automatic object. Its length depends on LEN of a pure module function of a constant. -- John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail [EMAIL PROTECTED] phone (+64)(4)463 5341 fax (+64)(4)463 5045 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #4 from John dot Harper at mcs dot vuw dot ac dot nz 2007-06-18 02:44 --- Subject: Re: Pure function not allowed in specification expression On Mon, 18 Jun 2007, kargl at gcc dot gnu dot org wrote: Date: 18 Jun 2007 01:46:09 - From: kargl at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug fortran/32386] Pure function not allowed in specification expression --- Comment #2 from kargl at gcc dot gnu dot org 2007-06-18 01:46 --- According to Lahey, the code is invalid. Lahey/Fujitsu Fortran 95 Source Check Output Compiling program unit halvestring at line 1: Compiling program unit testspec at line 9: 2049-S: SOURCE.F90, line 13: Automatic object 'stringb' cannot be specified in the main program unit. Encountered 1 error, 0 warnings, 0 informations in file SOURCE.F90. Compiling file SOURCE.F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. So I think Lahey is wrong. My stringb is not an automatic object; it is a character string whose length is LEN of a pure module function of a constant. -- John Harper, School of Mathematics, Statistics and Computer Science, Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail [EMAIL PROTECTED] phone (+64)(4)463 5341 fax (+64)(4)463 5045 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 02:45 --- t.f:10: note: not vectorized: possible dependence between data-refs (*a_54(D))[S.13_17] and (*a_54(D))[D.1376_50] -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Component|fortran |tree-optimization Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-06-18 02:45:31 date|| Summary|can't determine dependence |can't determine dependence |(source/destination overlap)|(source/destination overlap ||without more than size) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #2 from malitzke at metronets dot com 2007-06-18 02:47 --- I am not making this request lightheartedly. POINTER_PLUS was developed on a branch and went in very cleanly. I always stressed to my students that that A good theory is a most practical thing I just happen to to a member of Sigma Xi. from discussions surrounding the release of gcc-4.2.0 there appear to be a number of unresolved issues concerning gcc-4.2 and the release manager had serious misgivings. POINTER_PLUS just might help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 02:50 --- No pointer plus will make it worse. It changes so many non tested parts of GCC it is not funny. I added like 5 testcases to the testsuite because we were not testing those parts. The reason why 4.2 was bad is not because of features but because people did not work on regressions that much. I think 4.3 has/is changed a lot of people and how they work because most of the work they were working on has gone in. So people now are working on regressions, this is unlike 4.2 where people working hard on other projects during stage3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #4 from malitzke at metronets dot com 2007-06-18 02:53 --- I realize that good things do not come easy. I also believe there is over-reliance on regression among the gcc-insiders. Enhancement has a priority below trivial and I am jut requesting a study of an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug fortran/32373] not vectorized: can't determine dependence (equivalence)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:09 --- The problem with the first one is that we don't pull out the load of spaces.n from the loop which is dealing with common blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
[Bug tree-optimization/32375] not vectorized: can't determine dependence (array sections)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:13 --- I think some of this is related to PR 32075. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||32075 Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|fortran |tree-optimization Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-06-18 03:13:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
[Bug c/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #5 from malitzke at metronets dot com 2007-06-18 03:15 --- Hey, more good news about POINTER_PLUS. It might help smoke out bugs in other parts of GCC. I hope these can be labeled as so called regressions so that people will be forced to work on them. Concerning non-regression test cases and as a by-product of my porting work I am developing a list of packages having good and excellent make check diagnostics. I do not consider kernels good test beds for a compiler because the are vey specialized and narrow programming constructs that take great pains to circumvent many compiler areas and certainly dynamic libraries. I was very surprised that I turned up 3 cases that got real attention from the linux folks. (One had nothing to do with the compiler; just SCSI controller stuff) -- malitzke at metronets dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug tree-optimization/32378] can't determine dependence (distinct sections of an array)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-18 03:15 --- I think some of this is related to PR 32075. (Looking into IR tells you that). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |tree-optimization GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug tree-optimization/32387] back port POINTER_PLUS to gcc-4.2.1 on an exceptional basis
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-18 03:19 --- First you are crazy even in suggesting a back port. 4.2.x is feature frozen. If you don't like that, use 4.3.0 (trunk) instead. Yes it might show up other bugs in other places but that is the reason why they are called latent bugs. Please stop reopening this. Pointer plus is too many changes to go on a release branch. I think you also need to learn a release cycle is. Please read http://gcc.gnu.org/develop.html . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |tree-optimization Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32387
[Bug fortran/32388] New: Internal compiler error in convert_move
The following Fortran 95 program gives the compile-time output below it: [EMAIL PROTECTED] test system: ~/Jfh/Test 60 cat testdpconst.f90 PROGRAM testdpconst ! initialization sometimes /= assignment INTEGER,PARAMETER :: long = selected_int_kind(15) DOUBLE PRECISION :: dx = 2d0 PRINT 666,'sqrt(dx)**2 ',sqrt(dx)**2 ,'in hex format',transfer(sqrt(dx)**2,1_long) PRINT 666,'sqrt(2d0)**2 ',sqrt(2d0)**2 ,'in hex format',transfer(sqrt(2d0)**2,1_long) 666 FORMAT (1X,A, = ,F18.16,/,1X,A, = ,Z16) END PROGRAM testdpconst [EMAIL PROTECTED] test system: ~/Jfh/Test 61 gfortran -v testdpconst.f90 Driving: gfortran -v testdpconst.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-52) /usr/libexec/gcc/i386-redhat-linux/4.1.1/f951 testdpconst.f90 -quiet -dumpbase testdpconst.f90 -mtune=generic -auxbase testdpconst -version -I /usr/lib/gcc/i386-redhat-linux/4.1.1/finclude -o /tmp/ccHotQOh.s GNU F95 version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux) compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 testdpconst.f90: In function âMAIN__â: testdpconst.f90:7: internal compiler error: in convert_move, at expr.c:362 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. [EMAIL PROTECTED] test system: ~/Jfh/Test 62 -- Summary: Internal compiler error in convert_move Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot harper at vuw dot ac dot nz GCC build triplet: ? GCC host triplet: ? GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32388
[Bug tree-optimization/32379] can't determine dependence (loop reversal required)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:48 --- Part of the problem is related to PR 32075. (Looking into IR tells you that). The other part is loop reversal which I think still needs 32075 to be able to reverse the loop. We could do the loop reversal in the front-end (which does not need 32075 to be fixed) or the middle-end. Though I think we still need 32075 fixed to vectorize the loop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||32075 Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|fortran |tree-optimization Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-06-18 03:48:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32379
[Bug fortran/32388] Internal compiler error in convert_move
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-18 03:50 --- John, This works for me with both a 4.2 and 4.3 (aka trunk, bleeding edge) compilers. I think you'll find a much more pleasant gfortran experience if you upgrade from 4.1.1.. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32388
[Bug fortran/32388] Internal compiler error in convert_move
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-18 03:56 --- I see this in 4.1.2 but this has been fixed already in 4.2.0. So closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32388
[Bug fortran/32386] Pure function not allowed in specification expression
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-06-18 04:12 --- From Fortran 95/2003 Explained, Metcalf. Reid, and Cohen Page 101: The other way that automatic objects arise is through varying character length. The variable word2 in Subroutine example(word1) character(len = *), intent(inout) :: word1 character(len = len(word1)) :: word2 is an example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32386
