[Bug c++/32232] [4.1/4.2/4.3 Regression] ICE in resolve_overloaded_unification
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-07-07 07:32 --- Subject: Bug 32232 Author: mmitchel Date: Sat Jul 7 07:31:54 2007 New Revision: 126435 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126435 Log: PR c++/32232 * pt.c (resolve_overloaded_unification): Robustify. Return a bool, not an int. (type_unification_real): Adjust accordingly. PR c++/32232 * g++.dg/template/overload9.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/overload9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug c++/32232] [4.1/4.2 Regression] ICE in resolve_overloaded_unification
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-07-07 07:36 --- Fixed in 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression] ICE|[4.1/4.2 Regression] ICE in |in |resolve_overloaded_unificati |resolve_overloaded_unificati|on |on | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug target/32664] New: [sh] ICE in create_pre_exit, at mode-switching.c:373
Hello, there seems to be a problem compiling the attached source file with sh-elf-gcc: /home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem /home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/sh-elf-new/sh-elf/bin/ -B/n/07/mstein/cross-local/sh-elf-new/sh-elf/lib/ -isystem /n/07/mstein/cross-local/sh-elf-new/sh-elf/include -isystem /n/07/mstein/cross-local/sh-elf-new/sh-elf/sys-include -L/home/mstein/sim/sh-elf/build/./ld -O2 -g -O2 -m2a -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -DHAVE_CC_TLS -o _divdi3.o -MT _divdi3.o -MD -MP -MF _divdi3.dep -DL_divdi3 -c /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c \ -fexceptions -fnon-call-exceptions /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c: In function '__divdi3': /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c:1102: internal compiler error: in create_pre_exit, at mode-switching.c:373 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. host gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/mstein/svn/trunk/configure --enable-languages=c --disable-nls --prefix=/n/07/mstein/host-gcc/trunk-2007-07-07 Thread model: posix gcc version 4.3.0 20070706 (experimental) xgcc -v Using built-in specs. Target: sh-elf Configured with: /n/07/mstein/combined-trunk/configure --target=sh-elf --prefix=/n/07/mstein/cross-local/sh-elf-new --with-sysroot=/n/07/mstein/cross-local/sh-elf --enable-languages=c --disable-nls --disable-build-warnings --with-newlib --with-gnu-as -with-gnu-ld Thread model: single gcc version 4.3.0 20070706 (experimental) Tested revision: 126426 Last succesfull build revision: 126390 -- Summary: [sh] ICE in create_pre_exit, at mode-switching.c:373 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32664
[Bug target/32664] [sh] ICE in create_pre_exit, at mode-switching.c:373
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-07-07 07:46 --- Created an attachment (id=13862) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13862&action=view) preprocessed source file from gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32664
[Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
--- Comment #1 from ubizjak at gmail dot com 2007-07-07 08:22 --- This is fixed in gcc-4.3: _Z3fooPyPKyy: movq%rdx, %rax mulq(%rsi) movq%rdx, (%rdi) ret _Z3fooPyPKyyy: andq(%rsi), %rcx movq%rcx, %rax mulq%rdx movq%rdx, (%rdi) ret _Z4foo2PyPKyy: movq%rdx, %r8 movq%rdx, %rax pushq %rbx <<< here mulq(%rsi) popq%rbx <<< here movq%rdx, (%rdi) movq8(%rsi), %rax mulq%r8 movq%rdx, 8(%rdi) ret _Z4foo2PyPKyyy: movq%rcx, %r9 andq(%rsi), %r9 movq%rdx, %r10 movq%r9, %rax mulq%rdx movq%rdx, (%rdi) andq8(%rsi), %rcx movq%rcx, %rax mulq%r10 movq%rdx, 8(%rdi) ret A lot of infrastructure changes were introduced during gcc-4.3 development (subregs splitting, dataflow) to produce the code above, and these changes surely won't get ported to release branches. Saving and restoring %rbx is not needed in foo2 case, perhaps dataflow experts know why it is still generated? -- ubizjak at gmail dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
[Bug target/32660] ICE using __builtin_ia32_vec_ext_v2di()
--- Comment #2 from ubizjak at gmail dot com 2007-07-07 08:23 --- Compiles OK in 4.3.0. -- ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32660
[Bug target/32660] ICE using __builtin_ia32_vec_ext_v2di()
--- Comment #3 from uros at gcc dot gnu dot org 2007-07-07 09:23 --- Subject: Bug 32660 Author: uros Date: Sat Jul 7 09:23:04 2007 New Revision: 126438 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126438 Log: PR target/32660 Backport from mainline. * config/i386/sse.md (*vec_extractv2di_1_sse2): New. (*vec_extractv2di_1_sse): New. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32660
[Bug target/32660] [4.2 Regression] ICE using __builtin_ia32_vec_ext_v2di()
--- Comment #4 from ubizjak at gmail dot com 2007-07-07 09:24 --- Confirmed, still regression on 4.2 branch. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-07 09:24:27 date|| Summary|ICE using |[4.2 Regression] ICE using |__builtin_ia32_vec_ext_v2di(|__builtin_ia32_vec_ext_v2di( |) |) Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32660
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #1 from ubizjak at gmail dot com 2007-07-07 09:25 --- Confirmed, not a regression. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-07 09:25:01 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug fortran/32665] New: allocatable array on lhs deleted while still in use on rhs
While experimenting with testcases from PR31320, I hit this:
$> cat alloc.f90
TYPE :: x
INTEGER, ALLOCATABLE :: a(:)
END TYPE
TYPE(x) :: a
a = x((/ 1, 2, 3 /))
a = x((/ a%a, 4 /))
end
$> gfortran-svn -g -Wall -fdump-tree-original allocatable.f90 && ./a.out
Segmentation fault
$> valgrind --tool=memcheck --leak-check=full ./a.out
[...]
==2287== Invalid read of size 4
==2287==at 0x804895F: MAIN__ (allocatable.f90:8)
==2287==by 0x8048C78: main (fmain.c:22)
==2287== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==2287==
==2287== Process terminating with default action of signal 11 (SIGSEGV)
==2287== Access not within mapped region at address 0x0
==2287==at 0x804895F: MAIN__ (allocatable.f90:8)
==2287==by 0x8048C78: main (fmain.c:22)
>From trre-dump:
[...]
_gfortran_deallocate (a.a.data, &D.1050);
a.a.data = 0B;
[...]
D.1029 = (int4[0:] *) a.a.data;
[...]
while (1)
{
if (S.6 > a.a.dim[0].ubound) goto L.1;
(*(int4[0:] *) atmp.4.data)[offset.5] = (*D.1029)[S.6 * D.1034 +
D.1030];
offset.5 = offset.5 + 1;
S.6 = S.6 + 1;
}
L.1:;
$> gcc version 4.3.0 20070705 (experimental)
--
Summary: allocatable array on lhs deleted while still in use on
rhs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32665
[Bug target/32664] [sh] ICE in create_pre_exit, at mode-switching.c:373
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-07-07 10:42 ---
This is same on sh4-unknown-linux-gnu. A reduced testcase
long long
foo (long long u)
{
return u;
}
fails on sh4 with -fnon-call-exceptions.
It looks that it started to fail after the patch
r126403 | uros | 2007-07-06 17:53:15 +0900 (Fri, 06 Jul 2007) | 13 lines
PR rtl_optimization/32450
* function.c (thread_prologue_and_epilogue_insns): Emit blockage insn
to ensure that instructions are not moved into the prologue when
profiling is on. Remove unused prologue_end variable.
(expand_function_end): Emit blockage insn instead of ASM_INPUT rtx
as a scheduling barrier.
mode-switching.c:create_pre_exit skipped the above scheduling barrier
when scanning the insns:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00457.html
Now the barrier is replaced with a real blockage insn, we should skip
this real blockage insn. I'm testing the patch below:
* mode-switching.c: Skip blockage insn instead of ASM_INPUT rtx.
--- ORIG/trunk/gcc/mode-switching.c 2007-06-12 09:34:43.0 +0900
+++ LOCAL/trunk/gcc/mode-switching.c2007-07-07 18:31:46.0 +0900
@@ -209,6 +209,7 @@ create_pre_exit (int n_entities, int *en
edge eg;
edge_iterator ei;
basic_block pre_exit;
+ rtx blockage_insn = gen_blockage ();
/* The only non-call predecessor at this stage is a block with a
fallthrough edge; there can be at most one, but there could be
@@ -255,8 +256,7 @@ create_pre_exit (int n_entities, int *en
last_insn = return_copy;
continue;
}
- if (GET_CODE (PATTERN (return_copy)) == ASM_INPUT
- && strcmp (XSTR (PATTERN (return_copy), 0), "") == 0)
+ if (rtx_equal_p (PATTERN (return_copy), blockage_insn))
{
last_insn = return_copy;
continue;
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||build, ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-07-07 10:42:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32664
[Bug c++/31338] [4.1 regression] Cannot apply "!" to complex constants
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:43 --- This fix ported PR 31780 back to the 4.2 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-07 10:47 --- The ICE is now also present on the 4.2 branch. Most likely caused by the patch for PR 31338. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com Summary|[4.3 regression] ICE with |[4.2/4.3 regression] ICE |incompatible types for ?: |with incompatible types for |with "complex type" |?: with "complex type" |conversion |conversion Target Milestone|4.3.0 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:59
---
Mark, is there any reason, you added the exectuable flag?
If not, would you mind removing it?
> Propchange: trunk/gcc/testsuite/g++.dg/init/new20.C
>('svn:executable' added)
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||mark at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug tree-optimization/19910] [4.2/4.3 regression] ICE with -ftree-loop-linear
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-07-07 11:07 --- The testcase indeed doesn't crash on mainline (i686-pc-linux-gnu) anymore. It still crashes on the 4.2 branch, though. Given that the testcase disappeared and reappeared on mainline the problem might still be latent on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug target/32337] [4.3 Regression] Error: Register number out of range 0..1
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||07/msg00629.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-07 12:45:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
[Bug tree-optimization/32650] Convert p+strlen(p) to strchr(p, '\0') if profitable
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-07 13:27 --- Confirmed. -- rguenth 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-07-07 13:27:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32650
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-07 13:32 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |RESOLVED Keywords||missed-optimization Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
[Bug target/28904] operand out of range on Linux/PowerPC
--- Comment #8 from srm at schokokeks dot org 2007-07-07 13:37 --- crystalspace also has a bug report for this (http://www.crystalspace3d.org/trac/CS/ticket/210) as mentioned there, one could try this http://www.crystalspace3d.org/trac/CS/ticket/258 which is using a special branch for the python modules. using this branch, i had no problem building the python modules. maybe it's worth a look for you :) i dont really get the point...but, eager to... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #1 from hjl at lucon dot org 2007-07-07 14:31 --- Revision 126198 is good and revision 126338 is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #2 from hjl at lucon dot org 2007-07-07 14:47 --- Revision 126286 is good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
--- Comment #3 from scovich at gmail dot com 2007-07-07 14:55 --- While it's nice that the new optimization framework can eliminate the redundant IMUL instruction(s), why were they being generated in the first place? Compiling the simpler foo() without optimizations gives: _Z3fooPyPKyy: .LFB2: pushq %rbp .LCFI0: movq%rsp, %rbp .LCFI1: pushq %rbx .LCFI2: movq%rdi, -16(%rbp) movq%rsi, -24(%rbp) movq%rdx, -32(%rbp) movq-24(%rbp), %rax movq(%rax), %rax movq%rax, %rcx movl$0, %ebx << here movq-32(%rbp), %rax movl$0, %edx << here movq%rbx, %rsi imulq %rax, %rsi<< here movq%rdx, %rdi imulq %rcx, %rdi<< here addq%rdi, %rsi mulq%rcx addq%rdx, %rsi movq%rsi, %rdx movq%rdx, %rax xorl%edx, %edx movq%rax, %rdx movq-16(%rbp), %rax movq%rdx, (%rax) popq%rbx leave ret Barring something really strange it seems like this problem could/should be fixed at its source, even for 4.1/4.2 Reopen? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
[Bug fortran/31832] FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above
--- Comment #3 from danglin at gcc dot gnu dot org 2007-07-07 15:09 --- I don't know. I haven't been able to bootstrap hppa64-hp-hpux11.11 since the dataflow merge. The following two tests are failing on hppa2.0w-hp-hpux11.11 (revision 126397): FAIL: gfortran.dg/integer_exponentiation_2.f90 -O3 -fomit-frame-pointer -funrol l-loops execution test FAIL: gfortran.dg/integer_exponentiation_2.f90 -O3 -fomit-frame-pointer -funrol l-all-loops -finline-functions execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31832
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #3 from hjl at lucon dot org 2007-07-07 15:14 --- Revision 126328 is good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #4 from hp at gcc dot gnu dot org 2007-07-07 15:17 --- In reply to comment #4: confirmed. I've now confirmed that it is commit 126198 that exposed this bug, so I'll remove all other people from CC. You're very welcome to add yourself back, of course. :) Richi, if you can shed some light on what optimizations (what passes) your patch helped (caused more work for) the most, I'd be grateful. Or if you just fix the bug. :) There are trees named regress126197 and regress126198 in my home directory on gcc11 on the compile farm... where you don't have an account, bother. -- hp 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-07-07 15:17:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #5 from rguenther at suse dot de 2007-07-07 15:24 --- Subject: Re: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure On Sat, 7 Jul 2007, hp at gcc dot gnu dot org wrote: > --- Comment #4 from hp at gcc dot gnu dot org 2007-07-07 15:17 --- > In reply to comment #4: confirmed. I've now confirmed that it is commit > 126198 > that exposed this bug, so I'll remove all other people from CC. You're very > welcome to add yourself back, of course. :) Richi, if you can shed some light > on what optimizations (what passes) your patch helped (caused more work for) > the most, I'd be grateful. Or if you just fix the bug. :) There are trees > named regress126197 and regress126198 in my home directory on gcc11 on the > compile farm... where you don't have an account, bother. So the only real change in this patch is in the following hunk: Index: tree-inline.c === --- tree-inline.c (revision 126197) +++ tree-inline.c (revision 126198) @@ -1278,10 +1278,15 @@ setup_one_parameter (copy_body_data *id, tree init_stmt; tree var; tree var_sub; - tree rhs = value ? fold_convert (TREE_TYPE (p), value) : NULL; + tree rhs = value; tree def = (gimple_in_ssa_p (cfun) ? gimple_default_def (id->src_cfun, p) : NULL); + if (value + && value != error_mark_node + && !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))) +rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value); + /* If the parameter is never assigned to, has no SSA_NAMEs created, we may not need to create a new variable here at all. Instead, we may be able to just use the argument value. */ See also PR32624. Can you check if changing this part like in comment #4 of that PR fixes this bug? It will only result in less casts and less temporaries, but as can be seen from PR32624 this has some strange effects. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #4 from hjl at lucon dot org 2007-07-07 15:35 --- I verified that this patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00323.html causes this regression. It only happens for 32bit target. -- hjl at lucon dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #6 from hp at gcc dot gnu dot org 2007-07-07 15:44 ---
Failing pass:
#4 0x00738bbf in execute_one_pass (pass=0xca6280) at
/home/hp/regress126198/gcc/gcc/passes.c:1147
(gdb) p *pass
$1 = {name = 0xafff81 "store_copyprop", gate = 0x848c70 ,
execute = 0x84c060 ,
sub = 0x0, next = 0xca61c0, static_pass_number = 85, tv_id = 40,
properties_required = 584, properties_provided = 0,
properties_destroyed = 0, todo_flags_start = 131072, todo_flags_finish =
1063, letter = 0 '\0'}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug libstdc++/32666] New: FAIL: abi_check
abi_check is failing on hppa-unknown-linux-gnu with Debian lenny (libc6 2.5-9): === libstdc++-v3 check-abi Summary === # of added symbols: 74 # of missing symbols:22 # of incompatible symbols: 23 using: baseline_symbols.txt FAIL: abi_check I've seen this with 4.2.1 and 4.3.0. -- Summary: FAIL: abi_check Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
[Bug libstdc++/32666] FAIL: abi_check
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07 15:55 --- Subject: Re: New: FAIL: abi_check > I've seen this with 4.2.1 and 4.3.0. Attached is the output log (probably somewhat out of order). Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07 15:55 --- Created an attachment (id=13863) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13863&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #7 from hp at gcc dot gnu dot org 2007-07-07 15:56 --- Created an attachment (id=13864) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13864&action=view) one of the dumps generated with -fdump-tree-store_copyprop-vops-blocks -fdump-tree-store_ccp-vops-blocks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #8 from hp at gcc dot gnu dot org 2007-07-07 15:57 --- Created an attachment (id=13865) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13865&action=view) the other dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #9 from hp at gcc dot gnu dot org 2007-07-07 16:00 --- Using the patch in comment #5 applied on 126197 causes the same failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
--- Comment #4 from rask at sygehus dot dk 2007-07-07 16:08 --- In reply to comment #1: If you're splitting a multiword subreg (such as %rbx:%rcx) after reload, then the prologue/epilogue code has no way of knowing that all use of %rbx is later optimized away. I don't know if this is what's happening here, but that would be the first thing I'd look for. In reply to comment #2: For both GCC 4.1.x and 4.2.x, the status is "regression fixes & docs only", so unless some older release produced better code, this won't be fixed in GCC 4.1.x or 4.2.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-07 16:13 --- So the bogus replacement happens in store_copyprop (function _ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiET_S3_S3_T0_RKT1_St20forward_iterator_tag) for a (yet) mysterious reason it replaces in # BLOCK 25 freq:2 # PRED: 23 [46.0%] (false,exec) 21 [46.0%] (false,exec) # SMT.1008_263 = PHI # __i$D47460$SharedInfo_92 = PHI <__i$D47460$SharedInfo_40(23), SR.1030_31(21)> # __i$D47460$ptr_93 = PHI <__i$D47460$ptr_39(23), __i$D47460$ptr_75(21)> __i$D47460$ptr_106 = __i$D47460$ptr_93 + 4; # VUSE D.52134_317 = D.48545_101->SharedInfo; ! if (__i$D47460$SharedInfo_92 != D.52134_317) goto ; else goto ; # SUCC: 32 [85.0%] (true,exec) 26 [15.0%] (false,exec) the __i$D47460$SharedInfo_92 by __i$D47460$SharedInfo_40. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #11 from hp at gcc dot gnu dot org 2007-07-07 16:15 --- Created an attachment (id=13866) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13866&action=view) dump with -fdump-tree-store_copyprop-vops-blocks-details -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug fortran/32644] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-07 16:35 --- I will have a look -- 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|NEW |ASSIGNED Last reconfirmed|2007-07-06 11:53:03 |2007-07-07 16:35:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug c/32570] Compiling GCC 4.3.0 with CIL instead of using GCC 4.2 or 4.3 finds many warnings that GCC does not report
--- Comment #3 from rob1weld at aol dot com 2007-07-07 16:41 --- A bug report has been filed with 'hal'. What had happened was that CIL had optimized away, in some cases, and created incorrect code in other cases; based on what it read of the GCC 4.3 sources. It then fed the C2C back to GCC which then complained about it's code. This will be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32570
[Bug fortran/32644] [4.3 Regression] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-07 16:48 --- This is a regression against 4.2. It looks like its not making it through the parser. Hmm. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Keywords|diagnostic |rejects-valid Summary|"CHARACTER*1, c" produces |[4.3 Regression] |"Unclassifiable statement" |"CHARACTER*1, c" produces ||"Unclassifiable statement" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #5 from hjl at lucon dot org 2007-07-07 16:54 --- Before the change, PRE generates: # prephitmp.165_1394 = PHI # prephitmp.165_1395 = PHI # nlast_26 = PHI <0(127), nlast_442(130)> # lasp_21 = PHI <1(127), lasp_454(130)> D.1457_436 = prephitmp.165_1395; ii.62_440 = ii; D.1361_441 = ii.62_440 + -1; nlast_442 = (*iwhi_303(D))[D.1361_441]; D.1459_443 = nlast_442 + -1; D.1460_444 = D.1459_443 * nlast_442; D.1461_445 = D.1460_444 / 2; D.1462_446 = D.1457_436 + D.1461_445; storetmp.156_466 = D.1462_446; *nswe_430(D) = D.1462_446; D.1463_447 = prephitmp.165_1394; D.1464_448 = D.1463_447 + 1; storetmp.156_452 = D.1464_448; *ncat_431(D) = D.1464_448; D.1466_451 = nlast_26 + lasp_21; (*inat_192(D))[D.1463_447] = D.1466_451; D.1465_453 = prephitmp.165_1394; After change, PRE generates: # prephitmp.165_1395 = PHI # nlast_26 = PHI <0(127), nlast_442(130)> # lasp_21 = PHI <1(127), lasp_454(130)> D.1457_436 = prephitmp.165_1395; ii.62_440 = ii; D.1361_441 = ii.62_440 + -1; nlast_442 = (*iwhi_303(D))[D.1361_441]; D.1459_443 = nlast_442 + -1; D.1460_444 = D.1459_443 * nlast_442; D.1461_445 = D.1460_444 / 2; D.1462_446 = D.1457_436 + D.1461_445; storetmp.156_466 = D.1462_446; *nswe_430(D) = D.1462_446; D.1463_447 = D.1465_453; D.1464_448 = D.1463_447 + 1; *ncat_431(D) = D.1464_448; D.1466_451 = nlast_26 + lasp_21; (*inat_192(D))[D.1463_447] = D.1466_451; D.1465_453 is never initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug tree-optimization/32607] [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-07 17:02 --- Related to (or a dup of) PR 31926. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn||31926 Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32607
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
-- 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=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-07 17:04
---
So the problem is that we detect
PHI node __i$D47460$SharedInfo_92 copy-of chain: __i$D47460$SharedInfo_92 ->
__i$D47460$SharedInfo_40 -> SR.1030_31 -> SR.1030_31 [COPY]
but later replace with __i$D47460$SharedInfo_40 instead of SR.1030_31.
So the problem seems to be we sort of have
struct Foo {
int x;
};
void use(int);
void foo(struct Foo *p, int q)
{
int a = p->x;
int b, c, d;
if (a)
c_1 = p->x;
else
{
c_3 = a;
}
# c_4 = PHI
use (c);
}
where copyprop figures that c_1 and a are the same load and so does
figure that c_4 is a copy of a and c_1 and c_3. But there is no
code that figures the proper ssa_name loaded into as of a dominance
relationship. (Of course the above testcase doesn't fail... but you
get the idea what happens.)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug pch/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-07-07 17:23
---
The following creates a similar copy chain, but still chooses the right one to
copy from.
struct Foo {
int x;
};
void use(int);
void foo(struct Foo *p, int q)
{
int a = p->x;
int b, c;
p->x = a;
if (q)
c = p->x;
else
c = a;
use (c);
}
./cc1 -quiet -O2 t.i -fdump-tree-all-vops-details -fno-tree-fre -fno-tree-pre
-fno-tree-dominator-opts -fno-tree-vrp
Visiting PHI node: c_1 = PHI
Argument #0: c_5 copy-of chain: c_5 -> a_3 -> a_3 [COPY]
Argument #1: a_3 copy-of chain: a_3 -> a_3 [NOT A COPY]
PHI node c_1 copy-of chain: c_1 -> c_5 -> a_3 -> a_3 [COPY]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug middle-end/32662] Significant extra code generation for 64x64=>128-bit multiply
--- Comment #5 from rask at sygehus dot dk 2007-07-07 17:26 --- s/multiword subreg/multiword hard reg/g and s/comment #2/comment #3/g in comment #4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|pch |tree-optimization Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug fortran/29876] ICE on bad operator in ONLY clause of USE statement
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-22 10:05:35 |2007-07-07 17:47:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29876
[Bug c++/32667] New: builtin operator= generates memcpy with overlapping memory regions
This code generates a warning when run with valgrind:
#include
using namespace ::std;
struct X {
double values[10];
};
int main()
{
vector x;
x.push_back(X());
for (vector::iterator i=x.begin();i!=x.end();++i) {
*i = *(x.end()-1);
}
return 0;
}
g++ test.cpp -o foo -O3
Valgrind error:
valgrind --tool=memcheck foo
==24513== Memcheck, a memory error detector for x86-linux.
==24513== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==24513== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==24513== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==24513== For more details, rerun with: -v
==24513==
==24513== Source and destination overlap in memcpy(0x1BB68028, 0x1BB68028, 80)
==24513==at 0x1B9057E5: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==24513==by 0x8048696: main (in /home/ray/tmp/foo)
==24513==
==24513== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 1)
==24513== malloc/free: in use at exit: 0 bytes in 0 blocks.
==24513== malloc/free: 1 allocs, 1 frees, 80 bytes allocated.
==24513== For a detailed leak analysis, rerun with: --leak-check=yes
==24513== For counts of detected errors, rerun with: -v
On my machine "man memcpy" says "...The memory areas may not overlap. Use
memmove(3) if the memory areas do overlap. ..."
--
Summary: builtin operator= generates memcpy with overlapping
memory regions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Raimund dot Merkert at baesystems dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[Bug c++/16696] Strange message when operator++ not found
--- Comment #10 from rob1weld at aol dot com 2007-07-07 18:05 ---
I compiled the program I was working on using GCC 4.2 that was configured using
the option "--enable-concept-checks" and one file would not compile; giving
this error:
/usr/include/c++/4.2/bits/boost_concept_check.h: In member function 'void
__gnu_cxx::_InputIteratorConcept<_Tp>::__constraints() [with _Tp =
profile_t::const_iterator]':
/usr/include/c++/4.2/bits/boost_concept_check.h:63: instantiated from 'void
__gnu_cxx::__function_requires() [with _Concept =
__gnu_cxx::_InputIteratorConcept]'
/usr/include/c++/4.2/bits/stl_numeric.h:84: instantiated from '_Tp
std::accumulate(_InputIterator, _InputIterator, _Tp) [with _InputIterator =
profile_t::const_iterator, _Tp = long long unsigned int]'
/usr/include/c++/4.2/bits/boost_concept_check.h:456: error: no
'operator++(int)' declared for postfix '++', trying prefix operator instead
I recompiled that one file only using GCC 4.3 that was configured WITHOUT using
the option "--enable-concept-checks" and the file compiled fine. I ran "make
check" and all tests passed.
I did some searching for the use of concept checks, first on my installed
files:
# grep -r GLIBCXX_CONCEPT_CHECKS /usr/include/*
/usr/include/c++/4.2/bits/concept_check.h:#ifndef _GLIBCXX_CONCEPT_CHECKS
/usr/include/c++/4.2/bits/c++config.h:#define _GLIBCXX_CONCEPT_CHECKS 1
Binary file /usr/include/c++/4.2/bits/stdc++.h.gch/O0g.gch matches
Binary file /usr/include/c++/4.2/bits/stdc++.h.gch/O2g.gch matches
Binary file /usr/include/c++/4.2/bits/stdtr1c++.h.gch/O2g.gch matches
/usr/include/c++/4.2/i686-pc-linux-gnu/bits/c++config.h:#define
_GLIBCXX_CONCEPT_CHECKS 1
Binary file /usr/include/c++/4.2/i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch
matches
Binary file /usr/include/c++/4.2/i686-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch
matches
Binary file /usr/include/c++/4.2/i686-pc-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
matches
/usr/include/c++/4.1.2/bits/concept_check.h:#ifndef _GLIBCXX_CONCEPT_CHECKS
/usr/include/c++/4.1.2/i486-linux-gnu/bits/c++config.h:/* #undef
_GLIBCXX_CONCEPT_CHECKS */
/usr/include/c++/4.1.2/i486-linux-gnu/64/bits/c++config.h:/* #undef
_GLIBCXX_CONCEPT_CHECKS */
/usr/include/c++/3.4/bits/concept_check.h:#ifndef _GLIBCXX_CONCEPT_CHECKS
/usr/include/c++/3.4/x86_64-linux-gnu/bits/c++config.h:/* #undef
_GLIBCXX_CONCEPT_CHECKS */
/usr/include/c++/3.4/i486-linux-gnu/bits/c++config.h:/* #undef
_GLIBCXX_CONCEPT_CHECKS */
/usr/include/c++/4.1/bits/concept_check.h:#ifndef _GLIBCXX_CONCEPT_CHECKS
/usr/include/c++/4.1/i486-linux-gnu/bits/c++config.h:/* #undef
_GLIBCXX_CONCEPT_CHECKS */
/usr/include/c++/4.1/i486-linux-gnu/64/bits/c++config.h:/* #undef
_GLIBCXX_CONCEPT_CHECKS */
Next, on GCC 4.3.0 source code (edited results - removed .html and ChangeLogs):
/root/downloads/gcc-4_3-trunk/libstdc++-v3/include/bits/concept_check.h
/root/downloads/gcc-4_3-trunk/libstdc++-v3/src/Makefile.in
/root/downloads/gcc-4_3-trunk/libstdc++-v3/src/concept-inst.cc
/root/downloads/gcc-4_3-trunk/libstdc++-v3/src/Makefile.am
/root/downloads/gcc-4_3-trunk/libstdc++-v3/configure
/root/downloads/gcc-4_3-trunk/libstdc++-v3/config.h.in
/root/downloads/gcc-4_3-trunk/libstdc++-v3/acinclude.m4
The file gcc-4_3-trunk/libstdc++-v3/docs/html/17_intro/howto.html says:
"Undefined by default. Configurable. When defined, performs compile-time
checking on certain template instantiations to detect violations of the
requirements of the standard."
It would be better if they were on by default - I can compile GCC 4.2 and 4.3
on target i686-pc-linux-gnu with them on. It seems unfortunate to have them
off.
This file obviously needs a little update but,
gcc-4_3-trunk/libstdc++-v3/docs/html/19_diagnostics/howto.html says:
"They are off by default for all versions of GCC from 3.0 to 3.4 (the latest
release at the time of writing). They can be enabled at configure time with
"--enable-concept-checks". You can enable them on a per-translation-unit basis
with "#define _GLIBCXX_CONCEPT_CHECKS" for GCC 3.4 and higher (or with
#define _GLIBCPP_CONCEPT_CHECKS for versions 3.1, 3.2 and 3.3)."
Reading that tells me that they are off by default and if you configure GCC
using "--enable-concept-checks" they are also automatically on for any code you
compile, thus the error message.
Suggested FIX:
The error message could be converted to a warning message _IF_ the compiler
detected the problem and instead of issuing an error message used a (NEW) GCC
command line switch "-fno-concept-checks" to disable the checks for the one
file - better yet, for the one function (or line of code!).
This would give us the benefit of concept checks without the problem of needing
to rewrite older code to avoid what is described as "Strange message when
operator++ not found". Indeed, if not strange it is a challenge for a non C++
programmer to figure out the line of source code at fault from the resulting
error message,
A precident for adding a new GCC option ("-fno-concept-ch
[Bug c++/32667] builtin operator= generates memcpy with overlapping memory regions
--- Comment #1 from pcarlini at suse dot de 2007-07-07 18:19 --- Interesting: mainline is not affected by the problem. I would guess thanks to fixing libstdc++/29286 ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[Bug fortran/32644] [4.3 Regression] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-07 18:19 --- I have confirmed that this problem occurred after the iso_c_binding merge and is not part of the initial merge itself. That narrows it down quite a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug fortran/29876] ICE on bad operator in ONLY clause of USE statement
--- Comment #1 from patchapp at dberlin dot org 2007-07-07 18:25 --- Subject: Bug number PR29876 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-07/msg00645.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29876
[Bug c++/16696] Strange message when operator++ not found
--- Comment #11 from pcarlini at suse dot de 2007-07-07 18:27 --- One comment, to avoid wasting time (I don't have the time to understand why the old library-simulation of concept checks is discussed in a C++ PR): for sure we are not going to enable by default the simulated concept checks (and all the compile-time performace issues and slight non-conformance issues). It's way, way, too late for that. *Real* concepts are finally, gloriously coming in C++0x. We can only consider slightly tweaking what we have in case some of the "concepts" are slightly off. Only a tad above regression-only mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16696
[Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-07 19:07 --- Salvatore, could you please recheck this one? I can not observe any problems, neither on dt_bnd.f90 nor on the reduced testcase. $> gfortran-svn -g -fbounds-check dt_bnd.f90 && ./a.out [snipped output] $> valgrind --tool=memcheck --leak-check=full a.out [...] ==12425== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==12425== malloc/free: in use at exit: 0 bytes in 0 blocks. ==12425== malloc/free: 24 allocs, 24 frees, 44,703 bytes allocated. $> gfortran-svn -v gcc version 4.3.0 20070705 (experimental) The same holds for: $> gfortran-4.2 -v gcc version 4.2.1 20070620 (prerelease) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29804
[Bug c++/32232] [4.1/4.2 Regression] ICE in resolve_overloaded_unification
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-07 19:16 --- Subject: Bug 32232 Author: mmitchel Date: Sat Jul 7 19:16:09 2007 New Revision: 126443 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126443 Log: PR c++/32232 * pt.c (resolve_overloaded_unification): Robustify. Return a bool, not an int. (type_unification_real): Adjust accordingly. PR c++/32232 * g++.dg/template/overload9.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/overload9.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug c++/32232] [4.1 Regression] ICE in resolve_overloaded_unification
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-07-07 19:16 --- Fixed in 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mmitchel at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.1/4.2 Regression] ICE in |[4.1 Regression] ICE in |resolve_overloaded_unificati|resolve_overloaded_unificati |on |on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #11 from mark at codesourcery dot com 2007-07-07 19:18 ---
Subject: Re: [4.1/4.2/4.3 regression] ICE with invalid use
of new
reichelt at gcc dot gnu dot org wrote:
> --- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:59
> ---
> Mark, is there any reason, you added the exectuable flag?
> If not, would you mind removing it?
>
>> Propchange: trunk/gcc/testsuite/g++.dg/init/new20.C
>>('svn:executable' added)
I suspect that this is an accident of the file having been on a Cygwin
system at some point. I've noticed that when I scp from a Cygwin
system, text files tend to get executable permissions.
If you will tell me how to remove the flag, I will take care of it.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-07-07 19:26 ---
Here's a testcase:
int foo1 (float fp)
{
return __builtin_isnan (fp);
}
int foo2 (float fp)
{
return __builtin_isnan ((double)fp);
}
int foo3 (double fp)
{
return __builtin_isnan (fp);
}
int foo4 (long double fp)
{
return __builtin_isnan (fp);
}
when compiled with -fdump-tree-original using mainline I get:
;; Function foo1 (foo1)
;; enabled by -tree-original
{
return SAVE_EXPR <(double) fp> unord SAVE_EXPR <(double) fp>;
}
;; Function foo2 (foo2)
;; enabled by -tree-original
{
return SAVE_EXPR <(double) fp> unord SAVE_EXPR <(double) fp>;
}
;; Function foo3 (foo3)
;; enabled by -tree-original
{
return fp unord fp;
}
;; Function foo4 (foo4)
;; enabled by -tree-original
{
return fp unord fp;
}
The function foo1 should not have the argument cast to double, but because it's
variadic, the default C promotion rules apply.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-07 19:26 --- The ICE is occurring in the gimplifier; it appears not to handle expressions with type error_mark_node. Either we should not gimplify anything after an error occurs, or it must be made more robust. I'm thinking about whether or not the error itself is valid. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-07 19:26:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug middle-end/32668] New: The type-generic builtins apply default promotions
The type-generic builtins apply the default variadic promotions to their arguments before handing them off to the middle-end for processing. This is bad because e.g. __builtin_isnan(f), where f is a float, gets turned into __builtin_isnan((double)f). In most cases, the cast to double merely becomes a pessimization. However if we use a variadic builtin to implement e.g. isnormal, then casting a float argument to double can take a subnormal float like FLT_MIN/2 and make it a "normal" value because of the extended range of double. See: http://gcc.gnu.org/ml/gcc/2007-07/msg00221.html -- Summary: The type-generic builtins apply default promotions Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug target/31331] [avr] ICE on function attribute syntax for main()
--- Comment #6 from aesok at gcc dot gnu dot org 2007-07-07 19:30 --- Subject: Bug 31331 Author: aesok Date: Sat Jul 7 19:30:37 2007 New Revision: 126446 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126446 Log: PR target/31331 * config/avr/avr.c (avr_naked_function_p): Handle receiving a type rather than a decl. (avr_attribute_table): Make "naked" attribute apply to function types rather than to decls. (avr_handle_fntype_attribute): New function. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #6 from hjl at lucon dot org 2007-07-07 19:35 ---
If I revert
- if (lhsval)
+ if (lhsval && vuse_equiv (lhsval, stmt))
the regression is gone. I suspected that the original code:
if (lhsval)
{
set_value_handle (newt, lhsval);
if (!is_gimple_min_invariant (lhsval))
add_to_value (lhsval, newt);
}
else
{
tree val = vn_lookup_or_add_with_stmt (newt, stmt);
vn_add (lhs, val);
}
doesnt't handle the case of
if (lhsval && !vuse_equiv (lhsval, stmt))
If I change it to
--- tree-ssa-pre.c.bad 2007-07-07 08:18:31.0 -0700
+++ tree-ssa-pre.c 2007-07-07 12:33:51.0 -0700
@@ -3362,7 +3362,8 @@ make_values_for_stmt (tree stmt, basic_b
else
{
tree val = vn_lookup_or_add_with_stmt (newt, stmt);
- vn_add (lhs, val);
+ if (!lhsval)
+ vn_add (lhs, val);
}
add_to_exp_gen (block, newt);
my testcase works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-07-07 19:35 --- I do think that the error is bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug target/31331] [avr] ICE on function attribute syntax for main()
--- Comment #7 from aesok at gcc dot gnu dot org 2007-07-07 19:37 --- Fixed. -- aesok at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug target/31331] [avr] ICE on function attribute syntax for main()
--- Comment #8 from aesok at gcc dot gnu dot org 2007-07-07 19:39 --- Subject: Bug 31331 Author: aesok Date: Sat Jul 7 19:39:36 2007 New Revision: 126447 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126447 Log: PR target/31331 * config/avr/avr.c (avr_naked_function_p): Handle receiving a type rather than a decl. (avr_attribute_table): Make "naked" attribute apply to function types rather than to decls. (avr_handle_fntype_attribute): New function. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-07 20:07 ---
Subject: Re: [4.3 regression]: revision 126369 went into an infinite loop
On 7 Jul 2007 19:35:01 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #6 from hjl at lucon dot org 2007-07-07 19:35 ---
> If I revert
>
> - if (lhsval)
> + if (lhsval && vuse_equiv (lhsval, stmt))
>
> the regression is gone. I suspected that the original code:
>
> if (lhsval)
> {
> set_value_handle (newt, lhsval);
> if (!is_gimple_min_invariant (lhsval))
> add_to_value (lhsval, newt);
> }
> else
> {
> tree val = vn_lookup_or_add_with_stmt (newt, stmt);
> vn_add (lhs, val);
> }
>
> doesnt't handle the case of
>
> if (lhsval && !vuse_equiv (lhsval, stmt))
>
Uh, as it shouldn't.
> If I change it to
>
> --- tree-ssa-pre.c.bad 2007-07-07 08:18:31.0 -0700
> +++ tree-ssa-pre.c 2007-07-07 12:33:51.0 -0700
> @@ -3362,7 +3362,8 @@ make_values_for_stmt (tree stmt, basic_b
> else
> {
> tree val = vn_lookup_or_add_with_stmt (newt, stmt);
> - vn_add (lhs, val);
> + if (!lhsval)
> + vn_add (lhs, val);
> }
>
> add_to_exp_gen (block, newt);
>
> my testcase works.
Only because you are now assigning different value numbers to things
we know to be the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #8 from hjl at lucon dot org 2007-07-07 20:08 ---
I am testing this patch:
--- gcc/tree-ssa-pre.c.bad 2007-07-07 08:18:31.0 -0700
+++ gcc/tree-ssa-pre.c 2007-07-07 12:48:47.0 -0700
@@ -3362,7 +3362,8 @@ make_values_for_stmt (tree stmt, basic_b
else
{
tree val = vn_lookup_or_add_with_stmt (newt, stmt);
- vn_add (lhs, val);
+ if (!lhsval || !VALUE_HANDLE_VUSES (lhsval))
+ vn_add (lhs, val);
}
add_to_exp_gen (block, newt);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #9 from dberlin at gcc dot gnu dot org 2007-07-07 20:09 ---
(In reply to comment #8)
> I am testing this patch:
>
> --- gcc/tree-ssa-pre.c.bad 2007-07-07 08:18:31.0 -0700
> +++ gcc/tree-ssa-pre.c 2007-07-07 12:48:47.0 -0700
> @@ -3362,7 +3362,8 @@ make_values_for_stmt (tree stmt, basic_b
> else
> {
> tree val = vn_lookup_or_add_with_stmt (newt, stmt);
> - vn_add (lhs, val);
> + if (!lhsval || !VALUE_HANDLE_VUSES (lhsval))
> + vn_add (lhs, val);
> }
>
> add_to_exp_gen (block, newt);
>
This patch is completely wrong. Please stop trying to work around the problem
by fixing the symptoms.
I will look at this in a moment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #7 from danglin at gcc dot gnu dot org 2007-07-07 20:30 --- There is some dependency on the pointer plus merge. After the merge, Steve's testcase fails with the stage1 compiler as previously shown. Before the merge, the test doesn't fail. However, the GCC build still fails at the same point. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug middle-end/32668] The type-generic builtins apply default promotions
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-07 20:39 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-07 20:39:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32668
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
22:02 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
The REG_DEAD problem is a red herring. The notes are recomputed
after the sched1 dump.
The real problem is that the argument point register isn't marked
as being alive on entry. On hppa64, the argument pointer isn't a
fixed register, it's not the same as the frame pointer, and it
can't be eliminated.
I'm trying the fix below. However, I think df-scan.c needs fixing.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 126442)
+++ config/pa/pa.c (working copy)
@@ -156,8 +156,8 @@
static enum reg_class pa_secondary_reload (bool, rtx, enum reg_class,
enum machine_mode,
secondary_reload_info *);
+static void pa_extra_live_on_entry (bitmap);
-
/* The following extra sections are only used for SOM. */
static GTY(()) section *som_readonly_data_section;
static GTY(()) section *som_one_only_readonly_data_section;
@@ -313,6 +313,9 @@
#undef TARGET_SECONDARY_RELOAD
#define TARGET_SECONDARY_RELOAD pa_secondary_reload
+#undef TARGET_EXTRA_LIVE_ON_ENTRY
+#define TARGET_EXTRA_LIVE_ON_ENTRY pa_extra_live_on_entry
+
struct gcc_target targetm = TARGET_INITIALIZER;
/* Parse the -mfixed-range= option string. */
@@ -5735,6 +5738,17 @@
return NO_REGS;
}
+/* Implement TARGET_EXTRA_LIVE_ON_ENTRY. The argument pointer
+ isn't a fixed register in the 64-bit runtime and we need to
+ record it as live on entry. */
+
+static void
+pa_extra_live_on_entry (bitmap regs)
+{
+ if (TARGET_64BIT)
+bitmap_set_bit (regs, ARG_POINTER_REGNUM);
+}
+
/* In the 32-bit runtime, arguments larger than eight bytes are passed
by invisible reference. As a GCC extension, we also pass anything
with a zero or variable size by reference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-07-07 22:12 --- Created an attachment (id=13867) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13867&action=view) Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-07-07 22:21 --- I've attached a patch which fixes this bug in an obvious way. Since complex types are arithmetic types in GNU C++, we should allow standard conversions to them from integers, just as we do for all other arithmetic types. However, this runs into problems with libstdc++. In particular, std::complex has a constructor from double and also a constructor from __complex__ double. Making the change in this patch makes that conversion ambiguous because now "std::complex(1)" can go via either the "__complex__ double" constructor or the plain "double" constructor. I'm pretty sure that we did indeed discuss this at some point in the past, although I couldn't find a link and I don't remember what we decided, if anything. The easiest way to fix this is probably to add more constructors to std::complex to match all of the arithmetic types directly, e.g., add "std::complex::complex(int, int = 0)". Then, that will be the best match. I think we need input from the libstdc++ maintainers before trying to do anything in the front end. Paolo? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||pcarlini at suse dot de Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug middle-end/23488] [4.1/4.2/4.3 Regression] GCSE load PRE does not work with non sets (or missing load PRE with plain decls)
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-07-07 22:23 --- Subject: Bug 23488 Author: dberlin Date: Sat Jul 7 22:23:26 2007 New Revision: 126449 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126449 Log: 2007-07-07 Daniel Berlin <[EMAIL PROTECTED]> Revert (note the sccvn portions are *not* reverted) 2007-07-06 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/23488 * tree-vn.c (set_value_handle): Use decl_vh_map for decl value handles. * tree-flow-inline.h (get_value_handle): Ditto. * tree-ssa-pre.c (decl_vh_map): New. (decl_node_pool): New. (can_value_number_operation): Support DECL_P. (can_PRE_operation): Ditto. (create_expression_by_pieces): Ditto. (find_existing_value_expr): Modify to differnetiate between addressing and top level. (create_value_handle_for_expr): Handle DECL's. (poolify_tree): Ditto. (make_values_for_phi): Don't insert into PHI_GEN during FRE. (make_values_for_stmt): Handle DECL's properly. (init_pre): Reorg to not init useless things during FRE. (fini_pre): Ditto. * tree-flow.h: Include pointer-set.h. (decl_vh_map): Declare. * Makefile.in (TREE_FLOW_H): Add pointer-set.h Removed: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-17.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow-inline.h trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-vn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
Re: make exit because build/genmodes.exe doesn't exist
Hi, I note that the above problem has been reported before by others. I am getting the same error message when trying to build gcc and gfortran (v.4.2.0) under cygwin. Has there been any resolution of this problem? Any help would be much appreciated. Dilano Saldin
[Bug c++/32667] builtin operator= generates memcpy with overlapping memory regions
--- Comment #2 from Raimund dot Merkert at baesystems dot com 2007-07-07 22:36 --- This may be an old bug and may have crept in between 3.3.3 and 3.4.0 (latter has it, former doesn't) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #9 from zadeck at naturalbridge dot com 2007-07-07 22:40 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07 > 22:02 --- > Subject: Re: [4.3 Regression] checking for suffix of object files... > configure: error: cannot compute suffix of f objeRO > > The REG_DEAD problem is a red herring. The notes are recomputed > after the sched1 dump. > > The real problem is that the argument point register isn't marked > as being alive on entry. On hppa64, the argument pointer isn't a > fixed register, it's not the same as the frame pointer, and it > can't be eliminated. > > I'm trying the fix below. However, I think df-scan.c needs fixing. > > Dave > suggest a way that we could accommodate this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #8 from pcarlini at suse dot de 2007-07-07 22:44 --- Hi Mark. First, I can point you to C++/21210. In that occasion (see in particular Comment #3) we struggled with the issue quite a bit (if I remember correctly we tried to avoid adding constructors...) then you came up with a "magic" very simple solution! While I study a bit more the present issue maybe you can re-focus that old one... (thanks for involving libstdc++ this time too) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #9 from mark at codesourcery dot com 2007-07-07 22:51 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion pcarlini at suse dot de wrote: > --- Comment #8 from pcarlini at suse dot de 2007-07-07 22:44 --- > Hi Mark. First, I can point you to C++/21210. In that occasion (see in > particular Comment #3) we struggled with the issue quite a bit (if I remember > correctly we tried to avoid adding constructors...) then you came up with a > "magic" very simple solution! While I study a bit more the present issue maybe > you can re-focus that old one... (thanks for involving libstdc++ this time > too) Ah, thanks for finding the old PR. In looking at the mail threads, I fail to find my magic solution. :-( Do you have a pointer to it? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
--- Comment #10 from pcarlini at suse dot de 2007-07-07 22:57 --- (In reply to comment #9) > Ah, thanks for finding the old PR. In looking at the mail threads, I > fail to find my magic solution. :-( Do you have a pointer to it? Well, that PR is *closed as fixed*. Maybe at the time I didn't follow all the details and your eventual fix was only partial, in some sense? Certainly 21210 is closed as fixed and we didn't add any constructor, contrary to some ideas temporarily envisaged in the discussion linked in Comment #3 therein. -- pcarlini at suse dot de changed: What|Removed |Added BugsThisDependsOn|21210 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug fortran/32669] New: "Actual argument contains too few elements for dummy argument" is triggered for valid code
The following piece of code is rejected: program tfe implicit none real ,dimension(1:4) :: x real ,dimension(0:3) :: y real ,dimension(-1:2) :: z call sub(x(:)) call sub(y(:)) call sub(z(:)) contains subroutine sub(a) implicit none real,dimension(1:4) :: a end subroutine sub end program tfe with these error messages: too_few_elements.f90:10.9: call sub(y(:)) 1 Warning: Actual argument contains too few elements for dummy argument 'a' (3/4) at (1) too_few_elements.f90:11.9: call sub(z(:)) 1 Warning: Actual argument contains too few elements for dummy argument 'a' (2/4) at (1) Seems like for arrays with the notation x(:) the actual size is miscomputed if they appear as an argument to a subroutine. Apparently this just happens for arrays whose lower bound is zero or less (y,z), while for positive lower bound everything is fine (x). Also there is no problem if the array is given in the form "y(0:3)" or just "y". The code above is accepted by gcc 4.1 and 4.2, but rejected by recent 4.3 trunk builds. So it seems to be a regression introduced in 4.3. The error messages come from interface.c(compare_actual_formal), line 1608. The size of the actual argument is computed by actual_size = get_expr_storage_size(a->expr); Maybe there is a problem in this routine? -- Summary: "Actual argument contains too few elements for dummy argument" is triggered for valid code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jaydub66 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32669
[Bug fortran/32644] [4.3 Regression] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #6 from patchapp at dberlin dot org 2007-07-07 23:20 --- Subject: Bug number PR32644 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-07/msg00660.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07 23:30 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f obje > suggest a way that we could accommodate this? Prior to reload being completed, I don't see that it matters whether the argument pointer is fixed or not. See df_get_entry_block_def_set(). After reload, I believe that we also need to mark the register in entry_block_defs. There may be refinements to this depending on whether the argument pointer is used or not. This might improve register allocation. The argument pointer is always copied when it isn't fixed. See default_internal_arg_pointer(). For now, I would suggest being conservative. For example, we aren't fussy as to whether argument registers are actually used or not. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug fortran/32644] [4.3 Regression] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-08 00:05 --- Subject: Bug 32644 Author: jvdelisle Date: Sun Jul 8 00:05:27 2007 New Revision: 126450 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126450 Log: 2007-07-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/32644 * decl.c (match_attr_spec): Don't return MATCH_ERROR if comma found and gfc_match_bind_c does not return MATCH_YES. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug fortran/32644] [4.3 Regression] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-08 00:09 --- Subject: Bug 32644 Author: jvdelisle Date: Sun Jul 8 00:09:20 2007 New Revision: 126451 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126451 Log: 2007-07-07 Jerry DeLisle <[EMAIL PROTECTED]> PR fortran/32644 * gfortran.dg/char_decl_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_decl_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug fortran/32644] [4.3 Regression] "CHARACTER*1, c" produces "Unclassifiable statement"
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-07-08 00:10 --- Fixed on trunk. Closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #11 from zadeck at naturalbridge dot com 2007-07-08 00:57 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07 > 23:30 --- > Subject: Re: [4.3 Regression] checking for suffix of object files... > configure: error: cannot compute suffix of f obje > > >> suggest a way that we could accommodate this? >> > > Prior to reload being completed, I don't see that it matters whether > the argument pointer is fixed or not. See df_get_entry_block_def_set(). > After reload, I believe that we also need to mark the register in > entry_block_defs. > Why can't you put something in the prologue that sets the reg and has an unspec as the lhs to make this reg live? I thought that the purpose of the unspecs was to be used in this manner since the unspec does not have actually map to any real insns. > There may be refinements to this depending on whether the argument > pointer is used or not. This might improve register allocation. > The argument pointer is always copied when it isn't fixed. See > default_internal_arg_pointer(). > > For now, I would suggest being conservative. For example, we aren't > fussy as to whether argument registers are actually used or not. > > Dave > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug preprocessor/32670] New: '$' is handled as a part of identifiers in asm
i686-pc-linux-gnu build fails with libtool: link: /exp/ldroot/dodes/i686-gcc-orig/gcc/gcj -B/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/ -B/exp/ldroot/dodes/i686-gcc-orig/gcc/ -ffloat-store -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/.libs -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava ./.libs/libgcj.so -lpthread -lrt -ldl -Wl,-rpath -Wl,/usr/local/lib ./.libs/libgcj.so: undefined reference to `FFI_TYPE_DOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_SINT64' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_LONGDOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_INT' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_FLOAT' on revision 126435. Pinski has pointed out it's because of the patch r126428 | sandra | 2007-07-07 07:10:59 +0900 (Sat, 07 Jul 2007) | 1 line -- Summary: '$' is handled as a part of identifiers in asm Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32670
[Bug fortran/32554] [4.2 Only] Bug in P formatting
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-07-08 02:20 --- Subject: Bug 32554 Author: jvdelisle Date: Sun Jul 8 02:20:10 2007 New Revision: 126456 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126456 Log: 2007-07-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/32554 Backport from trunk. * io/write.c (output_float): Set edigits to a fixed size, avoiding variation in field width calculation and eliminate buffer overrun. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug fortran/32554] [4.2 Only] Bug in P formatting
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-07-08 02:24 --- Subject: Bug 32554 Author: jvdelisle Date: Sun Jul 8 02:24:37 2007 New Revision: 126457 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126457 Log: 2007-07-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/32554 * gfortran.dg/fmt_p_1.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/fmt_p_1.f90 Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32554
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08 02:29 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f objeRO > Why can't you put something in the prologue that sets the reg and has an > unspec as the lhs to make this reg live? I thought that the purpose of > the unspecs was to be used in this manner since the unspec does not have > actually map to any real insns. I believe that's too late. The prologue expansion occurs after the greg pass. The problem is the arg pointer gets used in the greg pass since it isn't alive at entry. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #13 from zadeck at naturalbridge dot com 2007-07-08 02:41 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08 > 02:29 --- > Subject: Re: [4.3 Regression] checking for suffix of object files... > configure: error: cannot compute suffix of f objeRO > > >> Why can't you put something in the prologue that sets the reg and has an >> unspec as the lhs to make this reg live? I thought that the purpose of >> the unspecs was to be used in this manner since the unspec does not have >> actually map to any real insns. >> > > I believe that's too late. The prologue expansion occurs after the > greg pass. The problem is the arg pointer gets used in the greg pass > since it isn't alive at entry. > > Dave > > > why can't you generate a set of a pseudo from an unspec at the top of the function during rtl generation time. (or perhaps at one of the time of one of the expansions) There is nothing magical about the entry block defs except that they are all fixed regs. There really is not a mechanism to support a psuedo, or a varying register there. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
[Bug c++/32671] New: Segment violation
GCC crashed when I was compiling the Wormux game version 0.8alpha1. The GCC report: g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DINSTALL_DATADIR=\"/usr/share/games/wormux\" -DINSTALL_LOCALEDIR=\"/usr/share/locale\" -DFONT_FILE=\"/var/lib/defoma/fontconfig.d/D/DejaVu-Sans.ttf\" -DPACKAGE_VERSION=\"0.8alpha1\" -Werror -Wall -Wextra -Wno-unused-parameter -O2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/libxml++-2.6 -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -c -o xml_document.o `test -f 'tool/xml_document.cpp' || echo './'`tool/xml_document.cpp tool/xml_document.cpp: In static member function static bool LitDocXml::LitInt(const xmlpp::Node*, const std::string&, int&): tool/xml_document.cpp:98: internal compiler error: Violación de segmento Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . The bug is not reproducible, so it is likely a hardware or OS problem. -- Summary: Segment violation Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kmikc dot cvb at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32671
[Bug c++/32671] Segment violation
--- Comment #1 from kmikc dot cvb at gmail dot com 2007-07-08 03:52 --- Created an attachment (id=13868) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13868&action=view) File that contains the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32671
[Bug c++/32671] Segment violation
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 04:02 --- > The bug is not reproducible, so it is likely a hardware or OS problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32671
[Bug middle-end/32398] [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f object files: cannot compile
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08 05:12 --- Subject: Re: [4.3 Regression] checking for suffix of object files... configure: error: cannot compute suffix of f objeRO > There is nothing magical about the entry block defs except that they are > all fixed regs. That's not true for argument registers. > There really is not a mechanism to support a psuedo, or a varying > register there. Before the dataflow merge, the argument pointer was always included in "Registers live at start". I don't really see how an unspec insn helps if there is no mechanism to support a varying argument pointer. I pointed previously to the copy mechanism that handles varying argument pointers in function.c. I don't understand why a varying argument pointer can't be handled. I doubt an unspec by itself is sufficient since I think regrename is affected. The patch that I posted resolves the bootstrap issue but the documentation states that it shouldn't be necessary for various registers including ARG_POINTER_REGNUM. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
