[Bug rtl-optimization/34171] New: [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
With current trunk on Alpha with -O3: (sid)170:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O3 enlightenment-handlers.c enlightenment-handlers.c: In function 'doSignalsSetup': enlightenment-handlers.c:24: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #1 from tbm at cyrius dot com 2007-11-21 09:19 --- Program received signal SIGSEGV, Segmentation fault. df_chain_remove_problem () at gcc/df-problems.c:1948 1948for (use_rec = df_get_artificial_uses (bb-index); *use_rec; use_rec++) (gdb) where #0 df_chain_remove_problem () at gcc/df-problems.c:1948 #1 0x0001201466fc in df_chain_fully_remove_problem () at gcc/df-problems.c:1981 #2 0x00012013e3e8 in df_finish_pass (verify=0 '\0') at gcc/df-core.c:663 #3 0x0001202e3a78 in execute_todo (flags=132097) at gcc/passes.c:1015 #4 0x0001202e4230 in execute_one_pass (pass=0x1208c5e28) at gcc/passes.c:1140 #5 0x0001202e4488 in execute_pass_list (pass=0x1208c5e28) at gcc/passes.c:1171 #6 0x0001202e449c in execute_pass_list (pass=0x1208c25d8) at gcc/passes.c:1172 #7 0x0001203fc414 in tree_rest_of_compilation (fndecl=0x24a6c30) at gcc/tree-optimize.c:404 #8 0x0001205f77c8 in cgraph_expand_function (node=0x23e6500) at gcc/cgraphunit.c:1151 #9 0x0001205fab20 in cgraph_optimize () at gcc/cgraphunit.c:1214 #10 0x00012001ad58 in c_write_global_declarations () at gcc/c-decl.c:8081 #11 0x000120381888 in toplev_main (argc=value optimized out, argv=value optimized out) at gcc/toplev.c:1055 #12 0x0001200afa58 in main (argc=2550688, argv=0x0) at gcc/main.c:35 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #2 from tbm at cyrius dot com 2007-11-21 09:19 --- Created an attachment (id=14588) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14588action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #3 from tbm at cyrius dot com 2007-11-21 09:20 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
extern char coredump;
extern void sigemptyset (char *);
struct sigaction
{
char sa_mask;
};
void doSignalsSetup (void)
{
static const int signals[] = {
1, 2, 3, 4, 6, 8, 11, 13, 14, 15, 30 , 31
};
unsigned int i, sig;
struct sigaction sa;
for (i = 0; i sizeof (signals) / sizeof (int); i++)
{
sig = signals[i];
if (coredump
(sig == 4 || sig == 8 || sig == 11 || sig == 10))
continue;
sigemptyset (sa.sa_mask);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #4 from bonzini at gnu dot org 2007-11-21 09:47 --- Created an attachment (id=14589) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14589action=view) attempt Can you try this patch? I don't have the resources now to build a cross and test it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-21 10:16 --- Subject: Bug 34148 Author: rguenth Date: Wed Nov 21 10:16:21 2007 New Revision: 130329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130329 Log: 2007-11-21 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/34148 * tree-ssa-structalias.c (create_variable_info_for): Do not use field-sensitive PTA for single-element structures. * tree-ssa-alias.c (create_overlap_variables_for): Do not create SFTs for single-element structures. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #8 from huamama at gmail dot com 2007-11-21 10:24 --- Thanks. The complie flag in the Makefile of Busybox is /opt/arm/bin/arm-linux-gcc -I/home/mahua/opt/test/busybox-1.1.3/include -I/home/mahua/opt/test/busybox-1.1.3/include -I/home/mahua/opt/test/busybox-1.1.3/libbb -funsigned-char -Wall -Wstrict-prototypes -Wshadow -Os -funit-at-a-time -fstrict-aliasing -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG -Wl,--warn-common -Wl,--sort-common -Wl,--start-group -Wl,--end-group, I guess it is also the compile flag for file editor/vi.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #6 from ludovic at ludovic-brenta dot org 2007-11-21 10:44 --- I note that this (impressive) patch is not in mainline yet; it seems nobody has reviewed it yet. In the patch, you say: -fstack-check is broken in the 4.x series of compilers in the sense that you cannot recover from a stack overflow condition (for example in Ada). It's a regression from the 3.x series although there were bugs in that series too. Therefore, marking this PR as depending on middle-end/20548. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added BugsThisDependsOn||20548 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug target/34161] -Os produces 32-bit load from 16-bit variable
--- Comment #2 from vegard at peltkore dot net 2007-11-21 11:05 ---
It can trigger watchpoints on other members. Try this example:
struct s {
int dummy;
short x;
short y;
};
void dummy(struct s *b) { }
void f(struct s *a, struct s *b) {
dummy(b);
if (a)
b-x = a-x;
}
static struct s x;
static struct s y;
int
main()
{
f(x, y);
return 0;
}
That code never touches the y member of struct s. Yet when we run this in GDB,
we get this:
(gdb) rwatch x.y
Hardware read watchpoint 1: x.y
(gdb) run
Starting program: .../a.out
Hardware read watchpoint 1: x.y
Value = 0
0x080483c2 in main () at movzwl.c:17
17 b-x = a-x;
And this doesn't really make that much sense unless you know what's going on.
I'd say that following the principle of least surprise, this optimization is
unfortunate at the very least.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #5 from tbm at cyrius dot com 2007-11-21 10:56 --- (In reply to comment #4) Created an attachment (id=14589) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14589action=view) [edit] attempt Can you try this patch? I don't have the resources now to build a cross and test it. Now I'm getting: Program received signal SIGSEGV, Segmentation fault. 0x0001201466d0 in df_chain_remove_problem () at /home/tbm/scratch/gcc/gcc/df-problems.c:1941 1941 struct df_ref **def_rec = df_get_artificial_defs (bb-index); (gdb) where #0 0x0001201466d0 in df_chain_remove_problem () at /home/tbm/scratch/gcc/gcc/df-problems.c:1941 #1 0x0001201469e8 in df_chain_fully_remove_problem () at /home/tbm/scratch/gcc/gcc/df-problems.c:1982 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #9 from ubizjak at gmail dot com 2007-11-21 11:15 --- (In reply to comment #8) Thanks. The complie flag in the Makefile of Busybox is /opt/arm/bin/arm-linux-gcc -I/home/mahua/opt/test/busybox-1.1.3/include -I/home/mahua/opt/test/busybox-1.1.3/include -I/home/mahua/opt/test/busybox-1.1.3/libbb -funsigned-char -Wall -Wstrict-prototypes -Wshadow -Os -funit-at-a-time -fstrict-aliasing -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG -Wl,--warn-common -Wl,--sort-common -Wl,--start-group -Wl,--end-group, I guess it is also the compile flag for file editor/vi.c. Hm, the testcase compiles OK for me using '~/arm-gcc-4.1/gcc/cc1 -funsigned-char -Os -funit-at-a-time -fstrict-aliasing pr34147.i' and gcc version 4.1.3 20070620 (prerelease), Target: arm-elf So the bug is not triggered by these flags. Perhaps the bug is already fixed in current SVN branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug tree-optimization/34172] New: Missed store ccp optimization
#define N 256
struct
{
int x;
int y;
} S[100];
int z[100];
int
foo (int y)
{
int x;
S[5].x = 4;
S[5].y = 0;
x = S[5].x;
return (x);
}
On powerpc64-linux, r130275 with -O2 we get:
(taken from .store_ccp dump file)
foo (y)
{
int x;
bb 2:
S[5].x = 4;
S[5].y = 0;
x_1 = S[5].x;
return x_1;
}
[A patch was submitted
(http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01901.html) which is no longer
relevant because of -http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01370.html.]
--
Summary: Missed store ccp optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34172
[Bug tree-optimization/34148] [4.3 Regression] Too many VOPs, too deep tree-ssa-sccvn.c recursion
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-21 12:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34148
[Bug tree-optimization/34172] Missed store ccp optimization
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-21 12:04 --- Note that only store _copyprop_ was removed for now. But yes, store ccp removal is on the plate. Note that this and similar bugs should be fixed by extending value-numbering to disambiguate memory accesses itself and not only relying on virtual operands. 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-11-21 12:04:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34172
[Bug tree-optimization/34172] Missed store ccp optimization
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34172
[Bug ada/34173] New: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test
gnat.dg/release_unc_maxalign.adb execution test fails for me since 20.11.2007. At 19.11.2007 it whas worked. Compiler version: 4.3.0 20071120 (experimental) (GCC) Platform: i686-pc-linux-gnu configure flags: --enable-languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with-mpfr=/usr/local It fails with r130312 and works with r130286 /home/x/gcc/gcc/testsuite/gnat.dg/dg.exp ... *** glibc detected *** ./release_unc_maxalign.exe: munmap_chunk(): invalid pointer: 0x08061010 *** === Backtrace: = /lib/libc.so.6[0xb7e8d911] ./release_unc_maxalign.exe[0x804aff8] ./release_unc_maxalign.exe[0x804e625] ./release_unc_maxalign.exe[0x8049515] /lib/libc.so.6(__libc_start_main+0xdc)[0xb7e3f87c] ./release_unc_maxalign.exe[0x8049351] === Memory map: 08048000-0805b000 r-xp 08:07 2885527 /data/usr_local/x/gccobj/gcc/testsuite/gnat/release_unc_maxalign.exe 0805b000-0805c000 rw-p 00012000 08:07 2885527 /data/usr_local/x/gccobj/gcc/testsuite/gnat/release_unc_maxalign.exe 0805c000-08082000 rw-p 0805c000 00:00 0 [heap] b7e29000-b7e2a000 rw-p b7e29000 00:00 0 b7e2a000-b7f43000 r-xp 08:06 31145 /lib/libc-2.4.so b7f43000-b7f45000 r--p 00118000 08:06 31145 /lib/libc-2.4.so b7f45000-b7f47000 rw-p 0011a000 08:06 31145 /lib/libc-2.4.so b7f47000-b7f4a000 rw-p b7f47000 00:00 0 b7f65000-b7f71000 r-xp 08:07 2843714 /data/usr_local/x/gccobj/gcc/libgcc_s.so.1 b7f71000-b7f72000 rw-p b000 08:07 2843714 /data/usr_local/x/gccobj/gcc/libgcc_s.so.1 b7f72000-b7f73000 rw-p b7f72000 00:00 0 b7f73000-b7f8d000 r-xp 08:06 31138 /lib/ld-2.4.so b7f8d000-b7f8f000 rw-p 00019000 08:06 31138 /lib/ld-2.4.so bfb2f000-bfb47000 rw-p bfb2f000 00:00 0 [stack] e000-f000 ---p 00:00 0 [vdso] FAIL: gnat.dg/release_unc_maxalign.adb execution test -- Summary: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreasmeier80 at gmx dot de GCC host triplet: i686-pc-linux.gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34173
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-21 12:25
---
The following (doesn't need to be compiled with -fdefault-integer-8):
character (len=5) :: c
integer(kind=8) :: i
i = 3
c(i:i) = 'a'
if (c(i:i) /= 'a') call abort ()
end
gives the tree code below:
integer(kind=4) D.864;
integer(kind=4) D.863;
D.863 = (integer(kind=4)) i;
D.864 = (integer(kind=4)) i;
if (_gfortran_compare_string (MAX_EXPR (1 - D.863) + D.864, 0,
(character(kind=1)[1:5] *) c[D.863]{lb: 1 sz: 1}, 1, a[1]{lb: 1 sz: 1}) !=
0)
_gfortran_abort ();
We simply don't see that D.863 and D.864 are equal, due to the conversion.
--
fxcoudert 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-11-21 12:25:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #7 from manu at gcc dot gnu dot org 2007-11-21 12:34 --- (In reply to comment #5) AdaCore has done it on 7 architectures and is ready to contribute this code, see http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01846.html Why don't you ping directly the relevant maintainers? Otherwise, the patch is going to keep rotting in the patch queue. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug c/34174] New: gcc produces erroneous asm for movdi
Compiling the testcase for BUG #27386 with the fr30-elf crosscompiler
shows that while reloading memory operands to registers the source adress of
the memory operand is changed.
testcase:
typedef unsigned long long uint64_t;
uint64_t a, b, c;
int
foo(uint64_t x, uint64_t y, uint64_t z, int i)
{
a = x;
b = y;
c = z;
return 2 * i;
}
int main( void )
{
return foo(1234512345123ull,
3456734567345ull,
7897897897897ull,
42);
}
Looking at the assembler output which should store argument x in a
ldi:32 a, r3
ldi:8 #248, r1
extsb r1
addnfp, r1
ld @r1, r1
mov r1, r2-- *
addn4, r2
ld @r2, r2
st r1, @r3
st r1, @-r15
mov r3, r1
addn4, r1
st r2, @r1
At the position marked with * the compiler probably wants the adress of a which
was stored in r1 but r1 was changed by the previous ld instruction.
--
Summary: gcc produces erroneous asm for movdi
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus dot heigl at fme dot fujitsu dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: fr30-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug c/34174] gcc produces erroneous asm for movdi
--- Comment #1 from markus dot heigl at fme dot fujitsu dot com 2007-11-21 12:36 --- Created an attachment (id=14590) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14590action=view) The used testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug c/34174] gcc produces erroneous asm for movdi
--- Comment #2 from markus dot heigl at fme dot fujitsu dot com 2007-11-21 12:37 --- Created an attachment (id=14591) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14591action=view) The output asm file with sibling -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #6 from paolo dot bonzini at lu dot unisi dot ch 2007-11-21 12:51 --- Subject: Re: [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha So it means the basic block has been deleted. I want to see what happens if I consolidate all the out_of_date_transfer_functions bitmaps into one. Seongbae, do you remember experimenting with anything like that? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug target/34161] -Os produces 32-bit load from 16-bit variable
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-21 13:06 --- (In reply to comment #2) And this doesn't really make that much sense unless you know what's going on. I'd say that following the principle of least surprise, this optimization is unfortunate at the very least. Users would be surprised if optimized programs perform suboptimal operations when better code is possible. Please, take into account that. Now, what is unfortunate is that the hardware watchpoint triggers there. Perhaps the debug information could tell GDB to ignore the read, or perhaps GDB could figure it out by itself since the data read is never used. I personally don't see a satisfactory way to solve all the issues here. And this bug report is not the proper place. If you think there is a way to satisfy all issues, you can discuss your proposal with the GDB hackers (http://sourceware.org/ml/gdb/). Nonetheless, it seems to me that if a read occurs and the user sets a read watchpoint, then the user should be informed of it. As Richard said, if you don't want the read to occur at all, you can use packed. Also, you must take into account that debugging when optimisation is enabled is always going to be problematic. We aim to produce the most accurate debug information possible in that case, but disabling optimizations would be a contradiction since you could always debug with optimisations disabled if you wish. I hope this answer satisfies you. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34161
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-11-21 12:40 --- Why don't you ping directly the relevant maintainers? Probably because I have other things more interesting to do. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #9 from manu at gcc dot gnu dot org 2007-11-21 13:17 --- (In reply to comment #8) Why don't you ping directly the relevant maintainers? Probably because I have other things more interesting to do. :-) Then I humbly think you should have clearly stated that in your email and asked people interested in the patch to ping the relevant maintainers on your behalf. It is evident that there is a sense of ownership and responsibility with respect to patches and if you don't openly relinquish them, people seem to be reluctant to take the responsibility in their own hands. In short, I think people interested in the patch (and there seem to be a few) would push it if you send it again and prominently manifest that you hope someone will take care of the patch on your behalf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-11-21 13:34 --- Then I humbly think you should have clearly stated that in your email and asked people interested in the patch to ping the relevant maintainers on your behalf. That's what I've sort of done in the second sentence. In short, I think people interested in the patch (and there seem to be a few) would push it if you send it again and prominently manifest that you hope someone will take care of the patch on your behalf. Sorry, I won't have time to do that before 4.3.0 is released. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
--- Comment #11 from manu at gcc dot gnu dot org 2007-11-21 13:45 --- (In reply to comment #10) Then I humbly think you should have clearly stated that in your email and asked people interested in the patch to ping the relevant maintainers on your behalf. That's what I've sort of done in the second sentence. I feel Hopefully it will now spur a little more interest than last time perhaps wasn't understood as ***NOTE: I am NOT going to pursue this patch further, so if you are interested in this, please, feel free to ping the relevant maintainers, update the patch as appropriate and commit it on my behalf. ;-) Sorry, I won't have time to do that before 4.3.0 is released. I think that is ok, it seems a big change for stage3 anyway. I added it to the list of 4.4 pending patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug ada/23487] Assignment from incompatible pointer warning in __gnat_install_handler kills bootstrap
--- Comment #8 from charlet at gcc dot gnu dot org 2007-11-21 13:49 --- closing then. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23487
[Bug fortran/32129] ICE: Procedure call with array-section-actual to scalar dummy
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-21 13:51 --- I think this is valid code. The reduced testcase is: $ cat y.f90 program testCode implicit none type vec real, dimension(1) :: coords end type integer :: i real, dimension(1,1), parameter :: vy = 1. i = 1 call Sub(vec(vy(:,i))) contains subroutine Sub(xin) type(vec) :: xin intent(in) xin print*, xin end subroutine end program $ gfortran y.f90 y.f90: In function testcode: y.f90:9: internal compiler error: in gfc_trans_call, at fortran/trans-stmt.c:321 But it also happens with external functions: $ cat y2.f90 implicit none type vec integer, dimension(1) :: coords end type integer :: i integer, dimension(1,1), parameter :: vy = 0 i = 1 call shape(vec(vy(:,i))) end program $ gfortran y2.f90 y2.f90: In function MAIN__: y2.f90:8: internal compiler error: in gfc_trans_call, at fortran/trans-stmt.c:321 And it's actually a nice area for bugs to creep in: $ cat y3.f90 integer, parameter :: vy(1,1) = 0 type vec integer :: coords(1) end type integer :: i i = 1 print *, shape(vec(vy(:,i))) end program $ gfortran y3.f90 y3.f90: In function MAIN__: y3.f90:7: internal compiler error: Bad IO basetype (1) $ cat y4.f90 implicit none type vec integer, dimension(1) :: coords end type integer :: i integer, dimension(1,1), parameter :: vy = 0 i = 1 print *, shape(vec(vy(:,i))) end program $ gfortran y4.f90 y2.f90: In function MAIN__: y2.f90:8: internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:841 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords|ice-on-invalid-code |ice-on-valid-code Last reconfirmed|2007-05-31 11:57:03 |2007-11-21 13:51:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32129
[Bug fortran/34083] internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-21 13:53
---
It's fixed by the simple patch below:
Index: resolve.c
===
--- resolve.c (revision 130234)
+++ resolve.c (working copy)
@@ -740,6 +740,8 @@ resolve_structure_cons (gfc_expr *expr)
for (; comp; comp = comp-next, cons = cons-next)
{
+ int rank;
+
if (!cons-expr)
continue;
@@ -749,14 +751,14 @@ resolve_structure_cons (gfc_expr *expr)
continue;
}
- if (cons-expr-expr_type != EXPR_NULL
- comp-as comp-as-rank != cons-expr-rank
+ rank = comp-as ? comp-as-rank : 0;
+ if (cons-expr-expr_type != EXPR_NULL rank != cons-expr-rank
(comp-allocatable || cons-expr-rank))
{
gfc_error (The rank of the element in the derived type
constructor at %L does not match that of the
component (%d/%d), cons-expr-where,
-cons-expr-rank, comp-as ? comp-as-rank : 0);
+cons-expr-rank, rank);
t = FAILURE;
}
I'll regtest and submit later this week.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-11-13 15:44:50 |2007-11-21 13:53:53
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34083
[Bug bootstrap/32212] Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory
--- Comment #3 from rask at gcc dot gnu dot org 2007-11-21 14:44 --- Strictly speaking, it is a bug that building in the source tree doesn't work, but IIRC, the instructions on building GCC do mention that building in the source tree doesn't work, and no fix seem likely any time soon. -- rask at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32212
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #12 from jakub at gcc dot gnu dot org 2007-11-21 14:50 --- I disagree with that, it is preferrable to avoid including any headers in testcases if possible. Anyway, I'm testing a fold-const.c optimization which solves this already at the tree level. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-04 21:30:28 |2007-11-21 14:50:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #3 from rask at gcc dot gnu dot org 2007-11-21 15:40 --- Created an attachment (id=14592) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14592action=view) patch v1 for GCC 4.3 Please use -dp when posting asm output because it makes it easier to see what is going on. Please also state the compiler options needed to reproduce the bug. Anyway, confirmed on trunk with revision 130319 with -O0. It is the usual problem of a target which defines movdi patterns when it shouldn't and the fix is to just delete the crap, which the attached patch does. It even saves an instruction. Before (function foo): ... ldi:32 a, r3 ; 13movsi_internal/4[length = 6] ldi:8 #248, r1; 52movsi_internal/1[length = 2] extsb r1 ; 53extendqisi2 [length = 2] addnfp, r1 ; 16addsi_regs [length = 2] ld @r1, r1 ; 74movsi_internal/7[length = 2] mov r1, r2 ; 75movsi_internal/5[length = 2] addn4, r2 ; 76addsi_small_int/1 [length = 2] ld @r2, r2 ; 77movsi_internal/7[length = 2] st r1, @r3 ; 78movsi_internal/6[length = 2] mov r3, r0 ; 79movsi_internal/5[length = 2] addn4, r0 ; 80addsi_small_int/1 [length = 2] st r2, @r0 ; 81movsi_internal/6[length = 2] ... After: ldi:32 a, r3 ; 19movsi_internal/4[length = 6] ldi:8 #248, r1; 77movsi_internal/1[length = 2] extsb r1 ; 78extendqisi2 [length = 2] addnfp, r1 ; 22addsi_regs [length = 2] ld @r1, r2 ; 23movsi_internal/7[length = 2] st r2, @r3 ; 24movsi_internal/6[length = 2] mov r3, r2 ; 82movsi_internal/5[length = 2] addn4, r2 ; 26addsi_small_int/1 [length = 2] addn4, r1 ; 28addsi_small_int/1 [length = 2] ld @r1, r1 ; 29movsi_internal/7[length = 2] st r1, @r2 ; 30movsi_internal/6[length = 2] Please try this patch with GCC 4.2.2. Also, do you happen to know of a simulator for fr30? -- rask at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #13 from jakub at gcc dot gnu dot org 2007-11-21 16:26 --- Created an attachment (id=14593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14593action=view) gcc43-pr29749.patch Patch I'm about to test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #7 from spark at gcc dot gnu dot org 2007-11-21 16:22 --- (In reply to comment #6) Subject: Re: [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha So it means the basic block has been deleted. I want to see what happens if I consolidate all the out_of_date_transfer_functions bitmaps into one. Seongbae, do you remember experimenting with anything like that? Paolo Not really. I agree that it's most likely a bb being deleted though. I guess somebody will have to trace through using a debugger I'll try to build a cross to alpha and see if I can reproduce the problem today. -- spark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug fortran/34175] New: Document when fixed form and when free form source code is assumed
This was asked for on IRC. Add something about the following: .f90, .f95, .f03 (and at some point .f08) and their captial version .F90, .F95, .F03 (and at some point .F08 for Fortran 2008) will default to free-format Fortran. .for, .ftn and .f as well as .F, .FOR, .FTN and .FPP are considered as fixed form. The captial version is run through the C Preprocessor (cpp, sometimes also fpp called) prior compilation; .fpp is run though cpp even though lower cased. Present version: http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-and-GCC.html http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-and-conditional-compilation.html -- Summary: Document when fixed form and when free form source code is assumed Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34175
[Bug tree-optimization/34176] New: [4.3 Regression] SCCVN breaks gettext
The following testcase reduced from gettext does not terminate with FRE
enabled, as that replaces nitems + len2 with len2.
typedef __SIZE_TYPE__ size_t;
typedef unsigned int index_ty;
typedef index_ty *index_list_ty;
struct mult_index
{
index_ty index;
unsigned int count;
};
struct mult_index_list
{
struct mult_index *item;
size_t nitems;
size_t nitems_max;
struct mult_index *item2;
size_t nitems2_max;
};
int __attribute__((noinline))
hash_find_entry (index_list_ty *result)
{
static index_ty x = 2;
*result = x;
return 0;
}
struct mult_index * __attribute__((noinline))
foo (size_t n)
{
return 0;
}
int
main (void)
{
size_t nitems = 0;
for (;;)
{
index_list_ty list;
if (hash_find_entry (list) == 0)
{
size_t len2 = *list;
struct mult_index *destptr;
struct mult_index *dest;
size_t new_max = nitems + len2;
if (new_max != len2)
break;
dest = foo (new_max);
destptr = dest;
while (len2--)
destptr++;
nitems = destptr - dest;
}
}
return 0;
}
--
Summary: [4.3 Regression] SCCVN breaks gettext
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: blocker
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug target/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #5 from dominiq at lps dot ens dot fr 2007-11-21 17:32 --- The bug is not present in PPC OSX 10.5.1 (at least the C code in comment #1, returns -126). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug c++/34166] -fleading-underscore duplicate underscore in some template cases
--- Comment #1 from shockenhull at niceberg dot com 2007-11-21 18:02 --- Created an attachment (id=14598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14598action=view) .ii file that produce error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34166
[Bug inline-asm/34177] Inline assembly uses wrong register
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-21 18:06 --- r25 is not marked as clobbered so what do you expect? Try: asm volatile(mov r25, %0 : =r (RunTsk)::r25); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |inline-asm Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug c/34177] Inline assembly uses wrong register
--- Comment #1 from pete at highdesertsoftware dot net 2007-11-21 17:53 --- Created an attachment (id=14594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14594action=view) Standard out from make -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug c/34177] Inline assembly uses wrong register
--- Comment #3 from pete at highdesertsoftware dot net 2007-11-21 17:54 --- Created an attachment (id=14596) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14596action=view) Preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug testsuite/34168] runtime tests in gfortran.dg/vect fail for unsupported [non-SSE2] targets
--- Comment #2 from ubizjak at gmail dot com 2007-11-21 17:40 --- Changed summary to reflect real cause of failures. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|dg-require-effective-target |runtime tests in |vect_double doesn't work|gfortran.dg/vect fail for ||unsupported [non-SSE2] ||targets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34168
[Bug c/34177] Inline assembly uses wrong register
--- Comment #4 from pete at highdesertsoftware dot net 2007-11-21 17:57 --- Created an attachment (id=14597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14597action=view) Fragment from the lss file This shows a mix is c and assembly showing where the incorrect register is used in the mov statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #8 from steven at gcc dot gnu dot org 2007-11-21 17:47 --- Martin, can you go up to frame #4, and do print *pass in gdb? Thanks. -- steven 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-11-21 17:47:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug c/34177] New: Inline assembly uses wrong register
asm volatile(mov r25, %0 : =r (RunTsk)); Selects the incorrect register for the move. -- Summary: Inline assembly uses wrong register Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pete at highdesertsoftware dot net GCC host triplet: Windows GCC target triplet: AVR (WinAVR) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug c/34177] Inline assembly uses wrong register
--- Comment #2 from pete at highdesertsoftware dot net 2007-11-21 17:53 --- Created an attachment (id=14595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14595action=view) Standard error from make -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug fortran/34162] F2008: Allow internal procedures as actual argument
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-21 18:21 --- Some quotes from comp.lang.fortran to help with the implementation - or at least rise awareness of some problems. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/eaa52a125f022287/ - Steve Lionel writes: - The implementation is indeed not trivial and has to be different on each of the three operating systems we support, but it can be done. Note that the standard does say: NOTE 12.16 This standard does not allow internal procedures to be used as actual arguments, in part to simplify the problem of ensuring that internal procedures with recursive hosts access entities from the correct instance (12.5.2.3) of the host. If, as an extension, a processor allows internal procedures to be used as actual arguments, the correct instance in this case is the instance in which the procedure is supplied as an actual argument, even if the corresponding dummy argument is eventually invoked from a different instance. - Steve Lionel writes then later: On Oct 25, 4:57 pm, glen herrmannsfeldt [EMAIL PROTECTED] wrote: Does it have to be invoked from some instance of the containing procedure? Traditionally, procedure names as actual arguments were represented by the address of the procedure. In this case, they have to also include a reference to the instance, mostly the local variables, of the procedure. It has to be invoked while the containing procedure is active. You can't store it away somewhere and use it later. Once the containing procedure exits, the passed procedure thing becomes undefined (as of course do the local variables of the containing procedure.) A common implementation in the past was to write onto the stack a mini- routine that loads a register with the context (address of a frame pointer, etc.) and then calls the actual procedure. Now that operating systems (and processors) block execution of code from the stack, due to viruses taking advantage of this, other places are needed to store the code, but the concept is usually similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34162
[Bug fortran/13615] -Wuninitialized produces wrong error message for characters
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-21 18:58
---
$ cat z.f
subroutine warn_character(d)
character c, d
d = c
end
$ gfortran -O2 -Wall z.f -c
z.f: In function warn_character:
z.f:3: warning: c[1]{lb: 1 sz: 1} is used uninitialized in this function
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-09-29 08:14:43 |2007-11-21 18:58:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13615
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #14 from rask at gcc dot gnu dot org 2007-11-21 19:11 --- it is preferrable to avoid including any headers in testcases if possible. Yes, but IMHO not at the cost of disabling the test on targets where it is supposed to run and pass. Targets without stdint.h are rare and this sort of optimization really does need to be tested on the 8-bit and 16-bit targets too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #9 from tbm at cyrius dot com 2007-11-21 18:11 ---
(In reply to comment #8)
Martin, can you go up to frame #4, and do print *pass in gdb? Thanks.
You mean in execute_one_pass, right?
Breakpoint 4, execute_one_pass (pass=0x1208c51b8) at gcc/passes.c:1065
1065 current_pass = pass;
(gdb) print *pass
$1 = {name = 0x1207c2e7e useless, gate = 0,
execute = 0x1203a57a0 remove_useless_stmts,
sub = 0x0, next = 0x120896890, static_pass_number = 12,
tv_id = 0, properties_required = 1,
properties_provided = 0, properties_destroyed = 0,
todo_flags_start = 589824,
todo_flags_finish = 1, letter = 0 '\0'}
(gdb)
(gdb) c
Continuing.
Breakpoint 3, execute_one_pass (pass=0x1208c51b8) at gcc/passes.c:1140
1140 execute_todo (todo_after | pass-todo_flags_finish);
(gdb) print *pass
$2 = {name = 0x1207c2e7e useless, gate = 0,
execute = 0x1203a57a0 remove_useless_stmts,
sub = 0x0, next = 0x120896890, static_pass_number = 12,
tv_id = 0, properties_required = 1,
properties_provided = 0, properties_destroyed = 0,
todo_flags_start = 589824,
todo_flags_finish = 1, letter = 0 '\0'}
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug fortran/34083] internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-21 18:32 --- Subject: Bug 34083 Author: fxcoudert Date: Wed Nov 21 18:32:40 2007 New Revision: 130332 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130332 Log: PR fortran/34083 * resolve.c (resolve_structure_cons): Also check for zero rank. * gfortran.dg/derived_constructor_comps_2.f90: Add check. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34083
[Bug fortran/34083] internal compiler error: in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:2819
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-21 18:34 --- Fixed. -- fxcoudert 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=34083
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #10 from steven at gcc dot gnu dot org 2007-11-21 20:02 --- That is useless information. You have a breakpoint on execute_one_pass, which executes the pass list. Look at *pass _at the point of the ICE_. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug c++/34178] New: Compilation using -frepo fails
When compiling the following piece of code with -frepo, linking fails
templatetypename T
class A
{
private:
static int x;
public:
int getX() { return x; }
};
templatetypename T int AT::x=0;
int main()
{
Aint a;
a.getX();
}
g++ -frepo -c -o test.o test.cpp
g++ -o test test.o
collect: recompiling test.cpp
collect: relinking
test.o: In function `Aint::getX()':
test.cpp:(.text+0x4): undefined reference to `Aint::x'
collect2: ld returned 1 exit status
I tested this with an unpatched gcc 4.3.0 20071012 and 4.1.2 with on Gentoo
Linux.
gcc 3.4.6 compiles correctly.
Probably the output of the .rpo-files is interesting:
gcc-3:
M test.cpp
D /home/rbuergel/frepo-test
A '-frepo' '-c' '-o' 'test.o' '-march=i686'
C _ZN1AIiE1xE
O _ZN1AIiE4getXEv
gcc-4:
M test.cpp
D /home/rbuergel/frepo-test
A '-frepo' '-c' '-o' 'test.o' '-shared-libgcc' '-mtune=generic' '-march=i686'
'-frandom-seed=0x63d4762b' '-shared-libgcc'
C _ZN1AIiE4getXEv
gcc-4 gets it right, if x is just declared and defined, but not initialized.
--
Summary: Compilation using -frepo fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34178
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #11 from tbm at cyrius dot com 2007-11-21 20:23 --- (In reply to comment #10) That is useless information. You have a breakpoint on execute_one_pass, which executes the pass list. I thought you said frame 4 and that was execute_one_pass. Anyway, Seongbae Park found the problem in the meantime so I guess he'll add more info soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug inline-asm/34177] Inline assembly uses wrong register
--- Comment #6 from pete at highdesertsoftware dot net 2007-11-21 20:38
---
Subject: Re: Inline assembly uses wrong register
Thank you for your exceptionally fast response. However, adding the
clobber did not help. The problem, I think, is r19 is used as the local
variable RunTsk, yet r24 is what gets moved to r25. I guess I didn't
make clear what the problem was.
Another fagment from the lss file.
if (RunTsk gRunningIdx)
64a:80 91 cc 04 ldsr24, 0x04CC
64e:38 17 cpr19, r24
650:10 f4 brcc.+4 ; 0x656 HDStos_Tick+0x64
{
/* Pass the new thread index in r25 */
asm volatile(movr25, %0 : =r (RunTsk)::r25);
652:98 2f movr25, r24
asm volatile(rjmp hdstos_Switch);
654:87 cf rjmp.-242; 0x564 hdstos_Switch
}
Thanks
-Pete
pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-11-21 18:06
---
r25 is not marked as clobbered so what do you expect?
Try:
asm volatile(mov r25, %0 : =r (RunTsk)::r25);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #12 from spark at gcc dot gnu dot org 2007-11-21 20:40 --- At the end of fwprop2 pass in fwprop_done(), we call cleanup_cfg() and it merges a few blocks, making some bb disappear (in this particular case, bb index 25), which clears the bit in df_chain-out_of_date_transfer_functions. Then, somehow, some of the insns originating from 25 has their bb numbers not reset, and later those insns get the new bb numbers assigned, at which point we call df_insn_change_bb(), which sets the bit for the deleted block on out_of_date_transfer_functions map. Then after fwprop, TODO runs df_finish_pass and we bomb. I'm working on a fix. -- spark at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2007-11-21 17:47:04 |2007-11-21 20:40:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug inline-asm/34177] Inline assembly uses wrong register
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-11-21 20:42 --- Oh you are not storing to RunTsk but to r25 so your constraints are incorrect still. Try: asm volatile(mov r25, %0 : : r (RunTsk):r25); This still makes the bug invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug c/34179] New: ice for legal code
I just tried to compile the Suse Linux package with the GNU C compiler version 4.3 snapshot 20071116 The compiler said options.c:274: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Source code attached. Flag -O3 required. -- Summary: ice for legal code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34179
[Bug c/34179] ice for legal code
--- Comment #1 from dcb314 at hotmail dot com 2007-11-21 21:07 --- Created an attachment (id=14599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14599action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34179
[Bug inline-asm/34177] Inline assembly uses wrong register
--- Comment #8 from pete at highdesertsoftware dot net 2007-11-21 21:01 --- Subject: Re: Inline assembly uses wrong register Thank you so much. That fixed it. Sorry to bother you with user error. It worked in 3.4.6, the last version of WinAVR I installed, that is why I assumed a bug. I've read and re-read about inline assembler and I just don't get it. Is there a place with tons and tons of examples? Thanks again. -Pete pinskia at gcc dot gnu dot org wrote: --- Comment #7 from pinskia at gcc dot gnu dot org 2007-11-21 20:42 --- Oh you are not storing to RunTsk but to r25 so your constraints are incorrect still. Try: asm volatile(mov r25, %0 : : r (RunTsk):r25); This still makes the bug invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34177
[Bug target/34174] gcc produces erroneous asm for movdi
--- Comment #4 from markus dot heigl at fme dot fujitsu dot com 2007-11-21 21:46 --- I will test it tomorrow when I'm at work again. There are simulators available from Greenhills and an Instruction set simulator from Cygnus. But that are both commercial products. Our own IDE Softune Workbench has a simulator builtin but it is written for Windows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34174
[Bug libffi/31937] libffi doesn't support ppc without FPU
--- Comment #5 from andreast at gcc dot gnu dot org 2007-11-21 22:13 --- New patch here: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01128.html -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|andreast at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31937
[Bug libffi/31937] libffi doesn't support ppc without FPU
--- Comment #6 from andreast at gcc dot gnu dot org 2007-11-21 22:14 --- Buh, reassigng. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-02 22:01:59 |2007-11-21 22:14:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31937
[Bug target/34155] [4.3 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:2666 on sh64
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-11-21 22:36 --- I've committed a patch to avoid producing nested VEC_SELECT pattern by the back end in the first place. Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34155
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-21 22:30 --- The patch is semi-wrong. The call to emit_insn_after_noloc() should already set the proper BLOCK_FOR_INSN for every insn. Only doing the df_insn_change_bb() should be sufficient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug target/34155] [4.3 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:2666 on sh64
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-11-21 22:29 --- Subject: Bug 34155 Author: kkojima Date: Wed Nov 21 22:29:04 2007 New Revision: 130335 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130335 Log: PR target/34155 * config/sh/sh.md (binary_sf_op): Remove. (binary_sf_op0, binary_sf_op1): New define_insn_and_split. * config/sh/sh.c (sh_expand_binop_v2sf): Use gen_binary_sf_op0 and gen_binary_sf_op1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34155
[Bug tree-optimization/34179] [4.3 Regression] verify_ssa failed (found real variable when subvariables should have appeared)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-21 22:09 --- ./cc1 -quiet t3.i -O3 -Wfatal-errors t3.i: In function 'setparam': t3.i:4917: error: found real variable when subvariables should have appeared ... looks like a dup of PR34138. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ice for legal code |[4.3 Regression] verify_ssa ||failed (found real variable ||when subvariables should ||have appeared) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34179
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #5 from tbm at cyrius dot com 2007-11-21 22:08 --- Note that Diego had some questions about the patch: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00860.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #13 from spark at gcc dot gnu dot org 2007-11-21 22:08 ---
The following patch seems to fix the problem:
diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c Wed Nov 21 14:07:15 2007 -0800
@@ -2629,6 +2629,7 @@ cfg_layout_merge_blocks (basic_block a,
/* In the case basic blocks are not adjacent, move them around. */
if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
{
+ rtx insn;
rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));
emit_insn_after_noloc (first, BB_END (a), a);
@@ -2637,7 +2638,15 @@ cfg_layout_merge_blocks (basic_block a,
first = NEXT_INSN (first);
gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
BB_HEAD (b) = NULL;
+ insn = NEXT_INSN (first);
delete_insn (first);
+
+ for (; insn != NEXT_INSN (BB_END (b));
+ insn = NEXT_INSN (insn))
+ {
+ set_block_for_insn (insn, a);
+ df_insn_change_bb (insn);
+ }
}
/* Otherwise just re-associate the instructions. */
else
I'm going to stare at the surrounding code a bit more
to convince myself, and will do some testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug c++/34180] New: Default copy constructor copies const auto_ptr members
It is an error to assign or copy a const auto_ptr. g++ should refuse to compile
the following code:
bug.cpp:
#include memory
int main()
{
class A
{
const std::auto_ptrint a;
};
A a;
}
Compiled with:
g++ bug.cpp
This code compiles, incorrectly, on the following version of gcc:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-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.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)
--
Summary: Default copy constructor copies const auto_ptr members
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeidsath at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34180
[Bug target/34141] gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel Darwin9
--- Comment #6 from dominiq at lps dot ens dot fr 2007-11-21 22:42 --- I filled a bug report to Apple: radar #5610291. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #15 from spark at gcc dot gnu dot org 2007-11-21 22:43 ---
(In reply to comment #14)
The patch is semi-wrong. The call to emit_insn_after_noloc() should already
set the proper BLOCK_FOR_INSN for every insn. Only doing the
df_insn_change_bb() should be sufficient.
Thanks Steven. Something like:
diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c Wed Nov 21 14:40:43 2007 -0800
@@ -2629,6 +2629,7 @@ cfg_layout_merge_blocks (basic_block a,
/* In the case basic blocks are not adjacent, move them around. */
if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
{
+ rtx insn;
rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));
emit_insn_after_noloc (first, BB_END (a), a);
@@ -2637,6 +2638,14 @@ cfg_layout_merge_blocks (basic_block a,
first = NEXT_INSN (first);
gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
BB_HEAD (b) = NULL;
+
+ /* emit_insn_after_noloc doesn't call df_insn_change_bb.
+ We need to explicitly call df_insn_change_bb here. */
+ for (insn = NEXT_INSN (first);
+ insn != NEXT_INSN (BB_END (b));
+ insn = NEXT_INSN (insn))
+ df_insn_change_bb (insn);
+
delete_insn (first);
}
/* Otherwise just re-associate the instructions. */
I see bunch of similar loops throughout cfgrtl.c.
I'll see if I should refactor those loops into separate functions
(one with set_block_for_insn and one without).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug c++/34180] Default copy constructor copies const auto_ptr members
--- Comment #1 from jeidsath at gmail dot com 2007-11-21 22:45 ---
I apologize, a line was incorrectly cut from the copy and paste, here is the
full code that should not compile, but does:
#include memory
int main()
{
class A
{
const std::auto_ptrint a;
};
A a;
A b = a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34180
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-21 23:02 --- If you look at what SCCVN does for the affected SCC then you see that iteration converges to Setting value number of dest_7 to dest_7 Setting value number of list_23 to list_23 Value numbering destptr_3 stmt = destptr_3 = PHI dest_7(4), destptr_12(5) Setting value number of destptr_3 to destptr_3 Value numbering destptr.3_13 stmt = destptr.3_13 = (int) destptr_3; Setting value number of destptr.3_13 to destptr.3_13 Value numbering dest.4_14 stmt = dest.4_14 = (int) dest_7; Setting value number of dest.4_14 to destptr.3_13 Value numbering D.1217_15 stmt = D.1217_15 = destptr.3_13 - dest.4_14; RHS destptr.3_13 - dest.4_14 simplified to 0 has constants 1 ... that is, destptr.3_13 == dest.4_14 -- but, in the final run with the correct table in place we get Setting value number of dest_7 to dest_7 Setting value number of list_23 to list_23 Value numbering destptr_3 stmt = destptr_3 = PHI dest_7(4), destptr_12(5) Setting value number of destptr_3 to destptr_3 Value numbering destptr.3_13 stmt = destptr.3_13 = (int) destptr_3; Setting value number of destptr.3_13 to destptr.3_13 Value numbering dest.4_14 stmt = dest.4_14 = (int) dest_7; Setting value number of dest.4_14 to dest.4_14 Value numbering D.1217_15 stmt = D.1217_15 = destptr.3_13 - dest.4_14; Setting value number of D.1217_15 to D.1217_15 increasing the number of iterations doesn't fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug c++/34180] Default copy constructor copies const auto_ptr members
--- Comment #2 from pcarlini at suse dot de 2007-11-21 23:21 ---
I think this is the issue, nothing specific to std::auto_ptr:
struct G { G() { } G(G) { } };
int main()
{
class A
{
const G g;
};
A a;
A b = a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34180
[Bug c++/34180] Default copy constructor copies const auto_ptr members
--- Comment #3 from jeidsath at gmail dot com 2007-11-21 23:52 ---
(In reply to comment #2)
I think this is the issue, nothing specific to std::auto_ptr:
struct G { G() { } G(G) { } };
int main()
{
class A
{
const G g;
};
A a;
A b = a;
}
No, copying of const values is certainly allowed:
const int i = 5;
const int i2 = i; //SHOULD compile
Your struct G can also be created and copied:
G g;
G g2 = g;
However, the same does not work with const auto_ptr, because copying
is a non-const operation for auto_ptrs:
const auto_ptrint i;
const auto_ptrint i2 = i; //ERROR
Did you mean to make the copy constructor private? In that case, G
certainly won't work in my example, const or not, and g++ catches
this.
Now, if you're trying to make a more general example, try this:
#include iostream
struct H
{
H()
{ a=5; } ;
H(H rhs)
{ rhs.a=10; };
int a;
};
int main()
{
struct B
{
const H h;
};
B b;
B b2 = b;
std::cout b.h.a \n;//ERROR prints out 10,
//b.h has been changed despite constness
}
The copy constructor for H does not take a const reference because I
am modelling auto_ptr -- compare gcc's definition of the auto_ptr copy
constructor in memory:
auto_ptr(auto_ptr __a) throw() : _M_ptr(__a.release()) { }
Joel Eidsath
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34180
[Bug c++/34180] Default copy constructor copies const auto_ptr members
--- Comment #4 from pcarlini at suse dot de 2007-11-22 00:10 ---
(In reply to comment #3)
(In reply to comment #2)
I think this is the issue, nothing specific to std::auto_ptr:
struct G { G() { } G(G) { } };
int main()
{
class A
{
const G g;
};
A a;
A b = a;
}
No, copying of const values is certainly allowed:
const int i = 5;
const int i2 = i; //SHOULD compile
Your struct G can also be created and copied:
G g;
G g2 = g;
Of course, and of course. But that has nothing to do with my reduced snippet,
which is equivalent to our standard-conforming implementation of std::auto_ptr,
as far as I can see, and, does compile, whereas it should not - to be clear, I
think you are therefore right, just there is nothing wrong with our
implementation of std::auto_ptr, if anything, this is a front-end issue. By the
way, ICC rejects my reduced snippet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34180
[Bug c++/34180] Default copy constructor copies const auto_ptr members
--- Comment #5 from jeidsath at gmail dot com 2007-11-22 00:24 --- Of course, and of course. But that has nothing to do with my reduced snippet, which is equivalent to our standard-conforming implementation of std::auto_ptr, as far as I can see, and, does compile, whereas it should not - to be clear, I think you are therefore right, just there is nothing wrong with our implementation of std::auto_ptr, if anything, this is a front-end issue. By the way, ICC rejects my reduced snippet. My fault, I see now -- I should have noticed that your copy constructor was a non-const function. I agree that this is a front-end issue. -- jeidsath at gmail dot com changed: What|Removed |Added CC||jeidsath at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34180
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #16 from spark at gcc dot gnu dot org 2007-11-22 00:30 ---
I'm bootstrapping the following patch. This includes some slight refactoring of
set_block_for_insn/df_insn_change_bb loops within cfgrtl.c.
It's mostly cosmetic change on top of the patch on comment #15.
diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c Wed Nov 21 23:48:55 2007 +
@@ -465,23 +465,48 @@ emit_insn_at_entry (rtx insn)
commit_edge_insertions ();
}
-/* Update insns block within BB. */
+/* Update BLOCK_FOR_INSN of insns between BEGIN and END
+ including BEGIN but not END, and notify df of the change.
+ Note that NEXT_INSN (END) has to have a valid value
+ (either NULL or a pointer to a valid insn). */
+
+static void
+update_bb_for_insns (rtx begin, rtx end, basic_block bb)
+{
+ rtx insn;
+
+ for (insn = begin; insn != end; insn = NEXT_INSN (insn))
+{
+ if (!BARRIER_P (insn))
+ {
+ set_block_for_insn (insn, bb);
+ df_insn_change_bb (insn);
+ }
+}
+}
+
+/* Call df_insn_change_bb for insns between BEGIN and END
+ including BEGIN but not END.
+ Note that NEXT_INSN (END) has to have a valid value
+ (either NULL or a pointer to a valid insn). */
+
+static void
+notify_bb_change_for_insns (rtx begin, rtx end)
+{
+ rtx insn;
+
+ for (insn = begin; insn != end; insn = NEXT_INSN (insn))
+if (!BARRIER_P (insn))
+ df_insn_change_bb (insn);
+}
+
+/* Update BLOCK_FOR_INSN of insns in BB to BB,
+ and notify df of the change. */
void
update_bb_for_insn (basic_block bb)
{
- rtx insn;
-
- for (insn = BB_HEAD (bb); ; insn = NEXT_INSN (insn))
-{
- if (!BARRIER_P (insn))
- {
- set_block_for_insn (insn, bb);
- df_insn_change_bb (insn);
- }
- if (insn == BB_END (bb))
- break;
-}
+ update_bb_for_insns (BB_HEAD (bb), NEXT_INSN (BB_END (bb)), bb);
}
/* Return the INSN immediately following the NOTE_INSN_BASIC_BLOCK
@@ -629,16 +654,7 @@ rtl_merge_blocks (basic_block a, basic_b
/* Reassociate the insns of B with A. */
if (!b_empty)
{
- rtx x;
-
- for (x = a_end; x != b_end; x = NEXT_INSN (x))
- {
- set_block_for_insn (x, a);
- df_insn_change_bb (x);
- }
-
- set_block_for_insn (b_end, a);
- df_insn_change_bb (b_end);
+ update_bb_for_insns (a_end, NEXT_INSN (b_end), a);
a_end = b_end;
}
@@ -843,14 +859,9 @@ try_redirect_by_replacing_jump (edge e,
which originally were or were created before jump table are
inside the basic block. */
rtx new_insn = BB_END (src);
- rtx tmp;
-
- for (tmp = NEXT_INSN (BB_END (src)); tmp != barrier;
- tmp = NEXT_INSN (tmp))
- {
- set_block_for_insn (tmp, src);
- df_insn_change_bb (tmp);
- }
+
+ update_bb_for_insns (NEXT_INSN (BB_END (src)),
+ barrier, src);
NEXT_INSN (PREV_INSN (new_insn)) = NEXT_INSN (new_insn);
PREV_INSN (NEXT_INSN (new_insn)) = PREV_INSN (new_insn);
@@ -2637,6 +2648,12 @@ cfg_layout_merge_blocks (basic_block a,
first = NEXT_INSN (first);
gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
BB_HEAD (b) = NULL;
+
+ /* emit_insn_after_noloc doesn't call df_insn_change_bb.
+ We need to explicitly notify. */
+ notify_bb_change_for_insns (NEXT_INSN (first),
+ NEXT_INSN (BB_END (b)));
+
delete_insn (first);
}
/* Otherwise just re-associate the instructions. */
@@ -2644,13 +2661,8 @@ cfg_layout_merge_blocks (basic_block a,
{
rtx insn;
- for (insn = BB_HEAD (b);
- insn != NEXT_INSN (BB_END (b));
- insn = NEXT_INSN (insn))
- {
- set_block_for_insn (insn, a);
- df_insn_change_bb (insn);
- }
+ update_bb_for_insns (BB_HEAD (b),
+ NEXT_INSN (BB_END (b)), a);
insn = BB_HEAD (b);
/* Skip possible DELETED_LABEL insn. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #10 from huamama at gmail dot com 2007-11-22 01:38 --- hi, I also build the toolchains in linux, and when compile busybox using the same configuration, no compile error will shown. And only when i build the toolchains in cygwin, when compile the busybox using the same configuration, error will shown. aslo, in cygwin, if CONFIG_BUILD_AT_ONCE=y is not selected, when compile vi.c , no error will shown, but if CONFIG_BUILD_AT_ONCE=y is selected, when compile vi.c, error will shown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
Why you do not write? I Pamela mvfpwaqtrrme
http://zq-h.nm.ru 5999$ mnothly! raqyvwpfzen
[Bug tree-optimization/34147] internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:936
--- Comment #11 from huamama at gmail dot com 2007-11-22 01:51 --- Below is the CONFIG_BUILD_AT_ONCE in busybox is detailed in configuration file of buysbox, Does that mean in cygwin, maybe the ram is less than 300M, so when compile all the busybox, some unexpected internal compiler error will shown. I think the vi.c is ok with compile, because if i select only vi and some other fewer package in busybox configuration, the compile is also fine, but if more packages are selected, an error will shown, sometime is segmentation fault in vi.c, sometime is internal compiler error: in set_iv, at tree-ssa-loop-ivopts.c:. Is that something wrong if compile many things using gcc an error will shown? Thanks. config CONFIG_BUILD_AT_ONCE bool Compile all sources at once default n help Normally each source-file is compiled with one invocation of the compiler. If you set this option, all sources are compiled at once. This gives the compiler more opportunities to optimize which can result in smaller and/or faster binaries. Setting this option will consume alot of memory, e.g. if you enable all applets with all features, gcc uses more than 300MB RAM during compilation of busybox. This option is most likely only beneficial for newer compilers such as gcc-4.1 and above. Say 'N' unless you know what you are doing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34147
[Bug tree-optimization/34181] New: FAIL: g++.dg/opt/anchor1.C (internal compiler error)
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/a
nchor1.C -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/
include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libst
dc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/l
ibstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fm
essage-length=0 -O2 -fno-show-column
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux
11.11/./libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./l
ibstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libiberty
-lm -o ./anchor1.exe(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/anchor1.C: In member function 'void
Y
Font::_ZTv0_n12_N5YFontD1Ev()':
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/anchor1.C:59: internal compiler
error
: in optimize_inline_calls, at tree-inline.c:2914
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/anchor1.C: In member function 'void
Y
Font::_ZTv0_n12_N5YFontD1Ev()':
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/anchor1.C:59: internal compiler
error
: in optimize_inline_calls, at tree-inline.c:2914
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
FAIL: g++.dg/opt/anchor1.C (internal compiler error)
FAIL: g++.dg/opt/anchor1.C (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/anchor1.C:59: internal compiler
error
: in optimize_inline_calls, at tree-inline.c:2914
WARNING: g++.dg/opt/anchor1.C compilation failed to produce executable
(gdb) p *e
$3 = {caller = 0x7aeaa280, callee = 0x7ac96200, prev_caller = 0x0,
next_caller = 0x0, prev_callee = 0x0, next_callee = 0x0,
call_stmt = 0x7aeafe38, aux = 0x0, inline_failed = 0x0, count = 0,
frequency = 0, loop_nest = 0}
(gdb) bt
#0 optimize_inline_calls (fn=0x7ae78af0) at ../../gcc/gcc/tree-inline.c:2914
#1 0x004b9174 in cgraph_early_inlining () at ../../gcc/gcc/ipa-inline.c:1469
#2 0x00385410 in execute_one_pass (pass=0x400a3228)
at ../../gcc/gcc/passes.c:1118
...
--
Summary: FAIL: g++.dg/opt/anchor1.C (internal compiler error)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa2.0w-hp-hpux11.11
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34181
[Bug testsuite/34182] New: FAIL: g++.dg/other/datasec1.C (test for excess errors)
FAIL: g++.dg/other/datasec1.C (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/datasec1.C:1: warning: -fdata-secti ons not supported for this target -- Summary: FAIL: g++.dg/other/datasec1.C (test for excess errors) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34182
[Bug testsuite/34183] New: FAIL: g++.dg/other/first-global.C scan-assembler _GLOBAL__I_foobar
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/test/gnu/ gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/other /first-global.C -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstd c++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.1 1/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gc c/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/u til -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -fno-show-column -S -o first-global.s(timeout = 300) PASS: g++.dg/other/first-global.C (test for excess errors) FAIL: g++.dg/other/first-global.C scan-assembler _GLOBAL__I_foobar -- Summary: FAIL: g++.dg/other/first-global.C scan-assembler _GLOBAL__I_foobar Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34183
[Bug target/34091] [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:392
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-11-22
03:12 ---
Subject: Re: New: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands,
at postreload.c:392
paer% gcc-4.2 -c -O s_texfilter.i
swrast/s_texfilter.c: In function âsample_lambda_2dâ:
swrast/s_texfilter.c:1420: error: insn does not satisfy its constraints:
(insn 2621 1258 1259 96 (set (mem/c:HI (plus:SI (reg/f:SI 30 %r30)
(const_int -474 [0xfe26])) [0 S2 A16])
(reg:HI 68 %fr22)) 53 {*pa.md:3126} (nil)
(nil))
swrast/s_texfilter.c:1420: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
The simplest fix is probably not to allow QImode and HImode values
in the floating point registers as there's no instructions that operate
on them.
I have implemented this, but it doesn't fix the problem. There
are problems in the backend handling spills for floating floating point
instructions. The issue has been around for a long time and never
resolved completely. It's papered over by register copies to
the general registers, and usually we don't get into trouble since
the architecture has quite a few registers.
I made an initial stab at fixing this by tightening up GO_IF_LEGITIMATE_ADDRESS
but I have run into problems with pseudos not being allocated hard registers.
This probably means I don't have the change quite right. I also have a
problem with paradoxical SUBREGS when the inner register is spilled. I'm
not clear on how this is to be handled on a big endian target with strict
alignment. The documentation says reload is supposed to prevent this from
happening, but it doesn't seem to. I see this with the testcase from this
PR. It's combine that creates the paradoxical SUBREG. Tracing back
why reload doesn't allocate a hard register is tough...
I'm going to try another approach. Use a lax definition for
GO_IF_LEGITIMATE_ADDRESS and try to fix things up using pa_secondary_reload.
I view this as a critical target bug. However, if we find a fix, I
don't think it should be applied to 4.2 and earlier since it's very likely
to break something else.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34091
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #2 from matz at gcc dot gnu dot org 2007-11-22 04:26 --- The problem starts already in the first iteration: Value numbering destptr_3 stmt = destptr_3 = PHI dest_9(6), destptr_14(7) Setting value number of destptr_3 to dest_9 So, for now we assume dest_9 == destptr_3, quite okay, lets assume so. Next statement: Value numbering destptr.2_15 stmt = destptr.2_15 = (int) destptr_3; Setting value number of destptr.2_15 to destptr.2_15 Looks innocent, but what this actually does is entering the RHS ((int)destptr_3) into the unary hash-table, but with translated (!) ssa names, ergo it enters (int)dest_9 into the hashtable, as having destptr.2_15 as value. I.e. (int)dest_9 == destptr.2_15. From there on everything breaks apart, because nobody is ever removing this association from the hash-table. So, from then on, whenever we are going to process this insn: Value numbering dest.3_16 stmt = dest.3_16 = (int) dest_9; Setting value number of dest.3_16 to destptr.2_15 We are looking up (int)dest_9 in the unary hash-table, find it, see it's associated value destptr.2_15 in there and happily use it. Even in the later iterations where the initial dest_9 == destptr_3 association isn't generated anymore. But the hashtable still contains the (then invalid) RHS (int)dest_9. So, during the optimistic iterations we come to a fix point, but a completely wrong one. In particular we still (wrongly) think that nitems_19 is zero. As the valid_info only iterates once over the SCC this isn't enough to fix the problem. It has a clean hash-table again, so the above breakage isn't reintroduced, but as it started with wrong info it still is wrong afterwards (in particular when it sees that nitems_19 is not zero it won't reiterate). This can be worked around with also iterating until nothing changes with the new hash table (with valid_info). That's obviously not what is wanted, so there has to be a way to either cleanup the hashtable after iterations (this also doesn't seem to be designed in this way), or to not enter information into the hash tables which might become invalid in later iterations. The reason for inserting the translated expressions into the hash table obviously is for optimization purposes (so that we are sure we have a canonical version in it), but this canonicalization needs to happen when looking up the hash table, not when _inserting_ into it, as canonicalization is transient and changes from iteration to iteration. Proof of concept patch fixing only the unary case (and hence this particular bug) comes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #3 from matz at gcc dot gnu dot org 2007-11-22 04:31 --- Created an attachment (id=14600) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14600action=view) incomplete fix Concept patch touching only the unary case. binary, phi nodes and maybe references would need something similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-11-22 04:48 --- Subject: Re: [4.3 Regression] SCCVN breaks gettext On 22 Nov 2007 04:26:57 -, matz at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from matz at gcc dot gnu dot org 2007-11-22 04:26 --- The problem starts already in the first iteration: Value numbering destptr_3 stmt = destptr_3 = PHI dest_9(6), destptr_14(7) Setting value number of destptr_3 to dest_9 So, for now we assume dest_9 == destptr_3, quite okay, lets assume so. Next statement: Value numbering destptr.2_15 stmt = destptr.2_15 = (int) destptr_3; Setting value number of destptr.2_15 to destptr.2_15 Looks innocent, but what this actually does is entering the RHS ((int)destptr_3) into the unary hash-table, but with translated (!) ssa names, Right, but this is the optimistic set of hash tables, so that is okay. At the end of SCC iteration, it is okay to keep optimistic assumptions in the optimistic table, even if they turned out to be wrong. However, at the end of SCC iteration, SSA_VAL should always be correct for everything. ergo it enters (int)dest_9 into the hashtable, as having destptr.2_15 as value. I.e. (int)dest_9 == destptr.2_15. From there on everything breaks apart, because nobody is ever removing this association from the hash-table. In particular we still (wrongly) think that nitems_19 is zero. I don't see where above it has set nitems_19 to zero. This can be worked around with also iterating until nothing changes with the new hash table (with valid_info). That's obviously not what is wanted, There should be no need, as the fixpoint iteration of the optimistc table should eventually end up with the values you want to insert into the valid table. That's in fact, the whole point. so there has to be a way to either cleanup the hashtable after iterations (this also doesn't seem to be designed in this way), Again, it's okay for the optimistic assumptions to remain in the table, and in fact, is designed for it to happen. The paper goes into why this is so. information into the hash tables which might become invalid in later iterations. No, this is also okay. Again, it is fine for the optimistic hashtable to have invalid info. It is not okay for SSA_VAL to end up with invalid value numbers at the end of iteration. | version in it), but this canonicalization needs to happen when looking up the hash table, not when _inserting_ into it, as canonicalization is transient and changes from iteration to iteration. Again, this isn't right. The paper goes into detail as to why it is okay for the optimistic talbe to behave this way, and why it is okay to do algebraic simplification/etc on insert. The real problem seems to me, at least unless you guys haven't pasted that part of the trace, that nitems_19 isn't part of the SCC but should be. By the time iteration of the SCC finishes, we should have discovered that nitems_19 does not have the value 0. The one in a real compiler I have of SCCVN both do canonicalization on insert, as does the original code from Rice's massively scalar compiler (which is where the algorithm comes from). Maybe we aren't traversing uses in function arguments during DFS walk? Given the code size_t new_max = nitems + len2; if (new_max != len2) break; dest = foo (new_max); destptr = dest; while (len2--) destptr++; nitems = destptr - dest; the SCC we get should consist of destptr, dest, nitems, len2, and new_max I could see if we were not DFS walking the argument to foo for some reason, we would never get new_max/nitems/len2 into the SCC. --Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug c++/34184] New: Scope broken for inherited members inside template class?
The following code fails to compile
this.cpp: In member function 'int fooT::baz::foo()':
this.cpp:8: error: 'i' was not declared in this scope
// begin this.cpp
template class T
struct foo {
struct bar {
int i;
};
struct baz : bar {
int foo() { return i; }
};
};
int main() { }
// end this.cpp
Changing it to 'this-val' solves the problem, but is unwieldy for classes with
lots of members. I'm unsure what the Standard says, but I thought you only
needed 'this-' when the member depends on information the compiler won't have
until template instantiation time. However, that doesn't really apply here --
foo and bar do not depend on the template's type, so the compiler should be
able to figure things out well before the template gets instantiated.
FWIW Sun's CC accepts the code with no warnings. It's usually much more strict
than gcc (to the point of being really frustrating). Even if the Standard says
gcc is right, it would be very convenient if gcc matched CC on this
extension.
--
Summary: Scope broken for inherited members inside template
class?
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34184
[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha
--- Comment #17 from steven at gcc dot gnu dot org 2007-11-22 07:06 --- I'd say s/update_bb_for_insns/update_bb_for_insn_chain/ And it doesn't hurt to set BLOCK_FOR_INSN, so now that the code is factored to new functions, I'd also say s/notify_bb_change_for_insns/update_bb_for_insn_chain/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171
[Bug tree-optimization/34176] [4.3 Regression] SCCVN breaks gettext
--- Comment #5 from steven at gcc dot gnu dot org 2007-11-22 07:10 --- The one in a real compiler I have of SCCVN both do canonicalization on insert, as does the original code from Rice's massively scalar compiler (which is where the algorithm comes from). The one? real compiler? both? Parse error! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34176
[Bug tree-optimization/34179] [4.3 Regression] verify_ssa failed (found real variable when subvariables should have appeared)
--- Comment #3 from tbm at gcc dot gnu dot org 2007-11-22 07:32 --- It's the same. *** This bug has been marked as a duplicate of 34138 *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34179
[Bug tree-optimization/34138] [4.3 Regression] verify_ssa failed (found real variable when subvariables should have appeared)
--- Comment #4 from tbm at gcc dot gnu dot org 2007-11-22 07:32 --- *** Bug 34179 has been marked as a duplicate of this bug. *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34138
