[Bug target/31403] wrong branch instructions generated with -m2a on sh-elf
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-04-20 08:45 --- A binary search shows that this started to fail from the revision 123295 * config/sh/sh.md (movsi_ie): Fix memory constraints attribute length. I'd like to add Christian to the cc list because he must be interested in this issue. movsi_ie is used also for SH2A and I didn't know that SH2A has 4-byte move instructions like mov.l reg,@(12-bit_disp,reg'). An easy fix would be the patch below, though I can't test it until the other bootstrap/regtest cycles end up. --- ORIG/trunk/gcc/config/sh/sh.md 2007-03-29 08:44:33.0 +0900 +++ LOCAL/trunk/gcc/config/sh/sh.md 2007-04-19 20:36:20.0 +0900 @@ -4968,7 +4968,36 @@ label: ! move optimized away" [(set_attr "type" "pcload_si,move,movi8,move,*,load_si,mac_gp,prget,arith,store,mac_mem,pstore,gp_mac,prset,mem_mac,pload,load,fstore,pcload_si,gp_fpul,fpul_gp,fmove,fmove,fmove,nil") (set_attr "late_fp_use" "*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,yes,*,*,yes,*,*,*,*") - (set_attr "length" "*,*,*,4,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,*,0")]) + (set_attr_alternative "length" + [(const_int 2) + (const_int 2) + (const_int 2) + (const_int 4) + (const_int 2) + (if_then_else + (ne (symbol_ref "TARGET_SH2A") (const_int 0)) + (const_int 4) (const_int 2)) + (const_int 2) + (const_int 2) + (const_int 2) + (if_then_else + (ne (symbol_ref "TARGET_SH2A") (const_int 0)) + (const_int 4) (const_int 2)) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 2) + (const_int 0)])]) (define_insn "movsi_i_lowpart" [(set (strict_low_part (match_operand:SI 0 "general_movdst_operand" "+r,r,r,r,r,r,r,m,r")) -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org, christian dot bruel at ||st dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-20 08:45:54 date|| Summary|Problem while compiling gcc |wrong branch instructions |for sh-elf |generated with -m2a on sh- ||elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31403
[Bug libstdc++/31638] [4.0/4.1/4.2/4.3 Regression] string usage leads to warning with -Wcast-align
--- Comment #2 from pcarlini at suse dot de 2007-04-20 08:50 --- I will check, but I don't think this can possibly happen in mainline, after we fixed c++/30500. Otherwise, the underlying issue is libstdc++/19495, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[Bug target/31640] New: cache align alignment is too aggressive on sh-elf
The sh4 port aligns blocks that have no fallthrus and that are either frequently executed (JUMP_ALIGN) or preceeded a barrier (LABEL_ALIGN_AFTER_BARRIER) on a cache line. While in theory this help to avoid cache misses if the block slits over 2 cache lines, in practise this reduces cache locality and lenghten distance between blocks. The number of issued instructions are also impacted. For example the relative indirect address in jump tables needs a byte zero extend instruction if the distance occupies 8 bits instead of 7 bits. I ran some experiments and benchmarked (eembc) with 2 strategies 1) -falign-jumps=1 2) Align the block if the size is bigger than a given threshold. (empirically set to 16 bytes, half of the cache line size). See illustrating attached patch. My conclusion is that in -O3 the performance never degrades (option 2 is a little bit better, even improving dhrystone by 3%) when removing this padding. And the text size improves by ~15%. So I was not able to measurate the benefit of the cache line padding although the code size impact is big (even in -O2/-O3 a code size bloat should be motivated by some performance improvement). Is there a motivating test that justifies this microoptimisation ? In the illustrating patch I still align the basic blocks on 4-bytes to account for better instruction fetch accesses -- Summary: cache align alignment is too aggressive on sh-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chrbr at gcc dot gnu dot org GCC target triplet: sh-superh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640
[Bug target/31640] cache block alignment is too aggressive on sh-elf
-- chrbr at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Summary|cache align alignment is too|cache block alignment is too |aggressive on sh-elf|aggressive on sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #4 from jakub at gcc dot gnu dot org 2007-04-20 12:40 --- Subject: Bug 31632 Author: jakub Date: Fri Apr 20 12:40:47 2007 New Revision: 123988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123988 Log: PR tree-optimization/31632 * fold-const.c (fold_binary): Use op0 and op1 instead of arg0 and arg1 for optimizations of comparison against min/max values. Fold arg0 to arg1's type for optimizations of comparison against min+1 and max-1 values. * gcc.c-torture/compile/20070419-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20070419-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug tree-optimization/31602] Overflow warning causes GDB -Werror build failure
--- Comment #3 from ian at airs dot com 2007-04-20 16:17 --- Created an attachment (id=13394) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13394&action=view) Proposed patch This patch fixes the test case in the PR. I am testing it. It would be interesting to hear whether it also fixes the actual code in gdb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
[Bug target/31640] cache block alignment is too aggressive on sh-elf
--- Comment #1 from chrbr at gcc dot gnu dot org 2007-04-20 14:13 --- Created an attachment (id=13391) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13391&action=view) Illustrative patch to not align small basic blocks I used this patch to reduce the number of basic blocks aligned on cache-lines. My choice was not to align blocks less than 16 bytes (also tried 32 bytes) seems to give the best results. Note than never aligning doesn't degrade eebmc perfs (similar to -falign-jumps=1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640
[Bug target/31641] [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
--- Comment #1 from tbm at cyrius dot com 2007-04-20 15:25 --- Created an attachment (id=13392) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13392&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug target/31641] New: [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618
[ Forwarded from http://bugs.debian.org/395533 ] We're seeing the following ICE on s390. This is with gcc 4.1, but I can also reproduce it with current 4.3 from SVN. I haven't tried 4.0, but 3.4 works. raptor% /usr/lib/gcc-snapshot/bin/g++ -c -O min4.c min4.c: In member function 'void StringTest::constructor()': min4.c:64: internal compiler error: in s390_expand_setmem, at config/s390/s390.c:3618 Please submit a full bug report, -- Summary: [4.1/4.2/4.3 Regression] ICE in s390_expand_setmem, at config/s390/s390.c:3618 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31641
[Bug tree-optimization/29789] Missed invariant out of the loop with conditionals and shifts
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-04-20 15:33 ---
Note that this does fix the loop invariant motion only in the case of two
ifs can be merged (because that re-instantiates the A & (1 << B) form). The
following parts are still not resolved:
void quantum_cnot(int control, int target, unsigned long *state, int size)
{
int i;
for(i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=29789
[Bug c/31642] New: -O2 -fno-guess-branch-probability -fno-tree-ch -fno-tree-dominator-opts -fno-tree-lrs -fno-tree-dce -fno-tree-vrp -funit-at-a-time -ftree-copy-prop -ftree-copyrename yields an infi
Using -O2 -fno-guess-branch-probability -fno-tree-ch -fno-tree-dominator-opts -fno-tree-lrs -fno-tree-dce -fno-tree-vrp -funit-at-a-time -ftree-copy-prop -ftree-copyrename on the SPEC CPU2000 benchmark 176.gcc yields an infinite loop (using the train input which usually runs for 2s runs for hours). This is confirmed on Fedora Core 4 / x86 (Intel Pentium 4), and also on an linux/amd64 for which I have no details. Removing any of the -fno-X flags seems to solve the issue, and adding -ffloat-store doesn't change a thing, which suggests this is not floating-point (convergence) related. -- Summary: -O2 -fno-guess-branch-probability -fno-tree-ch -fno- tree-dominator-opts -fno-tree-lrs -fno-tree-dce -fno- tree-vrp -funit-at-a-time -ftree-copy-prop -ftree- copyrename yields an infinite loop in SPEC benchmark 176.gcc Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kenneth dot hoste at elis dot ugent dot be GCC host triplet: i686-Linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31642
[Bug tree-optimization/29789] Missed invariant out of the loop with conditionals and shifts
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-04-20 16:09 ---
Subject: Re: Missed invariant out of the loop with conditionals and shifts
> void quantum_cnot(int control, int target, unsigned long *state, int size)
> {
> int i;
>
> for(i=0; i {
> if (state[i] & ((unsigned long) 1 << control))
> state[i] ^= ((unsigned long) 1 << target);
> }
> }
>
> (and more similar loops in libquantum). It would be nice if rtl
> loop-invariant
> motion could detect this form:
>
> (insn 23 22 24 4 (parallel [
> (set (reg:DI 67)
> (lshiftrt:DI (reg:DI 62 [ D.1992 ])
> (subreg:QI (reg/v:SI 63 [ control ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) 470 {*lshrdi3_1_rex64} (nil)
> (nil))
>
> (insn 24 23 25 4 (parallel [
> (set (reg:SI 68)
> (and:SI (subreg:SI (reg:DI 67) 0)
> (const_int 1 [0x1])))
> (clobber (reg:CC 17 flags))
> ]) 301 {*andsi_1} (nil)
> (nil))
>
> and move the invariant (1 << control).
how exactly do you imagine this transformation should work? The insns
you show essentially are
tmp = x >> control;
z = tmp & 1;
I do not see how to transform just this pattern profitably (without also
seeing that z is only used in condition).
I could hack something in, however handling just this single pattern
specially seems a bit weird to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29789
[Bug target/31640] cache block alignment is too aggressive on sh-elf
--- Comment #2 from chrbr at gcc dot gnu dot org 2007-04-20 15:51 --- Created an attachment (id=13393) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13393&action=view) testcase for new instruction introduced by increased distance In this example, the max distance between the jump table and the cases is artificially augmented by the padding. Although each basic block is very small and has very few chances to spread over several cache blocks. In addition the extu.b r1,r1 instruction can be avoided. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640
[Bug tree-optimization/29789] Missed invariant out of the loop with conditionals and shifts
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-20 13:51 --- Mine. I have a tree if-conversion patch that produces :; D.1993 = MEM[base: state, index: ivtmp.32, step: 8]; if (pretmp.25 == (pretmp.25 & D.1993)) goto ; else goto ; :; MEM[base: state, index: ivtmp.32, step: 8] = 1 << target ^ D.1993; :; ivtmp.32 = ivtmp.32 + 1; if (size > (int) ivtmp.32) goto ; else goto ; and finally .L4: movq(%r11,%r9,8), %rdi movq%rsi, %rax andq%rdi, %rax cmpq%rax, %rsi jne .L5 xorq%rdx, %rdi movq%rdi, (%r11,%r9,8) .L5: addq$1, %r9 cmpl%r9d, %r8d jg .L4 for the inner loop. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-10 01:55:58 |2007-04-20 13:51:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29789
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #5 from jakub at gcc dot gnu dot org 2007-04-20 12:46 --- Subject: Bug 31632 Author: jakub Date: Fri Apr 20 12:46:06 2007 New Revision: 123990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123990 Log: PR tree-optimization/31632 * fold-const.c (fold_binary): Use op0 and op1 instead of arg0 and arg1 for optimizations of comparison against min/max values. Fold arg0 to arg1's type for optimizations of comparison against min+1 and max-1 values. * gcc.c-torture/compile/20070419-1.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/20070419-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug tree-optimization/31632] [4.1 regression] ICE in compare_values
--- Comment #6 from jakub at gcc dot gnu dot org 2007-04-20 12:49 --- Subject: Bug 31632 Author: jakub Date: Fri Apr 20 12:49:37 2007 New Revision: 123992 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123992 Log: PR tree-optimization/31632 * fold-const.c (fold_binary): Use op0 and op1 instead of arg0 and arg1 for optimizations of comparison against min/max values. Fold arg0 to arg1's type for optimizations of comparison against min+1 and max-1 values. * gcc.c-torture/compile/20070419-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20070419-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31632
[Bug tree-optimization/29789] Missed invariant out of the loop with conditionals and shifts
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-04-20 16:59 --- I posted a patch for the tree level im instead to handle this special case right after the reciprocal special case. I agree it's a special case, but as it happens in spec 2k6... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29789
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #15 from arcangelpip at hotmail dot com 2007-04-20 17:06 --- Don't you just hate idiots in these cases. (Yes, I am referring to myself here) Well, it's completely broken again on my system, look here. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31636 I apologise for being less than helpful here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug java/31622] Segment violation in the “toString” method on a mathematical expression
--- Comment #4 from tromey at gcc dot gnu dot org 2007-04-20 17:39 --- Please post the output of running gcj -C -v Fail.java Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
[Bug middle-end/31642] -O2 -fno-guess-branch-probability -fno-tree-ch -fno-tree-dominator-opts -fno-tree-lrs -fno-tree-dce -fno-tree-vrp -funit-at-a-time -ftree-copy-prop -ftree-copyrename yields an i
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-20 18:24 --- We need a testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31642
[Bug c++/17000] parse error calling member template function of non-lvalue from within template class member
--- Comment #10 from ddneilson at gmail dot com 2007-04-20 18:51 --- (In reply to comment #9) > (In reply to comment #8) > > The work around is doing: > > get_a().template func2 (); > > > > > > Which tells the compiler for sure func2 is a template. > > > > Thanks, yeh I figured that out just now. Should it happen like this though? > Surely the compiler should be able to work out it's a template and therefore > not need the qualification? > I was just about to report a similar bug, but it was also "fixed" by adding a "template" qualifier to the function call. However, when studying the bug I ran my test case through the xlC compiler. It compiles "get_a().func2();" just fine; it doesn't need "get_a().template func2();" syntax. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000
[Bug c/31642] -O2 -fno-guess-branch-probability -fno-tree-ch -fno-tree-dominator-opts -fno-tree-lrs -fno-tree-dce -fno-tree-vrp -funit-at-a-time -ftree-copy-prop -ftree-copyrename yields an infinite l
--- Comment #2 from kenneth dot hoste at elis dot ugent dot be 2007-04-20 19:24 --- (In reply to comment #1) > We need a testcase. > I would provide one if I knew how, I'm quite new at this... Any pointers? -- kenneth dot hoste at elis dot ugent dot be changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31642
[Bug c++/31498] [4.1/4.2/4.3 Regression] ICE with vector initializer in template
--- Comment #1 from janis at gcc dot gnu dot org 2007-04-20 19:35 --- This starts passing for me between 2007-03-10 and 2007-03-20. Andrew, if it fails for you with a later mainline than that, perhaps it's an intermittent failure rather than a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31498
[Bug tree-optimization/31602] Overflow warning causes GDB -Werror build failure
--- Comment #4 from drow at gcc dot gnu dot org 2007-04-20 20:04 --- Subject: Re: Overflow warning causes GDB -Werror build failure On Fri, Apr 20, 2007 at 03:17:19PM -, ian at airs dot com wrote: > This patch fixes the test case in the PR. I am testing it. It would be > interesting to hear whether it also fixes the actual code in gdb. With this patch I can successfully build GDB for mips-linux - thanks! (barring PR31605). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
[Bug c++/31498] [4.1 Regression] ICE with vector initializer in template
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-20 20:30 --- I was testing at the time "4.3.0 20070306" and I tested with yesterday's trunk and it passes. It also works on the 4.2 branch as of "4.2.0 20070415". -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.4.0 4.0.2 4.1.0 4.2.0 |3.4.0 4.0.2 4.1.0 4.2.0 |4.3.0 | Known to work|3.3.3 |3.3.3 4.3.0 Summary|[4.1/4.2/4.3 Regression] ICE|[4.1 Regression] ICE with |with vector initializer in |vector initializer in |template|template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31498
[Bug target/28623] [4.1/4.2/4.3 regression] ICE in extract_insn, at recog.c:2077 (nrecognizable insn) [alpha]
--- Comment #4 from rth at gcc dot gnu dot org 2007-04-20 20:36 --- Subject: Bug 28623 Author: rth Date: Fri Apr 20 20:35:55 2007 New Revision: 124002 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124002 Log: PR target/28623 * config/alpha/alpha.c (get_unaligned_address): Remove extra_offset argument; update all callers. (get_unaligned_offset): New. * config/alpha/alpha.md (extendqidi2, extendhidi2): Don't use get_unaligned_address, just pass on the address directly. (unaligned_extendqidi): Use gen_lowpart instead of open-coding the subreg in the helper patterns. (unaligned_extendqidi_le): Use get_unaligned_offset. (unaligned_extendqidi_be, unaligned_extendhidi_le): Likewise. (unaligned_extendhidi_be): Likewise. (unaligned_extendhidi): Tidy. * config/alpha/alpha-protos.h: Update. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/alpha-protos.h trunk/gcc/config/alpha/alpha.c trunk/gcc/config/alpha/alpha.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28623
[Bug middle-end/31642] -O2 -fno-guess-branch-probability -fno-tree-ch -fno-tree-dominator-opts -fno-tree-lrs -fno-tree-dce -fno-tree-vrp -funit-at-a-time -ftree-copy-prop -ftree-copyrename yields an i
--- Comment #3 from kenneth dot hoste at elis dot ugent dot be 2007-04-20 20:51 --- identifying source code lines corresponding to infinite loop using GDB: (gdb) backtrace #0 regclass (f=0x9ac29f4, nregs=71) at regclass.c:732 #1 0x08065d5c in rest_of_compilation (decl=0x9b4526c) at toplev.c:3056 #2 0x0805713b in finish_function (nested=0) at c-decl.c:6791 #3 0x08048a25 in yyparse () at c-parse.c:1684 #4 0x08066a83 in compile_file (name=Variable "name" is not available. ) at toplev.c:2227 #5 0x080681a3 in main (argc=4, argv=0xbf945ea4) at toplev.c:3921 (gdb) n 736 else if ((GET_CODE (insn) == INSN (gdb) n 717 for (insn = f; insn; insn = NEXT_INSN (insn)) (gdb) n 729 if (GET_CODE (insn) == NOTE (gdb) n 732 else if (GET_CODE (insn) == NOTE (gdb) n 736 else if ((GET_CODE (insn) == INSN (gdb) n 717 for (insn = f; insn; insn = NEXT_INSN (insn)) (gdb) backtrace #0 regclass (f=0x9ac29f4, nregs=71) at regclass.c:717 #1 0x08065d5c in rest_of_compilation (decl=0x9b4526c) at toplev.c:3056 #2 0x0805713b in finish_function (nested=0) at c-decl.c:6791 #3 0x08048a25 in yyparse () at c-parse.c:1684 #4 0x08066a83 in compile_file (name=Variable "name" is not available. ) at toplev.c:2227 #5 0x080681a3 in main (argc=4, argv=0xbf945ea4) at toplev.c:3921 (gdb) The program seems stuck in the for-loop at line 717. The value for insn seems to be cycling (it's taking different values, but cycles back to a previous value). Any pointers on how to reduce this further are welcome... Since this is (pretty old though) GCC code (the 176.gcc corresponds to a 2.x version of GCC I believe), maybe someone can shed soem light on this? I'm not at all familiar with GCCs insides... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31642
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- Comment #12 from bdavis at gcc dot gnu dot org 2007-04-20 20:56 --- i can confirm the attached patch is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #96 from David dot Monniaux at ens dot fr 2007-04-20 21:19 --- The following paper explains how this kind of behaviour occurs, why it is "correct", why it is difficult to fix but how it can be partly fixed, and how this breaks many testing and proving techniques: http://hal.archives-ouvertes.fr/hal-00128124 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Comment #20 from steven at gcc dot gnu dot org 2007-04-20 21:58 --- It is my intention to fix see.c to work on x86* hardware, so I'm taking this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-15 20:30:45 |2007-04-20 21:58:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Comment #21 from steven at gcc dot gnu dot org 2007-04-20 22:10 --- Collection of important related links: http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00766.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437#c5 -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27437 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug fortran/31587] Module files shouldn't be updated if their content doesn't change
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-04-20 22:13
---
(In reply to comment #11)
> Time to CC Janis?
No need. There's nothing a bit of trial-and-error can't help you write :)
The following adds the necessary dejagnu directive, and uses it in a new test.
I guess the MD5 sum should be the same on all platforms, so it's a good test,
although it means the test will need updating every time someone changes the
format of module files :)
Index: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp (revision 123942)
+++ lib/gcc-dg.exp (working copy)
@@ -455,6 +455,24 @@
}
}
+# Scan Fortran modules for a given regexp.
+#
+# Argument 0 is the module name
+# Argument 1 is the regexp to match
+proc scan-module { args } {
+set modfilename [string tolower [lindex $args 0]].mod
+set fd [open $modfilename r]
+set text [read $fd]
+close $fd
+
+upvar 2 name testcase
+if [regexp -- [lindex $args 1] $text] {
+ pass "$testcase scan-module [lindex $args 1]"
+} else {
+ fail "$testcase scan-module [lindex $args 1]"
+}
+}
+
# Verify that the compiler output file exists, invoked via dg-final.
proc output-exists { args } {
# Process an optional target or xfail list.
Index: gfortran.dg/module_md5_1.f90
===
--- gfortran.dg/module_md5_1.f90(revision 0)
+++ gfortran.dg/module_md5_1.f90(revision 0)
@@ -0,0 +1,14 @@
+! Check that we can write a module file, that it has a correct MD5 sum,
+! and that we can read it back.
+!
+! { dg-do compile }
+module foo
+ integer(kind=4), parameter :: pi = 3_4
+end module foo
+
+program test
+ use foo
+ print *, pi
+end program test
+! { dg-final { scan-module "foo" "MD5:18a257e13c90e3872b7b9400c2fc6e4b" } }
+! { dg-final { cleanup-modules "foo" } }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
[Bug libstdc++/31643] New: Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
Problem:
When calling the out() method of a codecvt facet for a locale that specifies
UTF-8 encoding, the method fails to recognize partial (i.e., incomplete) UTF-8
encoding sequences at the end of the source string. Instead of returning the
expected
std::codecvt_base::partial status code with the returned source position
(arg-4) indexing the start of the incomplete sequence, the method returns
std::codecvt_base::ok with the returned source position just past the end of
the source string. Nothing from the partial sequence ends up in the
destination
wide string (as expected).
Compilation:
gcc -v --save-temps -Wall -ansi -pedantic -g -o localetest localetest.cxx
Compilation output:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/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-51)
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
loc
aletest.cxx -mtune=generic -ansi -Wall -pedantic -fworking-directory
-fpch-prepr
ocess -o localetest.ii
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../..
/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/i386-redhat-
linux
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/4.1.1/include
/usr/include
End of search list.
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -fpreprocessed localetest.ii
-
quiet -dumpbase localetest.cxx -mtune=generic -ansi -auxbase localetest -g
-Wall
-pedantic -ansi -version -o localetest.s
GNU C++ version 4.1.1 20070105 (Red Hat 4.1.1-51) (i386-redhat-linux)
compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-51).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4720743fdfefd64206c8550433f6e508
as -V -Qy -o localetest.o localetest.s
GNU assembler version 2.17.50.0.6-2.fc6 (i386-redhat-linux) using BFD version
2.
17.50.0.6-2.fc6 20061020
/usr/libexec/gcc/i386-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m elf_i386
--
hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 -o localetest
/usr/lib/gcc/i38
6-redhat-linux/4.1.1/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../
../crti.o /usr/lib/gcc/i386-redhat-linux/4.1.1/crtbegin.o
-L/usr/lib/gcc/i386-re
dhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1
-L/usr/lib/gcc/i386-redh
at-linux/4.1.1/../../.. localetest.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s
-lgc
c /usr/lib/gcc/i386-redhat-linux/4.1.1/crtend.o
/usr/lib/gcc/i386-redhat-linux/4
.1.1/../../../crtn.o
Test Source File (localetest.cxx):
//
// This test demonstrates that UTF-8 codecvt facets are ignoring incomplete
// trailing encoding sequences. The expected behavior is a return of the
// status value std::codecvt_base::partial, with the returned current source
// position at the start of the failed sequence. The actual behavior is a
// return of std::codecvt_base::ok, with the returned current source position
// at the end of the source string (i.e., the incomplete sequence is ignored).
//
#include
#include
#include
using namespace std;
//
// Some typedefs to help with facet access.
//
typedef codecvt_base::result Result;
typedef string::traits_type::state_type State;
typedef codecvt Converter;
wchar_t to[256];// Destination buffer.
//
// Perform each test iteration fresh, just to make sure that there isn't any
// lingering context between tests.
//
void
dotest(
const string &test_name,
const char *const locale_name,
const string &test_string
) {
State q;// Shift state context.
const string::value_type *me = 0; // Multibyte source current postion.
wstring::value_type *we = 0;// Wide destination current position.
Result status; // Conversion status.
//
// Set the current locale.
//
locale loc(locale_name);
locale::global(loc);
cout.imbue(loc);
//
// Start with a clear output buffer.
//
memset(to, 0, sizeof(to));
//
// Do the conversion from narrow multibyte to wide unicode.
//
const Converter& cvt = use_facet(loc);
memset(&q, 0, sizeof(q));
string::size_type src_size = test_string.size();
status =
cvt.in(
q,
test_string.data(), test_string.data() + src_
[Bug fortran/31618] backspace intrinsic is not working on an unformatted file
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-04-20 22:29 --- Strictly speaking, this is not a violation of the Fortran standard, as there are no guarantees of what happens after an error. Nonetheless, we should fix it. I'm investigating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug libstdc++/31643] Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
--- Comment #1 from jcavalla at postini dot com 2007-04-20 22:30 --- Created an attachment (id=13395) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13395&action=view) Verbose compilation output Produced with: g++ -v --save-temps -Wall -ansi -pedantic -g -o localetest localetest.cxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
[Bug libstdc++/31643] Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
--- Comment #2 from jcavalla at postini dot com 2007-04-20 22:31 --- Created an attachment (id=13396) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13396&action=view) Original test case source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
[Bug libstdc++/31643] Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
--- Comment #3 from jcavalla at postini dot com 2007-04-20 22:31 --- Created an attachment (id=13397) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13397&action=view) Preprocessed intermediate file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
[Bug libstdc++/31643] Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
--- Comment #4 from jcavalla at postini dot com 2007-04-20 22:32 --- Created an attachment (id=13398) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13398&action=view) Test results -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
[Bug libstdc++/31643] Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
--- Comment #5 from jcavalla at postini dot com 2007-04-20 22:37 --- 1. Please note that 'g++' was used to compile, not 'gcc' as stated below. Sorry. 2. I marked this bug 'major' instead or 'normal' because callers will not be able to determine whether or not they need to supply more input to complete a sequence. If in a read/convert type loop with preserved shift state across convert calls, this may not matter. I will run such a test and post the results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
[Bug libstdc++/31643] Codecvt facets with UTF-8 encoding fail to recognize partial encoding sequences
--- Comment #6 from jcavalla at postini dot com 2007-04-20 22:59 --- I ran additional tests just to make sure that the shift state was valid across calls, even though partial is not returned when a chunk ends in a partial encoding sequence. I split several 2,3, and 4 byte UTF character sequences across two calls to the codecvt in() method. Each time, the sequence was correctly widened into 1 UTF-32 character code. Thus, the shift state appears to be OK. Just the return value of 'ok' is incorrect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31643
[Bug target/31628] stdcall function is miscompiled
--- Comment #6 from rth at gcc dot gnu dot org 2007-04-21 00:53 --- Subject: Bug 31628 Author: rth Date: Sat Apr 21 00:53:37 2007 New Revision: 124014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124014 Log: PR target/31628 * config/i386/i386.c (type_has_variadic_args_p): Look for any TREE_LIST with a void_type_node value, not void_list_node exactly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug target/31628] stdcall function is miscompiled
--- Comment #7 from rth at gcc dot gnu dot org 2007-04-21 00:58 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug tree-optimization/31605] [4.2/4.3 Regression] VRP eliminates a useful test due with conversion from unsigned int to int
--- Comment #5 from ian at airs dot com 2007-04-21 02:08 --- Created an attachment (id=13399) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13399&action=view) Proposed patch Currently testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31605
[Bug preprocessor/11242] [mingw32] #include takes my memory directory instead of the standard memory header file
--- Comment #6 from zackw at panix dot com 2007-04-21 02:56 --- I am inclined to think that this is an operating system bug and should be worked around in the mingw32 libraries, not in cpplib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242
